Отчет о НИР - Разумные решения
advertisement
ОБЩЕСТВО С ОГРАНИЧЕННОЙ ОТВЕТСТВЕННОСТЬЮ «НПК «РАЗУМНЫЕ РЕШЕНИЯ» (ООО «НПК «РАЗУМНЫЕ РЕШЕНИЯ») УДК 004.942 № госрегистрации: 01201179187 Инв. № 005 МОН УТВЕРЖДАЮ Генеральный директор ООО "НПК "Разумные решения" А.В. Царев 10.08.2012 г. ОТЧЕТ О НАУЧНО-ИССЛЕДОВАТЕЛЬСКОЙ РАБОТЕ Разработка и исследование прототипа интеллектуальной системы для согласованного адаптивного планирования и связанного изменения планов движения поездов для минимизации отклонения высокоскоростных поездов класса «Сапсан» от графика движения под влиянием непредвиденных внешних событий по теме: ОБОБЩЕНИЕ И ОЦЕНКА РЕЗУЛЬТАТОВ ИССЛЕДОВАНИЙ (заключительный, этап №3) ГК от «17» октября 2011 г. №07.514.11.4094 Шифр: 2011-1.4-514-125-063 Руководитель НИОКР, директор по разработкам ООО "НПК "Разумные решения" П.О. Скобелев 10.08.2012 г. Нормоконтроль, директор по общим вопросам ООО "НПК "Разумные решения" А.Н. Мочалкин 10.08.2012 г. Самара 2012 2 РЕФЕРАТ Отчет 346 с., 78 рис., 26 табл., 3 прил., 34 источника МУЛЬТИАГЕНТНЫЕ СИСТЕМЫ, ОНТОЛОГИИ, РЕДАКТОР ОНТОЛОГИИ, РЕДАКТОР СЦЕН, СЕТЕЦЕНТРИЧЕСКИЕ СЕТИ, ДИНАМИЧЕСКОЕ ПЛАНИРОВАНИЕ, ВЫСОКОСКОРОСТНОЙ ПОЕЗД КЛАССА «САПСАН», РАСПИСАНИЕ ДВИЖЕНИЯ ПОЕЗДОВ Объектом исследования является процесс адаптивного планирования движения поездов для минимизации отклонения высокоскоростных поездов класса «Сапсан» от графика движения под влиянием непредвиденных внешних условий. Целью выполнения научно-исследовательской работы является повышение эффективности перепланирования расписаний высокоскоростных поездов при возникновении незапланированных событий в реальном времени путем автоматизации динамического планирования с использованием мультиагентных технологий и сетецентрического подхода. Данная работа основана на методах управления сложными системами, выполнена с использованием мультиагентных технологий, методов построения и управления онтологиями. В основе работы лежит сетецентрический подход к созданию программного комплекса нового класса, функционирующего как р2р сеть взаимодействующих интеллектуальных систем (система систем) для согласованного управления высокоприоритетными и низкоприоритетными поездами в реальном времени. В результате выполнения НИР были достигнуты следующие результаты: а) произведена программная реализация разработанных методов в виде экспериментального образца сетецентрической системы планирования, обеспечивающей согласованную работу двух модулей планирования; б) выполнен анализ полученных результатов и подготовлены рекомендации по дальнейшему развитию подхода и созданию промышленной версии системы для ее внедрения в эксплуатационную работу ОАО «РЖД»; в) проведены дополнительные патентные исследования в соответствии с ГОСТ Р 15.011-96; г) проведена технико-экономическая оценка рыночного потенциала полученных результатов; д) разработан проект ТЗ на проведение ОКР по рассматриваемой теме; 3 е) разработана программная документация на экспериментальный образец; ж) реализованы мероприятия по достижению значения программных индикаторов и показателей; и) разработан заключительный отчет о НИР; к) подготовлена и оформлена отчетная документация в соответствии с требованиями технического задания и актов Заказчика. Основные конструктивные, технологические и технико-эксплуатационные характеристики: обеспечение оперативной реакции на непредвиденные события и обеспечение минимизации отклонения ВСП «Сапсан» от графика движения за счет адаптивного управления ЖД ресурсами. Степень внедрения: экспериментальный образец. Рекомендации по внедрению: дальнейшее развитие сетецентрического подхода и создание промышленной версии системы для экспериментального использования в ОАО «РЖД». Область применения: подразделения ОАО «РЖД». Эффективность: сокращение времени на принятие управленческих решений при перепланировании графика движения поездов. Прогнозные предположения о развитии объекта исследования: полученные результаты могут быть использованы для построения и функционирования интеграционной платформы комплексной автоматизации планирования ресурсов РЖД. 4 СОДЕРЖАНИЕ НОРМАТИВНЫЕ ССЫЛКИ ...........................................................................................................10 НОРМОКОНТРОЛЬ .........................................................................................................................11 ОПРЕДЕЛЕНИЯ ...............................................................................................................................12 ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ ..............................................................................................14 ВВЕДЕНИЕ .......................................................................................................................................15 1 ЭТАП 1. ВЫБОР НАПРАВЛЕНИЯ ИССЛЕДОВАНИЙ. ТЕОРЕТИЧЕСКИЕ ИССЛЕДОВАНИЯ ПОСТАВЛЕННЫХ ПЕРЕД НИР ЗАДАЧ ...............................................17 1.1 Аналитический обзор современной научно-технической, нормативной, методической литературы, затрагивающей научно-техническую проблему, исследуемую в рамках НИР ........................................................................................................17 1.1.1 Анализ современных тенденций в области повышения эффективности управления ресурсами организаций в реальном времени...................................................17 1.1.2 Анализ современных компьютерных методов и средств повышения эффективности использования ресурсов организаций........................................................23 1.1.3 Анализ основных особенностей и перспектив применения мультиагентных технологий для повышения эффективности распределения, планирования и оптимизации ресурсов в реальном времени .............................................28 1.1.4 Анализ основных особенностей и перспектив технологии представления и обработки знаний для поддержки процессов согласованного принятия решений при управлении ресурсами организаций ..................32 1.1.5 Тенденции развития и применение информационных технологий в области обеспечения железнодорожного движения............................................................36 1.1.6 Выводы и предложения по результатам проведенных анализа и исследований ...........................................................................................................................38 1.2 Теоретические исследования и анализ задачи управления пассажирскими перевозками, а также управления высокоскоростным транспортом......................................39 1.2.1 Анализ задачи управления пассажирскими перевозками высокоскоростным транспортом ...........................................................................................39 1.2.2 Особенности инфраструктуры РЖД ...........................................................................42 1.2.3 Анализ возможности применения мультиагентного подхода для адаптивного планирования и динамического управления расписанием для 5 минимизации отклонения от графика высокоскоростного железнодорожного транспорта................................................................................................................................50 1.2.4 Выводы и предложения по результатам проведенных анализа и исследований ...........................................................................................................................53 1.3 Анализ задачи адаптивного планирования и динамического управления расписанием для минимизации отклонения от графика высокоскоростного железнодорожного транспорта ...................................................................................................54 1.4 Анализ современного состояния методов и средств динамического планирования подвижных объектов применительно к инфраструктуре РЖД в реальном времени ........................................................................................................................54 1.5 Разработка программного мультиагентного подхода к построению процессов управления ЖД ресурсами .......................................................................................55 1.5.1 Разработка формализованных моделей индивидуального планирования ключевых ресурсов инфраструктуры РЖД .................................................55 1.5.2 Разработка метода согласованного адаптивного управления расписанием движения поездов на основе мультиагентного подхода. Разработка логики агентов активных сущностей предметной области, позволяющих реализовать полный цикл реакции на события, планирование и исполнение планов в реальном времени ...........................................................................61 1.5.3 Описание мира агентов ................................................................................................64 1.5.4 Примеры разрешения конфликтных ситуаций ..........................................................66 1.5.5 Разработка структуры данных и алгоритмов принятия решений, а также протоколов проведения переговоров агентами в ходе динамического планирования ресурсов, включая выявление конфликтов, согласованную подвижку и перераспределение операций во времени ........................................................67 1.5.6 Разработка моделей взаимодействий агентов, позволяющих осуществлять взаимные уступки во имя общей цели системы ..........................................96 1.5.7 Алгоритмы разрешения конфликтов при резервировании блокучастков за счет изменения скорости движения и длительности остановок ..................100 1.5.8 Алгоритм разрешения конфликтов по всему расписанию .....................................103 1.5.9 Выводы и предложения по результатам проведенных анализа и исследований .........................................................................................................................104 6 1.6 Разработка принципов построения сетецентрических интеллектуальных систем для согласованного планирования ресурсов РЖД, способных к согласованному коллективному взаимодействию в реальном времени, на основе баз знаний и мультиагентных технологий ..............................................................................104 1.6.1 Выводы и предложения по результатам проведенных анализа и исследований .........................................................................................................................110 1.7 Разработка программной модели ......................................................................................110 1.7.1 Разработка спецификации требований к программной модели управления движением поездов ..........................................................................................110 1.7.2 Разработка бизнес-модели и модели вариантов использования системы ..................................................................................................................................111 1.7.3 Характеристика объекта автоматизации ..................................................................113 1.7.4 KPI’s системы .............................................................................................................115 1.7.5 Выводы и предложения по результатам проведенных анализа и исследований .........................................................................................................................116 1.8 Разработка экспериментального образца системы, позволяющего осуществлять адаптивное динамическое планирование в рамках одного модуля планирования .............................................................................................................................116 1.8.1 Описание структуры и принципов работы модуля планирования ........................116 1.8.2 Интерфейсы, примеры интерфейсов, реализованных на основе алгоритма разрешения конфликтов по всему расписанию ...............................................124 1.8.3 Выводы и предложения по результатам проведенных анализа и исследований .........................................................................................................................129 2 ЭТАП 2. ЭКСПЕРИМЕНТАЛЬНЫЕ ИССЛЕДОВАНИЯ ПОСТАВЛЕННЫХ ПЕРЕД НИР ЗАДАЧ ..................................................................................................................130 2.1 Разработка частного технического задания на создание экспериментального образца по ГОСТ 34.602-89. .....................................................................................................130 2.2 Разработка структуры онтологии инфраструктуры РЖД, включая базовые классы, концепты, отношения, свойства и атрибуты инфраструктуры РЖД, используемые в процессе планирования, для настройки на конкретные примеры применения .................................................................................................................................130 2.2.1 Онтологический подход к описанию знаний предметной области .......................130 2.2.2 Онтологический базис, способы представления онтологии ..................................135 2.2.3 Структура онтологии инфраструктуры РЖД ..........................................................139 7 2.3 Разработка принципов создания и редактирования онтологий и сцен, содержащих оперативную информацию о ситуации на участке направления, в виде семантических сетей .........................................................................................................153 2.4 Разработка методов и средств редактирования сцен для решения задач управления ресурсами на участке направления .....................................................................154 2.5 Разработка архитектуры распределённой адаптивной р2р сети системы для согласованного планирования объектов инфраструктуры РЖД. .........................................158 2.6 Описание архитектуры решения через взаимодействие планировщиков разных уровней ..........................................................................................................................162 2.7 Разработка компонентов адаптивной р2р платформы для автоматизации планирования ресурсов РЖД ....................................................................................................171 2.8 Разработка средств для обеспечения возможности двустороннего непрерывного человеко-машинного диалога системы с лицами, принимающими решения .......................................................................................................................................173 2.9 Разработка методов интеграционной платформы, обеспечивающей взаимодействие частей системы...............................................................................................179 2.10Разработка программы и методики экспериментальных исследований .......................180 2.11Онтологическая настройка ЭО на предметную область для проведения исследований и экспериментов ................................................................................................181 2.11.1 Принцип создания онтологии. ..................................................................................182 2.11.2 Принцип редактирования онтологий........................................................................182 2.11.3 Принцип редактирования сцен..................................................................................183 2.11.4 Общий пример редактирования онтологии и сцены с конкретной ситуацией на участке направления......................................................................................183 2.12Проведение экспериментальных исследований. Оформление актов и протоколов экспериментальных исследований ......................................................................185 3 ЭТАП 3. ОБОБЩЕНИЕ И ОЦЕНКА РЕЗУЛЬТАТОВ ИССЛЕДОВАНИЙ ........................186 3.1 Программная реализация разработанных методов в виде ЭО сетецентрической системы планирования, обеспечивающей согласованную работу двух модулей .................................................................................................................186 3.1.1 Описание сетецентрического подхода при планировании .....................................186 3.1.2 Принцип работы .........................................................................................................187 3.1.3 Входные и выходные данные ....................................................................................189 3.1.4 Развитие .......................................................................................................................190 8 3.2 Анализ полученных результатов и подготовка рекомендаций по дальнейшему развитию подхода и созданию промышленной версии системы для ее внедрения в эксплуатационную работу ОАО «РЖД» .......................................................190 3.2.1 Сетецентрический подход к управлению сложными системами ..........................191 3.2.2 Интеграционная платформа ......................................................................................192 3.3 Проведение технико-экономической оценки рыночно-экономической оценки рыночного потенциала полученных результатов ......................................................195 3.3.1 Направления применения сетецентрических разработок .......................................195 3.3.2 Возможности использования результатов НИР для решения других задач 199 3.3.3 Вариант использования сетецентрической системы на основе разработанной архитектуры .................................................................................................200 3.3.4 Вывод о созданной архитектуре сетецентрической системы ................................204 3.3.5 Варианты использования сетецентрических систем с разработкой новой архитектуры системы ................................................................................................205 ЗАКЛЮЧЕНИЕ...............................................................................................................................210 СПИСОК ИСПОЛЬЗУЕМЫХ ИСТОЧНИКОВ ..........................................................................213 ПРИЛОЖЕНИЕ 1 ОТЧЕТ О ПАТЕНТНЫХ ИССЛЕДОВАНИЯХ .........................................217 ПРИЛОЖЕНИЕ 2 ОТЧЕТ О ДОПОЛНИТЕЛЬНЫХ ПАТЕНТНЫХ ИССЛЕДОВАНИЯХ..................................................................................................................273 ПРИЛОЖЕНИЕ 3 ТЕХНИЧЕСКОЕ ЗАДАНИЕ НА ОКР ..........................................................325 9 НОРМАТИВНЫЕ ССЫЛКИ В настоящем отчёте о НИР использованы ссылки на следующие стандарты: 1) ГОСТ 7.32–2001 Система стандартов по информации, библиотечному и издательскому делу. Отчет о научно-исследовательской работе. Структура и правила оформления. 2) ГОСТ 7.9–95 Система стандартов по информации, библиотечному и издательскому делу. Реферат и аннотация. Общие требования. 3) ГОСТ 2.125-88 Единая система конструкторской документации. Правила выполнения эскизных конструкторских документов. 4) ГОСТ 15.101-98 Система разработки и постановки продукции на производство. Порядок выполнения научно-исследовательских работ 5) «Инструкция по разработке графика движения поездов в ОАО "РЖД"». Утверждена распоряжением ОАО "РЖД" от 27.12.2006 N 2568р 6) ТЕХНИЧЕСКИЙ РЕГЛАМЕНТ ТС «О безопасности высокоскоростного железнодорожного транспорта» (ТР ТС 002/2011). Утвержден Решением Комиссии Таможенного союза от 15 июля 2011 года N 710 7) «Инструктивные указания по организации вагонопотоков на железных дорогах ОАО «РЖД». Утверждены 16 октября 2006 г. 10 НОРМОКОНТРОЛЬ В соответствии с требованиями п.п. 3.4 ГОСТ 7.32-2001 - о необходимости обязательного нормоконтроля отчета о НИР в организации-исполнителе, руководствуясь ГОСТ 2.111, был проведен нормоконтроль документации ответственным Мочалкиным А.Н. 11 ОПРЕДЕЛЕНИЯ В настоящем отчёте о НИР использованы следующие определения: Агент Автономный программный объект, способный анализировать ситуацию, принимать решения, коммуницировать с другими агентами, вести переговоры друг с другом для разрешения возникающих конфликтов и затем информировать систему и пользователя о результатах своих действий. В процессе переговоров и принятия решений программные агенты пользуются знаниями, хранящимися в онтологии. Высокоскоростной поезд класса Высокоскоростной электропоезд (из семейства электро- «Сапсан» поездов Velaro производства компании Siemens AG), приобретённый ОАО «РЖД» для эксплуатации на российских скоростных железных дорогах. Графический интерфейс поль- Система средств для взаимодействия пользователя с зователя (GUI-интерфейс) компьютером, основанная на представлении всех доступных пользователю системных объектов и функций в виде графических компонентов экрана (окон, значков, меню, вкладок, кнопок, списков, текстовых полей и т.п.). При этом пользователь имеет произвольный доступ ко всем видимым экранным объектам (с помощью клавиатуры или устройства координатного ввода типа «мышь»). Диаграмма Гантта Ленточная диаграмма, используемая для графической иллюстрации плана работ и представляющая собой отрезки, размещенные на горизонтальной временной шкале. Динамическое планирование Метод, позволяющий изменять план работы системы в масштабе реального времени. Отличие от инкрементного планирования заключается в том, что в динамическом планировании используется не просто обычное распределение работ по интервалам на временной шкале, но и поддерживается возможность разрешать кон12 фликтные ситуации путём внесения в план работ различного рода изменений, таких как перемещение, замена или прекращение операции. Знания Закономерности некой предметной области (принципы, связи, способы взаимодействия), полученные в результате практической деятельности и профессионального опыта, позволяющие моделировать бизнес-процессы в некоторой предметной области и решать задачи в этой области. Мультиагентные технологии Интегрируют последние достижения информационных технологий и программирования, методов и средств искусственного интеллекта, распределённых информационных систем и компьютерных сетей, в основе которых лежит понятие интеллектуального программного агента. С помощью мультиагентных технологий взаимодействие объектов реального мира моделируется переговорами их программных агентов, где настраиваемый программный агент человека действует в системе от имени и по поручению своего владельца, представляет его интересы во взаимодействии с органами исполнительной власти для наилучшей реализации его потребностей и возможностей. Расписание Последовательность выполнения запланированных задач (событий мероприятий) по времени. KPI Ключевые показатели эффективности Performance Indicators, KPI) (англ. Key система оценки, которая помогает определить достижение стратегических и тактических (операционных) целей и сравнить получающиеся результаты. 13 ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ В настоящем отчёте о НИР применяют следующие термины, обозначения и сокращения с соответствующими определениями: АБ – автоблокировка БЗ – база знаний ВСП – высокоскоростной поезд ДК – диспетчерский контроль ЖД – железная дорога ИКТ – информационно-коммуникационные технологии ИСИ – инструкция по сигнализации на железных дорогах РФ МАС – мультиагентная (многоагентная) система МАТ – мультиагентные технологии НИР – научно-исследовательская работа РЖД – российские железные дороги СБЦ – средства сигнализации, централизации и блокировки ТРА – техническо-распорядительный акт ФЦНТП – Федеральная целевая научно-техническая программа ЭО – Экспериментальный образец 14 ВВЕДЕНИЕ Целью выполнения научно-исследовательской работы является повышение эффективности планирования движения поездов для минимизации отклонения высокоскоростных поездов класса «Сапсан» от графика движения под влиянием непредвиденных внешних событий путем разработки интеллектуальной системы с использованием мультиагентных технологий. Для решения поставленной задачи предлагается развитие сетецентрического подхода к созданию программного комплекса нового класса, функционирующего как р2р сеть взаимодействующих интеллектуальных систем (система систем) для согласованного управления высокоприоритетными и низкоприоритетными поездами в реальном времени. Цели работ: разработка частного технического задания на создание экспериментального образца, разработка структуры онтологии РЖД, включая базовые классы, концепты, отношения, свойства и атрибуты, используемые в процессе планирования, разработка принципов создания и редактирования онтологий и принципов создания и редактирования сцен, содержащих оперативную информацию о ситуации на участке направления, разработка методов и средств редактирования онтологий и сцен в виде редакторов, разработка архитектуры и компонентов распределённой адаптивной р2р сети системы для согласованного планирования объектов инфраструктуры РЖД, разработка средств для обеспечения возможности двустороннего непрерывного человеко-машинного диалога системы с лицами, принимающими решения, разработка методов интеграционной платформы, обеспечивающей взаимодействие частей системы, разработка программы и методики экспериментальных исследований. Основанием выполнения работ является решение Конкурсной комиссии Министерства Образования и Науки Российской Федерации 2011-1.4-ИР2 (протокол от 27.09.2011 г. в рамках лота №3 «Проведение проблемно-ориентированных поисковых исследований в области информационно-телекоммуникационных систем для решения задач Технологической платформы «Высокоскоростной интеллектуальный железнодорожный транспорт» по теме «Разработка и исследование прототипа интеллектуальной системы для согласованного адаптивного планирования и связанного изменения планов движения поездов для минимизации отклонения высокоскоростных поездов класса «Сапсан» от графика движения под влиянием непредвиденных внешних событий» (шифр «2011-1.4-514-125-063»), выполняемой в рамках Федеральной целевой научно-технической программы (ФЦНТП) «Исследования и разработки по приоритетным направлениям развития научно-технологического комплекса России на 2007–2012 годы» (мероприятие 1.4 Программы (IX очередь) «Проведение проблемно15 ориентированных поисковых исследований и создание научно-технического задела в области информационно-коммуникационных систем») по государственному контракту от 17 октября 2011 г. № 07.514.11.4094, заключённому между Федеральным агентством по науке и инновациям и Научно-производственной компанией «Разумные решения». Обоснованием необходимости проведения НИР является высокая сложность решения этой задачи, что обусловлено наличием множества факторов, которые требуется учитывать при планировании, множества участников с зачастую конфликтными интересами, разнообразием критериев принятия решений, тесными взаимосвязями между отдельными подразделениями и этапами решения задач, неопределенностью и динамикой процессов и рядом других факторов. Результатом третьего этапа НИР является завершенная программная реализация разработанных методов в виде экспериментального образца сетецентрической системы планирования, обеспечивающей согласованную работу двух модулей планирования, а также анализ полученных результатов и рекомендации по дальнейшему развитию подхода для создания промышленной версии системы для ее внедрения в эксплуатационную работу ОАО «РЖД». Наименования этапов: 1. Выбор направления исследований. Теоретические исследования поставленных перед НИР задач, инв. №02201261619 2. Экспериментальные исследования №02201261618 16 поставленных перед НИР задач, инв. 1 ЭТАП 1. ВЫБОР НАПРАВЛЕНИЯ ИССЛЕДОВАНИЙ. ТЕОРЕТИЧЕСКИЕ ИССЛЕДОВАНИЯ ПОСТАВЛЕННЫХ ПЕРЕД НИР ЗАДАЧ 1.1 Аналитический обзор современной научно-технической, нормативной, методической литературы, затрагивающей научнотехническую проблему, исследуемую в рамках НИР Обзор современной научно-технической, нормативно-технической, методической документации и других материалов проводился по двум основным направлениям: а) использование мультиагентных технологий в области повышения эффективности управления ресурсами; б) использование компьютерных систем поддержки принятия решений для оперативного управления (в том числе высокоскоростным железнодорожным транспортом). 1.1.1 Анализ современных тенденций в области повышения эффективности управления ресурсами организаций в реальном времени Колоссальные изменения, происходящие в сфере управления крупными организациями и предприятиями, во многом связывают с переходом к так называемому постиндустриальному или информационному обществу, чертами которого является: а) более популярной организационной структурой становится сетевая организация (сеть), а не иерархия. Сеть малых организаций (отделов, систем или объектов) гораздо более адаптивны и чувствительны к изменениям, чем сложные бюрократические структуры; б) доминирующей методологией развития становится самоорганизация (как движение снизу-вверх, кооперация малых простейших объектов) и эволюция; в) преобладающий уровень информационного обмена – глобальный, а не региональный или местный. Организации, не имеющие доступа к глобальным внешним ресурсам, а также постоянному мониторингу внутренних процессов в рамках информационной сети, не могут контролировать крупные структуры. Эти тенденции начинают диктовать требования к структурной организации крупных компаний, в которых на первый план выходят механизмы самоорганизации, базирующиеся 17 на накоплении и использовании знаний о проблемных ситуациях, методах и средствах решения задач, так и к программным системам, которые используются в этих предприятиях для поддержки процессов принятия решений. Как показывает практика эффективного управления предприятиями [2], все большее число компаний стремится реформировать сферу управления и отказаться от принципа «идеальной бюрократической структуры», предпочитая переходить от громоздких иерархий, жестко формализованных и централизованных структур к сетевым структурам из небольших и вполне самостоятельных частей, который показывают большую интеллектуальность, гибкость, надежность, подвижность, способность чутко и динамично реагировать на изменения. В этой связи в последнее время в литературе появился целый спектр новых названий форм организации предприятий, к числу которых можно отнести так называемые «новые», «предприятия ХХI века», «сетевые», «интеллектуальные», «виртуальные» и т.д. Однако, эти названия, так или иначе, отражают характерные свойства холистической организации или предприятия. В сфере управления холизм предполагает, что предприятие организовано из относительно автономных частей, каждая из которых может, в идеале, представлять собой самостоятельное предприятие. Эти части могут декомпозироваться до уровня отдельных подразделений (например, аналитическое, ремонтное, обслуживающее) или вплоть до людей в организации, каждый из которых может быть также рассмотрен как автономное «предприятие» нижнего уровня. При таком подходе основным вопросом встает организация знаний, протоколов взаимодействия и организация отдельных частей таким образом, чтобы они взаимно усиливались, т.е. наблюдался синергетический эффект. Ответом на данную задачу является умелое внедрение принципов самоорганизации, позволяющих подразделениям внутри организации создавать «вложенные», возможно временные «организации» (коллективы), позволяющие быть открытыми к изменениям, адаптивно и гибко решать появляющиеся задачи. Такие предприятия можно называть холоническими, состоящими из холонов (от лат. «holos» – целое и «on» – частица), автономно и самостоятельно принимающими решения, но обязанными согласовывать эти решения с другими холонами. Гибко и динамично взаимодействуя на внутреннем рынке организации, холоны способны формировать новые организации или команды, необходимые для решения поставленных задач в условиях априорной неопределенности и высокой динамики изменений в среде. Таким образом, перспективные направления реформ в управлении современными предприятиями связаны с холистическим (целостным) подходом и переходом от замкнутых функционально-ориентированных подразделений в рамках централизованных иерархических 18 структур с жесткими связями - к открытым автономным сетевым организациям (холонам), формирующим децентрализованные сетевые структуры с гибкими связями, устанавливаемыми и пересматриваемыми по мере необходимости. Холоническое предприятие может быть построено и как гетерархическая сеть, допускающая временные иерархии. В частности, «холоны» могут представлять отдельные подразделения, структурные единицы или группы людей как временные коллективы сотрудников предприятия. При этом важно, чтобы предприятие содержало внутренний «рынок взаимдействия», где все подразделения, вплоть до отдельных сотрудников могут конкурировать или кооперироваться между собой на основе динамически устанавливаемых прямых договорных отношений. В настоящее время существует большое количество научных и прикладных работ в области организации поддержки принятия решений по управлению ресурсами организаций. Работа [3] посвящена синтезу систем управления взаимодействием производственноэкономических структур на основе моделей конфликтно-устойчивых решений. Важно, что в данных работах учитывается, что появление сети Интернет привело к созданию глобальной информационной инфраструктуры, принципиально изменяя тем самым роль информации в экономической деятельности, а также отмечается целесообразность организации в структуре производственно-экономической системы информационно-аналитической подсистемы, которая должна обеспечить упорядоченное накопление, научное обоснованное обобщение и анализ сведений по различным направлениям и их защиту с выделением определяющих факторов и на этой основе – выработку предложений по дальнейшему развитию и разрешению возникших на рынке ситуаций. По мнению авторов, такая подсистема может быть реализована с использованием современных информационных технологий, позволяя обеспечить интеллектуальную поддержку принятия решений. Важно отметить, что работах по данной тематике отмечается специфическая роль конфликтов во взаимодействии участников процесса принятия решений. Указывается, что конфликты представляют собой не только и не столько негативное противоборство социальных и природных сил, сколько системные многоплановые явления, феноменологию которых можно выразить аспектами: специфический способ взаимодействия двух и более систем; динамическое явление, в котором будущее не входит составной частью в прошлое; регулирующая часть самоорганизации систем, обусловливающая неустойчивый, нелинейный, необратимый характер процессов их развития и взаимодействия со средой. На основе этой идеи в указанных в данном разделе работах формализована системная модель ресурсного взаимодействия субъектов внутреннего рынка предприятия, учитываю19 щая многообразие и конфликтный характер отношений между ними, разработан комплекс математических моделей, имитирующих динамику ресурсного взаимодействия субъектов с инвариантными свойствами к предмету исследования, и созданы алгоритмы принятия решения и оценки эффективности обеспечения конфликтно-устойчивого ресурсного взаимодействия субъектов в логико-лингвистическом и структурно-параметрическом представлении. Труды [4, 5] посвящены разработке методологии управления процессами развития больших систем управления с использованием авиационной и космической информации. В качестве объекта исследования здесь выбраны большие системы административноорганизационного управления, являющие собой множество переменного во времени состава разнородных субъектов различного уровня иерархии, распределенных на территории больших пространств и объединенных административными и/или экономическими связями в единое целое, каждый из которых, либо самостоятельно, либо во взаимодействии с другими субъектами решает определенную для него часть известной совокупности задач данной системы. В этих работах отмечается, что в составе больших систем административноорганизационного управления имеется множество субъектов, которые предназначены для решения одной и той же совокупности задач. Различными для данных субъектов являются внешние условия, в которых они функционируют, а также техническое обеспечение пользователей и технологии выполнения работ, в том числе их математическое обеспечение. Далее в этих работах предлагается формирование программ развития больших систем административно-организационного управления с целью обеспечения соответствия рассматриваемой системы стоящим перед ней задачам. Интересно, что приводятся разные схемы построения программ развития, различающиеся схемами центров принятия решений. В целом, можно отметить, что наиболее современные и перспективные разработки в данной области связаны с поиском аналогии с природными системами. В силу сложности создания детерминированных алгоритмов и систем управления при решении разнообразных проблем по управлению ресурсами, современные исследователи пробуют применять модели, в основе которых лежат аналоги самоорганизующихся природных систем, что позволяет по-новому взглянуть на задачу управления эволюционным развитием сложной системы и выработать механизмы косвенного влияния на это развитие. В работах [6, 7] отмечается, что традиционные централизованные системы управления теряют гибкость, необходимую в соответствии с современными требованиями конфигуриуемости и адаптивности. Предлагаемая парадигма холонических производственных систем (HMS) нацелена на удовлетворение этих требований и основана на построении системы управления компаниями на основе подходов, наследуемых от живых систем. Этот подход 20 дает альтернативную возможность построения адаптивных систем управления, где традиционное централизованное управление заменяется распределением принятия решений между автономными сущностями, организованными в иерархические структуры. В результате появляется эффект самоорганизации, благодаря которому удается получить новые свойства систем управления производством. В указанных работах затрагиваются такие проблемы управления сложными производственными системами, как нелинейность процессов, возможность проявления хаоса, неопределенность принятия решений, в связи с чем, отмечается сложность построения эффективных систем управления. В работах предлагается эту сложность не устранять и не избегать, а путем проведения аналогий с большими социальными и биологическими системами управлять эмерджентным поведением производственных систем. Для этого в эмерджентном поведении выделяется два уровня: макро-уровень, на котором система управления рассматривается как единое целое и микро-уровень, на котором система рассматривается как совокупность компонентов, связанных между собой взаимодействием. В результате большого количества этих взаимодействий локальных компонентов система получает некоторое собственное поведение на макро- уровне, в котором присутствует как эмерджентное поведение, которым можно управлять, так и случайные составляющие. В такое среде интеллект образуется на основе координации взаимодействия компонентов системы, но задается не путем задания встроенной жесткой и заранее предопределенной на все случаи жизни логики принятия решений. Развитие такой системы также видится эволюционным – причем эволюция здесь определяется как процесс изменения, то есть развития, реформирования или роста через поколения, который ведет к появлению более совершенной или сложной формы. Процесс эволюции организационно-технической системы рассматривается как реконфигурация распределенной сети сущностей – компонентов этой сложной системы, отраженный в появлении, изменении или исчезновении сущностей, а также в установлении, изменении и устранении связей между ними. Отмечается, что в идеале такое реконфигурирование должно производиться «на лету», без остановки деятельности системы. Также в этом контексте следует отметить работу [8]. Здесь также отмечается необходимость обеспечения адаптивности и гибкости систем управления производством за счет применения парадигмы холонических мультиагентных систем. При этом в качестве одной из ключевых проблем, возникающих при решении этой задачи, выделяется организация эффективного взаимодействия между автономными агентами. Организация холонов в системе позволяет обеспечить конфигурируемость, требуемую для обеспечения эволюционного развития системы. Отмечается, что холоны могут быть до21 бавлены, изменены или удалены «на лету» без того, чтобы останавливать или изменять функционирование других холонов или системы в целом. Таким образом, обеспечивается робастность системы, в первую очередь в смысле устойчивости ее поведения к внешним изменениям. В то же время отмечается необходимость обеспечения достоверности получаемой информации и существенное влияние неточных или неверных сведений на устойчивость работы системы. Также в этой работе затрагивается вопрос автономности и кооперации. Кооперация определяется как процесс совместных действий, направленный на достижение общих целей или целей системы. Кооперация приводит к необходимости объединения участников в группы и другие структуры. При этом агенты, обладающие свойством автономности в процессе кооперации могут, как достигать собственные цели, так и изменять их, в основном посредством смены приоритетов текущих задач и ограничений. В связи с этим отмечается необходимость обеспечения гармонии между устойчивостью, кооперацией и автономностью в мультиагентной системе. Много автономности у агентов приводит к высокой адаптивности, но возможной нестабильности работы системы благодаря низкому уровню устойчивости и кооперации. Ограниченная автономность в свою очередь влияет на способность системы адаптироваться к внешним изменениям. Отметим, что изложенные положения требуют дополнения. В разные моменты жизни мультиагентной системы вполне целесообразно динамически изменять баланс между этими параметрами, причем определять необходимость таких изменений требуется также динамически, на основе анализа результатов мониторинга показателей эффективности, характеризующих способность системы к адаптации. В работе [9] указывается, что понимание того, как функционируют сложные системы в реальной природе, позволяет копировать некоторые их свойства при разработке мощных адаптивных и эволюционирующих организационно-технических систем. В основном, данная работа посвящена созданию гибких производственных систем в соответствии с принципами организации систем в живой природе. В последнее время для обеспечения таких востребованных характеристик как модульность, робастность, гибкость и способность к самоорганизации разработано несколько подходов, в частности мультиагентные технологии, холонические производственные системы и бионические производственные системы. Отмечается, что, несмотря на существенные различия, эти парадигмы объединяет общая точка зрения на производственную систему как на распределенную, автономную и адаптивную сложную систему. В описываемой работе дается обзор теорий биологии, которые вдохновляют на разработку новых методов и технологий, описываются примеры применения этих технологий в 22 практических приложениях, указываются возможные проблемы, связанные с применением данного подхода и приводятся примеры реализации этого подхода с помощью мультиагентных технологий. Подчеркивается, что все эти подходы поддерживают реконфигурируемость организационно-технической системы, однако при их реализации часто эта возможность искусственно ограничивается. Это весьма важно в контексте данной работы, так как позволяет сделать вывод о том, что весьма актуальна разработка специализированных подходов к построению и отслеживанию развития такого рода систем, что позволило бы разработчикам программного обеспечения больше внимания уделять вопросам поддержки функциональности, обеспечивающей формирование эмерджентного интеллекта. 1.1.2 Анализ современных компьютерных методов и средств повышения эффективности использования ресурсов организаций Все большее число современных предприятий сталкивается с необходимостью решения задачи оптимального планирования ресурсов в реальном времени. При этом в первую очередь речь идет о предприятиях, располагающих значительным количеством неоднородных единиц ресурсов, одновременно находящихся в работе, выполняющих десятки тысяч операций в день, причем в заранее неизвестные моменты времени, оперирующих на значительных территориях, часто в национальном масштабе, и стремящихся удовлетворить самые разнообразные требования. Для таких компаний решение указанной задачи становится критически важным, поскольку без использования автоматизированных систем управления и планирования ресурсов эти предприятия просто не могут успешно развиваться, решать стоящие перед ними задачи, быть эффективными и конкурентоспособными. Для решения указанной задачи необходимы новые методы, алгоритмы и программные средства, которые бы позволяли гибко создавать и адаптировать планы и расписания в реальном времени. Гибкость предполагает здесь оперативную автоматическую реакцию на непредвиденные события (например проведение незапланированных ремонтных работ; авария на каком-то участке дороги, разнообразные отказы инфраструктуры ЖД). При этом, особенная сложность заключается в том, что все непредвиденные события необходимо учитывать с условием минимализации отклонения движения поездов от запланированного графика. Большая часть классических подходов предполагает, что весь пул заказов (планов по грузо и пассажиропотоку) и ресурсов (имеющихся доступных составов, инфраструктуре 23 движения, планов выполнения ремонтных работ и пр.), а также ограничений известен заранее. Поэтому задача формирования расписания сводится к созданию статичного графика. При это внесение изменений в него требует значительных трудозатрат. Реальные события, сопровождающие исполнение графика всегда подвержены случайным отклонениям, которые характеризуются высокой неопределенностью и которые нельзя спрогнозировать. Следовательно, необходим интеллектуальный инструмент, позволяющий адаптировать первоначальный план к новым событиям. При этом каждое событие должно активировать обработку соответствующих заказов и ресурсов, вызывая цепочку операций перепланирования, глубина которой может быть ограничена допустимым временем ответа или другими факторами. В то же время, если имеется запас времени, расписание может подвергаться непрерывной оптимизации или, в общем случае, балансировке интересов всех участников, поскольку каждый заказ или ресурс может иметь собственную специфическую систему критериев, предпочтений и ограничений. При этом, если строить решения на базе автоматических планировщиков, предлагаемых такими крупными компаниями, как SAP, Oracle, Manugistics, i2, ILOG и ряде других, реализующих различные методы Constraint programming и базирующихся на комбинаторном переборе вариантов в глубину, например, метод ветвей и границ [см. обширный справочник по алгоритмам планирования - Handbook of Scheduling: Algorithms, Models and Performance Analysis. Edited by J. Y-T. Leung // Chapman & Hall / CRC Computer and Information Science Series. – 2005] то можно столкнуться с серьезной проблемой выражающейся в невозможности быстрой реакции на вновь поступающие события. Для сокращения перебора, решения данной проблемы, при планировании можно применить различные эвристики и мета-эвристики (под «эвристикой» обычно понимается набор правил, определяющих какая альтернатива является лучшей, а под «метаэвристикой» - стратегия выбора эвристик), позволяющие обеспечивать хорошие решения за разумное время, сокращая перебор и делая его более направленным. К числу наиболее известных эвристик можно отнести «жадные» методы, в которых решения принимаются последовательно путем выбора на каждом шаге лучшей из альтернатив, при этом однажды принятое решение никогда не пересматривается. Более сложными являются специализированные методы локальной оптимизации, где некоторым образом полученное начальное приближение улучшается различными локальными изменениями. Если хорошее решение не достигнуто, может генерироваться некоторое новое начальное приближение, и процесс повторяется. К числу наиболее известных мета-эвристик можно отнести Simple Local Search Based Meta-heuristics (SLSBM) – мета-эвристики локальной оптимизации (со случайным выбором 24 кандидата из списка лучших, с заглядыванием вперед или рандомизацией критериев и т.д.). Еще одна получившая в последнее время развитие мета-эвристика Simulated Annealing (моделирование процесса остывания) является расширением методов локальной оптимизации, в котором формируются «разбегающиеся» зависимые решения и на каждом шаге разрешается принимать не только лучшие решения, но и некоторые ухудшающие решения с вероятностью, вычисляемой как функция от некоторого управляющего параметра, аналога температуры. Идеей, получающей сейчас все большее и большее распространение, является использование истории методов локальной оптимизации (Tabu Search), когда на некоторые уже исследованные варианты налагается запрет (табу), и потому они не рассматриваются на следующем шаге. Еще одна новая мета-эвристика – Ant Search, в которой моделируется поведение муравьев, добывающих пищу. Интересно, что и многие другие мета-эвристики также наследуют физические или биологические концепции, например, Adaptive Memory Programming – использование общей памяти решений. В ряде случаев исследователи применяют смешанные мета-эвристики Miscellaneous, в которых, например, действуют несколько параллельных алгоритмов, каждый из которых предлагает свое решение. Вместе с тем, даже с учетом рассмотренных мета-эвристик, применяемые методы и средства перебора вариантов требуют очень больших затрат времени на расчет планов. Например, расчет оптимального плана для крупной транспортной компании имеющей ресурсы, заказы и инфраструктуру движения, в одном из имеющихся пакетов программ занимает 8-10 часов, за это время ситуация - объем заказов, наличие доступных ресурсов может существенно поменяться и потребуется начинать планирование с начала. Это говорит о том, что средства для планирования в реальном времени остаются весьма примитивными, возможность гибкой адаптации на основе приходящих событий связывается преимущественно с возможностью ручной корректировки планов и полное ориентирование на диспетчеров. В результате, по оценкам экспертов, создаваемые автоматические расписания движения лишь на 40% выполнимы, что вынуждает многие крупные транспортные компании по-прежнему содержать штат опытных и дорогостоящих специалистов и диспетчеров, и осуществлять ручное или полуавтоматическое планирование. Все это не только снижает эффективность использования существующих методов и средств, но и на практике во многом существенно затрудняет их использование. Недостатки традиционных алгоритмов оптимизации при работе в конфликтной ситуации и решении плохо определенных задач в условиях высокой динамики, привели к появлению нового класса задач, связанных с построением расписания и динамическим планированием ресурсов в реальном времени. 25 Такая задача обеспечения согласованного взаимодействия по распределению ресурсов организации путем использования современных информационно-коммуникационных технологий, компьютерных методов и программных средств является в настоящее время весьма актуальной и при этом достаточно сложной. В связи с этим множество исследователей посвящают ее решению довольно много внимания. Следует отметить, что прямое применение существующих математических методов не позволяет добиться эффективных результатов – нужно использовать наиболее современные методы и технологии разработки сложных программных систем, которые основаны на последних достижения в области искусственного интеллекта. В обзоре исследований данной проблемы следует упомянуть работу [10], посвященную компьютерной поддержке переговоров при согласовании управленческих решений. Согласование управленческих решение рассматривается как потенциально противоречивый переговорный процесс, в ходе которого договаривающиеся стороны, возможно конфликтующие, стараются выработать совместное решение для получения результата, которого они не могут достичь другим путем. В качестве факторов, осложняющих согласование решений, выделяются слабая структурированность проблем, отсутствие объективной меры успеха результата, итеративность принятия решений при малом количестве альтернатив, неопределенность и субъективность решений, сложность подсчета общего KPI системы. Важно, что в этой работе выделяются фазы анализа сложившейся обстановки, определение своей позиции и формирование первого предложения, определение тактики ведения переговоров и собственно проведение переговоров. Такой подход позволяет добиться определенной гибкости в организации согласования каждого решения, когда стратегия обработки новых событий вырабатывается индивидуально с учетом текущего состояния системы и хода переговоров. Также уточняется, что задача компьютерной поддержки переговоров возникает только в распределенных системах поддержки принятия решений, как между узлами различных уровней взаимодействия, так и между узлами одного уровня. Проблемам управления взаимодействием уделяется достаточно много внимания при исследовании основополагающих принципов управления сложными организационнотехническими системами. Основные теоретические результаты здесь состоят в разработке новых принципов управления открытыми системами, решении проблемы интеграции знаний, изучении принципов организации согласованной деятельности, а практические результаты отражаются в мультиагентных технологиях и принципах построения онтологий, которые ре- 26 ализованы в интеллектуальных программных системах управления распределением ресурсов в режиме реального времени. Также при изучении фундаментальных принципов организации информационного взаимодействия лиц, принимающих решения, необходимо отметить работу [11]. Когда говорят о коллегиальном управлении, то имеют в виду, что принятие решений осуществляется группой лиц, каждое из которых несет персональную ответственностью за определенную область деятельности. Поэтому любую проблемную ситуацию, сложившуюся в системе, это действующее лицо, называемое «актором», рассматривает со своей субъективной точки зрения, хотя выход из создавшегося положения должен быть найдет совместными усилиями, то есть принятие решений происходит в условиях, когда необходимо согласовывать индивидуальные (относящиеся к сфере деятельности акторов) и групповые (общие для всех акторов) интересы и ценности, которые чаще всего являются противоречивыми. Если количество акторов невелико (несколько человек), то коллегиальное решение может быть принято в результате переговоров «за круглым столом», при которых договаривающиеся стороны могут в необходимой степени взаимно информировать друг друга, создавая возможность достижения компромисса путем соглашений на основе взаимных уступок. В данной работе подчеркивается актуальность разработки систем поддержки принятия коллегиальных решений с применением информационно-коммуникационных технологий, для чего предлагается использовать подход, основанный на применении онтологических моделей ситуаций. Для достижения компромисса между акторами должна быть организована коммуникация, структура которой включает в себя акторов-коммуникантов, наделенных сознанием и владеющих нормами некоторой семиотической системы (языка), ситуацию, которую они стремятся осмыслить и понять, тексты, выражающие смысл ситуации в языке, цели, делающие тексты направленными и процесс материальной передачи текстов. Различие точек зрения акторов порождает множество онтологий, композиция которых может формировать новые онтологии. Множественность онтологий не исключает возможности разработки общей онтологии, которая разделялась бы и использовалась всеми неоднородными акторами. Указанные выше принципы организации согласованной инженерной деятельности и автоматизированных систем поддержки принятия коллегиальных решений могут быть реализованы, например, при построении интеллектуальных систем управления распределенными ресурсами в реальном масштабе времени с использованием мультиагентных технологий [12]. 27 Проведенный анализ показывает существенные ограничения применения существующих систем планирования и оптимизации ресурсов и приводит к необходимости разработки качественно новых инновационных систем интеллектуального управления. 1.1.3 Анализ основных особенностей и перспектив применения мультиагентных технологий для повышения эффективности распределения, планирования и оптимизации ресурсов в реальном времени Новый подход к решению проблемы оперативной обработки информации в процессах принятия решений может быть основан на применении мультиагентных технологий, получивших интенсивное развитие в последнее десятилетие на стыке методов искусственного интеллекта, объектно-ориентированного программирования, параллельных вычислений и телекоммуникаций. В основе этой технологии лежит понятие «агента» - программного объекта, способного воспринимать ситуацию, принимать решения и коммуницировать с себе подобными, динамически устанавливая связи между собой. На сайте Ассоциации AgentLink Европейского союза [13], объединяющей разработчиков МАС, представлен план развития этого направления до 2020-2030 гг. Актуальность и значимость создания мультиагентных систем в современном все более сложном и быстро меняющемся мире трудно переоценить. Существуют результаты в области логики рассуждений агентов, методов представления знаний, платформ для мультиагентных решений, а также прикладных систем в диапазоне от моделирования социальных процессов – до управления роботами. Однако, если число научных работ в этой области стремительно растет, то с коммерциализацией научных разработок и практическими применениями мультиагентных технологий дело обстоит гораздо скромнее - несмотря на тот факт, что на сегодня хорошо известно более 25 коммерческих компаний и 100 университетских проектов в этой области разработок. Причины этой ситуации состоят в том, что рассматриваемые системы, отвечая новым требованиям глобальной экономики и информационного общества, во многом меняют саму парадигму современного программирования, формируя новые постановки задач и требуя разработки инновационных методов и средств решения этих задач для практических применений [14]. Несмотря на эти трудности, в мире уже известен целый ряд успешных промышленных МАС проектов, в диапазоне от управления логистикой боя и миниатюрными беспилотными самолетами – до управления коттеджами для экономного расходования энергии. Список 28 коммерческих компаний, активно разрабатывающих и применяющих МАС, начал заметно расти уже на рубеже столетий: LostWax (Великобритания), Whitestein Technology / Living Systems (Швейцария), NuTech Solution (США), Magenta Technology (Великобритания – Россия). Применению мультиагентных систем и технологий для решения задач управления ресурсами в настоящее время уделяется достаточно серьезное внимание. Прежде всего, стоит отметить работу [15]. Во многих работах отмечается, что один из новых подходов к управлению предприятиями связан с построением открытых сетевых организаций, подразделения которых, в свою очередь, могут строиться и функционировать как автономные предприятия и напрямую взаимодействовать, как между собой, так и с внешними организациями. Отмечается, что такая сетевая организация позволяет предприятию более оперативно приобретать новые знания и гибко адаптировать свою структуру или принципы функционирования с учетом изменений в среде. В то же время сетевая организация приводит к существенному усложнению и интенсификации процессов принятия и согласования решений, связанных как с текущим функционированием, так и с развитием предприятия. Для обеспечения своей эффективности в этом случае предприятия должны постоянно осуществлять идентификацию потребностей и возможностей в среде и оперативно реконфигурировать свои производственные, финансовые и другие ресурсы, своевременно внедряя новые технологии, обновляя номенклатуру продукции и т.п. Основой последних успешных разработок в области мультиагентных технологий является «биологический» подход (bio-inspired), получивший название «Интеллекта роя» (“Swarm Intelligence”), изначально нацеленный на создание мультиагентных систем нового класса, использующих принципы самоорганизации и эволюции, характерные для поведения живых систем, например, колонии муравьев или роя пчел. Решение любой сложной задачи в таких системах формируется эволюционным путем, часто методом «проб и ошибок», за счет взаимодействия большого числа (десятков и сотен тысяч) простых агентов, непрерывно конкурирующих и кооперирующих друг с другом. Уже в первых работах по этому направлению было показано, что данный подход позволяет решать задачи самой высокой сложности, не поддающиеся решению другими способами, например, в области планирования и оптимизации ресурсов, распознавания образов, понимания текстов и ряда других. Например, при решении таким методом сложных задач оптимизации программные агенты моделируют поведение колонии муравьев в поисках корма – соответствующий под29 ход получил название Ant Optimization. Агенты-исследователи сначала случайным образом разбегаются от гнезда и независимо исследуют окружающую среду, представляющую собой пространство решений. Однако, по мере достижения результата успешные особи, возвращаясь к гнезду с добычей, оставляют следы, которые улавливают другие члены колонии, что заставляет их координировать свое поведение и выбирать тот же путь, направляясь к тому же источнику корма. Если корма много, то все больше муравьев (агентов) обращается к данному источнику, усиливая «протаптывание» дорожки, которая, в свою очередь, привлекает все больше муравьев, и, наоборот, по мере уменьшения корма, привлекательность дорожки ослабевает, и начинают набирать конкурирующую силу другие «дорожки», в это время случайно найденные другими муравьями. В этом случае решение сложной задачи (оптимизации, кластеризации, распознавания образов и т.д.) находится даже в тех случаях, когда другие классические математические методы не работают вовсе, но для построения такого решения может потребоваться довольно много времени для реализации различных «попыток», получение результата иногда никак не гарантировано, и данный подход трудно применим в реальном времени. В то же время, сильные стороны этого подхода связаны с возможностью решения сложных задач за счет взаимодействия большого числа простых агентов, конкуренцией агентов, реализующих разные методы «проб и ошибок», эволюционным решением задач, в котором допускается пересматривать решения, наличием общего поля памяти, корректируемого в ходе различных попыток, как инструмента простейшего согласования действий агентов. Кроме того, стало очевидно, что Swarm Intelligence – важная альтернатива принятому в области искусственного интеллекта классическому пониманию интеллектуальной системы. В этом понимании интеллект должен прийти от механической сборки блоков (как при сборке автомобиля), отвечающих за память, сознание, разные виды рассуждений и т.д. Интеллект же в Swarm Intelligence не находится ни в одном блоке, а рождается как новое динамически возникающее (эмерджентное) свойство системы в результате взаимодействия большого числа совершенно не интеллектуальных элементов. Факт, что умственные возможности одного муравья или пчелы относительно малы, но рой пчел или колония муравьев представляют собой мощный организм с высокой степенью интеллекта, позволяющий защищать гнездо, осваивать новые территории, находить пропитание и решать многие другие задачи в условиях постоянно изменяющихся ситуаций в среде. Важный шаг в развитии этого направления исследований был сделан в работах Артура Кестлера в рамках предложенной им концепции холонических систем, первая реализация которых в системе PROSA была выполнена в работе Хенрика Ван Брюсселя, Пола Валкенаерса и ряда других авторов из Христианского университета (Бельгия). 30 При создании мультиагентных систем для производства выделяются агенты заказа, продукта, ресурса, а также штабной агент, позволяющий хранить общее для всех знание об особенностях производства, оказывать консультации и задавать стратегии другим агентам. Холонический подход был успешно развит для создания мультиагентных систем управления промышленным производством в работах под руководством проф. Владимира Марека из Технического университета г. Прага (Чехия) [16]. Этот подход применялся при создании систем управления производством для концерна Skoda, автоматизации управления для подводных лодок по заказу Rockwell International, управления роем беспилотных самолетов в интересах Министерства обороны США и в ряде других приложений. Работы в этом направлении активно ведутся под руководством проф. Пауло Лейтао в Политехническом институте Браганки (Португалия), где применялись, в частности, при создании системы АДАКОР для контроля производства продукции [17]. Динамичное развитие данного направления привело к появлению ставшей уже регулярной международной конференции по холоническим и мультиагентным системам в промышленном производстве - International Conference on Holonic and Multi-Agent Systems in Manufacturing (HoloMAS). В настоящее время на рынке известен целый ряд мультиагентных платформ для разработки мультиагентных систем, наиболее популярные из них [19 –20]: а) JADE (Java Agent Development Framework) – наиболее широко используемая мультиагентная платформа для создания мультиагентных систем. Упрощает разработку мультиагентных систем через предоставление middle-ware (промежуточного слоя), совместимого с FIPA стандартами на разработку таких систем. Распространяется Telecom Italia, но в последнее время в Наблюдательный Совет вошли также компании Motorola, Whitestein Technologies AG, Profactor GmbH, and France Telecom R&D. б) Cougaar (Cognitive Agent Architecture) – также Java-based платформа для построения распределенных мультиагентных систем, разработанная в результате многолетнего проекта известной военной организации DARPA в исследовательских проектах ALP и Ultra*Log. Включает не только исполняющую систему (run-time engine), но также некоторые средства для визуализации, управления данными и другие. в) JACK Intelligent Agents - Java платформа для создания мультиагентных систем, разрабатываемая коммерческой Agent Oriented Software Pty. Ltd. Третье поколение платформы реализует правила процедурных рассуждений (Procedural Reasoning Rules) и поддерживает платформу распределнных систем Distributed Multi-Agent Reasoning System (dMARS). В JACK одна из немногих платформ, где используется 31 BDI модель логики агентов и встроенные формально-логические средства планирования работы агентов. 1.1.4 Анализ основных особенностей и перспектив технологии представления и обработки знаний для поддержки процессов согласованного принятия решений при управлении ресурсами организаций Среди современных подходов к автоматизации представления и обработки знаний для поддержки принятия решений по управлению ресурсами организаций в последнее время наибольший интерес представляют разработки, связанные с созданием и применением онтологий. Онтология – это формализованные концептуальные знания о предметной области, представленные в форме, допускающей компьютерную обработку и используемые при принятии решений. При проектировании онтологии деятельности предприятия все необходимые знания разделяют на знания предметной области и знания, относящиеся к методу решения задачи или принятия решений. Термин «онтология» используется как для обозначения базы знаний в целом, содержащей описания данных с помощью некоторой концептуальной схемы, так и для обозначения собственно концептуальной схемы, при этом оперативная информация, отражающая текущее состояние объектов, специфицированных с помощью концептов и отношений, выделяется в так называемую «сцену». Онтологии достаточно удобны для обеспечения информационной поддержки принятия решений, поскольку позволяют отделить знания от программного кода, а также описывать проблемные ситуации. Онтологическая модель ситуации [11] представляет собой описание ситуации в форме понятий и отношений путем многостороннего диалога неоднородных акторов, находящихся в этой ситуации и имеющих возможность воздействовать на нее. В онтологической модели ситуации отражаются как явные знаний, так и неявные, которые являются источником неопределенности и риска конфронтации между акторами. Онтологическая модель ситуации выполняют объединяющую роль платформы, на базе которой происходят процессы согласования точек зрения и взаимных уступок акторов. Отмечается, что этот процесс носит итерационный характер, что очень важно учитывать при организации их взаимодействия. В указанной работе формулируются также требования к системам поддержки принятия коллегиальных решений с применением онтологических моделей ситуации на основе информационно-коммуникационных технологий. На наш взгляд, наиболее важными с точки 32 зрения организации управления ресурсами является компьютерное представление онтологий предметных областей в виде баз знаний неоднородных акторов, участвующих в процессах принятия коллегиальных решений, и организацию доступа к ним с целью получения информации об интересах и предпочтениях каждого актора, интеграция знаний с применением композиции онтологий, сетевой обмен информацией между акторами по принципу «каждый с каждым», автоматизацию конструирования и трансформации онтологической модели ситуации путем разработки и использования механизмов коллективного выбора «подходящих» вариантов из множества предлагаемых акторами решений, регистрацию найденных общих решений в системной библиотеке, что позволит корректировать управление в будущем. Вообще, применение онтологий для решения задач интеллектуальной поддержки принятия решений в настоящее время получает широкое распространение. Вопросы проектирования онтологий предметных областей отражены, например, в работах [11]. В работе [12] указывается, что использование онтологического анализа в качестве единой методологической основы обработки информации в системах компьютерного моделирования позволяет осуществить эффективную поддержку всех логически обусловленных фаз процесса моделирования, включая свойственные каждой фазе механизмы интеграции знаний, предложить концепцию и средства ведения альтернативных и эволюционных исследований на моделях. Отмечается, что определяющими чертами систем компьютерного онтологического моделирования являются положения: методологии решения задач суть упорядоченные процессы приобретения, накопления и использования знаний; актуальные релевантные знания разнородны, изучаемые системы являются открытыми в том смысле, что содержание и объем актуальных знаний подвержены изменениям в масштабе времени исследований, прикладные задачи с позиций сложившегося размежевания научно-технического знания являются междисциплинарными. Также следует отметить работу [21], в которой предлагается подход к интеграции разнородных знаний, основанный на агентных взаимодействиях и заключающийся в совместном использовании агентных механизмов работы со знанием на естественном языке и мультиагентного кластерного анализа. Этот подход позволил разработать методы автоматизированного конструирования онтологий, представления и обработки информации, анализа результатов и пополнения знаний, обеспечивая цикл познания, необходимый для эффективного и оперативного использования информации. В работе [22] достаточно полно описаны современные подходы к использованию онтологии в информационных системах на этапе проектирования и разработки информационной системы и на этапе ее функционирования. Отмечается, что в управляемой онтологией 33 разработке информационной системы онтология может быть использована не только для построения новой информационной системы (в инжиниринге информационной системы), но и для реинжиниринга информационной системы, с целью повышения степени ее расширяемости и качестве сопровождения. Онтология может служить для описания области знаний информационной системы и спецификации структуры хранилища данных, поддерживает систематизацию и интеграцию релевантных информационных ресурсов и содержательный доступ к ним. Благодаря использованию онтологии система знаний информационной системы и ее контент образуют единую сеть знаний и данных, по связям которой может осуществляться удобная навигация и содержательный поиск, существенно расширяющий поиск по ключевым словам. Работы [23, 24] посвящены контекстно-ориентированному управлению знаниями для персонифицированной поддержки взаимодействия участников производственных сетей. Здесь производственная сеть рассматривается как совокупностью объединенных на принципах кооперации в рамках единого информационного пространства технологических ресурсов юридически независимых предприятий, способных на основании их координации и оперативного распределения производить конечный продукт или услугу. Отмечается, что сетевой принцип организации требует оперативной координации большого количества независимых участников большой сети, для чего необходимо использование систем управления знаниями с целью формирования общего информационного взаимодействия. Для решения этой проблемы, в частности для повышения эффективности и оперативности взаимодействия участников производственной сети, предлагается использование персонифицированной системы управления знаниями, реализовать которую предлагается с помощью онтологий. Для обеспечения согласованности информационных ресурсов могут быть использованы модели управления контекстом в системах интеллектуальной поддержки принятия решений в структурированных динамических областях [25, 26]. Контекст, формализованный средствами онтологической модели представления знаний, позволяет структурировать накопленную информацию и обеспечивает семантическую совместимость информационных ресурсов друг с другом и с системами интеллектуальной поддержки принятия решений. Разработке методов и моделей автоматического построения онтологий на основе генетического и автоматного программирования посвящена работа [27]. Работа основывается на определении T.R. Gruber, согласно которому онтология является точной спецификацией концептуализации. С этой точки зрения для каждой из баз данных, или баз знаний, или систем, основанных на знаниях, или агентов знаний должны быть построены спецификации, основанные на некоторой концептуализации. Множества объектов и отношений между ними 34 должны быть описаны в некотором словаре, в котором система, основанная на знаниях, представляет свои знания. Данная работа посвящена разработке технологии создания методов автоматического построения онтологий, позволяющей сформировать библиотеку методов извлечения знаний о терминах и отношениях между ними из терминологических словарей и научных текстов. Для создания методов автоматического построения онтологий в данной работе предлагаются модель генерации систем продукций на основе применения генетического программирования, модель генерации преобразователей на основе генетического и автоматного программирования, модель генерации систем логического вывода на основе генетического и автоматного программирования и модель аппарата активации продукций на основе применения автоматного программирования. Аппарат активации может быть использован как для проверки систем продукций на корректность, так и для функционирования в реальном режиме. В системах поддержки принятия решений знания играют ключевую роль, поэтому ориентация именно на накопление знаний и обеспечения ими участников процесса взаимодействия крайне важно для обеспечения эффективности функционирования единого информационного пространства предприятия. В этом контексте следует отметить работы [28], посвященные разработке многоуровневых моделей сложно-структурированных предметных областей и их использование при разработке систем, основанных на знаниях. Отличительная особенность таких систем состоит в том, что знания, необходимые для выполнения профессиональной деятельности, отделены в них от программ для решения прикладных задач. В указанных работах поднимается очень важный вопрос: как обеспечить редактирование и развитие знаний экспертом без участия посредника – инженера знаний, осуществляющего сопровождение баз знаний для систем, созданных с использованием универсальных систем управления базами данных. Для решения этого вопроса предлагается использовать онтологию, задающую систему понятий и связей между ними. Указанное исследование направлено на решение проблемы создания расширяемых специализированных оболочек систем, основанных на знаниях, для сложноструктурированных предметных областей, которые позволяли бы создавать и изменять базы знаний и онтологии предметной области, а также поддерживали механизмы расширения множества классов прикладных задач. Для этого предлагается класс математических соотношений (декларативных моделей), которые могут использоваться при моделировании онтологий и знаний, класс логических языков для представления этих декларативных моделей, методы анализа сложноструктурированных предметных областей с выбранной точки зрения и общая архитектура расширяемых специализированных оболочек систем, основанных на знаниях. 35 1.1.5 Тенденции развития и применение информационных технологий в области обеспечения железнодорожного движения Тенденции к более эффективному, рентабельному и ориентированному на качество предоставляемых услуг функционированию железнодорожной системы настоятельно продвигается по политическими, экономическими и экологическими причинам во всем мире. Железнодорожное сообщение представляет собой стратегически важный актив для обеспечения грузовых и пассажирских перевозок. На развитие данной отрасли в Европе тратят до 35 миллиардов € в год. Кроме того, железные дороги являются наиболее безопасным видом транспорта. Замечая внушительный технологический прогресс железных дорог очевидным для всех является факт, что многое может быть сделано для оптимизации работы усовершенствования ее эффективности. Например, для существенно повысить конкурентоспособность и долю на рынке перевозок, может как использование современных высокоскоростных поездов, так и более высокая производительность обычных поездов. Информационные технологии и технологии связи (ICT) уже привнесли важные инновации в работу сетей железных дорог в области повышения безопасности (системы сигнализации типа ERTMS), поддержки эксплуатации дорог (системы управления и контроля) и оказания услуг клиентам (информация для пассажиров, электронная покупка билетов и так далее). Данное направление – ICT, было и будет критически важным в преобразований железных дорог в интеллектуальную систему перевозок [29], следуя основным принципам, заявленным в соответствии с новой Директивой по функциональной совместимости железных дорог в рамках ЕС [30]. Одна из областей направления работы и применения инфокоммуникационных технологий интенсивно развиваемая в странах ЕС, связана с обслуживанием подвижного состава и контролем его состояния. Основная цель данной задачи состоит в том, чтобы минимизировать вероятность критических ошибок во время движения состава поезда, с серьезными последствиями в терминах качества обслуживания и дополнительных затрат, и в то же время поддерживая затраты на техобслуживание настолько низко, насколько это возможно, чтобы уменьшить расходы жизненного цикла и улучшить рентабельность инвестиций. Необходимость улучшения диагностических систем, для поддержки процессов техобслуживания была отражена в проекте EuRoMain FP5-IST. Проект EuRoMain показал возможность осуществления концепции дистанционного техобслуживания посредством бортовой связи и связи бортового оборудования с землей (результат другого проекта FP5-IST: TrainCom). EuRoMain также продемонстрировал важность стандартного формата для диа36 гностических данных, чтобы упростить их понимание и установление связи с напольными инструментами. Очень популярным становиться системный подход на базе онтологий железных дорог, что нашло отражение в проекте InteGRail, FP6 [31, 32], который представил архитектуру коллективного использования информации, на основе онтологии и SOA (сервисно- ориентированная архитектура). Этот проект показал, что подход на основе онтологии и модульного построения структуры системы может быть эффективно и широко применен в железнодорожных системах привнося измеримое увеличение уровня эффективности работы всей железной дороги. При этом нужно отметить, что онтология не новая идея. Онтология - это формальный язык, который позволяет описать любую концепцию в пределах области знаний, используя логические правила для ее выражения в терминах отношений к другим (ранее определенным) понятиям или концепциям. Начиная с фундаментальных понятий (например, время и место) и перемещаясь к более детальным понятиям. Цель состоит в том, чтобы полностью описать знание, которое мы имеем о такой области. Новая область, где усовершенствования необходимы и могут быть достигнуты, используя решения технологий ICT , связана с развитием средств помощи диспетчеризации, с обслуживанием подвижного состава, а также постоянным контролем его состояния. При этом основная цель средств диспетчеризации состоит в том, чтобы минимизировать вероятность критических ошибок во время движения поездов, ошибок, которые могут привести к серьезными последствиями. Тривиальные события (например, несработавшая стрелка, либо несработавший светофор, срочные работы проводимые на путях) могут иметь отрицательные последствия в виде задержки поезда, а чаще всего каскадное воздействие на все поезда на данном направлении, что влечет дополнительные транспортные затраты и снижения рентабельности. Кроме того, нарушение и перерывы в движении поездов (например, электричек) может привести к условиям социальной напряженности и недовольства местного населения. Анализ зарубежного и отечественного опыта показывает, что СППР широко применяются для решения задач управления и принятия решений на железных дорогах мира. В Германии СППР используются для расследования несчастных случаев на государственных железных дорогах; в Италии и Германии - для диспетчерского управления движением поездов; во Франции - для регулирования порожних грузовых вагонов; в Испании для диагностики подвижного состава; в Англии - для диагностики и проверки эксплуатационной готовности поездов и для информационного обслуживания пассажиров; в Японии - для анализа ва- 37 риантов автоматизации и для сезонного регулирования графика движения; в США - для анализа вариантов трассы и для анализа причин нарушения графика движения. Таким образом, можно сделать вывод об актуальности настоящей научноисследовательской работы. 1.1.6 Выводы и предложения по результатам проведенных анализа и исследований Существующие классические методы планирования и оптимизации ресурсов на практике имеют и ряд важных ограничений: а) не учитывают сложности современного бизнеса, оперирующего тысячами взаимосвязанных заказов и ресурсов и условий, имеющих множество своих особенностей; б) не обеспечивают возможности адаптивного планирования в режиме реального времени, т.к. это требует возможностей для динамического выявления и разрешения конфликтов в уже имеющемся расписании; в) предполагается, что все имеющиеся заказы и ресурсы «одинаковы» в том смысле, что обладают одним и тем же набором критериев, предпочтений и ограничений, на практике же часто необходимо индивидуально настраивать эти критерии, предпочтения и ограничения, причем, иногда меняя их в ходе работы системы; г) не позволяют поддерживать баланс интересов различных сторон, участвующих в планировании, гибко «разменивая» уровень сервиса на время, прибыль или риски доставки, неудобства водителя и т.д.; д) не предоставляют средств для учета специфических для каждой компании знаний, влияющих на качество получаемых планов; е) не позволяют диспетчеру легко объяснить и дать возможность автоматически модифицировать предлагаемые решения. Таким образом, можно сделать вывод, что предпосылки создания планирования и поддержки предприятия решения на базе сетецентрических мультиагентных систем существуют и широко описаны в научной литературе, однако при этом НИР, нацеленных на практическое применение мультиагентных технологий в области управления ресурсами, нее проводилось. Достижение поставленной цели НИР предполагается за счет совершенствования процессов принятия управленческих решений, за счет использования современных технологий представления и обработки знаний (баз знаний) и онтологий, а также мультиагентного подхода в построении системы автоматизации обеспечения оперативной реакции на события, 38 гибкого планирования и согласованного взаимодействия всех участников движения и обслуживания РЖД. В этой связи на первом этапе работ по проекту подготовлен обзор и проведен анализ современных информационных технологий для поддержки управленческих решений, прежде всего для повышения эффективности управления ресурсами в реальном времени. Результатом анализа является выбор направления теоретических исследований и проведения работ по оценке возможности применения мультиагентного подхода и создания модуля планирования для построения графиков движения поездов на определенной инфраструктуре путей. 1.2 Теоретические исследования и анализ задачи управления пассажирскими перевозками, а также управления высокоскоростным транспортом 1.2.1 Анализ задачи управления пассажирскими перевозками высокоскоростным транспортом Основной задачей управления пассажирскими перевозками является достижение максимальной эффективности функционирования пассажирского транспорта, обеспечение полного и качественного удовлетворения платежеспособного населения в перевозках с минимальными издержками. При этом необходимо учитывать их особую социальную значимость для территориальной подвижности населения с низким уровнем доходов в регионах, где вследствие географических особенностей, железнодорожные пассажирские перевозки являются единственным видом транспорта. Для осуществления перевозочного процесса железные дороги располагают техническими средствами, включающими в себя подвижной состав и инфраструктуру, в которую входят: а) железнодорожный путь с необходимым путевым развитием в раздельных пунктах для приема, скрещения, обгона, расформирования, формирования и отправления поездов и выполнения других операций; б) сооружения для посадки, высадки и обслуживания пассажиров; в) устройства для хранения, погрузки и выгрузки грузов; 39 г) устройства сигнализации, централизации и блокировки, информационные комплексы для обеспечения безопасности движения поездов и ускорения производственных процессов; д) сооружения для экипировки и ремонта локомотивов и вагонов; е) устройства электроснабжения, в том числе тяговые подстанции и контактная сеть на электрифицированных линиях; ж) устройства водоснабжения и другие; Работа железнодорожного транспорта подчинена трём законам (по убывающей степени важности): обеспечение безопасности движения поездов; график движения поездов; план формирования. Также можно добавить рентабельность и экономическую эффективность, как фактор, набирающий все больший вес. Технологические процессы работы станций применяют как типовые, так и составленные специально для станций с большим объемом работы (сортировочных, грузовых, пассажирских и участковым), применительно к местным условиям работы. Основным требованием к организации работы станции является безусловное обеспечение безопасности движения. Для этого используют техническо-распорядительный акт (ТРА), который содержит общие сведения о станции и прилегающих к ней перегонах, данные о примыкании подъездных путей, назначении станционных путей, стрелок и сигналов, об условиях приема и отправления поездов, организации маневровой работы и особенностях ее выполнения на станции. Система управления движением поездов включает в себя техническое нормирование и оперативное планирование эксплуатационной работы, регулирование перевозок и перевозочных средств, оперативное руководство перевозочным процессом и анализ выполненной работы. Оперативное руководство перевозочным процессом осуществляет диспетчерский аппарат, несущий сменное дежурство. На дорогах эту задачу выполняет распорядительный отдел службы перевозок. Оперативной работой станций руководят дежурные по станции, а на крупных станциях – станционные и маневровые диспетчеры. Движением поездов на участках руководят поездные диспетчеры. Участки, которыми они ведают, называются диспетчерскими кругами. Границами этих кругов являются, как правило, участковые и сортировочные станции. Основная задача поездного диспетчера — обеспечить движение поездов по графику, а в случае его нарушения – ввести опоздавшие поезда в график. С этой целью диспетчер применяет такие регулировочные меры, как уменьшение продолжительности стоянки поездов на раздельных пунктах, отправление по неправильному пути на двухпутных участках, изменение порядка и пунктов скрещения и обгона 40 поездов и др. Необходимые сведения диспетчер получает со станций и от машинистов локомотивов с перегонов участка. Кроме того, ему регулярно передается информация о подходе поездов и вагонов и сложившейся обстановке на каждом стыковом пункте. Важное значение для совершенствования организации движения поездов и использования резервов имеет анализ эксплуатационной работы железнодорожной сети, дорог, отделений и станций. Этот анализ выявляет степень выполнения установленных норм и показателей, причины отклонения от них и позволяет наметить меры по исправлению положения. Различают оперативный и периодический анализ. Оперативный анализ заключается в разборе результатов работы за смену и сутки, а периодический – за более длительный срок (пятидневка, декада, месяц, год). Основная задача организации пассажирских перевозок состоит в удовлетворении потребностей населения в передвижении наряду с обеспечением безопасности и высококачественного обслуживания пассажиров на вокзалах и в поездах. Планы пассажирских перевозок разрабатываются на перспективу и на год с разбивкой по кварталам. В перспективных планах устанавливают объем перевозок в пассажиро-километрах на основе анализа отчетности о выполненных перевозках за прошедший период, данных о росте населения, развитии народного хозяйства, в том числе о строительстве новых городов и поселков, железных дорог, расширении сети курортов и домов отдыха и т.д. Учитывают и такие факторы, как массовые организованные перевозки пассажиров на выставки, а также туристов и учащихся, удельный вес междугородных и пригородных перевозок пассажиров другими видами транспорта. Годовые планы перевозок разрабатывают более детально. При планировании перевозок определяют пассажиропотоки по направлениям и периодам года, а для пригородного движения и по месяцам, дням и часам суток. Для этого используются данные обследований пассажиропотоков. При составлении расписания отправление дальних поездов с начальных пунктов назначают, как правило, в вечернее время, а прибытие на конечные пункты – в утреннее. Расписание местных и пригородных поездов стремятся сделать удобным для основной категории пассажиров, увязывая его с часами работы предприятий и учреждений. Наибольший удельный вес в общем объеме пассажирских перевозок занимают пригородные перевозки. Характерными особенностями этих перевозок являются необходимость частых остановок для посадки и высадки пассажиров и значительная неравномерность движения по периодам года, часам суток и дням недели. На пригородных линиях со значительными пассажиропотоками для удобства пассажиров применяют так называемое зонное движение. Это значительно сокращает время нахождения пассажиров в пути и улучшает использование подвижного состава. 41 Пассажирские поезда делятся на три группы: дальние, следующие на расстояние свыше 700 км, местные – до 700 км и пригородные – до 150 км. Дальние и местные поезда в зависимости от скорости движения и количества остановок подразделяются на скоростные, скорые и пассажирские. На сегодняшний день скоростные поезда курсируют в трех направлениях: «Сапсан» из Москвы в Санкт-Петербург и из Санкт-Петербурга через Москву в Нижний Новгород, а также высокоскоростной поезд Alstom Allegro Санкт-Петербург– Хельсинки. 1.2.2 Особенности инфраструктуры РЖД В данном подразделе описываются особенности инфраструктуры РЖД, значимые с точки зрения формирования мультиагентной модели. 1.2.2.1 Классификация поездов и их обслуживание Поездом называется сформированный и сцепленный состав вагонов с одним или несколькими действующими локомотивами или моторными вагонами, имеющий установленные сигналы. По старшинству поезда подразделяют на: а) внеочередные – пожарные и восстановительные поезда, снегоочистители, локомотивы без вагонов и специальный самоходный подвижной состав, предназначенные для восстановления нормального движения и тушения пожара; б) очередные – в порядке приоритетности представлены пассажирскими высокоскоростными (следуют со скоростью выше 200 км/ч), пассажирскими скоростными (следуют со скоростью до 250 км/ч.), пассажирскими скорыми, остальными пассажирскими, почтово-багажными, воинскими, грузопассажирскими, людскими, ускоренными грузовыми, грузовыми, хозяйственными поездами и локомотивами без вагонов в) назначаемые по особым требованиям – очередность таких поездов устанавливают при назначении. Всем поездам в зависимости от категории на станциях формирования присваивают номера: скорым – 1 … 99, пассажирским дальним круглогодичного обращения – 171 … 299, грузовым сквозным – 2001 … 2998, грузовым участковым – 3001 … 3398, грузовым сборным – 3401 … 3498, пригородным – 6001 … 6999 и т.д. Поезда одного направления имеют нечетные номера, а поезда обратного направления – четные. 42 Нормы массы и длины поездов устанавливают в плане их формирования и графике движения. В отношении сквозных поездов нормы массы унифицированы для всего направления следования, с тем, чтобы избежать ее перелома (изменения) при переходе с одного участка на другой. Ускоренные грузовые поезда имеют несколько меньшие нормы массы. Грузовые поезда могут быть тяжеловесными и поездами повышенной массы. В зависимости от длины помимо существуют обычные грузовые поезда; грузовые поезда повышенной длины (длина составляет 350 осей и более); длинносоставные (длина превышает максимальную норму, установленную графиком движения на участке следования этого поезда) и соединенные (составленный не менее чем из двух сцепленных поездов с действующими локомотивами в голове каждого поезда). Грузовой поезд обслуживает локомотивная бригада, тогда как пассажирский – также проводники, а в необходимых случаях и другие работники. Пассажирские поезда подразделяют на следующие категории: дальние, следующие на расстояние свыше 700 км, местные – 150 ... 700 км и пригородные – до 150 км. Дальние и местные поезда в зависимости от скорости движения и числа остановок могут быть скоростными, скорыми и пассажирскими. К скоростным и скорым относятся поезда, следующие с высокой скоростью и имеющие остановки только на больших станциях. Пассажирские поезда следуют с меньшей скоростью и останавливаются на всех или на большинстве станций. Их средняя скорость движения составляет лишь около 50 км/ч. 1.2.2.2 Инфраструктура железной дороги Железнодорожная линия – совокупность перегонов, станций и других раздельных пунктов, оснащенных соответствующими техническими средствами для осуществления перевозок. Пропускной способностью железнодорожной линии называется наибольшее число поездов или пар поездов установленной массы, которое может быть пропущено в единицу времени (сутки, час) в зависимости от имеющихся постоянных технических средств, типа и мощности подвижного состава и принятых методов организации движения поездов (типа графика). Различают наличную пропускную способность, т.е. ту, которой обладает линия в настоящее время, и потребную, необходимую для заданных размеров движения. Станции являются основными предприятиями транспорта. В зависимости от основного назначения различают три вида пассажирских станций: обслуживающие дальнее, местное и пригородное движение; головные, обслуживающие только пригородное движение, и зонные на пригородных участках, включая пересадочные станции в пунктах слияния или пересечения с линиями метрополитена. 43 Железнодорожный путь – это комплекс инженерных сооружений, предназначенный для пропуска по нему поездов с установленной скоростью. Переход подвижного состава с одного пути на другой обеспечивают устройства по соединению и пересечению путей, относящиеся к их верхнему строению. Соединение путей друг с другом осуществляют стрелочными переводами, а пересечение путей – глухими пересечениями. Для высокоскоростного движения необходима отдельная изолированная инфраструктура, по которой не осуществляется грузовое движение, нет пересечений с автомобильными дорогами (переездов), обеспечено соответствующее удаление от прилегающих к путям строений и искусственных сооружений, а также иные технические условия. Одним из основных условий обеспечения безопасности движения поездов является наличие тормозных средств, достаточных для остановки поезда на расстоянии, равном длине тормозного пути, при следовании с наибольшей допустимой скоростью по руководящему спуску в случае возникновения препятствия для движения. Руководящим называется наибольший по крутизне спуск (с учетом сопротивления в кривых) протяженностью не менее тормозного пути. Тормозной путь в зависимости от руководящего спуска и допустимой максимальной скорости движения принимается равным 1000, 1200, 1300, 1500, 1600 и 1700 м. 1.2.2.3 Средства сигнализации, централизации и блокировки (СБЦ) Средства сигнализации, централизации и блокировки (СЦБ) – это устройства автоматики телемеханики на железнодорожном транспорте. Классификация сигналов Значения сигнальных показаний установлены Инструкцией по сигнализации на железных дорогах Российской Федерации (ИСИ) 44 Железнодорожная сигнализация Сигналы Сигнальные указатели Постоянные Видимые (дневные, ночные, круглосуточные) Постоянные Переносные Светофоры Сигнальные знаки Предупредительные Звуковые Поездные Звуковые Щиты Флаги Флаги Флаги Диски Диски Фонари Фонари Фонари Внимание! Токораздел Отключить ток Поднять токоприемник Включить ток на электровозе Предельный столбик Граница станции Начало опасного места Конец опасного места С – подача свистка Остановка локомотива Входные Предупредительные Выходные Маневровые Проходные Горочные Маршрутные Заградительные Прикрытия Повторительные Маршрутные Включить ток на электропоезде Остановка первого вагона Конец контактной подвески Временные Подготовиться к опусканию токоприемника Опустить токоприемник Поднять токоприемник Поднять нож, закрыть крылья Стрелочные Путевого заграждения Гидравлических колонок Опустить токоприемник Локомотивные Перегрева букс Рисунок 1.1 – Классификация сигналов Светофоры в зависимости от назначения подразделяются на: а) входные – ограждающие станции со стороны прилегающих перегонов и разрешающие или запрещающие поезду следовать на станцию; б) выходные – разрешающие или запрещающие поезду отправляться со станции на перегон; в) проходные, расположенные на перегоне – разрешающие или запрещающие поезду следовать на ограждаемые ими участки; г) маршрутные – разрешающие или запрещающие поезду следовать из одного района станции в другой; д) сигналы прикрытия, ограждающие места одноуровневых пересечений железных дорог с другими железными дорогами, трамвайными путями и троллейбусными линиями, а также разводные мосты. Кроме того, бывают светофоры предупредительные, маневровые, горочные, заградительные, повторительные и локомотивные. Основными сигнальными цветами на железнодорожном транспорте являются красный, желтый и зеленый (возможны их сочетания). Красный огонь принят в качестве сигнала остановки, желтый разрешает движение, но требует снижения скорости, зеленый разрешает движение с установленной скоростью. 45 Также применяют синий, лунно-белый, прозрачно-белый и молочно-белый сигнальные огни. Синий огонь используют как запрещающий на маневровых светофорах, а луннобелый – как разрешающий маневровый и пригласительный на входных, выходных и маршрутных светофорах. Прозрачно-белый огонь применяют в ручных фонарях, поездных сигналах, указателях гидроколонок, светящихся указателях перегрева букс и др., тогда как молочно-белый – в указателях путевого заграждения и стрелочных указателях. Поездными сигналами являются фонари с прозрачно-белыми, красными и желтыми огнями, красные и желтые флаги, а также красные диски. Эти сигналы служат для обозначения головы и хвоста поезда и других подвижных единиц. По числу, цвету и расположению сигналов в голове и хвосте поезда можно в любое время суток определить, по какому пути и как следует поезд – локомотивом или вагонами вперед. Автоматическая блокировка Автоблокировка (АБ) является основной системой регулирования движения поездов на одно- и двухпутных линиях магистральных железных дорог. При использовании автоблокировки межстанционный перегон разделен на блокучастки длиной 1,0...2,6 км. Каждый блок-участок огражден проходным светофором. Сигнальные показания светофоров сменяются автоматически при движении поезда по перегону. Исключением являются выходные и входные светофоры: ими управляют дежурные по станциям. Автоблокировка бывает двух-, трех- и четырехзначной. На магистральных железных дорогах применяют трех- и четырехзначную АБ. При использовании трехзначной АБ между движущимися поездами должно быть не менее трех свободных блок-участков. Желтый огонь светофора показывает, что на стоящем впереди светофоре горит красный огонь, перед которым машинист должен остановить поезд. Зеленый огонь показывает, что впереди свободны как минимум два блок-участка и можно двигаться с установленной скоростью. В случае применения четырехзначной АБ на каждом проходном светофоре добавляется сигнальное показание в виде одновременно горящих желтого и зеленого огней. Это позволяет обеспечить минимальный интервал попутного следования поездов с любой скоростью. АБ позволяет организовать движение поездов в попутном направлении с интервалом 8 мин, а на пригородных участках – с интервалом 3...4 мин. 1.2.2.4 Устройства диспетчерского контроля за движением поездов Устройства диспетчерского контроля за движением поездов (ДК) применяют на участках, оборудованных АБ, для передачи информации поездному диспетчеру об установленном направлении движения (на участках однопутной блокировки), о занятости блок46 участков, главных и приемоотправочных путей промежуточных станций, показаниях входных и выходных светофоров. Кроме того, устройства ДК дают возможность дежурным промежуточных станций следить за движением поездов на прилегающих перегонах, а также получать информацию о повреждениях перегонных устройств АБ и переездной сигнализации на этих перегонах. На железных дорогах применяют систему частотного диспетчерского контроля (ЧДК). Она включает в себя устройства телеконтроля, информирующие о состоянии перегонов в пределах диспетчерского круга. С перегонов информация о состоянии контролируемых объектов по специально выделенным проводам сначала передается на промежуточные станции, а затем по цепи ДК поступает на центральный диспетчерский пункт. Контрольная информация отправляется с каждой перегонной установки в виде определенного частотного кода, и на табло дежурного по промежуточной станции включается соответствующая контрольная лампочка. Частотные сигналы, принятые на диспетчерском пункте, усиливаются, расшифровываются, и определяются станции, с которых они поступили, и состояние контролируемого объекта. Сигнальная индикация состояния контролируемых объектов в системе ЧДК высвечивается на табло, где показываются все блок-участки перегона, главные и приемоотправочные пути промежуточных станций, все входные и выходные светофоры. Дальность действия системы, определяемая видом линии связи, составляет для кабельных линий 180 км, а для воздушных – 300 км. При использовании каналов высокочастотной связи дальность действия ДК практически неограниченна. 1.2.2.5 График движения поездов График движения является основным нормативно-технологическим документом, регламентирующим работу всех подразделений по организации движения поездов. График движения выражает план всей эксплуатационной работы железных дорог. Движение поездов строго по графику достигается точным соблюдением технологических процессов работы станций, локомотивных и вагонных депо, тяговых подстанций, пунктов технического обслуживания, дистанций пути и других подразделений железных дорог, связанных с движением поездов. Объединяя и координируя работу этих подразделений, график движения позволяет им действовать согласованно. На основе графика составляют расписание движения поездов, в котором указывают время прибытия, отправления и проследования поездов для каждого раздельного пункта. Ход поезда изображается на графике в виде движения точки в системе координат, где по оси абсцисс откладывается время суток от 0 до 24 ч, а по оси ординат – пройденное рас47 стояние. Таким образом, график движения выражает зависимость t =f(S), где S — путь, пройденный поездом; t — время его хода. След движения точки условно принимают за прямую, соединяющую точки отправления и прибытия поезда, соответствующие смежным раздельным пунктам, исходя из того, что поезд следует по перегону с постоянной скоростью. Угол наклона прямой к горизонтали характеризует скорость движения поезда. Фактически же эта скорость изменяется, причем особенно существенно при замедлении поезда перед остановкой и разгоне после отправления (см. штриховую кривую на Рисунок 1.2). Фрагмент графика движения поездов: 3 А 8 5 18 3 Оси раздельных пунктов 6 Б 2 21 02 5 А-В – обозначения раздельных пунктов; 0,1 на оси абсцисс – время (часы); цифры на осях раздельных пунктов – время прибытия, отправления или проследования поезда (число минут сверх целого десятка); числа над наклонными прямыми – условные номера поездов; штриховая кривая в левом нижнем углу – реальный графи движения поезда с учетом изменения его скорости В 2 0 9 1 Рисунок 1.2 – Фрагмент графика движения поездов Для составления графика должны быть известны его основные элементы: а) время хода поездов различных категорий по перегонам; б) продолжительность стоянки поездов на станциях для выполнения технических, грузовых и пассажирских операций; в) станционные интервалы – минимальные промежутки времени, необходимые для выполнения операций на раздельных пунктах по приему, отправлению и пропуску поездов; г) интервалы между поездами в пакете; д) время нахождения локомотивов на станциях локомотивного депо и в пунктах оборота. График обычно строят на стандартной сетке с масштабом времени 4 мм – 10 мин и масштабом расстояний 2 мм – 1 км. На сетке каждый час разделен вертикальными линиями 48 на шесть 10-минутных интервалов, при этом получасовые деления отмечают штриховой прямой. Горизонтальными линиями обозначают оси раздельных пунктов. Линии движения нечетных поездов наносят сверху вниз, а четных – снизу вверх. В точках пересечения этих линий с осями раздельных пунктов (в тупых углах) проставляют время прибытия, отправления или проследования поездов, – цифру, указывающую число минут сверх целого десятка. В зависимости от скорости движения поездов различают параллельные и непараллельные (нормальные) графики. При параллельных графиках поезда каждого направления следуют с одинаковой скоростью, поэтому линии их хода параллельны друг другу. В обычных условиях эксплуатации движение происходит по нормальным графикам, так как пассажирские и грузовые поезда движутся с разными скоростями. По числу главных путей на перегонах графики подразделяют на однопутные и двухпутные (Рисунок 1.3). В первом случае главный путь используется для движения в обоих направлениях и скрещение поездов может происходить только на станциях и разъездах, во втором случае – как на перегонах, так и на станциях. 0 1 0 2 А 1 2 А 2905 2903 2901 01 25 22 Б 10 29 08 29 29 30 22 29 04 В 06 Б Г В Однопутный график движения поездов: А-Г – обозначения раздельных пунктов; 0, 1, 2 – врем (часы); числа над наклонными прямыми – условные номера поездов. Двухпутный график движения поездов: А-Г – обозначения раздельных пунктов; 0, 1, 2 – врем (часы); числа над наклонными прямыми – условные номера поездов. Рисунок 1.3 – Однопутный и двухпутный график движения поездов По соотношению числа поездов в четном и нечетном направлениях различают парные графики, когда это число одинаковое, и непарные — в противном случае. В зависимости от расположения поездов попутного следования графики могут быть пачечные, пакетные и частично пакетные. 49 При пачечном графике поезда движутся друг за другом с разграничением межстанционным перегоном. Это означает, что нельзя отправить на перегон поезд, пока ранее отправленный не прибыл на следующую станцию, т.е. на перегоне может находиться только один поезд. При пакетном графике поезда следуют пакетами с разграничением в них поездов временем или блок-участками. В этом случае на перегоне между станциями одновременно могут находиться несколько попутных поездов, образующих пакет. Такие графики применяют при использовании автоблокировки. При частично пакетных графиках часть поездов движется одиночно, а часть – пакетами. 1.2.3 Анализ возможности применения мультиагентного подхода для адаптивного планирования и динамического управления расписанием для минимизации отклонения от графика высокоскоростного железнодорожного транспорта Одной из центральных задач РЖД является эффективная организация процесса распределения, планирования и оптимизации производственных, технологических, ремонтных, кадровых, финансовых и других ресурсов в реальном времени. Переход к реальному времени в управлении ресурсами позволяет значительно повысить эффективность работы, обеспечить прозрачность, согласованность и слаженность работы всех звеньев цепи крупной корпорации, дает новые возможности для оптимизации и контроля, быстрой реакции на непредвиденные события (террористические атаки) и т.д. Сложность решения этой задачи обусловлена наличием множества участников с зачастую конфликтными интересами, разнообразием критериев принятия решений, тесными взаимосвязями между отдельными подразделениями и этапами решения задач, неопределенностью и динамикой процессов и рядом других факторов. Успешное решение этой задачи может помочь существенно снизить затраты, повысить качество обслуживания клиентов, сократить сроки реализации заказов, уменьшить риски и объемы штрафных санкций, повысить безопасность транспорта. Примером применения может служить планирование поездов на определенном направление, с приоритезацией движения высокоскоростных поездов с учетом как заранее запланированных событий - ремонт путей, так и быстрое перепланирование в случае непредвиденных событий (поломка состава, задержка впереди идущего поезда). 50 Для решения данной задачи предлагается создание распределенной мультиагентной системы управления ресурсами предприятия, построенной как сеть динамических планировщиков производственных, транспортных и возможно других сервисных подразделений компании, необходимых для планирования самих перевозок, а также сопутствующих ресурсов обслуживания железной дороги. При этом каждое подразделение, вовлеченное в цепь выполнения заказов будет иметь типовой планировщик созданный на базе мультиагентной платформы что обеспечит возможность согласованного взаимодействия на одной шине динамического планировщика движения совместно, например, с динамическим планировщиком ремонтных работ, а также сделает работу каждого подразделения прозрачной и адаптивной для партнеров в цепи реализации заказов и выполнения работ. Эти планировщики будут представлять собой распределенное решение в сервисной архитектуре (SOA), интегрируясь с базами данных (БД) отдельных подразделений предприятия (Рисунок 1.4). Динамический Динамический Динамический планировщик планировщик планировщик ма- поездов ремонтов путей шинистов и др. БД Динамический БД БД Динамический БД планировщик БД планировщик Динамический БД планировщик ма- поездов ремонтов путей шинистов и др. Общая шина предприятия для обмена сообщениями Общая шина предприятия для обмена сообщениями Рисунок 1.4 - Архитектура мультиагентной системы управления предприятия Каждый такой динамический планировщик, построенный с применением мультиагентных технологий, позволит подразделениям корпорации вести оперативное планирование своих работ в реальном времени и автоматически выстраивать или корректировать расписание использования ресурсов, а также непрерывно оптимизировать ход работ с учетом географии и местоположения ресурсов, особенностей выполнения заказов и т.д. В свою очередь, каждый планировщик реального времени может быть интегрирован с существующими базами данных и имеющимися платформами отечественного или зарубежного производства (SAP, Oracle, etc). Из формируемых частных и сводного планов в любой момент времени для любого подразделения (участника) будет ясно, где, когда и какие работы планируется осуществлять, на каком оборудовании, и какие ресурсы и материалы, к какому сроку и в каком объеме, потребуются для их выполнения. 51 Для согласования этих сроков динамические планировщики через общую шину предприятия получат возможность вести переговоры и договариваться о предоставлении сервисов и поставках ресурсов, при необходимости вовлекая сотрудников подразделений, в том числе, через их сотовые телефоны. Однако для решения сложных задач такого рода требуется существенное развитие разработанного ранее подхода и переход на новый более сложный уровень к сетецентрическим системам, когда уже строится не одна, а много подобных систем и обеспечивается согласованное взаимодействие между ними. Развитие данного подхода для решения сложных задач управления ресурсами в реальном времени позволит создать и на практике исследовать новый класс интеллектуальных систем, а также обеспечить возможность решения сложных задач, которые решались плохо или не решались вовсе в существующих математических подходах – и в результате добиться большей продуктивности и эффективности, гибкости и оперативности, производительности и живучести создаваемых систем, находящих все большее применение в самых разных сферах. Перечислим основные преимущества мультиагентного подхода к планированию: 1) процесс планирования может начинаться с любой стороны и инициироваться от любых внешних или внутренних событий; 2) процесс планирования настраивается критериями принятия решений, которые устанавливает и гибко меняет пользователь, причем в ходе работы системы; 3) планирование является ситуативным, т.е. формируется и используется модель ситуации с учетом множества деталей (сцена); 4) планирование осуществляется гибко и оперативно, поскольку в основном пересматриваются лишь части расписания; 5) учитывается сетевая взаимозависимость между элементами динамического расписания (все связано со всем), все аспекты которой очень трудно, а иногда и просто невозможно проследить одному человеку при наличии сотен и тысяч связанных операций в согласованном расписании; 6) решение строится более сбалансированным, имеется возможность разрешать конфликты и находить компромиссы по ряду критериев, причем «эластичность» компромиссов регулируется пользователем; 7) возможна непрерывная проактивная оптимизация использования ресурсов, когда агенты продолжают искать лучшие решения, если имеется запас времени; 8) рассчитывается и используется индивидуальная микроэкономика каждого груза и каждого полета для оценки эффективности его исполнения; 52 9) обеспечивается наглядность и прозрачность процесса принятия решений для всех участников взаимодействия; 10) решение в виде наилучшего возможного согласованного расписания ищется не предопределенным и последовательным образом, как результат работы жесткого алгоритма, а исходя из сложившейся ситуации и отталкиваясь от «интересов» наиболее важных заказов или наиболее занятых ресурсов; 11) изменению подвергается только та часть расписания, которая непосредственно связана с событием, остальные части не затрагиваются и не меняются; 12) пользователь может в любой момент «заморозить» изменения в выбранной части расписания; 13) знания, необходимые для принятия решений по планированию формализуются и «извлекаются» из специалистов, и в результате становятся объективными, уменьшая роль человеческого фактора и вероятность ошибок; 14) знания в онтологии, отделенные от программного кода системы могут пополняться и/или модифицироваться специалистами в определенных пределах без привлечения программистов; 15) система может быть использована как моделирующая система для поиска альтернативных вариантов; 16) система может использоваться в режиме тренажера для обучения; 17) система позволяет накапливать и вести аудит принятых решений по каждому потребности или возможности. Указанные преимущества позволят автоматизировать процессы согласованного принятия решения для оперативного управления ресурсам с учетом реальных жизненных требований. 1.2.4 Выводы и предложения по результатам проведенных анализа и исследований В данном подразделе описана предметная область объекта исследования, выдвинуто предложение по решению задачи достижения цели НИР. Для создания интеллектуальной системы согласованного адаптивного планирования и связанного изменения планов движения поездов с целью минимизации отклонения высокоскоростных поездов класса «Сапсан» от графика движения под влиянием непредвиденных внешних событий предлагается использовать сетецентрическую систему, состоящую из не- 53 скольких структурно разделенных мультиагентных планировщиков как отдельных подсистем. При этом, можно считать, что основной элемент новой сетецентрической парадигмы управления ресурсами состоит в том, что необходимо сотрудничество и информационный обмен между подсистемами. Некоторая информация, собранная и консолидированная в одной подсистеме, может быть использована в других. Ключевой технологией для обеспечения широкого обмен информации между подсистемами должна стать мультиагентная платформа и сервис ориентированная архитектура (SOA). 1.3 Анализ задачи адаптивного планирования и динамического управления расписанием для минимизации отклонения от графика высокоскоростного железнодорожного транспорта В рамках выполнения НИР аналитиками компании исполнителя были проведены работы по анализу задачи адаптивного планирования и динамического управления расписанием для минимизации отклонения от графика высокоскоростного железнодорожного транспорта. Результаты анализа вошли в отчетные материалы подраздела 1.2 «Теоретические исследования и анализ задачи управления пассажирскими перевозками, а также управления высокоскоростным транспортом», а также подраздела 1.5 «Разработка программного мультиагентного подхода к построению процессов управления ЖД ресурсами». 1.4 Анализ современного состояния методов и средств динамического планирования подвижных объектов применительно к инфраструктуре РЖД в реальном времени В рамках выполнения НИР аналитиками компании исполнителя были проведены работы по анализу современного состояния методов и средств динамического планирования подвижных объектов применительно к инфраструктуре РЖД в реальном времени. Результаты анализа вошли в отчетные материалы подраздела 1.2 «Теоретические исследования и анализ задачи управления пассажирскими перевозками, а также управления высокоскоростным транспортом», а также подраздела 1.5 «Разработка программного мультиагентного подхода к построению процессов управления ЖД ресурсами». 54 1.5 Разработка программного мультиагентного подхода к построению процессов управления ЖД ресурсами 1.5.1 Разработка формализованных моделей индивидуального планирования ключевых ресурсов инфраструктуры РЖД В рамках разработки программного мультиагентного подхода предполагается использование онтологий (баз знаний), что позволит отделить предметные знания от программного кода системы. Онтология – это формализованные концептуальные знания о предметной области, используемые в правилах принятия решений. Для представления онтологии используется семантическая сеть, которая состоит узлов и упорядоченных отношений (связей), соединяющих эти узлы. Узлы выражают понятия или предположения, а связи описывают взаимоотношения между этими узлами. Сцена – это набор экземпляров классов, описывающих некоторую ситуацию. Каждый из экземпляров набора связан с некоторым концептом онтологии отношением вид-род. Таким образом, понятие онтологии является определенного рода словарем терминов для сцены (начальной, промежуточной или финальной). Формализованное представление знаний в форме онтологий: а) обеспечивает единство терминологии для всех систем планирования ресурсов; б) агенты используют знания о потребностях объектов в ходе работы и принятия решений; в) возможность расширения знаний в случае появления новых объектов (например, новая модификация ВСП); г) обеспечивается возможность анализа альтернативных вариантов планов движения поездов, что позволяет проводить его оптимизацию; д) обеспечивается гибкая перенастройка системы без перепрограммирования. Общая онтология представлена с использованием нотаций диаграммы классов (Рисунок 1.5). Онтология железной дороги содержит следующие концепты, атрибуты и отношения: Направление – концепт описывает направление железной дороги. Атрибуты: а) начальный пункт, б) конечный пункт, в) протяженность, г) количество путей, д) движение поездов. 55 Входной эл-т пути Элемент пути 1..* 1 1 1 1 1..* 1 1..* Блок-участок Светофор -Признак: крас.,зел. 1 Временные отношения элемента пути Стрелка -Км начала -Км конца -Признак занятости -Светофор -След.блок-участок 1 1 Выходной эл-т пути -Км местонахождения 1 1..* ITemporaryRelation 1 Заданный маршрут движения (ЗМД) -Станция отправления -Сранция назначения -Элемент пути IOperation IDemand 1 1 Line_ISchedileTrain IScheduleTrain -Поезд -Кол-во строк в расписании 1 1..* -Номер по порядку -Станция -Время прибытия -Время отправления -Входящий ЗМД -Исходящий ЗМД 1 Станция -Наименование -Параметры работы 1 1 1 1 1 Window -Время начала -Время окончания -Можно проехать -Ограничение скорости IOperation 1 Поезд -Номер -Направление движения -Тип -Кол-во вагонов -Длина -Состояние 1..* 1..* IScheduleWindows -Кол-во окон (строк в расписании) -Window 1 1 1 IScheduleActualWindows ITemporaryRelation -Кол-во окон (строк в расписании) -Window ISchedileActualTrain 1 -Кол-во строк в расписании -Элемент пути -Скорость -Движение -Останов -Экстренное торможение 1 IResource Рисунок 1.5 – Модель сущностей в части описания расписания, потребностей и базовых ресурсов Движение поездов – концепт описывает поезда, проходящие по направлению железной дороги. Атрибуты: а) тип поезда, б) количество поездов в сутки. 56 Путь – концепт описывает часть железной дороги для одновременного движения поездов только в одном направлении. Атрибуты: а) I путь для движения поездов с четными номерами, б) II путь для движения поездов с нечетными номерами. Инфраструктура – концепт описывает участок железной дороги. Атрибуты: а) элемент пути, б) станция. Элемент пути – концепт описывает часть дорожной инфраструктуры – наследник концепта IOResource. Атрибуты: а) блок-участок, б) светофор, в) стрелка, г) пикет, д) переезд, е) временные отношения – наследник концепта ItemporaryRelation. Блок-участок – концепт описывает минимальный учетный отрезок железной дороги протяженностью 1-1,5 км – наследник концепта Элемент пути. Атрибуты: а) путь, б) головная станция, в) расстоянием от головной станции на начало участка, г) расстоянием от головной станции на конец участка, д) признак занятости, е) местонахождение: 1) на перегоне, 2) внутри станции, ж) признак ложной занятости, и) светофор, к) следующий блок-участок. Пикет – концепт описывает столбики, выставленные на блок-участке через каждые 100 м – наследник концепта Элемент пути. Атрибуты: а) номер, б) головная станция, в) расстоянием от головной станции на начало участка, Стрелка – концепт описывает техническое устройство для перевода поезда с одного пути на другой – наследник концепта Элемент пути. Атрибуты: 57 г) номер, д) станция, е) входной путь, ж) выходной путь. Светофор – концепт описывает техническое устройство, сигнализирующее о возможности движения – наследник концепта Элемент пути. Атрибуты: а) номер, б) станция, в) параметры работы: 1) зеленый – открыт, 2) красный – закрыт. Переезд – концепт описывает пересечение железной дороги с автодорогой – наследник концепта Элемент пути. Атрибуты: а) идентификатор, б) параметры работы: 1) ЛСК – закрытие переезда, Маршрут движения – концепт описывает план движения поезда по путям железной дороги. Атрибуты: а) станция отправления, б) станция назначения, в) элемент пути. Станция – концепт описывает пункт, имеющий путевое развитие для приема, отправления, обгона поездов – наследник концепта IOResource. Атрибуты: а) название станции, б) параметры работы: 1) ВСДЧ – высокоскоростной пропуск в чётном направлении 2) ВСДН – высокоскоростной пропуск в нечётном направлении 3) КРУ – станцию можно взять на управление автодиспетчеру. Вагон – концепт описывает вагон. Атрибуты: а) номер, б) поезд, в) тип вагона: 1) контейнер, 2) платформа, 3) для сыпучих грузов. 58 Локомотив – концепт описывает локомотив. Атрибуты: а) номер, б) поезд. Поезд – концепт описывает сформированный состав из локомотива и вагонов – наследник концепта IOResource. Атрибуты: а) номер, б) направление движения, в) тип поезда: 1) высокоскоростной, 2) скорый, 3) пригородный, 4) пассажирский, 5) грузовой. г) количество вагонов, д) длина, е) состояние: 1) движение, 2) экстренное торможение, ж) расписание, и) запланированное расписание. Окно (проведения ремонтных работ) – концепт описывает выполняемые работы на определенных участках путей – наследник концепта IOperation. Атрибуты: а) элемент пути, на котором находится окно; б) вид работ; в) время начала работ; г) время окончания работ; д) тип окна: 1) проездное; 2) непроездное. Предупреждение – концепт описывает требование снизить скорость движения поезда (60, 80, 25 и др.). Атрибуты: а) элемент пути, на котором находится предупреждение, б) скорость движения, в) тип предупреждения: 1) постоянное; 59 2) временное; 3) внезапно возникшее. Информация – концепт описывает информационное сообщение, например, об отсутствии напряжения. Атрибуты: а) сообщение; б) элемент пути, для которого выдается информация. Конфликтная ситуация – концепт описывает конфликтные ситуации, имеющие отношение к ВСП «Сапсан». Атрибуты: а) тип конфликтной ситуации; б) впереди идет опаздывающий поезд; в) опаздывает ВСП «Сапсан»; г) ложная занятость; д) окно; е) неоткрытие светофора; ж) внезапное ограничение скорости. 1) алгоритм разрешения конфликтной ситуации. Расписание поезда – концепт описывает расписание движения поезда – наследник концепта IDemand. Атрибуты: а) поезд, б) количество строк расписания, в) строки расписания. Строка расписания поезда – концепт описывает движения поезда между станциями. Атрибуты: а) номер по порядку, б) станция, в) время прибытия, г) время отправления, д) входящий маршрут движения, е) исходящий маршрут движения. Запланированное расписание поезда – концепт описывает расписание движения поезда, построенное планировщиком на основе реального состояния движения – наследник концепта ITemporaryRelation. Атрибуты: а) количество строк расписания; б) окно; в) скорость; 60 г) состояние поезда. Расписание окон – концепт описывает расписание окон – наследник концепта IOperation. Атрибуты: а) количество строк расписания, б) окно. Запланированное расписание окон – концепт описывает расписание движения поезда, построенное планировщиком на основе реального состояния движения – наследник концепта ITemporaryRelation. Диспетчер – концепт описывает должностное лицо, ответственное за организацию движения на конкретном участке. Атрибуты: а) ФИО, б) круг. Круг – концепт описывает зону ответственности поездного диспетчера на конкретном участке. Атрибуты: а) диспетчер, б) инфраструктура, в) действия. 1.5.2 Разработка метода согласованного адаптивного управления расписанием движения поездов на основе мультиагентного подхода. Разработка логики агентов активных сущностей предметной области, позволяющих реализовать полный цикл реакции на события, планирование и исполнение планов в реальном времени Метод согласованного адаптивного управления расписанием на базе мультиагентного подхода позволит формировать оптимальное расписание прибытия и отправления пассажирских поездов по начальным и конечным станциям на основе обеспечения требований пассажиров, рациональной загрузки технических станций и увязки составов пассажирских поездов в общий оборот с выбором композиций, максимально удовлетворяющих спрос пассажиров на места по типам вагонов и эффективно использующих подвижной состав. В предлагаемой мультиагентной технологии каждой потребности или возможности реального мира ЖД в соответствие может быть поставлен программный агент, способный действовать от его лица и по его поручению, которые формируют сети потребностей и возможностей (ПВ-сети). 61 Как видно из рисунка 1.6, агенты потребностей и возможностей могут как конкурировать на виртуальном рынке системы, так и кооперировать (например, две станции могут конкурировать за выдачу мощности или наоборот дополнять друг друга при существенном росте потребности). Рисунок 1.6 - Виртуальный рынок системы, где D и S – агенты возможностей и потребностей предприятия (потребителей, станций, блоков и т.д.) В результате, новизна предлагаемого нами метода динамического планирования состоит в том, чтобы моделировать процесс распределения ресурсов и построения сложных расписаний через сопряженное взаимодействие участников этого процесса, которые по определению имеют различные цели, предпочтения и ограничения. Конфликты, порождаемые событиями (например, приход новой потребности, для которой в текущей ситуации нет открытой возможности), могут разрешаться агентами заказов и ресурсов путем переговоров и взаимных уступок, направленных на достижение приемлемых для всех компромиссов. Компромисс достигается тогда, когда один агент уступает свое место другому, причем с ухудшением своего положения, что сопровождается выигрышем для всей системы и соответствующим образом компенсируется из запаса специально вводимых виртуальных денег, являющихся всеобщим мерилом в поиске компромиссов типа «время-деньги», «качество-риск» и т.п. Например несрочный ремонт может быть подвинут на время либо отложен, но при достижении определенных критических параметров, когда он набирает вес и встраивается в расписание изменяя при этом график движения поездов. Разрешение конфликта может вызывать целую цепочку операций перепланирования, сдвижку заказов вправо или влево по шкале времени, обмен заказами между ресурсами и т.д., глубина которой может быть ограничена допустимым временем ответа или другими факторами. В то же время, если имеется запас времени, решение о выделении ресурса или сформированное расписание использования ресурса может подвергаться непрерывной, в том 62 числе, и классической оптимизации. Постоянная активность всех агентов сети, причем как со стороны потребностей, так и возможностей, вызывает многосторонние переговоры в системе, идущие асинхронно и квазипараллельно. При этом каждый агент рассматривается как машина состояний, возвращающая управление проектанту после каждого такта переговоров, т.е. агенты не «засыпают» надолго и всегда готовы быстро отреагировать на события. Таким образом, реализуется способность системы оперативно реагировать на заранее непредвиденные события. Сложность модели ПВ-сети увеличивается как с ростом числа типов программных агентов, представляющих разнообразные интересы, предпочтения и ограничения различных участников, необходимых для решения задачи, так и ростом числа возможных взаимодействий между агентами разных типов. Метод сопряженных взаимодействий, поддерживаемый настоящей платформой реализуется следующим образом: а) фиксируется множество сопряженных (в общем случае, неоднородных) элементов системы (агентов), каждый из которых обладает определенными возможностями и потребностями в других ресурсах; б) описываются индивидуальные цели и критерии принятия решения всеми агентами, а также их предпочтения и ограничения; в) определяются правила и протоколы (регламенты) сопряженных взаимодействий между агентами, позволяющие выявлять конфликты и находить компромиссы между элементами при установлении связей; г) с помощью специальных инструментальных средств программирования разрабатывается мультиагентная система моделирования сопряженных взаимодействий; д) с помощью этой системы строится первоначальная сеть потребностей и возможностей (ПВ-сеть), определяющая соответствующее распределение ресурсов; е) если состояние ресурсов или потребности в них изменяются с приходом новых событий, то ПВ-сеть перестраивается с целью разрешения конфликтов, причем только в той части, которая непосредственно связана с изменениями; ж) решение задачи распределения ресурсов считается найденным, когда Данный метод оказывается применим к динамическому планированию ресурсов любой природы, как статичных, так и мобильных. Таким образом, решение задачи при данном подходе формируется эволюционным образом, в ходе отработки каждого нового события, и потому является необратимым (для обратимости необходимо воспроизведение условий, при которых решение принималось). 63 Описанный предлагаемый метод во многом интегрирует наиболее современные идеи оптимального планирования, реализуемого в мета-эвристиках, фактически создавая среду конкурирующих и кооперирующих алгоритмов (агентов). Так, агенты могут запоминать и избегать плохих решений за счет использования своей памяти, информировать друг друга о промежуточных опциях, при близости опций принимать решения случайно, прекращать поиск при наличии ограничений по времени принятия решений и т.д. При этом за счет представления задачи в форме, близкой к естественной, логика принятия решений системы становится более прозрачной как для программистов, так и пользователей, что позволяет встраивать большее число эвристик без увеличения сложности кода и уменьшает общее время разработки системы, а также делает результаты системы доступными для понимания пользователем. При этом в системе реализуется как логика реакции на события, когда каждое событие (приход новой заявки, задержка в пути, занятость участка дороги и т.д.) запускает (триггерит) цепочку перепланирований ресурсов в системе, так и про-активная оптимизация планов, позволяющая улучшать варианты, пока еще есть время для работы системы и принятия окончательных решений. 1.5.3 Описание мира агентов В перечень основных агентов входят: а) Агент расписания, соответствует расписанию движения поезда по заданному маршруту в целом. 1) тип – агент потребности; 2) цель – доставить поезд на конечную станцию в заданный срок; 3) ограничения – временные факторы, непредвиденные события, для выполнения требуются ресурсы; б) Агент строки расписания, соответствует расписанию движения поезда по участку маршрута между двумя станциями. 1) тип – агент потребности; 2) цель – доставить поезд от станции отправления до станции назначения в заданный срок; 3) ограничения – временные факторы, непредвиденные события, для выполнения требуются ресурсы; в) Агент окна. 1) тип – агент потребности; 64 2) цель – выполнить работы на элементах пути; 3) ограничения – временные факторы, непредвиденные события, для выполнения требуются ресурсы. г) Агент поезда. 1) тип – агент ресурса; 2) цель – выполнить движение согласно расписанию; 3) ограничения – вес, длина, скорость, невозможность движения по занятому блок-участку, интервал движения. д) Агент станции. 1) тип – агент ресурса; 2) цель – выполнить прием, отправление, обгон поездов; 3) ограничения – количество станционных элементов пути, количество одновременно присутствующих на станции поездов, временные факторы пребывания поезда на станции. е) Агент элемента пути. 1) тип – агент ресурса; 2) цель – предоставить часть дорожной инфраструктуры (блок-участок, стрелку, светофор) для прохождения поезда/выполнения окон; 3) ограничения – временные факторы, невозможность двух поездов одновременно находиться на одном блок-участке. ж) Агент временного слота. 1) тип – агент ресурса; 2) цель – определить временное отношение между ресурсами, описывающее, как ресурсы взаимосвязаны (или будут взаимосвязаны) на определенном промежутке времени; 3) ограничения – временной слот связан с ресурсом. Потребность в доставке поезда по расписанию или потребность в выполнении окон раскладывается на подпотребности, соответствующие строкам расписания. Агенты соответствующих потребностей взаимодействуют с агентами временных слотов. Агенты временных слотов резервируют ресурсы. Агенты временных слотов в процессе переговоров проактивно ищут другие слоты, которые используют тот же самый ресурс. Если агенты временных слотов обнаруживают конфликт, они должны разрешить его, после чего агент временного слота связывается с потребностью. 65 1.5.4 Примеры разрешения конфликтных ситуаций Впереди идет опаздывающий поезд Возможны следующие варианты разрешения конфликтной ситуации «Впереди опаздывающий поезд». Решение 1. а) опаздывающий поезд останавливается. б) опаздывающий поезд пропускает ВСП «Сапсан». в) опаздывающий поезд следует далее по ранее определенному маршруту. Решение 2. а) для опаздывающего поезда строится новый маршрут, чтобы освободить путь, по которому следует ВСП «Сапсан». б) ВСП «Сапсан» следует по ранее определенному маршруту. в) опаздывающий поезд следует по новому маршруту. Решение 3. а) для ВСП «Сапсан» строится новый маршрут. б) ВСП «Сапсан» следует по новому маршруту. в) опаздывающий поезд следует далее по ранее определенному маршруту. Ложная занятость Возможны следующие варианты разрешения конфликтной ситуации «Ложная занятость». Решение 1. а) ВСП «Сапсан» останавливается. б) ложная занятость устраняется. в) ВСП «Сапсан» следует далее по ранее запланированному маршруту. Решение 2. а) Для ВСП «Сапсан» строится новый маршрут. б) ВСП «Сапсан» следует по новому маршруту. Окно Возможны следующие варианты разрешения конфликтной ситуации «Окно». Решение 1. 66 а) ВСП «Сапсан» останавливается, если окно непроездное на допустимый интервал времени, или снижает скорость, если окно проездное. б) ВСП «Сапсан» следует далее по ранее запланированному маршруту. Решение 2. а) Для ВСП «Сапсан» строится новый маршрут. б) ВСП «Сапсан» следует по новому маршруту. 1.5.5 Разработка структуры данных и алгоритмов принятия решений, а также протоколов проведения переговоров агентами в ходе динамического планирования ресурсов, включая выявление конфликтов, согласованную подвижку и перераспределение операций во времени Пусть в системе имеются два поезда: ВСП «Сапсан» и скорый пассажирский поезд №1000. Введем следующие упрощающие предположения: а) расстояния между городами на направлении Москва – Санкт-Петербург приняты из удобства расчетов и отличаются от истинных (без потери общности рассуждений), б) поезда делают две остановки: Тверь и Бологое, в) ВСП «Сапсан» движется со средней скоростью 200 км/ч, г) скорый поезд №1000 движется со средней скоростью 100 км/ч, д) длина блок-участка на перегоне – 99-100 км, е) длина станционного блок-участка – 1 км, ж) количество блок-участков на станциях – 2-3, з) на 300-м и 600-м километрах находятся стрелки. Расписание ВСП «Сапсан» приведено в Таблица 1. Таблица 1 – Расписание ВСП «Сапсан» Станция Москва Тверь Бологое СпБ Прибытие Отправление Расстояние, км Время в пути, час 17:30 18:00 19:30 16:30 17:32 18:02 - 0 200 300 600 1 0.5 1.5 Расписание скорого поезда №1000 приведено в Таблице 2. 67 Таблица 2 – Расписание скорого поезда №1000 Станция Прибытие Отправление Расстояние, км Время в пути, час 15:00 16:00 19:00 13:00 15:05 16:05 - 0 200 300 600 2 1 3 Москва Тверь Бологое СпБ Инфраструктура направления Москва – Санкт-Петербург при принятых предположениях включает 4 станции (Москва (М) с тремя станционными блок-участками), Тверь (Т) с двумя станционными блок-участками, Бологое (Б) с двумя станционными блок-участками, Санкт-Петербург (СпБ) с тремя станционными блок-участками), 9 блок-участков на перегонах (1.1, 2.1, 3.1, 4.1, 4.2, 5.1, 5.2, 6.1, 6.2) и 2 стрелки (Рисунок 1.7). Рисунок 1.7 – Инфраструктура направления Москва – Санкт-Петербург 1.5.5.1 Планирование одного поезда В систему добавляется потребность в планировании скорого поезда №1000. На основании данных о его расписании и инфраструктуре направления строится заданный маршрут движения между станциями (Таблица 3). Таблица 3– Заданный маршрут движения скорого поезда №1000 Маршрут ЗМД-1 Станция отправления Москва Станция прибытия Тверь 68 Элементы пути 1. Блок-участок М.1 0 км – 1 км свободен Start: 13:00 Finish: 13:01 Маршрут Станция отправления Станция прибытия ЗМД-2 Тверь Бологое ЗМД-3 Бологое СпБ 69 Элементы пути 2. Блок-участок 1.1 1 км – 100 км свободен Start: 13:01 Finish: 14:00 3. Блок-участок 2.1 100 км – 200 км свободен Start: 14:00 Finish: 14:59 4. Блок-участок Т.1 200 км – 201 км свободен Start: 14:59 Finish: 15:00 1. Блок-участок Т.1 200 км – 201 км свободен Start: 15:05 Finish: 15:06 2. Блок-участок 3.1 201 км – 300 км свободен Start: 15:06 Finish: 15:59 3. Блок-участок Б.1 300 км – 301 км свободен Start: 15:59 Finish: 16:00 1. Блок-участок Б.1 300 км – 301 км свободен Start: 16:05 Finish: 16:06 2. Стрелка 1 301 км свободен Start: 16:06 Finish: 16:07 3. Блок-участок 4.1 301 км – 400 км свободен Start: 16:07 Finish: 17:00 4. Блок-участок 5.1 400 км – 500 км свободен Start: 17:00 Finish: 18:00 Маршрут Станция отправления Станция прибытия Элементы пути 5. Блок-участок 6.1 500 км – 600 км свободен Start: 18:00 Finish: 18:58 6. Стрелка 2 600 км свободен Start: 18:58 Finish: 18:59 7. Блок-участок СпБ.1 600 км – 601 км свободен Start: 18:59 Finish: 19:00 Мультиагентный планировщик формирует расписание движения скорого поезда №1000 (Таблица 4). Фактически каждая строка расписания соответствует потребности в выполнении определенного действия в течение заданного интервала времени, например, движение на блок-участке 1.1 с 13:01 до 14:00 или останов на станции Тверь с 15:00 до 15:05. Сцена с запланированным расписанием движения скорого поезда №1000 приведена на Рисунок 1.8. Таблица 4 – Запланированное расписание движения скорого поезда №1000 № Элемент пути 1 2 3 4 5 6 7 8 9 Блок-участок М.1 Блок-участок 1.1 Блок-участок 2.1 Блок-участок Т.1 Станция Тверь Блок-участок Т.1 Блок-участок 3.1 Блок-участок Б.1 Станция Бологое Скорость, км/ч 100 Состояние Start Движение 13:00 Starte d false 100 Движение 13:01 100 Движение 100 Finish Finished 13:01 false false 14:00 false 14:00 false 14:59 false Движение 14:59 false 15:00 false 0 Останов 15:00 false 15:05 false 100 Движение 15:05 false 15:06 false 100 Движение 15:06 false 15:59 false 100 Движение 15:59 false 16:00 false 0 Останов 16:00 false 16:05 false 70 № Элемент пути 10 11 12 13 14 15 16 Блок-участок Б.1 Cтрелка 1 Блок-участок 4.1 Блок-участок 5.1 Блок-участок 6.1 Cтрелка 2 Блок-участок СпБ.1 Скорость, км/ч 100 Состояние Start Движение 16:05 Starte d false 100 100 Движение Движение 16:06 16:07 100 Движение 100 100 100 Finish Finished 16:06 false false false 16:07 17:00 false false 17:00 false 18:00 false Движение 18:00 false 18:58 false Движение Движение 18:58 18:59 false false 18:59 19:00 false false 1.5.5.2 Перепланирование расписания поезда в связи с отклонением его движения от плана В процессе движения поезда в систему поступают фактические данные о его реальном местонахождении. До тех пока поезд не отклоняется от графика, заданный маршрут движения совпадает с расписанием, запланированным планировщиком. При этом наблюдается совпадение плана и факта, поэтому конфликт между планом и фактом не возникает. Пусть в систему поступает событие о реальном местонахождении поезда с отклонением от плана: поезд №1000, который следовал согласно расписанию, в 17:00 вошел на блокучасток 5.1, где в 17:10 произошла авария, на устранение которой требуется 50 мин. Поезд №1000 останавливается на блок-участке 5.1. Возникает конфликт между потребностью в движении поезда по блок-участку 5.1 с 17:00 до 18:00 и фактом останова поезда в 17:10. Объекты сцены мгновенно реагируют на событие следующим образом: а) объект «Поезд №1000» изменяет свое состояние с «движение» на «останов»; б) т.к. других поездов в сцене нет, без переговоров между агентами выполняется пересчет расписания поезда №1000 и добавление в него строк, соответствующих следующим операциям: 1) останов на блок участке 5.1 с 17:10 до 18:00; 2) движение по блок-участку 5.1 с 18:00 до 19:00; 3) движение по блок-участку 6.1 с 19:00 до 19:58; 71 Время прохождения Время прохождения Время прохождения Время прохождения Время прохождения Время прохождения Время прохождения -Start: 13:00 -Finish: 14:00 -Start: 14:00 -Finish: 15:00 -Start: 15:05 -Finish: 16:00 -Start: 16:05 -Finish: 16:06 -Start: 16:06 -Finish: 17:00 -Start: 17:00 -Finish: 18:00 -Start: 18:00 -Finish: 19:00 Блок-участок 1.1 Блок-участок 2.1 Блок-участок 3.1 -0 км -100 км -свободен -след. - 2.1 -100 км -200 км -свободен -след. - 3.1 -200 км -300 км -свободен -след. - 4.1 Стрелка 1 -300 км Блок-участок 4.1 Блок-участок 5.1 Блок-участок 6.1 -300 км -400 км -свободен -след. - 5.1 -400 км -500 км -свободен -след. - 6.1 -500 км -600 км -свободен -след. - нет Запланировать поезд -Кол-во остановок - 4 ЗМД 1 Блок-участок 5.2 Блок-участок 5.2 Блок-участок 6.2 -300 км -400 км -свободен -след. - 5.2 -400 км -500 км -свободен -след. - 6.2 -500 км -600 км -свободен -след. - нет -Москва -Тверь ISheduleTrain -Кол-во строк в расписании - 4 -Поезд №158 Строка расписания 1 Станция 1 -Москва -№1 -Москва -нет -13:00 -Входящий - нет -Исходящий - ЗМД1 Строка расписания 2 Станция 2 -Тверь -№2 -Тверь -15:00 -15:05 -Входящий - ЗМД1 -Исходящий - ЗМД 2 ЗМД 2 -Тверь -Бологое Строка расписания 3 Поезд -№1000 -Москва-СПб -Скорый -15 вагонов -375 м -Движение Станция 3 -Бологое Станция 4 -СпБ -№3 -Бологое -16:00 -16:05 -Входящий - ЗМД 2 -Исходящий - ЗМД 3 ЗМД 3 -Бологое -СпБ Строка расписания 4 -№4 -СпБ -19:00 -нет -Входящий - ЗМД 3 -Исходящий - нет Строка плана 1 -№1 -100 км/ч -Движение ITemporaryRelation -Conflicted: false -Start: 13:00 -Started: false -Finish: 14:00 -Finished: false Строка плана 2 -№2 -100 км/ч -Движение Строка плана 3 -№3 -0 км/ч -Останов ITemporaryRelationITemporaryRelation -Conflicted: false -Start: 14:00 -Started: false -Finish: 15:00 -Finished: false -Conflicted: false -Start: 15:00 -Started: false -Finish: 15:05 -Finished: false Строка плана 4 -№4 -100 км/ч -Движение ITemporaryRelation -Conflicted: false -Start: 15:05 -Started: false -Finish: 16:00 -Finished: false Строка плана 5 -№5 -0 км/ч -Останов ITemporaryRelation -Conflicted: false -Start: 16:00 -Started: false -Finish: 16:05 -Finished: false Строка плана 6 -№6 -100 км/ч -Движение ITemporaryRelation -Conflicted: false -Start: 16:05 -Started: false -Finish: 17:00 -Finished: false Строка плана 7 -№7 -100 км/ч -Движение ITemporaryRelation -Conflicted: false -Start: 17:00 -Started: false -Finish: 18:00 -Finished: false Рисунок 1.8 – Сцена с запланированным расписанием движения скорого поезда №1000 72 Строка плана 8 -№8 -100 км/ч -Движение ITemporaryRelation -Conflicted: false -Start: 18:00 -Started: false -Finish: 19:00 -Finished: false 4) движение по стрелке 2 с 19:58 до 19:59; 5) движение по станционному блок-участку СпБ.1 с 19:59 до 20:00. Таким образом, прибытие поезда №1000 в Санкт-Петербург перепланировано на 20:00 с опозданием на 1 час. Происходит отклонение фактического расписания, построенного планировщиком, от заданного маршрута движения на 1 час по времени, но движение будет выполняться на ранее запланированных блок-участках, т.к. они свободны. Мультиагентный планировщик изменит расписание поезда №1000 следующим образом (Таблица 5). Таблица 5 – Перепланированное расписание движения скорого поезда №1000 № Элемент пути Скорость, км/ч Состояние Start Started Finish Finished 1 Блок-участок М.1 100 Движение 13:00 true 13:01 true 2 Блок-участок 1.1 100 Движение 13:01 true 14:00 true 3 Блок-участок 2.1 100 Движение 14:00 true 14:59 true 4 Блок-участок Т.1 100 Движение 14:59 true 15:00 true 5 Станция Тверь 0 Останов 15:00 true 15:05 true 6 Блок-участок Т.1 100 Движение 15:05 true 15:06 true 7 Блок-участок 3.1 100 Движение 15:06 true 15:59 true 8 Блок-участок Б.1 100 Движение 15:59 true 16:00 true 9 Станция Бологое 0 Останов 16:00 true 16:05 true 10 Блок-участок Б.1 100 Движение 16:05 true 16:06 true 11 Cтрелка 1 100 Движение 16:06 true 16:07 true 12 Блок-участок 4.1 100 Движение 16:07 true 17:00 true 13 Блок-участок 5.1 100 Движение 17:00 true 17:10 true 14 Блок-участок 5.1 0 Останов 17:10 true 18:00 false 15 Блок-участок 5.1 100 Движение 18:00 false 19:00 false 16 Блок-участок 6.1 100 Движение 19:00 false 19:58 false 17 Cтрелка 2 Блок-участок СпБ.1 100 Движение 19:58 false 19:59 false 100 Движение 19:59 false 20:00 false 18 Сцена с перепланированным расписанием движения скорого поезда №1000 приведена на Рисунок 1.9. 73 Время прохождения Время прохождения Время прохождения Время прохождения Время прохождения Время прохождения Время прохождения -Start: 13:00 -Finish: 14:00 -Start: 14:00 -Finish: 15:00 -Start: 15:05 -Finish: 16:00 -Start: 16:05 -Finish: 16:06 -Start: 16:06 -Finish: 17:00 -Start: 17:00 -Finish: 18:00 -Start: 18:00 -Finish: 19:00 Блок-участок 1.1 Блок-участок 2.1 Блок-участок 3.1 -0 км -100 км -свободен -след. - 2.1 -100 км -200 км -свободен -след. - 3.1 -200 км -300 км -свободен -след. - 4.1 Стрелка 1 -300 км Блок-участок 4.1 Блок-участок 5.1 Блок-участок 6.1 -300 км -400 км -свободен -след. - 5.1 -400 км -500 км -занят -след. - 6.1 -500 км -600 км -свободен -след. - нет Запланировать поезд -Кол-во остановок - 4 ЗМД 1 Блок-участок 5.2 Блок-участок 5.2 Блок-участок 6.2 -300 км -400 км -свободен -след. - 5.2 -400 км -500 км -свободен -след. - 6.2 -500 км -600 км -свободен -след. - нет -Москва -Тверь ISheduleTrain -Кол-во строк в расписании - 4 -Поезд №158 Строка расписания 1 Станция 1 -Москва -№1 -Москва -нет -13:00 -Входящий - нет -Исходящий - ЗМД1 Строка расписания 2 Станция 2 -Тверь -№2 -Тверь -15:00 -15:05 -Входящий - ЗМД1 -Исходящий - ЗМД 2 ЗМД 2 -Тверь -Бологое Строка расписания 3 Поезд -№1000 -Москва-СПб -Скорый -15 вагонов -375 м -Останов Станция 3 -Бологое Станция 4 -СпБ -№3 -Бологое -16:00 -16:05 -Входящий - ЗМД 2 -Исходящий - ЗМД 3 ЗМД 3 -Бологое -СпБ Строка расписания 4 -№4 -СпБ -19:00 -нет -Входящий - ЗМД 3 -Исходящий - нет Строка плана 1 -№1 -100 км/ч -Движение ITemporaryRelation -Conflicted: false -Start: 13:00 -Started: true -Finish: 14:00 -Finished: true Строка плана 2 -№2 -100 км/ч -Движение Строка плана 3 -№3 -0 км/ч -Останов ITemporaryRelationITemporaryRelation -Conflicted: false -Start: 14:00 -Started: true -Finish: 15:00 -Finished: true -Conflicted: false -Start: 15:00 -Started: true -Finish: 15:05 -Finished: true Строка плана 4 -№4 -100 км/ч -Движение ITemporaryRelation -Conflicted: false -Start: 15:05 -Started: true -Finish: 16:00 -Finished: true Строка плана 5 -№5 -0 км/ч -Останов ITemporaryRelation -Conflicted: false -Start: 16:00 -Started: true -Finish: 16:05 -Finished: true Строка плана 6 -№6 -100 км/ч -Движение ITemporaryRelation -Conflicted: false -Start: 16:05 -Started: true -Finish: 17:00 -Finished: true Строка плана 7 -№7 -100 км/ч -Движение ITemporaryRelation -Conflicted: false -Start: 17:00 -Started: true -Finish: 17:10 -Finished: true Строка плана 8 -№8 -0 км/ч -Останов ITemporaryRelation -Conflicted: false -Start: 17:10 -Started: true -Finish: 18:00 -Finished: false Строка плана 9 -№9 -100 км/ч -Движение ITemporaryRelation -Conflicted: false -Start: 18:00 -Started: false -Finish: 19:00 -Finished: false Рисунок 1.9 – Сцена с перепланированным расписанием движения скорого поезда №1000 74 Строка плана 10 -№10 -100 км/ч -Движение ITemporaryRelation -Conflicted: false -Start: 19:00 -Started: false -Finish: 20:00 -Finished: false 1.5.5.3 Пропуск ВСП «Сапсан» на станции в связи с отклонением движения впереди идущего поезда от плана В системе имеется две потребности в планировании поездов: а) скорый поезд №1000; б) ВСП «Сапсан». На основании данных о расписании скорого поезда №1000 и инфраструктуре направления строится заданный маршрут его движения между станциями (Таблица 3). На основании данных о расписании ВСП «Сапсан» и инфраструктуре направления строится заданный маршрут его движения между станциями (Таблица 6). Таблица 6 – Заданный маршрут движения ВСП «Сапсан» Маршрут Станция отправления Станция прибытия ЗМД-1 Москва Тверь ЗМД-2 Тверь Бологое 75 Элементы пути 1. Блок-участок М.1 0 км – 1 км свободен Start: 16:30 Finish: 16:31 2. Блок-участок 1.1 1 км – 100 км свободен Start: 16:31 Finish: 17:00 3. Блок-участок 2.1 100 км – 200 км свободен Start: 17:00 Finish: 17:29 4. Блок-участок Т.1 200 км – 201 км свободен Start: 17:29 Finish: 17:30 1. Блок-участок Т.1 200 км – 201 км свободен Start: 17:32 Finish: 17:33 2. Блок-участок 3.1 201 км – 300 км свободен Start: 17:33 Finish: 17:59 Маршрут ЗМД-3 Станция отправления Станция прибытия Бологое СпБ Элементы пути 3. Блок-участок Б.1 300 км – 301 км свободен Start: 17:59 Finish: 18:00 1. Блок-участок Б.1 300 км – 301 км свободен Start: 18:02 Finish: 18:03 2. Стрелка 1 301 км свободен Start: 18:03 Finish: 18:04 3. Блок-участок 4.1 301 км – 400 км свободен Start: 18:04 Finish: 18:30 4. Блок-участок 5.1 400 км – 500 км свободен Start: 18:30 Finish: 19:00 5. Блок-участок 6.1 500 км – 600 км свободен Start: 19:00 Finish: 19:28 6. Стрелка 2 600 км свободен Start: 19:28 Finish: 19:29 7. Блок-участок СпБ.1 600 км – 601 км свободен Start: 19:29 Finish: 19:30 Мультиагентный планировщик формирует расписание движения ВСП «Сапсан» (Таблица 7) . 76 Таблица 7 – Запланированное расписание движения ВСП «Сапсан» № 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Элемент пути Блок-участок М.1 Блок-участок 1.1 Блок-участок 2.1 Блок-участок Т.1 Станция Тверь Блок-участок Т.1 Блок-участок 3.1 Блок-участок Б.1 Станция Бологое Блок-участок Б.1 Cтрелка 1 Блок-участок 4.1 Блок-участок 5.1 Блок-участок 6.1 Cтрелка 2 Блок-участок СпБ.1 Скорость, км/ч Состояние Start Started Finish Finished 200 Движение 16:30 false 16:31 false 200 Движение 16:31 false 17:00 false 200 Движение 17:00 false 17:29 false 200 Движение 17:29 false 17:30 false 0 Останов 17:30 false 17:32 false 100 Движение 17:32 false 17:33 false 200 Движение 17:33 false 17:59 false 200 Движение 17:59 false 18:00 false 0 Останов 18:00 false 18:02 false 200 Движение 18:02 false 18:03 false 200 200 Движение Движение 18:03 18:04 false false 18:04 18:30 false false 200 Движение 18:30 false 19:00 false 200 Движение 19:00 false 19:28 false 200 200 Движение Движение 19:28 19:29 false false 19:29 19:30 false false На Рисунке 1.10 показаны графики движения ВСП «Сапсан» (синий цвет) и скорого поезда №1000 (зеленый цвет). Графики не пересекаются. Рисунок 1.10 – Графики движения ВСП «Сапсан» и скорого поезда №100 77 На Рисунке 1.11 показаны маршруты движения ВСП «Сапсан» (синий цвет) и скорого поезда №1000 (зеленый цвет). На маршрутах движения конфликты отсутствуют. Рисунок 1.11 – Маршруты движения ВСП «Сапсан» и скорого поезда №1000 Пусть в систему приходит событие, что отправление поезда №1000 из Москвы по техническим причинам задерживается на 1 час. Мультиагентный планировщик пересчитывает расписание поезда №1000 следующим образом (Таблица 8). Таблица 8 – Пересчитанное расписание движения скорого поезда №1000 № Элемент пути Скорость, км/ч Состояние Start Started Finish Finished 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Блок-участок М.1 Блок-участок 1.1 Блок-участок 2.1 Блок-участок Т.1 Станция Тверь Блок-участок Т.1 Блок-участок 3.1 Блок-участок Б.1 Станция Бологое Блок-участок Б.1 Cтрелка 1 Блок-участок 4.1 Блок-участок 5.1 Блок-участок 6.1 Cтрелка 2 Блок-участок СпБ.1 100 100 100 100 0 100 100 100 0 100 100 100 100 100 100 100 Движение Движение Движение Движение Останов Движение Движение Движение Останов Движение Движение Движение Движение Движение Движение Движение 14:00 14:01 15:00 15:59 16:00 16:05 16:06 16:59 17:00 17:05 17:06 17:07 18:00 19:00 19:58 19:59 false false false false false false false false false false false false false false false false 14:01 15:00 15:59 16:00 16:05 16:06 16:59 17:00 17:05 17:06 17:07 18:00 19:00 19:58 19:59 20:00 false false false false false false false false false false false false false false false false 16 На основании сравнения запланированного расписания движения ВСП «Сапсан» (Таблица 7) и пересчитанного расписания поезда №1000 (Таблица 8) следует, что в 18:30 на 78 блок-участок 5.1, который согласно пересчитанному расписанию с 18:00 до 19:00 занят впереди идущим поездом №1000, должен войти ВСП «Сапсан». В системе наблюдается пересечение графиков движения ВСП «Сапсан» и скорого поезда №1000 ( Рисунок 1.12). На блок-участке 5.1 возникает конфликт между потребностью движения ВСП «Сапсан» и занятостью блок-участка (Рисунок 1.13). Рисунок 1.12 – Графики движения ВСП «Сапсан» и скорого поезда №100 пересекаются Рисунок 1.13 – Конфликт заданного маршрута движения ВСП «Сапсан» и пересчитанного расписания скорого поезда №1000 на блок-участке 5.1 Для разрешения конфликта планировщик выполняет следующие действия: а) перевод поезда №1000 со станционного блок-участка Б.1 на станционный блок участок Б.2 для пропуска ВСП «Сапсан» по станционному блок-участку Б.1; б) останов поезда №1000 на станции Бологое с 17:00 до 18:01 (станционный блокучасток Б.2) для пропуска ВСП «Сапсан»; в) перевод поезда №1000 со станционного блок-участка Б.2 на станционный блокучасток Б.1 для дальнейшего движения по заданному маршруту. В Таблица 9 представлено перепланированное расписание движения скорого поезда №1000. В результате перепланирования конфликт между потребностью движения ВСП «Сапсан» по блок-участку 5.1 и занятостью блок-участка 5.1 устранен. 79 Таблица 9 – Перепланированное расписание движения скорого поезда №1000 № 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 Элемент пути Блок-участок М.1 Блок-участок 1.1 Блок-участок 2.1 Блок-участок Т.1 Станция Тверь Блок-участок Т.1 Блок-участок 3.1 Блок-участок Б.1 Стрелка Б.1 – Б.2 Станция Бологое Стрелка Б.2 – Б.1 Блок-участок Б.1 Cтрелка 1 Блок-участок 4.1 Блок-участок 5.1 Блок-участок 6.1 Cтрелка 2 Блок-участок СпБ.1 Скорость, км/ч Состояние Start Started Finish Finished 100 Движение 14:00 false 14:01 false 100 Движение 14:01 false 15:00 false 100 Движение 15:00 false 15:59 false 100 Движение 15:59 false 16:00 false 0 Останов 16:00 false 16:05 false 100 Движение 16:05 false 16:06 false 100 Движение 16:06 false 16:59 false 100 Движение 16:59 false 17:00 false 100 Движение 17:00 false 17:01 false 0 Останов 17:01 false 18:04 false 100 Движение 18:04 false 18:05 false 100 Движение 18:05 false 18:06 false 100 100 Движение Движение 18:06 18:07 false false 18:07 19:00 false false 100 Движение 19:00 false 20:00 false 100 Движение 20:00 false 20:58 false 100 100 Движение Движение 20:58 20:59 false false 20:59 21:00 false false На Рисунке 1.14 показаны маршруты движения ВСП «Сапсан» (синий цвет) и скорого поезда №1000 (зеленый цвет) после перепланирования. 80 Рисунок 1.14 – Маршруты движения ВСП «Сапсан» и скорого поезда №1000 после перепланирования В результате перепланирования, отклонения движения ВСП «Сапсан» от расписания не произойдет. 1.5.5.4 Перепланирование расписания ВСП «Сапсан» в связи с отклонением движения впереди идущего поезда от плана В системе имеется две потребности в планировании поездов: а) скорый поезд №1000; б) ВСП «Сапсан». На основании данных о расписании скорого поезда №1000 и инфраструктуре направления строится заданный маршрут его движения между станциями (Таблица 3). На основании данных о расписании ВСП «Сапсан» и инфраструктуре направления строится заданный маршрут его движения между станциями (Таблица 6). Мультиагентный планировщик формирует расписание движения ВСП «Сапсан» (Таблица 7) . Графики движения ВСП «Сапсан» и скорого поезда №1000 не пересекаются (Рисунок 1.10). Пусть в систему приходит событие, что идущий впереди поезд №1000 задерживается на блок-участке 5.1 до 19:00. Мультиагентный планировщик изменит расписание поезда №1000 (Таблица 5). В системе наблюдается пересечение графиков движения ВСП «Сапсан» и скорого поезда №1000 (Рисунок 1.15). В результате, на блок-участке 5.1 возникает конфликт заданных маршрутов движения ВСП «Сапсан» и скорого поезда №1000 (Рисунок 1.16). 81 Рисунок 1.15 – Графики движения ВСП «Сапсан» и скорого поезда №100 пересекаются Рисунок 1.16– Конфликт заданных маршрутов движения ВСП «Сапсан» и скорого поезда №1000 в случае пересечения графиков их движения на блок-участке 5.1 Для разрешения конфликта планировщик выполняет следующие действия с учетом того, что перевести поезд №1000 с блок-участка 5.1 невозможно (Таблица 10): а) перевод ВСП «Сапсан» со станционного блок-участка Б.1 на блок участок 4.2 по Стрелке 1; б) движение ВСП «Сапсан» по блок-участку 5.2; в) движение ВСП «Сапсан» по блок-участку 6.2. Таблица 10 – Перепланированное расписание движения ВСП «Сапсан» № 1 2 3 4 5 6 Элемент пути Блок-участок М.1 Блок-участок 1.1 Блок-участок 2.1 Блок-участок Т.1 Станция Тверь Блок-участок Т.1 Скорость, км/ч Состояние Start Started Finish Finished 200 Движение 16:30 false 16:31 false 200 200 200 0 200 Движение Движение Движение Останов Движение 16:31 17:00 17:29 17:30 17:32 false false false false false 17:00 17:29 17:30 17:32 17:33 false false false false false 82 № Элемент пути Скорость, км/ч Состояние Start Started Finish Finished 7 8 9 10 11 12 13 14 15 Блок-участок 3.1 Блок-участок Б.1 Станция Бологое Блок-участок Б.1 Cтрелка 1 Блок-участок 4.2 Блок-участок 5.2 Блок-участок 6.2 Cтрелка 2 Блок-участок СпБ.1 200 200 0 200 200 200 200 200 200 200 Движение Движение Останов Движение Движение Движение Движение Движение Движение Движение 17:33 17:59 18:00 18:02 18:03 18:04 18:30 19:00 19:28 19:29 false false false false false false false false false false 17:59 18:00 18:02 18:03 18:04 18:30 19:00 19:28 19:29 19:30 false false false false false false false false false false 16 На Рисунке 1.17 показаны маршруты движения ВСП «Сапсан» (синий цвет) и скорого поезда №1000 (зеленый цвет) после перепланирования. Рисунок 1.17 – Маршруты движения ВСП «Сапсан» и скорого поезда №1000 после перепланирования В результате перепланирования конфликт между потребностью движения ВСП «Сапсан» по блок-участку 5.1 и занятостью блок-участка 5.1 устранен, отклонения движения ВСП «Сапсан» от расписания не произойдет. 1.5.5.5 Разложение требования на подтребования Объект «Требование» (IODemand), описывающий, что необходимо запланировать, может иметь подтребования. Например, задача «Доставить ВСП «Сапсан» по расписанию» разворачивается в набор подзадач о прохождении элементов пути. При этом каждая подзадача о прохождении элемента пути имеет потребность в элементе пути (подтребование). Элементы пути при этом рассматриваются как ресурсы. Потребности динамически формируются и исчезают по мере выполнения соответствующих подзадач. Потребности взаимодей- 83 ствуют между собой, вступая в конфликты за ресурсы и разрешая эти конфликты путем переговоров агентов. Рассмотрим три задачи: а) доставить ВСП «Сапсан» по расписанию (Требование 1); б) доставить скорый поезд №1000 по расписанию (Требование 2)4 в) организовать окна для выполнения ремонтных работ (Требование 3). Каждая из этих задач может быть разбита на подзадачи, имеющие потребности в элементах пути (Таблица 11– Таблица 13). Для простоты в качестве потребностей рассмотрим только блок-участки на перегонах. Будем считать, что все окна непроездные. Движение поездов имеет приоритет перед выполнением ремонтных работ. Таблица 11 – Потребности задачи «Доставить скорый поезд №1000 по расписанию» Подзадача Перегон Москва-Тверь Перегон Тверь-Бологое Перегон Бологое-СпБ Потребность в элементах пути Временные отношения Блок-участок 1.1 Блок-участок 2.1 Блок-участок 3.1 Блок-участок 4.1 Блок-участок 5.1 Блок-участок 6.1 13:00 – 14:00 14:00 – 15:00 15:00 – 16:00 16:00 – 17:00 17:00 – 18:00 18:00 – 19:00 Таблица 12 – Потребности задачи «Доставить ВСП «Сапсан» по расписанию» Подзадача Перегон Москва-Тверь Перегон Тверь-Бологое Перегон Бологое-СпБ Потребность в элементах пути Временные отношения Блок-участок 1.1 Блок-участок 2.1 Блок-участок 3.1 Блок-участок 4.1 Блок-участок 5.1 Блок-участок 6.1 16:30 – 17:00 17:00 – 17:30 17:30 – 18:00 18:00 – 18:30 18:30 – 19:00 19:00 – 19:30 Таблица 13 – Потребности задачи «Организовать окна для выполнения ремонтных работ» Подзадача Потребность в элементах пути Временные отношения Перегон Москва-Тверь (окно 1, окно 2) Перегон Тверь-Бологое (окно 3) Перегон Бологое-СпБ (окно 4) Блок-участок 1.1 Блок-участок 2.1 Блок-участок 3.1 Блок-участок 4.1 14:00 – 15:00 15:00 – 17:00 16:00 – 17:00 17:00 – 18:00 84 На Рисунке 1.18 показаны потребности для каждой из задач: потребности Задачи 1 – синим цветом, потребности Задачи 2 – зеленым цветом, потребности Задачи 3 – оранжевым цветом. Потребности всех задач удовлетворяются без конфликтов. Блок-участок 6 Блок-участок 5 Окно 4 Блок-участок 4 Окно 3 Блок-участок 3 Окно 2 Блок-участок 2 Окно 1 Блок-участок 1 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00 Рисунок 1.18 – Потребности Задачи 1, Задачи 2, Задачи 3 удовлетворяются без конфликтов Пусть в систему приходит событие, что отправление поезда №1000 из Москвы по техническим причинам задерживается на 1 час. Мультиагентный планировщик перепланирует расписание поезда №1000 так, что он пропускает ВСП «Сапсан» на станции Бологое (Таблица 9). В результате, потребности Задачи 3 в элементах пути вступают в конфликт с потребностями Задачи 1 и Задачи 2. Наблюдается наложение окон на запланированное движение поездов по блок-участкам 1, 2 и 3 (Рисунок 1.19). Т.к. все окна непроездные, движение поездов по блок-участкам с ограниченной скоростью во время окон невозможно. Т.к. движение поездов имеет приоритет перед выполнением ремонтных работ, конфликт разрешается в результате переговоров агентов потребностей и ресурсов следующим образом (Таблица 14): а) окно 1 сдвигается на более позднее время; б) окно 2 разбивается на два подокна (2.1 и 2.2), каждое из подокон сдвигается на более позднее время; в) окно 3 сдвигается на более раннее время. 85 Блок-участок 6 Блок-участок 5 Окно 4 Блок-участок 4 Окно 3 Блок-участок 3 Окно 2 Блок-участок 2 Окно 1 Блок-участок 1 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00 21:00 Рисунок 1.19 – Потребности Задачи3 вступают в конфликт с потребностями Задачи 1 и Задачи 2 Таблица 14 – Изменение потребностей задачи «Организовать окна для выполнения ремонтных работ» Подзадача Перегон Москва-Тверь (окно 1, окно 2.1, окно 2.2) Перегон Тверь-Бологое (окно 3) Перегон Бологое-СпБ (окно 4) Потребность в элементах пути Временные отношения Блок-участок 1.1 15:00 – 16:00 16:00 – 17:00 17:30 – 18:30 15:00 – 16:00 17:00 – 18:00 Блок-участок 2.1 Блок-участок 3.1 Блок-участок 4.1 Разрешение конфликта показано на Рисунок 1.20. 86 Блок-участок 6 Блок-участок 5 Окно 4 Блок-участок 4 Окно 3 Блок-участок 3 Окно 2.1 Блок-участок 2 Окно 2.2 Окно 1 Блок-участок 1 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00 21:00 Рисунок 1.20 – Конфликты между потребностями Задачи3 и Задачи 1, Задачи 2 устранены 1.5.5.6 Выбор альтернативного пути для нахождения свободного блокучастка на станции Рассмотрим упрощенную схему блок-участков и стрелок на станции (Рисунок 1.21). Схема содержит 3 станционных блок-участка: БУ1, БУ2, БУ3 и 4 стрелочных перевода: С1 для перевода с БУ1 на БУ2, С2 для перевода с БУ2 на БУ3, С3 для перевода с БУ3 на БУ2, С4 для перевода с БУ3 на БУ4. Рисунок 1.21 – Схема блок-участков и стрелок на станции Фрагмент расписания, соответствующий схеме блок-участков, приведенной на Рисунке 1.21, показан на Рисунке 1.22. Блок-участок и стрелка являются элементами пути, временные отношения для элемента пути задает объект ItemporaryRelation. 87 Время прохождения -Start: -Finish: Время прохождения -Start: -Finish: БУ1.1 -0 км -100 км -свободен -след. - 1.2 Время прохождения Время прохождения -Start: -Finish: -Start: -Finish: БУ1.2 Стрелка 1: БУ1.1-БУ2.1 -100 км Время прохождения -Start: -Finish: Время прохождения -Start: -Finish: БУ1.3 -0 км -100 км -свободен -след. -1.3 Стрелка 4: БУ2.1-БУ1.3 -101 км Время прохождения -Start: -Finish: -0 км -101 км -свободен -след. - 1.4 Время прохождения -Start: -Finish: БУ2.1 Стрелка 2: БУ2.1-БУ3.1 -100 км -0 км -100 км -свободен -след. - нет Стрелка 3: БУ3.1-БУ2.1 -101 км Время прохождения -Start: -Finish: БУ3.1 -0 км -100 км -свободен -след. - нет Рисунок 1.22 – Элементы расписания, соответствующего схеме блок-участков на станции Для того чтобы выбрать маршрут движения поезда по станционным блок-участкам, необходимо располагать информацией о занятости блок-участков. Пусть необходимо пропустить через станцию поезд, идущий по блок-участку БУ1, при условии, что станционные блок-участки БУ1.2 и БУ2.1 заняты, признак занятости должен быть указан в элементах расписания для блок-участков. Для поезда формируется альтернативный маршрут движения БУ1.1 – С1 – С2 – БУ3.1 – С3 – С4 – БУ1.3 (Рисунок 1.23). Рисунок 1.23 – Маршрут движения поезда на станции 88 Задача формирования альтернативного маршрута движения поезда по стрелочным переводам может быть сведена к решению задачи о нахождении кратчайшего пути в ориентированном взвешенном графе, в котором блок-участки и стрелки следует рассматртивать как ребра, а вершины – как точки разветвления путей. Под весом ребра следует рассматривать продолжительность занятости блок-участка движущимся или стоящим поездом. Кратчайшим будем считать маршрут с минимальной суммарной занятостью блок-участков и стрелок. Если имеется несколько свободных путей, алгоритм нахождения кратчайшего пути позволяет выбрать ближайший свободный путь и минимизировать количество стрелочных переводов. Задача пропуска через станцию поезда, идущего по блок-участку Б1, сводится к нахождению кратчайшего пути между вершинами графа A и F (Рисунок 1.24). Предположим, что станционный блок-участок Б 1.2 занят на 50 мин, станционный блок-участок Б 2.1 занят на 30 мин, а станционный блок-участок Б 3.1 свободен, т.е. занят на 0 мин. Продолжительность прохождения стрелок примем равной 1 мин. Рисунок 1.24 – Постановка задачи нахождения кратчайшего пути в графе В результате решения задачи будет найден кратчайший путь между вершинами A и F: A – B – C – D – E – F, который соответствует маршруту БУ1.1 – С1 – С2 – БУ3.1 – С3 – С4 – БУ1.3 (Рисунок 1.18) 1.5.5.7 Быстрое реагирование на текущую ситуацию и разрешение конфликтов в локальной области Рассмотрим пример, когда несколько требований уже разместились в расписании некоторого Блок-участка на соответствующих временных интервалах: пассажирский поезд №200, грузовой поезд №500, Окно для проведения ремонтных работ и ВСП «Сапсан» (Таблица 15, Рисунок 1.25). 89 Таблица 15 – Требования по прохождению Блок-участка Блок-участок Требования Временные отношения Поезд №200 Поезд №500 Окно ВСП «Сапсан» 13:00 – 14:00 13:30 – 15:00 15:30 – 16:30 17:00 – 17:30 №200 №500 13:00 14:00 Окно 15:00 16:00 17:00 18:00 19:00 Рисунок 1.25 – Запланированное расписание Блок-участка Пусть в 13:00 приходит событие, что поезд №200 задерживается на станции до 15:15. Необходимо перепланирование расписания, чтобы требование о прохождении БУ поездом №200 встало в расписании на 15:15. Агент поезда №200 пытается встать на требуемое ему место в расписании и, как видно из Рисунок 1.26 сразу обнаруживает конфликт с агентом Окна с перекрытием на дельту Д1, равную 45 мин (пунктир). Тогда агент поезда №200 решает, не может ли он уйти от конфликта, сдвинувшись влево, но тут наталкивается на агента поезда №500, при этом зона конфликта уменьшается до 30 мин (дельта Д2). Пусть поезд №200 может сдвинуться влево за счет того, что сократит стоянку на станции на 15 мин до 15:00. Теперь агент поезда №200 решает, что делать дальше. Либо попросить агента поезда №500 сдвинуться влево на дельту Д2, либо попросить агента Окна сдвинуться вправо на ту же дельту Д2, причем можно попробовать оба варианта последовательно, либо запустить эти опции параллельно. При этом «параллельность» будет состоять в том, чтобы не перебирать все варианты последовательно до конца, один за другим, а начать их исследовать все сразу, но постоянно сопоставлять прогресс и «обрывать» нити вариантов как можно быстрее, по мере того, как в ходе переговоров выявляются серьезные ограничения. 90 №200 Шаг 1 №500 Окно Блок-участок Д1 13:00 14:00 15:00 16:00 17:00 18:00 19:00 17:00 18:00 19:00 №200 Шаг 2 Окно №500 Блок-участок Д2 13:00 14:00 15:00 16:00 Рисунок 1.26 - Шаг 1 и 2. Распространение волны переговоров при приходе нового требования: в результате первого конфликта поезд №200 меняет исходную постановку и уходит влево Пусть агент поезда №200 работает в таком параллельном режиме и делает запросы одновременно к агенту поезда №500 на подвижку влево и к агенту Окна на подвижку вправо на Д2. Агент Окна рассматривает вариант своей подвижки вправо, но сразу обнаруживает, что сдвинуться вправо на Д2 не сможет, т.к. существует ограничение, что за 15 мин до прохода ВСП «Сапсан», т.е. в 16:45 блок-участок должен быть свободен. Агент Окна сообщает об этом агенту поезда №200, чтобы тот мог сравнить варианты и решить, в каком направлении следует продолжать поиск вариантов. Пусть агент поезда №500 со своей стороны сообщает, что он готов двигаться влево, но на Д2 сдвинуться не может, т.к. в 13:00 поезд №500 еще не будет готов к движению. Тогда агент поезда №200 просит агента Окна сдвинуться вправо на дельту Д3, равную 15 мин. Агент Окна соглашается и уходит вправо на Д3 (Рисунок 1.27). Далее агент поезда №200 запрашивает агента поезда №500, не может ли он сдвинуться влево на Д3, равную 15 мин. Поезд №500 может начать движение в 13:15, т.е. на 15 мин раньше первоначально запланированного времени, о чем агент поезда №500 сообщает агенту 91 поезда №200. Агент поезда №200 просит агента поезда №500 сдвинуться на Д3 влево, агент поезда №500 соглашается. №200 Шаг 2 №500 Окно Блок-участок Д2 13:00 14:00 15:00 16:00 17:00 18:00 19:00 17:00 18:00 19:00 №200 Шаг 3 №500 Окно Блок-участок Д3 13:00 14:00 15:00 16:00 Рисунок 1.27 - Шаг 3: в результате дальнейших переговоров Окно уходит вправо Когда процесс переговоров завершается согласием всех участников, т.е. решение задачи найдено, диспетчер завершает фаза планирования системы и дает команду агентам на переход к фазе исполнения, чтобы агенты могли исполнить намеченные планы и осуществить все подвижки. В результате проведенных переговоров и достигнутого согласия, агент Окна сдвигается вправо на Д3, агент поезда №500 сдвигается влево на Д3, т.е. агент поезда №500 и агент Окна расступаются для предоставления агенту поезда №200 возможности занять требуемое ему место, но это также требует от агента поезда №200 сдвига влево на Д3 (Рисунок 1.28), чтобы выйти на БУ к 14:45. В результате подвижек в расписании график движения ВСП «Сапсан» не нарушается. 92 Шаг 3 №200 Окно №500 Блок-участок Д3 13:00 14:00 Шаг 4 15:00 16:00 17:00 18:00 19:00 17:00 18:00 19:00 №200 Блок-участок №500 13:00 14:00 Окно 15:00 16:00 Рисунок 1.28 – Шаг 4 . Окончательное решение: в результате переговоров поезд №500 уходит влево и поезд №200 размещается в освободившемся месте 1.5.5.8 Варианты перепланирования по текущему времени Рассмотрим требования по прохождению Блок-участка 1 и Блок-участка 2 поездами №100, №200, №300, №500, ВСП «Сапсан». Имеются требования на окна для проведения ремонтных работ на блок-участках (Таблица 16). Запланированное расписание на Блок-участке 1 и Блок-участке 2 приведено на Рисунок 1.29, столбец «План». Таблица 16 – Требования по прохождению Блок-участка 1 и Блок-участка 2: перепланирование по событию Блок-участок Блок-участок 1 Блок-участок 2 Временные соотношения Требования План 13:00 – 14:00 13:30 – 14:45 14:45 – 15:45 16:00 – 16:45 17:00 – 17:30 18:00 – 19:00 14:00 – 15:00 14:45 – 16:00 15:45 – 16:45 16:45 – 17:15 17:30 – 18:00 19:00 – 20:00 Поезд №100 Поезд №200 Поезд №300 Окно ВСП «Сапсан» Поезд №500 Поезд №100 Поезд №200 Поезд №300 Окно ВСП «Сапсан» Поезд №500 93 Факт 13:30 – 14:30 14:00 – 15:15 15:15 – 16:15 16:15 – 16:45, 17:30 – 17:45 17:00 – 17:30 18:00 – 19:00 14:30 – 15:30 15:15 – 16:30 16:15 – 17:15 18:15 – 19:15 17:30 – 18:00 19:00 – 20:00 №300 №200 Блок-участок 2 Окно №100 №500 Сапсан №200 Блок-участок 1 №100 13:00 №300 Окно 15:00 14:00 №500 Сапсан 16:00 17:00 18:00 19:00 20:00 21:00 Рисунок 1.29 – Запланированное расписание на Блок-участке 1 и Блок-участке 2 Пусть в 13:00 пришло событие, что поезд №100 не находится на Блок-участке 1, а отстает от графика движения на 30 мин. Наблюдается расхождение между запланированным расписанием поезда №100 и фактическим графиком его движения. Возможны следующие способы перепланирования расписания. 1. Перепланирование расписания движения по блок-участкам может быть выполнено в момент прихода события, т.е. в 13:00 (Таблица 16 – столбец «Факт», Рисунок 1.30). Блок-участок 2 Точка перепланирования 13:00 №300 №200 Окно №500 Сапсан №100 №200 Блок-участок 1 №100 №300 Окно Сапсан №500 №100 13:00 15:00 14:00 16:00 17:00 18:00 19:00 20:00 21:00 20:00 21:00 №300 №200 Блок-участок 2 №100 Сапсан Окно Ок но №500 №500 №200 Блок-участок 1 №100 13:00 14:00 №300 15:00 Окно 16:00 Сапсан 17:00 18:00 19:00 Рисунок 1.30 – Перепланированное расписание на Блок-участке 1 и Блок-участке 2: перепланирование по событию В результате перепланирования, время прохождения блок-участков поездами №100, №200 и №300 сдвигается на более поздние сроки, порядок следования поездов сохраняется, Окно на Блок-участке 1 разделяется на 2 две части, т.к. за 15 мин до прохождения ВСП 94 «Сапсан» блок-участок должен быть свободен, Окно на Блок-участке 2 переносится на более поздний срок по той же причине. 2. Перепланирование расписания движения по блок-участкам может быть выполнено по факту появления поезда №100 на Блок-участке 1, т.е. в 13:30 (Таблица 17 – столбец «Факт», Рисунок 1.31). Таблица 17 – Требования по прохождению Блок-участка 1 и Блок-участка 2: перепланирование по факту Блок-участок Требования Блок-участок 1 Блок-участок 2 Блок-участок 2 Временные соотношения План Факт Поезд №100 Поезд №200 Поезд №300 Окно 13:00 – 14:00 13:30 – 14:45 14:45 – 15:45 16:00 – 16:45 ВСП «Сапсан» Поезд №500 Поезд №100 Поезд №200 Поезд №300 Окно ВСП «Сапсан» Поезд №500 17:00 – 17:30 18:00 – 19:00 14:00 – 15:00 14:45 – 16:00 15:45 – 16:45 16:45 – 17:15 17:30 – 18:00 19:00 – 20:00 14:45 – 15:15 13:30 – 14:45 15:15 – 16:15 16:15 – 16:45, 17:30 – 17:45 17:00 – 17:30 18:00 – 19:00 15:15 – 16:15 14:45 – 15:45 16:15 – 17:15 18:15 – 19:15 17:30 – 18:00 19:00 – 20:00 Точка перепланирования 13:30 №300 №200 Окно Сапсан №500 №100 №200 Блок-участок 1 №300 №100 13:00 14:00 Окно 15:00 Сапсан 16:00 №500 17:00 18:00 19:00 20:00 21:00 20:00 21:00 №200 Блок-участок 2 №100 №300 Сапсан Окно Ок но №500 №500 №200 Блок-участок 1 №100 13:00 14:00 15:00 №300 Окно 16:00 Сапсан 17:00 18:00 19:00 Рисунок 1.31 – Перепланированное расписание на Блок-участке 1 и Блок-участке 2: перепланирование по факту 95 В 13:30 поезд №200 уже отправляется, поэтому поезд №100 на Блок-участке 1 и Блокучастке 2 будет поставлен в расписании после поезда №200. 1.5.6 Разработка моделей взаимодействий агентов, позволяющих осуществлять взаимные уступки во имя общей цели системы Рассмотрим подход к разделению сцены между несколькими планировщиками по географическому принципу. Разобьем направление Москва – Санкт-Петеребург на две части: а) Москва – Бологое (Планировщик 1), б) Бологое – Санкт-Петербург (Планировщик 2). Потребности в элементах пути и временные отношения для планировщиков приведены в Таблица 18 и Таблица 19. Планировщики взаимодействуют между собой через объекты потребности в станционном блок-участке Б.1, для которого они разделяют планирование: Планировщик 1 планирует прибытие на станцию Бологое, а Планировщик 2 – отправление со станции. Если скорый поезд №1000 не отклоняется от графика движения, конфликт на станционном блокучастке Б.1 не возникает. Таблица 18 – Потребности в элементах пути для Планировщика 1 без отклонения от графика движения скорого поезда №1000 Временные отношения Потребность в элементах пути Блок-участок М.1 Блок-участок 1.1 Блок-участок 2.1 Блок-участок Т.1 Станция Тверь: Т.1 - останов Блок-участок Т.1 Блок-участок 3.1 Блок-участок Б.1 Станция Бологое: Б.1 - останов Скорый поезд №1000 ВСП «Сапсан» План Факт 13:00 – 13:01 13:01 – 14:00 14:00 – 14:59 14:59 – 15:00 15:00 – 15:05 13:00 – 13:01 13:01 – 14:00 14:00 – 14:59 14:59 – 15:00 15:00 – 15:05 16:30 – 16:31 16:31 – 17:00 17:00 – 17:29 17:29 – 17:30 17:30 – 17:32 15:05 – 15:06 15:06 – 15:59 15:59 – 16:00 16:00 – 16:05 15:05 – 15:06 15:06 – 15:59 15:59 – 16:00 16:00 – 16:05 17:32 – 17:33 17:33 – 17:59 17:59 – 18:00 18:00 – 18:02 96 Таблица 19 – Потребности в элементах пути для Планировщика 2 без отклонения от графика движения скорого поезда №1000 Временные отношения Потребность в элементах пути Блок-участок Б.1 Cтрелка 1 Блок-участок 4.1 Блок-участок 5.1 Блок-участок 6.1 Cтрелка 2 Блок-участок СпБ.1 Скорый поезд №1000 План Факт 16:05 – 16:06 16:06 – 16:07 16:07 – 17:00 17:00 – 18:00 18:00 – 18:58 18:58 – 18:59 18:59 – 19:00 16:05 – 16:06 16:06 – 16:07 16:07 – 17:00 17:00 – 18:00 18:00 – 18:58 18:58 – 18:59 18:59 – 19:00 ВСП «Сапсан» 18:02 – 18:03 18:03 – 18:04 18:04 – 18:30 18:30 – 19:00 19:00 – 19:28 19:28 – 19:29 19:29 – 19:30 Пусть в систему приходит событие, что отправление поезда №1000 из Москвы по техническим причинам задерживается на 1 час. Потребности в элементах пути и временные отношения для Планировщика 1 приведены в Таблица 20 с учетом задержки отправления поезда №1000. Таблица 20 – Потребности в элементах пути для Планировщика 1 с отклонением от графика движения скорого поезда №1000 на 1 час Временные отношения Потребность в элементах пути Блок-участок М.1 Блок-участок 1.1 Блок-участок 2.1 Блок-участок Т.1 Станция Тверь: Т.1 - останов Блок-участок Т.1 Блок-участок 3.1 Блок-участок Б.1 Станция Бологое: Б.1 - останов Скорый поезд №1000 ВСП «Сапсан» План Факт 13:00 – 13:01 13:01 – 14:00 14:00 – 14:59 14:59 – 15:00 15:00 – 15:05 14:00 – 14:01 14:01 – 15:00 15:00 – 15:59 15:59 – 16:00 16:00 – 16:05 16:30 – 16:31 16:31 – 17:00 17:00 – 17:29 17:29 – 17:30 17:30 – 17:32 15:05 – 15:06 15:06 – 15:59 15:59 – 16:00 16:00 – 16:05 16:05 – 16:06 16:06 – 16:59 16:59 – 17:00 17:00 – 17:05 17:32 – 17:33 17:33 – 17:59 17:59 – 18:00 18:00 – 18:02 Согласно расписанию, первоначально составленному Планировщиком 2, в 16:05 поезд №1000 должен находиться на станционном блок-участке Б.1, а он находится на станционном блок-участке Т.1., т.е. имеется расхождение между планом и фактом. Планировщик 2 пересчитывает расписание поезда №1000 на своем участке пути (Таблица 21). 97 Таблица 21 – Потребности в элементах пути для Планировщика 2 с отклонением от графика движения скорого поезда №1000 на 1 час: конфликт на блок-участке 5.1 Временные отношения Потребность в элементах пути Блок-участок Б.1 Cтрелка 1 Блок-участок 4.1 Блок-участок 5.1 Блок-участок 6.1 Cтрелка 2 Блок-участок СпБ.1 Скорый поезд №1000 План Факт 16:05 – 16:06 16:06 – 16:07 16:07 – 17:00 17:00 – 18:00 18:00 – 18:58 18:58 – 18:59 18:59 – 19:00 17:05 – 17:06 17:06 – 17:07 17:07 – 18:00 18:00 – 19:00 19:00 – 19:58 19:58 – 19:59 19:59 – 20:00 ВСП «Сапсан» 18:02 – 18:03 18:03 – 18:04 18:04 – 18:30 18:30 – 19:00 19:00 – 19:28 19:28 – 19:29 19:29 – 19:30 Т.к. имеется конфликт потребностей поезда №1000 и ВСП «Сапсан» в блок-участке 5.1, Планировщик 2 перепланирует расписание поезда №1000 так, чтобы он начал движение со станции Бологое на 1 час позже и пропустил ВСП «Сапсан» (Таблица 22). Таблица 22 – Потребности в элементах пути для Планировщика 2 с отклонением от графика движения скорого поезда №1000: задержка начала движения поезда №1000 со станции Бологое Временные отношения Потребность в элементах пути Блок-участок Б.1 Cтрелка 1 Блок-участок 4.1 Блок-участок 5.1 Блок-участок 6.1 Cтрелка 2 Блок-участок СпБ.1 Скорый поезд №1000 План Факт 16:05 – 16:06 16:06 – 16:07 16:07 – 17:00 17:00 – 18:00 18:00 – 18:58 18:58 – 18:59 18:59 – 19:00 18:05 – 18:06 18:06 – 18:07 18:07 – 19:00 19:00 – 20:00 20:00 – 20:58 20:58 – 20:59 20:59 – 21:00 ВСП «Сапсан» 18:02 – 18:03 18:03 – 18:04 18:04 – 18:30 18:30 – 19:00 19:00 – 19:28 19:28 – 19:29 19:29 – 19:30 Планировщик 1 должен перепланировать останов поезда №1000 для пропуска ВСП «Сапсан» так, чтобы интервал останова на станции Бологое увеличился на 1 час (Таблица 23). 98 Таблица 23 – Потребности в элементах пути для Планировщика 1 с отклонением от графика движения скорого поезда №1000: увеличение останова на станции Бологое на 1 час Временные отношения Потребность в элементах пути Блок-участок Б.1 Станция Бологое: Б.1 - останов Скорый поезд №1000 План Факт 15:59 – 16:00 16:00 – 16:05 16:59 – 17:00 17:00 – 18:05 ВСП «Сапсан» 17:59 – 18:00 18:00 – 18:02 При этом возникает конфликт между потребностями поезда №1000 и ВСП «Сапсан» в станционном блок-участке Б.1. Следовательно, Планировщик 1 должен запланировать перевод поезда №1000 со станционного блок-участка Б.1 на станционный блок-участок Б.2 и останов на станционном блок-участке Б.2 (Таблица 24). Планировщик 2 должен запланировать перевод поезда №1000 со станционного блок-участка Б.2 на станционный блок-участок Б.1 (Таблица 25). Таблица 24 – Планировщик 1: разрешение конфликта на станционном блок-участке Б.1 Временные отношения Потребность в элементах пути Блок-участок Б.1 Станция Бологое: Б.1 - останов Стрелка Б.1 – Б.2 Станция Бологое: Б.2 - останов Скорый поезд №1000 ВСП «Сапсан» План Факт 15:59 – 16:00 – 16:59 – 17:00 – 17:59 – 18:00 18:00 – 18:02 – 16:00 – 16:05 17:00 – 17:01 17:01 – 18:04 – – Таблица 25 – Планировщик 2: разрешение конфликта на станционном блок-участке Б.1 Временные отношения Потребность в элементах пути Стрелка Б.2 – Б.1 Блок-участок Б.1 Cтрелка 1 Блок-участок 4.1 Скорый поезд №1000 План Факт – – 16:06 – 16:07 16:07 – 17:00 18:04 – 18:05 18:05 – 18:06 18:06 – 18:07 18:07 – 19:00 99 ВСП «Сапсан» – 18:02 – 18:03 18:03 – 18:04 18:04 – 18:30 1.5.7 Алгоритмы разрешения конфликтов при резервировании блокучастков за счет изменения скорости движения и длительности остановок 1.5.7.1 Разрешение конфликтов путем изменения скоростей прохождения блок-участков и длительности остановок Если по одному и тому же блок-участку движутся поезда с различными скоростями, возникает конфликт в случае, если скорость второго поезда больше, чем первого. Предлагаются следующие пути разрешения конфликта: а) увеличение скорости движения поезда до максимально возможной, либо до удовлетворения требования; б) уменьшение скорости движения поезда до нулевой, т.е. до останова; в) увеличение продолжительности стоянки поезда (стоянка поезда не уменьшается). Рассмотрим примеры разрешения конфликтов между двумя поездами путем изменения скоростей. Пусть у поезда имеется требование, состоящее из двух подтребований: а) стоянка, б) движение по блок-учаску (перегону). Скорость второго поезда выше, чем скорость первого поезда. Пример 1. Увеличение продолжительности стоянки второго поезда. Разрешение конфликта показано на Рисунке 1.33. Рисунок 1.33 – Разрешение конфликта за счет увеличения продолжительности стоянки второго поезда 100 Пример 2. Увеличение скорости первого поезда. Разрешение конфликта показано на Рисунок 1.34. Рисунок 1.34 – Разрешение конфликта за счет увеличения скорости первого поезда Пример 3. Уменьшение скорости второго поезда. Разрешение конфликта показано на Рисунок 1.35. Рисунок 1.35 – Разрешение конфликта за счет уменьшения скорости второго поезда Разрешение конфликта выполняется следующим образом: а) каждое требование работает отдельно; б) второе требование находит конфликт с первым; в) рассматривается набор вариантов разрешения конфликтов; г) для каждого варианта оценивается KPI (1); д) выбирается вариант с минимальным значением KPI (1); е) выбранный вариант записывается в расписание; ж) в общем случае возникает волна изменений расписания. 101 1.5.7.2 Алгоритм разрешения конфликта при резервировании одного блок-участка с учетом приоритетов поездов Для того чтобы обеспечить дистанцию между поездами при движении и тормозной путь, будем считать, что расстояние между поездами на перегоне должно составлять не менее двух блок-участков, т.е. для поезда необходимо резервировать реально тот блок-участок, на котором он находится, и резервировать виртуально два соседних впереди идущих блокучастка. Если некоторый блок-участок соседствует со станционным блок-участком, поезда могут находиться на соседних блок-участках (Рисунок 1.36). Рисунок 1.36 – Расположение поездов на блок-участках без конфликтов На Рисунке 1.37 представлен конфликт между тремя поездами при резервировании одного блок-участка. Рисунок 1.37 – Конфликт при резервировании одного блок-участка Алгоритм разрешения конфликта при резервировании одного блок-участка и двух соседних с ним произвольным количеством Temporary Relations (TRs) в соответствии с приоритетами поездов: а) Рассчитать приоритет для каждого TR. б) Рассчитать середину желаемого интервала резервирования. в) Сортировать TRs в соответствии с приоритетами. г) Пройти по TRs в порядке снижения приоритетов. 1) Первый по порядку TR располагается произвольно, инициализируются края временного интервала Left = TR.Start – δ, Right = TR.Finish + δ; 102 2) Следующиий TR сравнивает левый и правый свободные края и их отклонения от середины собственного желаемого интервала времени резервирования. Прикрепляет свое время резервирования к тому краю интервала, где отклонение меньше. Изменяет значение одного из свободных краев. На Рисунок 1.38 показаны периоды резервирования одного блок-участка. Рисунок 1.38 – Периоды резервирования одного блок-участка 3) Шаг г) выполняется до тех пор, пока не бдут просмотрены все TRs. д) Запустить цепочку сдвигов TRs по соседним блок-участкам для каждого расписания параллельно, с расчетом на локализацию изменений в расписании, без учета образования новых конфликтов. 1.5.8 Алгоритм разрешения конфликтов по всему расписанию Возможны следующие алгоритмы разрешения конфликтов: а) поиск конфликтов резервирований. Конфликтом считается пересечение времени резервирования текущего блок-участка в расписаниях разных поездов. б) проход по группам конфликтующих TRs, резервирующих один блок-участок. Запуск алгоритма разрешения конфликта при резервировании одного блок-участка. Возможен параллельный запуск алгоритма разрешения конфликтов на блок-участках, расположенных на таком удалении друг от друга, что вероятность пересечения волн сдвигов мала, например, через каждые Δ >10 блок-участков. Параллельный запуск алгоритма разрешения конфликта назовем раундом. В этом случае алгоритм разрешения конфликтов будет запускаться одновременно, например, на блок-участках с номерами 3, 17, 29, 41, 81, 99 (раунд). У TRs неактивных блок-участков должен быть установлен флаг изменения в данном раунде. Флаг завершения раунда (глобальная переменная) должен изменяться в управляющем потоке. Управляющий поток ожидает завершения всех потоков. TR отвечает отказом на повторный сдвиг. Если ни данный вариант, ни другие варианты разрешения конфликта на конкретном блок-участке так и не смогут разрешить конфликт, конфликт остается до следующего цикла разрешения конфликтов. Цикл разрешения конфликтов включает все раунды. Δ будет временно увеличиваться на 1 в каждом раунде, где возникли конфликты параллельного выполнения. 103 1.5.9 Выводы и предложения по результатам проведенных анализа и исследований В данном подразделе описаны формализованные модели планирования, разработаны и описаны агенты ключевых ресурсов инфраструктуры РЖД, описан метод согласованного адаптивного управления расписанием движения поездов на основе мультиагентного подхода, описание логики агентов активных сущностей, разработанной структуры данных и алгоритмов принятия решений, разработанных моделей взаимодействия агентов. Таким образом, можно сделать вывод о принципиальной возможности применения мультиагентного подхода для оптимизации движения железнодорожного транспорта и о необходимости более детальной проработки концепции объединения нескольких мультиагентных планировщик в единую сетецентрическую систему. 1.6 Разработка принципов построения сетецентрических интеллектуальных систем для согласованного планирования ресурсов РЖД, способных к согласованному коллективному взаимодействию в реальном времени, на основе баз знаний и мультиагентных технологий В данном подразделе приводится описание основных положений сетецентрического подхода с целью планирования ресурсов РЖД для организации согласованного коллективного взаимодействия. Одной из важнейших задач, предусмотренных стратегическими направлениями научно-технического развития ОАО «Российские железные дороги» на период до 2015 г., является развитие и совершенствование интеллектуальной системы управления железнодорожным транспортом, предназначенной для организации централизованного автоматизированного управления движением поездов на линиях РЖД и организации всей производственной деятельности на РЖД на базе широкого использования современных методов анализа, управления, моделирования, логистики и прогнозирования, а также средств вычислительной техники и информационных технологий. Система должна объединить в единый комплекс все отраслевые АСУ [«Белая книга» ОАО «РЖД» - с. 30]. Пассажирский транспорт имеет большое социально-экономическое значение, так как играет важную роль в жизнеобеспечении общества. Железнодорожный транспорт является основополагающим для организации перевозочного процесса в России. Хорошо организованный железнодорожный транспорт является важнейшим условием эффективного материального производства и обеспечения нормальной социальной обстановки в стране. 104 Железнодорожные линии представляют собой совокупность перегонов, станций и других раздельных пунктов, оснащенных соответствующими техническими средствами для осуществления перевозок. Станции являются основными предприятиями транспорта, играющими важнейшую роль в обслуживании пассажиров, отправителей и получателей грузов, организации вагонопотоков и перевозочного процесса в целом, обеспечении безопасности движения. В работе железных дорог ярко проявляются свойства сложной системы: железнодорожная станция представляет собой открытую систему, которая подвержена постоянным и разнообразным воздействиям извне. Прежде всего, станция является частью сети, которая осуществляет перевозки (как грузовые, так и пассажирские). События, происходящие на одной станции, могут непосредственно отразиться на деятельности другой; задержка времени отправления одного состава влечет за собой задержку отправления следующего за ним состава, сокращение времени стоянок, а также время прибытия на станцию назначения; наличие «окон» в расписании также приводит к изменению первоначального расписания движения поездов. В связи с этим задача согласованного планирования ресурсов РЖД связана с необходимостью адекватной и быстрой реакции на различные события, с чем не всегда способен эффективно справляться человек. Таким образом, в современных условиях становится крайне актуальным применение современных инновационных методов автоматизации динамического планирования для повышения эффективности управления ресурсами в сложных организационно-технических системах в реальном времени. Для решения задачи предлагается разработка сетецентрического подхода к созданию программного комплекса, функционирующего как р2р сеть взаимодействующих интеллектуальных систем (система систем) для согласованного управления высокоприоритетными и низкоприоритетными поездами в реальном времени. В существующих классических системах планирования и оптимизации ресурсов задача управления ресурсами изначально рассматривается как централизованное, монолитное, последовательное решение. При этом все ресурсы и заказы считаются известными заранее; затем на основе традиционных классических методов (например, методами линейного и динамического программирования, программирования в ограничениях, различными эвристиками и метаэвристиками и т.д.) формируется некоторый план, коррективы в который при необходимости вносятся вручную. При этом любые объективные и субъективные отклонения от построенного жесткого детерминированного плана разрешаются специалистами (диспетчерами), как правило, в «ручном режиме», что на практике является чрезвычайно трудоемким процессом, и в ряде случаев еще более затрудняет внедрение указанных систем. 105 Сетецентрический подход позволяет создавать «системы систем» (или «сети сетей») позволяет преодолеть фундаментальную проблему сложности решаемой задачи, решить которую в рамках одной «монолитной», централизованной, последовательной системы не представляется возможным. Ключевым принципом сетецентрических систем, функционирующих в отсутствии выделенного центра, является принятие решений по принципу «as local as possible and as global as required» (локально настолько, насколько позволяет ситуация и глобально настолько, насколько требует ситуация). В рамках сетецентрического подхода рассматриваемая система должна изначально строиться как распределенная, открытая для наращивания и состоящая из автономных, но согласованно и координировано действующих интеллектуальных систем отдельных станций, которые в случае необходимости могли бы взаимодействовать, выявлять конфликты по ресурсам и находить приемлемые компромиссы путем проведения переговоров, действуя при этом под контролем диспетчерских. При этом недостаток ресурсов в одной станции мог бы компенсироваться использованием ресурсов другой станции, задержки на одной – приводили бы к согласованным изменениям планов на другой станции и т.д. В свою очередь, каждая интеллектуальная система одной станции может рассматриваться как сеть взаимодействующих подсистем планирования отдельными видами ресурсов станции (высокоскоростные поезда, скорые поезда, электрички, ремонтные бригады и пр.), также вырабатывающих согласованные решения по планированию использования ресурсов (Рисунок 1.39). Так, в рассматриваемой системе необходимо обеспечить взаимодействие следующих подсистем планирования: расписание движения грузовых поездов, расписание движения пассажирских поездов дальнего следования, расписание движения пассажирских высокоскоростных поездов, расписание движения пригородных поездов, расписание ремонтных работ (расписание «окон). Все данные расписания являются должны быть взаимоувязаны и, кроме того, при изменении какой-либо части одного расписания, должны быть скорректированы все «заинтересованные» расписания. При этом должен быть учтен приоритет движения высокоскоростных поездов класса «Сапсан» Для решения рассматриваемой проблемы в настоящем проекте предлагается развитие сетецентрического подхода к созданию программного комплекса нового класса, функционирующего как р2р сеть взаимодействующих интеллектуальных систем. В результате созданные интеллектуальные модули планирования различных РЖД ресурсов получат возможность договариваться между собой и согласованно динамически формировать и корректировать план движения поездов в условиях реальных проблемных ситуаций, возникающих на дороге. 106 Для решения проблемы эффективного управления ресурсами в сложных системах в реальном времени компанией-исполнителем был предложен мультиагентный подход на основе сетей потребностей и возможностей, который нашел успешное применение в целом ряде приложений. В этом подходе вместо одного «большого» пакетного оптимизатора создается «коллектив» из множества агентов-оптимизаторов, которые адаптивно (без полного пересмотра) формируют и корректируют расписание как самоорганизующуюся сеть из десятков и сотен тысяч связанных операций, но готовы идти на взаимные компромиссы и уступки ради общей цели. Планировщик движения поездов участка 1 Горьковской ЖД Планировщик движения поездов участка N Горьковской ЖД Планировщик движения поездов участка 1 Куйбышевской ЖД Планировщик движения поездов Планировщик двиучастка 1 Горьковжения поездов ской ЖД Планировщик движения поучастка N Горьковездов Горьковской ЖД ской ЖД Планировщик движения поездов участка N Куйбышевской ЖД Планировщик двиПланировщик движения поез-Планировщик движения поездов жения поездов дов Куйбышевской ЖД участка 1 Куйбыучастка N Куйбышевской ЖД шевской ЖД Планировщик движения поездов Куйбышевской ЖД Планировщик движения поездов Горьковской ЖД Планировщик движения поездов Московской ЖД Планировщик движения поездов Московской ЖД Планировщик движения поездов участка 2 Московской ЖД Планировщик движения поездов участка 1 Московской ЖД Планировщик расписания движения грузовых поездов Планировщик расписания движения грузовых поездов Планировщик движения поездов участка 1 Московской ЖД Планировщик расПланировщик расписания движения пассажирских поездов дальнего следования писания движения пригородных пассажирских поездов Планировщик расписания ремонтных дорожных работ («окон») Планировщик расПланировщик расписания движения Планировщик писания движения пригородных пасрасписания пассажирских посажирских поездов р2р ездовРисунок дальнего 1.39 – Архитектура адаптивнойремонтных дорожных раследования сетецентрической сети планировщиков бот РЖД («окон») Планировщик Планировщик движения поездов движения поездов участка 2 Московучастка МосковскойNЖД ской ЖД Планировщик движения поездов участка N Московской ЖД По определению, агентом является автономный программный объект, имеющий достаточные интеллектуальные возможности для самостоятельной (автономной) реализации цикла «восприятие-планирование-исполнение», что позволяет ему быть постоянно активным 107 (непрерывно исполняться в указанном выше цикле) и потому быстро реагировать на события в реальном времени и согласованно пересматривать свои решения при любых изменениях через взаимодействие с другими агентами и пользователями. При этом агенты могут взаимодействовать не только между собой, но и выходить на взаимодействие со своими пользователями, в интересах, от лица и по поручению которых они могут действовать. Такая система по определению становится информационно-коммуникационной, поскольку решение сложной проблемы должно строиться в постоянном диалоге с пользователями, что позволяет учесть множество различных конфликтных предпочтений и ограничений, причем возникающих и меняющихся динамически, в частности, связанных с взаимными уступками, преодолением ограничений и т.д. В предлагаемом подходе каждый заказ на перевозку пассажирского поезда и ресурс станции (локомотив, вагон, машинист, участок дороги и т.д.) получат своих программных агентов, действующих в интересах, от лица и по поручению участников процесса управления станцией, с учетом собственных стратегий и критериев, предпочтений и ограничений. Каждый агент является автономным программным объектом, который способен самостоятельно реализовывать полный цикл управления: реагировать на события, планировать и оптимизировать свои действия, исполнять намеченные планы и коммуницировать с другими агентами для согласования решений. При этом расписание, создаваемое агентами, строится как сеть взаимосвязанных операций в ходе самоорганизации заказов и ресурсов, в ходе которой формируется баланс интересов всех участников - посредством захвата заказами лучших ресурсов (и наоборот), выявления конфликтов и поиска компромиссов между агентами. Такое расписание никогда не прекращает строиться, и наоборот, постоянно пытается реорганизоваться и улучшиться в «узких» местах, что позволяет называть его активным, интеллектуальным или «живым», способным непрерывно адаптивно меняться в ходе возникновения любых событий, в том числе в случае изменения критериев планирования, например, минимизации времени выполнения заказа, уменьшения стоимости, сокращения рисков и штрафов и т.д. Важнейшим достоинством разработанной мультиагентной технологии в распределении, планировании и оптимизации ресурсов является возможность адаптивного построения и исполнения планов, когда план не строится всякий раз заново при возникновении новых событий, как это делается в классических методах оптимизации, а только адаптивно корректируется по мере появления событий в реальном времени, при необходимости (и при наличии ресурса времени), на сколь угодно длинную цепочку изменений. Такая автоматическая адаптация планов, причем часто в ходе их исполнения, осуществляется непрерывно путем выявления конфликтов в расписаниях, проведения переговоров и достижения компромиссов 108 между агентами потребностей и возможностей, что и позволяет системе работать в реальном времени. Для описания знаний, необходимых агентам в процессе принятия решений в условиях динамически изменяющейся ситуации в системах планирования, работающих в режиме реального времени, будет применен онтологический подход, что позволит отделить предметные знания от программного кода системы. Онтология (база знаний) – это формализованные концептуальные знания о предметной области. Концептуальность знаний онтологии означает, что эти знания формулируются в терминах наиболее общих классов понятий и отношений, описывающих фрагменты окружающего мира. Таким образом, онтология может быть построена как семантическая сеть понятий и отношений предметной области. В настоящее время для создания и поддержки онтологий существует целый ряд инструментов, которые помимо общих функций редактирования и просмотра выполняют поддержку документирования онтологий, импорт и экспорт онтологий разных форматов и языков, поддержку графического редактирования, управление библиотеками онтологий и т.д. Наиболее известны следующие онтологические среды: Ontolingua, Protégé, OntoEdit, OilEd, WebOnto. Однако, для использования в мультиагентных системах управления ресурсами требуются специализированные онтологии и средства поддержки их построения, позволяющие учитывать как особенности данной предметной области РЖД, так и принципы взаимодействия агентов в системе при обнаружении и разрешении конфликтов и поиске баланса интересов всех участников. При таком подходе мультиагентная система поддержки принятия решения будет способна, опираясь на знания, описанные в онтологии, выполнять поиск решений в соответствии с заданными целями и предпочтениями, находя определенный баланс между различными компромиссами, такими, как например, стоимость, удовлетворенность клиентов, риск и т.п. Разработанный подход обеспечит интеллектуализацию процессов принятия решений на станции для решения сложных задач управления ресурсами РЖД, повышения эффективности их использования, обеспечения безопасности движения, высокой оперативности, гибкости, производительности, надежности и масштабируемости разрабатываемых систем. 109 1.6.1 Выводы и предложения по результатам проведенных анализа и исследований В работе железной дороги ярко проявляются свойства сложной системы. Предлагается для проверки возможности применения разработанного сетецентрического подхода для планирования ЖД транспорта создать программную модель и экспериментальный образец, включающий в качестве компонент: несколько мультиагентных модулей планирования движения поездов на двух и более направлениях с привязкой к реальной инфраструктуре движения, модуль планирования работ на железной дороге. Необходимо также привязать все модули к общей онтологии, описывающей элементы предметной области в качестве классов понятий и отношений, и объединить модули в общую стетецентричекую систему. 1.7 Разработка программной модели В данном подразделе приводится описание разработанной программной модели управления движением поездов на основе мультиагентной технологии (далее – «мультиагентная модель»). Данная программная модель создается на основе мультиагентной технологии с целью обеспечения гибкого и эффективного перепланирования расписаний высокоскоростных поездов при возникновении незапланированных событий в реальном времени. 1.7.1 Разработка спецификации требований к программной модели управления движением поездов Экспериментальное исследование и анализ функциональности наиболее распространенных систем планирования движения поездов позволил сформировать список требований, которые необходимо удовлетворить в программной модели управления движением поездов: а) возможность ввода начальной ситуации по движению поездов; б) возможность ввода и автоматической обработки событий об изменениях состояний ресурсов; в) реализовывать метода адаптивного управления ресурсами; г) позволять осуществлять ручную доработку планов диспетчерами при необходимости; д) возможность отображения исходных и создаваемых расписаний; е) сохранение расписаний в базе данных; ж) восстановление расписаний из базы данных; и) построение отчетов по использованию ресурсов; 110 к) ведение формализованных моделей индивидуального планирования ключевых ресурсов инфраструктуры РЖД (поезд, путь, блок-участок, станция и др.); л) должны быть учтены технические характеристики объектов моделирования: 1) особенности построения ЖД-путей, состоящих из блок-участков (вопросы по обозначению и расположению блок-участков, связям между блок-участком и его путем, соседними блок-участками, блок-участком и окном); 2) особенности различных типов поездов; 3) вопросы по логике работы светофора; 4) вопросы о месте нахождения поезда и других объектов (атрибуты поезда или блок-участка); 5) вопросы по правилам движения поездов; м) отображение плана в виде диаграммы Гантта; н) поддержка версионности расписаний движения поездов; п) система должна функционировать на базе сервис-ориентированной архитектуры. 1.7.2 Разработка бизнес-модели и модели вариантов использования системы В данном подразделе представлены модель вариантов использования и основные структуры данных системы, разработанные на основе результатов работы по сбору и спецификации требований к программной модели управления движением поездов. Данные модели отражают специфику решаемых системой задач в разрезе функциональных возможностей и иллюстрируют общие границы применимости системы. Модель данных содержит описание основных сущностей и атрибутов на концептуальном уровне и служит для более точного описания требований к системе и основной функциональности. 111 Рисунок 1.39 – Диаграмма вариантов использования 112 Рисунок 1.40 – Диаграмма классов 1.7.3 Характеристика объекта автоматизации Система управления производственными процессами ОАО «РЖД» представляет собой сверхсложную систему, характеризующуюся большим разнообразием и количеством составных элементов и астрономическим числом их взаимосвязей в рамках производственного процесса. В таблице 26 приведены количественные показатели объекта автоматизации. Таблица 26 – Количественные показатели объекта автоматизации. Наименование показателя Количество Эксплуатационная длина (тыс. км) 85,2 Развёрнутая длина главных путей (тыс. км) 1240 Развёрнутая длина станционных и специальных путей (тыс. км) 50,6 Количество приёмо-отправочных путей (шт.) 26859 Количество сортировочных путей (шт.) 4659 113 Наименование показателя Количество Стрелки с ЭЦ (тыс. шт.) 132,5 В процентах к общему количеству (%%) 79,4 Электровозы (шт.) 9684 Тепловозы (шт.) 10419 Электропоезда, секций (шт.) 7519 Дизельпоезда, секций (шт.) 106 Паровозы (шт.) 520 Вагоны пассажирские (шт.) 26932 Автомоторельсовый подвижной состав (шт.) 4610 Подвижные машинные станции. (шт.) 132 Раздельные пункты с путевым развитием (шт.) 5280 Вокзалы, станции или линейные участки, производящие пассажирские опера- 4758 ции (шт.) Количество опорных станций. (шт.) 86 Решающих сортировочных станций. (шт.) 32 Локомотивные депо (шт.) 322 Вагонные депо (шт.) 196 КП (шт.) 556 Диспетчерские участки. (шт.) 143 Поездоучастки. (шт.) 112 Диспетчерский персонал в 1 смену. (чел.) 586 Локомотивных бригад. (шт.) 32000 Кроме приведённых выше количественных характеристик, большое значение имеют качественные показатели сложности объекта автоматизации: а) неопределенность: трудно предсказать изменения спроса и предложения б) событийность: часто случаются события, требующие оперативного изменения планов, решений в реальном масщтабе времени в) ситуативность: решение надо принимать по ситуации. г) многофакторность: много разных критериев, предпочтений и ограничений. 114 д) высокая связность: принятие оперативного решения на одном участке (станции) требует учёта принятых или планируемых решений на связанных участках (станциях) и вызывает изменение решений многих других. е) индивидуальность: участники требуют все более индивидуального подхода. ж) конфликты: все больше участников с противоречивыми интересами. и) трудоемкость: слишком много опций, чтобы просчитать последствия. к) оперативность: требуется высокая оперативность принятия решений. Эти особенности требуют новых современных стратегических подходов, методов и средств автоматизации производственной деятельности и обеспечения поддержки принятия решений в реальном времени. 1.7.4 KPI’s системы Эффективность функционирования мультиагентной системы динамического планирования движения пассажирских поездов оценивается на основе KPI's. Рассмотрим KPI DEVT – минимальное суммарное отклонение фактического времени (planned time) начала и окончания выполнения задачи от запланированного времени (demanded time) по всем блок-участкам (перегонам). Данный KPI позволяет оценить отклонение поезда от графика на всем маршруте движения. Введем следующие обозначения для Задачи на блок-участке (Рисунок 1.41): а) TDS – запланированное время старта, б) TDF – запланированное время окончания, в) TPS – фактическое время старта, г) TPF – фактическое время окончания, д) N – количество блок-участков (перегонов). Запланированный интервал ТDF ТDs Запланированный интервал ТDs ТDF ТPs ТPs Фактический интервал ТPF ТPF Рисунок 1.41 – ЗапланированноеФактический и фактическое время выполнения задачи интервал KPI DEVT вычисляется по формуле (1): 115 N DEV T i 1 TD TP TD TP min S S F (1) F 1.7.5 Выводы и предложения по результатам проведенных анализа и исследований Разработанные в данном подразделе спецификация программной модели, описание бизнес-процессов, а также предварительные требования по расчету KPI работы мультиагентных планировщиков служат основой для создания Экспериментального образца и составления Технического задания. 1.8 Разработка экспериментального образца системы, позволяющего осуществлять адаптивное динамическое планирование в рамках одного модуля планирования В данном подразделе приводится описание структуры Экспериментально образца (ЭО), планируемого к разработке на базе программной модели управления движением поездов. 1.8.1 Описание структуры и принципов работы модуля планирования 1.8.1.1 Компоненты модуля планирования экспериментального образца Для построения модуля мультиагентной обработки данных разработчики могут применять готовые компоненты, входящие в состав общей онтологии. Компоненты организованы в несколько групп (пространств имен), которые имеют разную степень специализации: от базовых компонент, имеющих самое общее назначение по обработке данных, до компонент, специализированных для создания модулей планирования мобильных ресурсов и поддерживающих некую стандартную реализацию логики переговоров для выработки эффективной последовательности выполнения поездок. Общая структура базовой платформы представлена на Рисунке 1.42. 116 Рисунок 1.42 Общая структура базовая платформа 1.8.1.2 Мультиагентное ядро обработки данных Базовое ядро платформы включает все предметно-независимые компоненты, которые могут быть использованы для построения мультиагентной системы, решающей любую задачу обработки данных. 1.8.1.3 Базовые классы и интерфейсы IAgent – базовый интерфейс агента, работающего в мультиагентной среде и имеющего определенную внутреннюю цель. Логика достижения результата заложена в реализации метода Process(), который вызывается диспетчером в ходе решения общей задачи. Интерфейс также объявляет методы для получения и отправления сообщений. В рамках метода Process() агент должен выполнить один неделимый шаг обработки. При этом в результате он может изменить общую сцену (значения свойств объектов и связи между ними) и послать сообщения другим участникам переговоров. IObject – базовый интерфейс объекта сцены. Все объекты сцены должны быть привязаны к одной определенной сцене и могут иметь несколько ассоциированных с ними агентов. На практике, часто конкретная реализация объекта реализует как интерфейс IObject, так и IAgent. IDispatcher – базовый интерфейс диспетчера агентов. Диспетчер обеспечивает порядок и своевременность передачи управления различным агентам, работающим с общей сценой. Конкретная реализация диспетчера может обеспечивать работу агентов в одном или не117 скольких потоках. Для управления процессом обработки данных диспетчер имеет методы для запуска и остановки обработки. Кроме того, можно явно добавить или удалить агентов из списка диспетчеризации. IScene – базовый интерфейс для доступа к сцене. Класс, реализующий этот интерфейс предоставляет списки всех объектов сцены, отвечает за подсчет показателей эффективности сцены и за сопоставление агентов объектам сцены. Базовый интерфейс требует наличия, как минимум, функции расчета общего показателя эффективности текущего решения, хранящегося в сцене. На основании динамики этого показателя определяется, улучшилось ли решение, и можно ли передавать его пользователям (или другим модулям). Модули базовой платформы представлены на рисунке 1.43. Рисунок 1.43 - Модули базовой платформы 118 1.8.1.4 Диспетчер мультиагентной среды В базовом ядре также объявлены простые классы, реализующие указанные выше интерфейсы. Данные классы можно использовать, как базовый вариант для решения простых задач. Dispatcher – простая реализация интерфейсов IDispatcher и IScene, обеспечивающая загрузку агентов, диспетчеризацию в одном потоке, передачу сообщений на сохранение данных каждый раз при росте основного показателя эффективности. Общая схема работы данной реализации диспетчера представлена ниже на Рисунке 1.44. Рисунок 1.44 – Алгоритм работы диспетчера Agent – класс абстрактной активной сущности, которая выступает одновременно в роли объекта и агента и имеет стандартный вид логики, состоящий из восприятия ситуации, определения вариантов действий, оценки различных вариантов и выстраивания их в последовательность шагов, отработки первого шага, определения конфликтных интересов и отправки предложений о разрешении конфликта. 119 Рисунок 1.45 – Алгоритм работы класса IAgent После завершения указанной последовательности действий агент передает управление диспетчеру. Если к моменту повторного получения управления ситуация изменилась, то агент переоценивает свои опции и формирует из них новый план действий. В базовой реализации не предусмотрено отдельных шагов, связанных с отслеживанием этапа переговоров, эта логика входит в шаг восприятия ситуации и может быть переопределена в наследниках от базового агента. 1.8.1.5 Описание взаимодействия с мультиагентным ядром Для использования любой конкретной реализации модуля мультиагентной обработки данных, построенного на мультиагентном ядре, необходимо сначала создать компоненты ядра: а) экземпляр конкретной реализации интерфейса IScene. Это может быть либо наследник от BasicDispatcher, который входит в состав платформы, либо более высокоуровневая реализация. б) экземпляр конкретной реализации IDispatcher. BasicDispatcher реализует также этот интерфейс. в) экземпляр IObjectFactory. Конкретная реализация не входит в состав базовой платформы. 120 После того, как компоненты созданы и связаны между собой, в сцену необходимо передать весь набор взаимосвязанных объектов, представляющих собой рабочие данные для обработки. При передаче их в сцену, автоматически генерируются агенты активных сущностей. После подготовки сцены можно запустить мультиагентную обработку (Рисунок 1.46). Рисунок 1.46 – Алгоритм работы объекта IScene Мультиагентное ядро непрерывно обрабатывает объекты сцены, создает и изменяет выходной результат. В любой момент времени (обычно, это делается периодически, в цикле) можно обратиться к сцене, проверить, насколько улучшился результат, и принять либо не принять его. Затем можно сформировать набор встречных изменений во входных данных. Это могут быть как изменения, пришедшие извне, так и изменения, сформированные в ответ на полученный результат, чтобы его скорректировать. Если сформированный набор измене121 ний предполагает немедленную реакцию системы, то необходимо, до передачи их в мультиагентное ядро, описать результат «по умолчанию», непосредственно изменив объекты сцены, или создав новые объекты. Затем общий набор изменений, включая результат «по умолчанию» передаются в сцену. Рисунок 1.47 – Алгоритм учета изменений 122 1.8.1.6 Мультиагентное ядро планирования Ядро мультиагентного планирования является расширением мультиагентного ядра обработки данных и содержит интерфейсы и базовые классы, специализированные для задач построения расписаний. 1.8.1.7 Базовые интерфейсы для описания задач планирования Для описания задачи планирования применяется несколько основных понятий, отражающих ее постановку, начальные условия и результат. IDemand – объект предметной области, описывающий, что необходимо запланировать. Это может быть описание задачи, требование о выпуске продукции к определенному сроку, строка в расписании, задающая планируемое время прибытия или отправления транспорта. Требования могут иметь подтребования. Так, задача доставки груза «разворачивается» в набор задач о погрузке, транспортировке и разгрузке. IOperation – элементарное требование, задача, которая должна быть непосредственно запланирована в виде конкретных временных отношений (расписания). В отличие от более абстрактного IDemand, который может удовлетворяться косвенно, через подтребования. IResource – объект предметной области, описывающий свойства конкретного физического объекта, который участвует в выполнении операций, которые мы планируем. ITemporaryRelation – временное отношение между ресурсами, описывающее, как ресурсы взаимосвязаны (или будут взаимосвязаны) на определенном промежутке времени и какие действия они выполняют. Эта сущность также применяется для описания фактической ситуации, фактически выполнявшихся задач и отношений между объектами в реальном мире. Общее описание структуры планировщика представлена на Рисунке 1.48. 123 Рисунок 1.48 - Общее описание структуры планировщика 1.8.2 Интерфейсы, примеры интерфейсов, реализованных на основе алгоритма разрешения конфликтов по всему расписанию Разрабатываемый в рамках проекта экспериментальный образец должен обеспечивать удобное взаимодействие с пользователем, показывать вновь поступающие события и текущее расписание работ, а также фактическое состояние работ. Интерфейс должен поддерживать простой и доступный ввод плановых значений движения транспорта, поддержку возможности внесения фактических данных (не совпадающих с плановыми), показывать прогресс планирования и результаты планирования (значения KPI позволяющие определить какой из вариантов лучше и почему). Основным интерфейсом отражающим выходные данные должны стать графики движения транспорта, с возможностью отображения окон. 124 Получаемые решения должны поддерживать возможность быть согласованными и санкционированными, либо должны быть отправлены на доработку пользователем, выступающим в роли диспетчера. В ходе работы экспериментального образца необходимо предусмотреть интерфейс, позволяющий изменять критерии планирования (например приоритет). Ниже показаны примеры выходных интерфейсов в качестве графиков движения, при отработке сценариев планирования и решения конфликтов: а) два поезда с одинаковыми приоритетами и одинаковой скоростью движения На Рисунке 1.49, Рисунке 1.50 показано, что разрешение конфликта для данного сценария выполняется за счет задержки одного из поездов, график движения которого изображен синим цветом, на станции. Рисунок 1.49 – График движения поездов до разрешения конфликта 125 Рисунок 1.50 – График движения поездов после разрешения конфликта б) Три поезда с одинаковыми приоритетами и одинаковой скоростью движения На Рисунке 1.51, Рисунке 1.52 показано, что разрешение конфликта для данного сценария выполняется за счет задержек поезда, график движения которого изображен синим цветом, на блок-участках, и пропуска остальных поездов, а также за счет уменьшения интервала движения между поездами, графики которых изображены красным и зеленым цветом, на отдельных блок-участках. 126 Рисунок 1.51 – График движения поездов до разрешения конфликта Рисунок 1.52 – График движения поездов после разрешения конфликта 127 в) два поезда, один из которых имеет более высокий приоритет и большую скорость движения На Рисунке 1.53, Рисунке 1.54 показано, что разрешение конфликта для данного сценария выполняется за счет задержки низкоприоритетного поезда на станции и пропуска более высокоприоритетного поезда. Рисунок 1.53 – График движения поездов до разрешения конфликта 128 Рисунок 1.54 – График движения поездов после разрешения конфликта 1.8.3 Выводы и предложения по результатам проведенных анализа и исследований Основная задача ЭО – обеспечение гибкого и эффективного перепланирования расписания железнодорожного транспорта в реальном времени с учетом приоритетного движения высокоскоростных поездов при возникновении незапланированных событий. При этом экспериментальный образец должен иметь возможность функционирования как адаптивная р2р сеть модулей, по крайней мере, 2х модулей интеллектуальных планировщиков (например, модуль планирования высокоскоростного ЖД транспорта и модуль управления ремонтными работами). В рамках выполнения этапа №1 по ГК, были выполнены работы по созданию экспериментального образца, в том числе созданы классы объектов необходимых для успешного выполнения функций планирования. Большинство классов описано в подразделе №1.5 «Разработка программного мультиагентного подхода к построению процессов управления ЖД ресурсами» в виде онтологии. Помимо классов описаны и формализованы интерфейсы реализуемые данными классами. Описанные интерфейсы и классы положены в основу мультиагентного модуля планирования. 129 2 ЭТАП 2. ЭКСПЕРИМЕНТАЛЬНЫЕ ИССЛЕДОВАНИЯ ПОСТАВЛЕННЫХ ПЕРЕД НИР ЗАДАЧ 2.1 Разработка частного технического задания на создание экспериментального образца по ГОСТ 34.602-89. Для создания экспериментального образца прототипа интеллектуальной системы для согласованного адаптивного планирования и связанного изменения планов движения поездов для минимизации отклонения высокоскоростных поездов класса «Сапсан» от графика движения под влиянием непредвиденных внешних событий было создано частное техническое задание (ЧТЗ). ЧТЗ представлено отдельным документом отчетной документации по НИР. 2.2 Разработка структуры онтологии инфраструктуры РЖД, включая базовые классы, концепты, отношения, свойства и атрибуты инфраструктуры РЖД, используемые в процессе планирования, для настройки на конкретные примеры применения Для описания знаний, необходимых агентам, входящим в состав МАС, используется онтологический подход, согласно которому знания должны быть отделены от программного кода системы и должны храниться в онтологии, представляющей собой сеть понятий и отношений предметной области. 2.2.1 Онтологический подход к описанию знаний предметной области Существует множество определений онтологии, наиболее широко используемым является следующее: «Онтология – это явная спецификация концептуализации» [1]. Здесь концептуализация означает абстрактное представление предметной области. Распространено также определение: «Онтология – общее понимание некоторой области интереса» [2]. Онтология – это формализованные концептуальные знания о предметной области, представленные в форме, допускающей компьютерную обработку и используемые при принятии решений. Концептуальность знаний онтологии означает, что эти знаний формулиру130 ются в терминах основных концептов (наиболее общих понятий и отношений), описывающих фрагменты окружающего мира. Концептуальность знаний онтологии означает, что эти знания формулируются в терминах основных понятий и отношений, описывающих фрагменты окружающего мира. Онтологии используются в качестве основы базы знаний об основных понятиях предметной области и связях между ними, этим обеспечивается единство терминологии и предоставляется возможность расширения знаний системы в случае появления новых концептов и связей, а также появляется возможность формально специфицировать ситуации в реальности. Краткий сравнительный анализ баз знаний против баз данных представлен на Рисунке 2.1. Онтология – это попытка всеобъемлющей и детальной формализации некоторой области знаний с помощью концептуальной схемы. Обычно такая схема состоит из структуры данных, содержащей все релевантные классы объектов, их связи и правила (теоремы, ограничения), принятые в этой области. Этот термин в информатике является производным от древнего философского понятия «онтология». Термин «онтология» используется как для обозначения базы знаний в целом, содержащей описания данных с помощью некоторой концептуальной схемы, так и для обозначения собственно концептуальной схемы, при этом оперативная информация, отражающая текущее состояние объектов, специфицированных с помощью концептов и отношений, выделяется в так называемую «сцену». В настоящее время онтологии все шире применяются для описания предметных областей и решения сложных задач моделирования, поддержки принятия решений, извлечения знаний и построения мультиагентных систем, при этом размер и сложность онтологий и баз знаний постоянно возрастают. Как правило, для создания таких сложных баз знаний требуется совместная работа нескольких экспертов. Рассмотрим требования к системе коллективной разработки онтологий, которая обеспечивала бы эффективную формализацию, проверку и использование знаний: а) контроль и разрешение противоречащих изменений знания; б) обнаружение и устранение ошибок; в) обнаружение и устранение избыточности онтологий, генерализация знаний; г) нотификация пользователей об изменения в онтологии; д) независимость и переносимость отдельных частей онтологий; е) распределённость знаний, физическое независимое хранение различных частей онтологий; ж) протоколирование изменений; 131 Рисунок 2.1 – Сравнительный анализ баз знаний и баз данных и) поддержка историчности, т.е. возможность возврата на предыдущее состояние базы знаний; к) устойчивость и надежность хранилища онтологии и базы знаний; л) поддержка многопользовательского режима работы с онтологиями в условиях распределённых и неоднородных пользователей: различное географическое положение, различные платформы (Microsoft Win-dows, Linux, MacOS и т.д.); м) обеспечение необходимой производительности в случае параллельной работы многих пользователей; 132 н) безопасность знаний от несертифицированного доступа; п) разделение прав пользователей при работе с базой знаний на уровне онтологий, элементов онтологий, операций над онтологией (просмотр, редактирования, удаление). В настоящее время для создания и поддержки онтологий существует целый ряд инструментов, которые помимо общих функций редактирования и просмотра выполняют поддержку документирования онтологий, импорт и экспорт онтологий разных форматов и языков, поддержку графического редактирования, управление библиотеками онтологий и т.д. Рассмотрим наиболее известные инструменты инженерии онтологий. Система Ontolingua была разработана в KSL (Knowledge Systems Laboratory) Стенфордского университета и стала первым инструментом онтологий. Она состоит из сервера и языка представления знаний. Сервер Ontolingua организован в виде набора онтологий, относящихся к Web-приложениям, которые надстраиваются над системой представления знаний Ontolingua. Редактор онтологий – наиболее важное приложение сервера Ontolingua является Web-приложением на основе форм HTML. Кроме редактора онтологий Сервер Ontolingua включает Webster (получение определений концептов), сервер OKBC (доступ к онтологиям Ontolingua по протоколу OKBC) и Chimaera (анализ, объединение, интегрирование онтологий). Все приложения, кроме сервера OKBC, реализованы на основе форм HTML. Система представления знаний реализована на Lisp. Сервер Ontolingua также предоставляет архив онтологий, включающий большое количество онтологий различных предметных областей, что позволяет создавать онтологии из уже существующих. Сервер поддерживает совместную разработку онтологии нескольким пользователям, для чего используются понятия пользователей и групп. Система включает графический браузер, позволяющий просмотреть иерархию концептов, включая экземпляры. Ontolingua обеспечивает использование принципа множественного наследования и богатый набор примитивов. Сохраненные на сервере онтологии могут быть преобразованы в различные форматы для использования другими приложениями, а также импортированы из ряда языков в язык Ontolingua. Protégé – локальная Java программа, разработанная группой медицинской информатики Стенфордского университета. Программа предназначена для построения (создания, редактирования и просмотра) онтологий моделей прикладной области. Её первоначальная цель – помочь разработчикам программного обеспечения в создании и поддержке явных моделей предметной области и включение этих моделей непосредственно в программный код. Protégé включает редактор онтологий, позволяющий проектировать онтологии разворачивая иерархическую структуру абстрактных или конкретных классов и слотов. Структура онтологии сделана аналогично иерархической структуре каталога. На основе сформированной онтоло133 гии, Protégé может генерировать формы получения знаний для введения экземпляров классов и подклассов. Инструмент имеет графический интерфейс удобный для использования неопытными пользователями, снабжен справками и примерами. Protégé основан на фреймовой модели представления знания OKBC (Open Knowledge Base Connectivity) и снабжен рядом плагинов, что позволяет его адаптировать для редактирования моделей в разных форматах (стандартный текстовый, базы данных JDBC, UML, языков XML, XOL, SHOE, RDF и RDFS, DAML+OIL, OWL). OntoEdit первоначально был разработан в институте AIFB, Университета Karlsruhe (сейчас коммерциализован Ontoprise GmbH) выполняет проверку, просмотр, кодирование и модификацию онтологий. В настоящее время OntoEdit поддерживает языки представления: FLogic, включая машину вывода, OIL, расширение RDFS и внутреннюю, основанную на XML, сериализацию модели онтологии используя OXML. К достоинствам инструмента можно отнести удобство использования; разработку онтологии под руководством методологии и с помощью процесса логического вывода; разработку аксиом; расширяемую структуру посредством плагинов, а также очень хорошую документацию. Так же как и Protégé, OntoEdit – автономное Java–приложение, которое можно локально установить на компьютере, но его коды закрыты. Архитектура OntoEdit подобна Protégé. Существует две версии OntoEdit: свободно распространяемая OntoEdit Free и лицензированная OntoEdit Professional. Естественно, что OntoEdit Professional имеет более широкий набор функций и возможностей (например, машину вывода, графический инструмент запросов, больше модулей экспорта и импорта, графический редактор правил, поддержка формата баз данных JDBC и т.д.). OilEd – автономный графический редактор онтологий, разработан в Манчестерском университете в рамках европейского IST проекта On-To-Knowledge. Инструмент основан на языке OIL (сейчас адаптирован для DAML+OIL, в перспективе – OWL), который сочетает в себе фреймовую структуру и выразительность дескриптивной логики c сервисами рассуждения. Что позволило обеспечить понятный и интуитивный стиль интерфейса пользователя и преимущества поддержки рассуждения (обнаружение логически противоречивых классов и скрытых отношений подкласса). Из недостатков можно выделить отсутствие поддержки экземпляров. WebOnto разработан для Tadzebao – инструмента исследования онтологий и предназначен для поддержки совместного просмотра, создания и редактирования онтологий. Его цели – простота использования, предоставление средств масштабирования для построения больших онтологий. Для моделирования онтологий WebOnto использует язык OCML (Operational Conceptual Modeling Language). В WebOnto пользователь может создавать структуры, включая классы с множественным наследованием, что можно выполнять графически. 134 Инструмент проверяет вновь вводимые данные контролем целостности кода OCML. Инструмент имеет ряд полезных особенностей: сохранение структурных диаграмм, раздельный просмотр отношений, классов, правил и т.д. Другие возможности включают совместную работу нескольких пользователей над онтологией, использование диаграмм, функций передачи и приёма и др. KADS22 – инструмент поддержки проектирования моделей знаний согласно методологии CommonKADS. Онтологии составляют часть таких моделей знаний (другая часть - модели вывода). Модели CommonKADS определены в CML (Conceptual Modeling Language). KADS22 – интерактивный графический интерфейс для CML со следующими функциональными возможностями: синтаксический анализ файлов CML, печать, просмотр гипертекста, поиск, генерация глоссария и генерация HTML. 2.2.2 Онтологический базис, способы представления онтологии Онтологии могут представляться различным образом: а) фреймы б) продукции в) семантические сети В разрабатываемой системе предлагается использовать семантические сети, которые образуются классами понятий и отношений, играющих роль связей. В онтологиях (по Аристотелю) можно выделить особые подклассы понятий: а) объекты - сущности, характеризуемые состояниями б) процессы – изменения состояний объектов в) отношения – позволяют конструировать новые объекты г) свойства – отражают способность объектов вступать во взаимодействие д) атрибуты – позволяют качественно или количественно характеризовать свойства Примеры классов понятий и отношений: а) классы понятий: «Транспортное средство», «Поезд», «Вагон», «Бригада», «Груз» б) примеры свойств: Цистерна «Может перевозить» нефть в) примеры процессов: «Груз доставляется вагоном потребителю», «Вагоны формируют поезд» г) примеры отношений: Груз «находиться» на поезде, груз «забронировал» вагон д) примеры атрибутов поезда: «Плановая дата отбытия», «Длительность движения», «Станция назначения», «Скорость движения». 135 В упрощенном виде фрагмент онтологии РЖД, показывающий примеры используемых понятий и отношений, показан на Рисунке 2.2. Рисунок 2.2 – Упрощенный фрагмент онтологии РЖД Для удобства работы с онтологиями выделяют триаду «онтология-модель-сцена»: а) онтология описывает понятия и отношения (как толковый словарь), необходимые для описания моделей объектов предметной области РЖД (станций, локомотивов, вагонов и т.д.). б) модель описывает устойчивые комбинации понятий и отношений (часть которых для удобства работы конкретизирована, например, модель станции), упрощающие создание формализованных описаний сцен и ситуаций на конкретных станциях. в) сцена описывает экземпляры понятий и отношений в заданный момент времени (как набор фактов) необходимые для описания «фотографии» ситуации на каждой конкретной станции с заданным уровнем подробности (включая текущее состояние объектов) в каждый момент времени. На Рисунке 2.3 показана взаимосвязь между понятиями «онтология предметной области» – «модель проекта» – «сцена». 136 1. Онтология описывает понятия и отношения (как толко- Онтология предметной области Онтология предметной Модель области проекта вый словарь), необходимые для описания моделей объектов любой предметной области науки (биотехнологии, наносистемы, космос, живые системы и т.д.). 2. Модель описывает устойчивые комбинации понятий и отношений (часть которых для удобства работы конкретизирована, например, модель продукта или технологии), упрощающие создание формализованных описаний сцен и ситуаций в конкретных проектах. Модель 3. Сцена описывает экземпляры понятий и отношений в проекта Сцена заданный момент времени (как набор фактов), необхо- (ситуация) Сцена (ситуация) димые для описания «фотографии» ситуации на каждом конкретном проекте с заданным уровнем подробности в каждый момент времени. 4. Онтология описывает понятия и отношения (как толко- вый словарь), необходимые для описания моделей объРисунок 2.3 – Взаимосвязь между понятиями «онтология предметной области» – «модель ектов любой предметной области науки (биотехнолопроекта» – «сцена» гии, наносистемы, космос, живые системы и т.д.). С использованием онтологии можно специфицировать конкретные факты и строить 5. Модель описывает устойчивые комбинации понятий и модели описания ситуаций (сцен) для работы агентов. отношений (часть которых для удобства работы конПреимущества применения онтологий для управления ресурсами РЖД: кретизирована, например, модель продукта или техноа) возможности и потребности РЖД постоянно меняются: вводятся новые станции, логии), упрощающие создание формализованных опименяется парк вагонов и локомотивов и т.д. Использование онтологий позволяет саний сцен и ситуаций в конкретных проектах. минимизировать затраты на внесение таких изменений; 6. Сцена описывает экземпляры понятий и отношений в б) описав отдельными онтологиями (концептами и отношениями) предметные облазаданный момент времени (как набор фактов), необхости РЖД, получаем возможность использовать их для построения моделей подраздимые для описания «фотографии» ситуации на кажделений РЖД в их конкретных конфигурациях и отражать их состояние сценами дом конкретном проекте с заданным уровнем подроб(«моментальными фотографиями» экземпляров объектов и отношений); ности в каждый момент времени. в) такой подход позволит отделить знания об объектах и их связях от программного кода системы и пополнять описания мира подразделений РЖД по мере необходимости, без перепрограммирования системы в каждом случае, например в следующем случае: Предположим, что планируется ввести класс локомотивов, который требует новых запчастей и ремонтов, расходных материалов и т.д. Для этого необходимо вве137 сти в онтологию новый объект и описать, что этот класс локомотивов требует (через специальное отношение «нуждается-в») указанных видов ремонта и запчастей, причем следует образовать базовые подклассы данного отношения, для которых можно задавать, какие ресурсы и в каком количестве нужны для планового ремонта (работники, детали), с какой регулярностью проводятся ремонты и т.д. Тогда агент нового локомотива сможет прочитать из онтологии конкретную специфику потребностей данной машины, создаст под них связанных агентов, которые будут планировать и поставлять необходимые ресурсы к нужному сроку. В этом случае придется допрограммировать систему только в случае возникновения непредвиденных ранее новых подклассов данного отношения, причем после такого дополнительного введения соответствующее отношение пополнит общую библиотеку отношений и станет доступным для всех подобных ситуаций. С использованием онтологии можно специфицировать конкретные факты и строить модели описания ситуаций для работы агентов Сцены используются для представления и обработки оперативной информации о ситуациях, являясь «фотографией» («зеркалом») реальности, что позволяет системе иметь в любой момент времени формализованное описание ситуации в выбранном фрагменте реальности, используемой для принятия решений агентами. Онтология включает машинно-интерпретируемые формулировки основных понятий предметной области и отношения между ними. Для представления онтологии и сцен используется семантическая сеть, которая состоит узлов и упорядоченных отношений (связей), соединяющих эти узлы. Узлы выражают понятия или предположения, а связи описывают взаимоотношения между этими узлами. Использование онтологий, моделей и сцен нужно, прежде всего, для того, чтобы стало возможным формализовывать, специфицировать, накапливать, изменять знания, используемые при автоматизированном принятии решений. Действительно, многие объекты и связи между ними, а также списки свойств и атрибутов в процессе работы постоянно меняются и можно предложить описывать предметные области отдельными онтологиями, которые потом использовать для построения моделей в конкретных конфигурациях, и отражать состояние реальности сценами («моментальными фотографиями») объектов и отношений с нужным уровнем детальности. Это позволит отделить знаний об объектах и их связях от программного кода системы и пополнять описания мира автоматизируемого объекта по мере необходимости, без перепрограммирования системы в случае изменений, и использовать эти знания для описания ситуаций. 138 2.2.3 Структура онтологии инфраструктуры РЖД 2.2.3.1 Базовые классы Ниже приведено описание структуры онтологии инфраструктуры РД, представляющее собой формализованное описание предметной области в виде классов. Разработана структура онтологии для описания основных концептов и отношений предметной области, концепт характеризуется свойствами (атрибутами). Направление – концепт описывает направление железной дороги. Атрибуты: а) начальный пункт, б) конечный пункт, в) протяженность, г) количество путей, д) движение поездов. Движение поездов – концепт описывает поезда, проходящие по направлению железной дороги. Атрибуты: а) тип поезда, б) количество поездов в сутки. Путь – концепт описывает часть железной дороги для одновременного движения поездов только в одном направлении. Атрибуты: а) I путь для движения поездов с четными номерами, б) II путь для движения поездов с нечетными номерами. Инфраструктура – концепт описывает участок железной дороги. Атрибуты: а) элемент пути, б) станция. Элемент пути – концепт описывает часть дорожной инфраструктуры – наследник концепта IOResource. Атрибуты: а) блок-участок, б) светофор, в) стрелка, г) переезд, 139 д) временные отношения – наследник концепта ItemporaryRelation. Блок-участок – концепт описывает минимальный учетный отрезок железной дороги протяженностью 1-1,5 км – наследник концепта Элемент пути. Атрибуты: а) путь, б) головная станция, в) расстоянием от головной станции на начало участка, г) расстоянием от головной станции на конец участка, д) признак занятости, е) местонахождение: 1) на перегоне, 2) внутри станции, ж) признак ложной занятости, и) светофор, к) следующий блок-участок. Стрелка – концепт описывает техническое устройство для перевода поезда с одного пути на другой – наследник концепта Элемент пути. Атрибуты: а) номер, б) станция, в) входной путь, г) выходной путь. Светофор – концепт описывает техническое устройство, сигнализирующее о возможности движения – наследник концепта Элемент пути. Атрибуты: а) номер, б) станция, в) параметры работы: 1) зеленый – открыт, 2) красный – закрыт. Переезд – концепт описывает пересечение железной дороги с автодорогой – наследник концепта Элемент пути. Атрибуты: а) идентификатор, б) параметры работы: 140 1) закрытие переезда, 2) открытие переезда. Поездная модель дороги (ПМД) – концепт описывает технологические операции с поездами в пределах дороги. Атрибуты: а) массив положения поездов, б) массив положения вагонов, в) массив положения локомотивов, г) элементы пути, д) состояние элементов пути. Маршрут движения – концепт описывает план движения поезда по путям железной дороги. Атрибуты: а) станция отправления, б) станция назначения, в) элемент пути. Станция – концепт описывает пункт, имеющий путевое развитие для приема, отправления, обгона поездов – наследник концепта IOResource. Атрибуты: г) название станции, д) поездная модель станции (ПМС). Поездная модель станции (ПМС) – концепт описывает технологические операции с вагонами поездов в пределах станции. Атрибуты: а) название станции, б) массив технологических операций, в) файл данных прицепок/отцепок вагона. Вагон – концепт описывает вагон. Атрибуты: а) инвентарный номер, б) порядковый номер в составе, в) поезд (состав), г) тип вагона: 1) контейнер, 2) платформа, 141 3) для сыпучих грузов, д) вес груза, е) код груза, ж) признак негабаритности груза, и) код станции назначения, к) код получателя, л) предельный срок доставки груза, м) состояние вагона: 1) нерабочий, 2) арендован, н) ограничение скорости, п) положение на станции (номер пути). Локомотив – концепт описывает локомотив. Атрибуты: а) инвентарный номер, б) поезд, в) массив технологических операций, г) положение на станции (номер пути). Поезд – концепт описывает сформированный состав из локомотива и вагонов – наследник концепта IOResource. Атрибуты: а) номер, б) направление движения, в) тип поезда: 1) высокоскоростной, 2) скорый, 3) пригородный, 4) пассажирский, 5) грузовой, г) количество вагонов, д) длина, е) массив технологических операций, ж) положение на станции (номер пути), и) индекс поезда в ПМД, к) индекс поезда в ПМС, 142 л) состояние: 1) движение, 2) экстренное торможение, 3) формирование, 4) расформирование, м) расписание, н) запланированное расписание. Отцеп – концепт описывает группу вагонов для выполнения технологических операций. Атрибуты: а) номер пути на станции, б) количество вагонов, в) массив технологических операций. Технологическая операция – концепт описывает производственные операции над вагонами и поездами. Атрибуты: а) код, б) наименование, в) мнемокод. Сортировочный листок – концепт описывает инструкцию для работников, занятых формированием/расформированием отцепов. Атрибуты: а) поезд, б) массив отцепов. Приемосдатчик – концепт описывает работника, осуществляющего коммерческий осмотр расформируемого состава. Атрибуты: а) ФИО, б) сортировочный листок. Горочный составитель – концепт описывает работника, выполняющего формирование состава на сортировочной горке. Атрибуты: а) ФИО, б) сортировочный листок, в) план формирования поезда. 143 Отцепщик – концепт описывает работника, выполняющего операции отцепки/сцепки вагонов. Атрибуты: а) ФИО, б) сортировочный листок. План формирования грузового поезда – концепт описывает упорядоченную таблицу кодов станций для выделения назначений плана формирования грузовых поездов. Атрибуты: а) код назначения поезда, б) массив номеров станций назначений вагонов, в) массив номеров станций расформирования поезда. Окно (проведения ремонтных работ) – концепт описывает выполняемые работы на определенных участках путей – наследник концепта IOperation. Атрибуты: а) элемент пути, на котором находится окно, б) вид работ, в) время начала работ, г) время окончания работ, д) тип окна: 1) проездное, 2) непроездное. Информация – концепт описывает информационное сообщение, например, об отсутствии напряжения. Атрибуты: а) сообщение, б) элемент пути, для которого выдается информация. Конфликтная ситуация – концепт описывает конфликтные ситуации, имеющие отношение к грузовому поезду. Атрибуты: а) тип конфликтной ситуации, б) алгоритм разрешения конфликтной ситуации. Телеграмма-натурный лист – концепт описывает технологический документ, с помощью которого осуществляется учет наличия вагонов на станции, учет перехода поездов, вагонов и контейнерам по межгосударственным или междорожным стыкам. Атрибуты: 144 а) станция формирования поезда, б) станция расформирования поезда, в) порядковый номер состава для направления списывания вагонов (с головы или хвоста), г) дата и время отправления со станции формирования, д) условная длина состава, е) масса брутто состава, ж) маршрут. Расписание представляет собой группу пар экземпляров концепта ITransition, соответствующих экземплярам концепта IState. Строка расписания – концепт ILineSchedule описывает строку расписания. Атрибуты: а) станция, б) время прибытия на станцию, в) время отбытия со станции. Требование планирования какого-либо какого-либо действия – концепт IDemand. Требование к планированию расписания движущегося объекта – концепт IMovingObjectDemand, наследник концепта IDemand. Атрибуты: а) приоритетный путь, б) список строк расписания – экземпляров концепта ILineShedule. Требование к планированию окон работ с подвижными или жестко заданными сроками – концепт InfrastructureElementBlockageDemand, наследник концепта IDemand. Атрибуты: а) блок-участок, б) список строк расписания – экземпляров концепта ILineShedule. Расписание поезда – концепт описывает расписание движения поезда – наследник концепта IDemand. Атрибуты: а) поезд, б) количество строк расписания, в) строки расписания. Строка расписания поезда – концепт описывает движения поезда между станциями. Атрибуты: а) номер по порядку, 145 б) станция, в) время прибытия, г) время отправления, д) входящий маршрут движения, е) исходящий маршрут движения. Запланированное расписание поезда – концепт описывает расписание движения поезда, построенное планировщиком на основе реального состояния движения – наследник концепта ITemporaryRelation. Атрибуты: а) количество строк расписания, б) окно. в) скорость, г) состояние поезда. Расписание окон – концепт описывает расписание окон – наследник концепта IOperation. Атрибуты: а) количество строк расписания, б) окно. Запланированное расписание окон – концепт описывает расписание движения поезда, построенное планировщиком на основе реального состояния движения – наследник концепта ITemporaryRelation. Диспетчер – концепт описывает должностное лицо, ответственное за организацию движения на конкретном участке. Атрибуты: а) ФИО, б) круг. Круг – концепт описывает зону ответственности поездного диспетчера на конкретном участке. Атрибуты: а) диспетчер, б) инфраструктура, в) действия. Состояние движущегося объекта в определенный момент времени – концепт IState. Пример – прибытие поезда на блок-участок. 146 Временные рамки некоторого состояния движущегося объекта (временной слот) – концепт ITransition описывает временной слот, т.е. начальный и конечный моменты времени пребывания движущегося объекта в некотором состоянии. Пример – интервал занятия поездом блок-участка. Концепт осуществляет связку с предыдущим и последующим ITransition. Состоит из двух IState, описывающих начальный и конечный моменты пребывания объекта в некотором состоянии, например, прибытие поезда на блок-участок и отбытие с него. Атрибуты: а) время начала, б) время окончания, в) состояние. 2.2.3.2 Реализация базовых классов и отношений онтологии инфраструктуры РЖД Корневой концепт предметной области – IObject. Все последующие концепты расширяют данный корневой концепт. Существует только как составная часть системы и нужен для работы, в реальном мире нет аналогов. Объявленные методы: а) boolean isClosed() – возвращает признак «закрытия» объекта в системе, закрытые объекты не участвуют в планировании и со временем удаляются из сцены; б) void setClosed(boolean value) – устанавливает признак «закрытия» объектов; в) boolean getValidity() – возвращает признак валидности объекта; г) void setValidity(boolean value) – устанавливает признак валидности объекта. Ресурс – концепт описывает объекты, относящиеся к ресурсам системы: блок-участок, стрелка, станция, движущийся объект. Перечисленные концепты расширяют данный концепт IResourse. Расширяет концепт IObject. Дополнительных объявленных методов не имеет. Блок-участок – описывает минимальный учетный отрезок железной дороги протяженностью 1-1,5 км, только прямой участок дороги, без ответвлений, связан с последующим и предыдущим блок участком – реазуемый концепт InfrastructureElement. Расширяет концепт IResourse. Объявленные методы: а) Collection<IInfrastructureElement> getConnections() – возвращает коллекцию элементов, соединенных с данным блок-участком; б) Collection<IIEGroup> getGroups() – возвращает коллекцию групп, в которые входит данный блок-участок; 147 в) INode getNode() – возвращает объект концепта стрелка, если блок-участок является частью стрелки.; г) double getLength() – возвращает длину блок-участка в километрах; д) double getMaxSpeed(IMovingObject movingObject) – возвращает ограничение скорости на данном блок-участке для конкретного поезда; е) double getTravelKPI(IMovingObject movingObject) – возвращает KPI данного блокучастка для конкретного поезда. Стрелка – описывает техническое устройство для перевода поезда с одного пути на другой, используется в системе по упрощённой схеме реализации. В системе Стрелку реализует концепт INode. Расширяет концепт IResourse. Объявленные методы: а) Collection<IInfrastructureElement> getElements() – возвращает коллекцию из всех блок-участков принадлежащих стрелке; б) Collection<IInfrastructureElement> getInputElements() – возвращает коллекцию только «входных» блок-участков данной стрелки, блок-участки из данного списка не имеют связей между собой; в) Collection<IInfrastructureElement> getOutputElements() – возвращает коллекцию только «выходных» блок-участков данной стрелки, блок-участки из данного списка не имеют связей между собой; Станция описывает пункт, имеющий путевое развитие для приема, отправления, обгона поездов – описывает концепт IIEGroup (коллекция блок-участков). Расширяет концепт IResourse. Объявленные методы: а) Collection<IInfrastructureElement> getElements() – возвращает коллекцию блокучастков данной станции. Движущийся объект – виды поездов, локомотивов, вагонов, кранов и т.д., любые движущиеся объекты на блок участке – реализует концепт IMovingObject. Расширяет концепт IResourse. Объявленные методы: а) int getNumber() – метод возвращает номер присвоенный движущемуся объекту; б) int getPriority() – метод возвращает приоритет движущегося объекта, принятый в системе; в) double getMaxVelocity() – метод возвращает максимальную скорость с которой может совержать движение объект. 148 Состояние ресурса в определенный момент времени – концепт IState. Расширяет концепт IObject. Объявленные методы: а) Date getTime() – возвращает время данного состояния; б) void setTime(Date value) – устанавливает время для данного состояния; в) List<IResource> getResources() – возвращает список ресурсов связанных с данным состоянием; г) void setResources(List<IResource> value) – устанавливает список ресурсов для данного ресурса; д) boolean isFixed() – возвращает признак фиксированности состояния; е) void setFixation(boolean value) – устанавливает признак фиксации состояния; ж) int getPriority() – возвращает приоритет данного состояния. Требование планирования какого-либо действия – концепт IDemand. Расширяет концепт IObject. Объявленные методы: а) int getPriority() – возвращает приоритет данного требования. Состояние железнодорожного ресурса в определенный момент времени – концепт IRailsState. Пример – прибытие поезда на блок-участок, окно ремонтных работ на блокучастке. Расширяет концепт IState. Объявленные методы: а) IInfrastructureElement getElement() – возвращает блок-участок, связанный с данным состоянием; б) void setElement(IInfrastructureElement value) – устанавливает блок-участок, связанный с данным состоянием; в) IDemand getGenerativeDemand() – возвращает требование связанное с данным состоянием; г) void setGenerativeDemand(IDemand value) – устанавливает требование, связанное с данным состоянием. Состояние движущегося объекта в определенный момент времени – концепт IMovingObjectState. Расширяет концепт IRailsState. Объявленные методы: а) boolean isCheckpoint() – возвращает признак состояния - принадлежит ли блокучасток состояния станции, которая присутствует в расписании движущегося объекта; 149 б) void setCheckpoint(boolean value) – устанавливает признак чек-поинта состояния; в) IMovingObject getMovingObject() – возвращает движущийся объект, связанный с состоянием; г) void setMovingObject(IMovingObject movingObject) – устанавливает движущийся объект, связанный с состоянием; д) double getMaxVelocity() – возвращает максимально допустимую скорость для данного состояния; е) void setMaxVelocity(double value) – устанавливает максимально допустимую скорость для данного состояния. Состояние блок-участка в определенный момент времени – концепт IInfrastructureElementState. Расширяет концепт IRailsState. Объявленные методы: а) double getMaxVelocity() – возвращает ограничение по скорости для данного состояния на блок-участке; б) void setMaxVelocity(double value) – устанавливает ограничение по скорости для данного состояния на блок-участке; Агент – концепт IAgent. Расширяет концепт IObject. Дополнительных объявляемых методов не имеет. Временные рамки некоторого состояния ресурса (временной слот) – концепт ITransition описывает временной слот, т.е. начальный и конечный моменты времени пребывания ресурса в некотором состоянии. Концепт осуществляет связку с предыдущим и последующим ITransition. Состоит из двух IState, описывающих начальный и конечный моменты пребывания объекта в некотором состоянии, например, прибытие поезда на блок-участок и отбытие с него. Расширяет концепт IObject и IAgent Объявленные методы: а) IState getStart() – возвращает состояние начала временного слота; б) IState getFinish() – возвращает состояние конца временного слота; в) void setStart(IState value) – устанавливает состояние начала временного слота; г) void setFinish(IState value) – устанавливает состояние конца временного слота; д) ITransition getNext() – возвращает следующий временной слот, связанный с данным; е) void setNext(ITransition value) – устанавливает следующий временной слот, связанный с данным; ж) ITransition getPrevious() – возвращает предыдущий временной слот, связанный с данным; 150 и) void setPrevious(ITransition value) – устанавливает предыдущий временной слот, связанный с данным. Временные рамки некоторого состояния железнодорожного ресурса (временной слот) – концепт IRailsTransition описывает временной слот, т.е. начальный и конечный моменты времени пребывания железнодорожного ресурса в некотором состоянии. Пример – интервал занятия поездом блок-участка, интервал ремонтных работ на блок-участке. Расширяет концепт ITransition. Объявляемых методов не имеет. Временные рамки некоторого состояния движущегося объекта (временной слот) – концепт IMovingObjectStateTransition описывает временной слот, т.е. начальный и конечный моменты времени пребывания движущегося объекта в некотором состоянии. Расширяет концепт IRailsTransition и IAgent. Объявленные методы: а) TimeSpan getMinimumTimeSpan() – возвращает минимальную продолжительность временного слота; б) void setMinimumTimeSpan(TimeSpan value) – устанавливает минимальную продолжительность временного слота. Временные рамки некоторого состояния блок-участка (временной слот) – концепт IInfrastructureElementStateTransition описывает временной слот, т.е. начальный и конечный моменты времени пребывания блок-участка в некотором состоянии. Расширяет концепт IRailsTransition и IAgent. Дополнительных объявленных методов не содержит. Строка расписания – концепт ILineSchedule описывает строку расписания. Расширяет концепт IObject. Объявленные методы: а) IIEGroup getCheckpoint() – возвращает станцию, связанную с данной строкой расписания; б) Date getArrivalTime() – возвращает время прибытия по расписанию на станцию данной строки; в) Date getDepartureTime() - возвращает время отправления по расписанию на станцию данной строки; г) void setCheckpoint(IIEGroup value) – устанавливает станцию, связанную с данной строкой расписания; д) void setArrivalTime(Date value) – устанавливает время прибытия на станцию данной строки; е) void setDepartureTime(Date value) - устанавливает время отправления на станцию данной строки. 151 Требование к планированию расписания движущегося объекта – концепт IMovingObjectDemand. Расширяет концепт IDemand и IAgent. Объявленные методы: а) List<IInfrastructureElement> getCurrentRoute() – возвращает текущий маршрут движущегося объекта по блок-участкам, связанный с данным требованием; б) void setCurrentRoute(List<IInfrastructureElement> list) – устанавливает текущий маршрут движущегося объекта по блок-участкам, связанный с данным требованием; в) List<IInfrastructureElement> getRequiredRoute() – возвращает требуемый маршрут движущегося объекта по блок-участкам, связанный с данным требованием; г) void setRequiredRoute(List<IInfrastructureElement> list) - устанавливает требуемый маршрут движущегося объекта по блок-участкам, связанный с данным требованием; д) List<ILineSchedule> getRequiredSchedule() – возвращает список из строк требуемого расписания; е) List<ILineSchedule> getResultingSchedule() – возвращает список из строк полученного расписания; ж) void setResultingSchedule(List<ILineSchedule> value) – устанавливает список из строк результирующего расписания; и) IMovingObject getMovingObject() – возвращает движущийся объект, связанный с данным требованием. Требование к планированию окон работ с подвижными или жестко заданными сроками – концепт InfrastructureElementBlockageDemand. Расширяет концепт IDemand и IAgent. Объявленные методы: а) IInfrastructureElement getBlockedElement() – возвращает блок-участок, для которого планируется окно ремонтных работ; б) Date getStart() – возвращает время начала окна; в) Date getFinish() – возвращает время окончания окна; г) void setStart(Date value) – устанавливает время начала окна; д) void setFinish(Date value) – устанавливает время окончания окна; е) Set<IMovingObject> getDeniedMovingObjects() – возвращает набор поездов для которых окно является непроходным; ж) double getMaxVelocity() – возвращает ограничение по скорости движения в данном окне. 152 2.3 Разработка принципов создания и редактирования онтологий и сцен, содержащих оперативную информацию о ситуации на участке направления, в виде семантических сетей Для работы с онтологиями и сценами необходимо разработать библиотеку инструментальных программных средств для поддержки создания, редактирования и навигации по онтологии и для создания и редактирования сцен, основанных на онтологиях. Такие средства должны позволять: а) проектировать онтологии в виде семантических сетей. При этом разработчик и пользователь может создавать и редактировать онтологии, специфицируя свои концепты (классы) и устанавливая связи между ними, и также, формируя сценарии действий; б) создавать сцены и работать с ними. Сцена – это набор экземпляров классов, описывающих некоторую ситуацию в мире. Каждый из экземпляров набора связан с некоторым концептом онтологии отношением вид-род; в) работать с экземплярами классов и экземплярами отношений; г) осуществлять навигацию по семантическим сетям онтологий и сцен (получение связанных сущностей, проверка наличия пути и т.д.). При этом функции по навигации доступны как разработчикам с помощью программного интерфейса приложения (API), так и в методах концептов. д) хранить онтологии и сцены в реляционной базе данных, либо в XML хранилище; е) импорт/экспорт онтологий в XML. В архитектуре инструментальных средств для поддержки работы с онтологиями и сценами можно выделить следующие компоненты: а) хранилища онтологий и онтологических сцен, объединяющие в себе все знания компании; б) средства отображения и навигирования по онтологиям и сценам, позволяющие пользователям просматривать корпоративные знания (поддерживается отображение онтологии в виде словаря понятий, либо семантической сети); в) средства редактирования онтологий и сцен; г) ядро системы, которое обеспечивает всю работу с онтологиями и сценами, при этом с использованием определенного API конструктор онтологий может интегрироваться в другие системы и использоваться в них. Общая структура инструментальных средств для поддержки работы с онтологиями и сценами представлена на Рисунке 2.4. Ключевыми компонентами для работы с онтологиями 153 являются редакторы онтологий и сцен, которые позволяют создавать, редактировать и удалять эти структуры данных с использованием механизмов баз данных. Рисунок 2.4 – Общая структура инструментальных средств для работы с онтологиями, моделями и сценами Сцена – это набор экземпляров классов, описывающих некоторую ситуацию. Каждый из экземпляров набора связан с некоторым концептом онтологии отношением вид-род. Таким образом, понятие онтологии является определенного рода словарем терминов для сцены (начальной, промежуточной или финальной). Сцена интегрирует ключевую оперативную информацию, относящуюся к задаче и методам, которая необходима агентам для принятия решений, являясь при этом «зеркалом» реальности. Последовательность сцен обеспечивает запись шагов процесса решения проблемы, которые могут храниться и использоваться для дальнейшего анализа или как альтернативные варианты. Можно также сравнить финальные сцены, полученные в результате двух параллельных процессов решения задач, и определить, какой процесс достиг лучшего решения. 2.4 Разработка методов и средств редактирования сцен для решения задач управления ресурсами на участке направления Конструктор сцен необходим для представления оперативной информации о ситуации по реализации бизнес-процессов РЖД. Конструктор сцен предназначен для создания и 154 редактирования сцен, основанных на онтологии и представляет собой приложение с графическим интерфейсом. Конструктор сцен позволяет: а) создавать сцены и работать с ними; б) редактировать загруженную в систему сцену; в) загружать, создавать инфраструктуру движения; г) осуществлять навигацию по семантическим сетям сцен; д) хранить сцены в реляционной базе данных, либо в XML хранилище. Редактор сцен представляет собой панель, на которую можно выкладывать геометрические объекты – графическое представление концептов. По двойному клику на концепте открывается соответствующая форма редактирования. Заполняются следующие поля: а) концепт-родитель; б) виды связей; в) поля атрибутов. В левой части таблицы представлены базовые концепты, которые загружаются из онтологии. Базовые концепты нельзя редактировать. Для формирования объекта сцены необходимо выбрать концепт и перенести его в поле редактирования, расположенное в средней части экрана. Далее объекту сцены следует присвоить «имя» и установить связи с другими объектами сцены. После завершения процесса формирования сцены, ее необходимо сохранить в одном из форматов: xml, db, bin-file. Редактор сцен реализован в виде отдельного приложения. Экран редактора сцен показан на Рисунок 2.5. Интерфейс редактора сцен представлен несколькими панелями: а) панель инструментов предоставляет следующие функции: 1) создание новой сцены, загрузка, сохранение; 2) вывод графической информации; 3) управление элементами сцены: вырезать, копировать, вставить, удалить; 4) управление действиями: отмена и возврат к предыдущему состоянию; 5) управлением шрифтом, расположением, цветом, масштабом текста; б) панель элементов – представлены элементы сцены, которые можно поместить в окно редактора; в) панель микрокарты – представлена схема элементов редактора в уменьшенном масштабе; г) панель редактора; 155 д) панель статистики – представлена статистика использования элементов сцены: блок-участков, стрелок, станций. Рисунок 2.5 – Редактор сцен с отображением окна статистики по элементам сцены. На Рисунке 2.6 показана сцена, содержащая фрагмент инфраструктуры РЖД. Элемент сцены «Станция» представлен в виде прямоугольника, в который можно добавлять элементы, находящиеся на станции, например, станционные блок-участки. Элемент сцены «Стрелка» представлен в виде кружка, находящегося между блок-участками, что позволяет отображать в сцене разветвления железнодорожных путей. Стрелки, направленные от одного элемента к другому, показывают как связь между элементами сцены, так и направление движения поезда. Рисунок 2.6 – Редактор сцен с отображением окна редактирования свойств элементов сцены 156 Для редактирования свойств элементов сцены в правой части экрана располагается редактор свойств. После расстановки элементов в нужном порядке, можно выбрать цвет для представления любого элемента сцены, как представлено на Рисунке 2.7. Рисунок 2.7 – Выбор цвета для представления элемента сцены Методы и средства редактирования сцен: а) Импорт сцены извне выполнятся при нажатии кнопки «Импорт». б) Создание новой сцены выполнятся при нажатии кнопки «Создать сцену». в) Экспорт онтологии и сцены с выполнятся при нажатии кнопки «Экспортировать сцену». При этом онтология и сцена преобразуются в один из форматов: xml, db или bine. г) Редактирование ранее созданного объекта осуществляется путем открытия формы редактирования с помощью двойного клика на объекте сцены и последующего внесения изменений в поля значений свойств объекта. д) Комплекс методов взаимодействия с пользователем для создания кнопок, вызова окон редактирования. Таким образом, предлагаемые методы и средства позволяют создавать и редактировать сцены, основанные на онтологиях, что облегчает пользователю-непрограммисту работу со сценой. Разработана архитектура конструктора сцен, которая в качестве основных компонентов включает исполняющую систему, хранилище сцен, средства редактирования, навигации и сохранения сцен в формализованном представлении. 157 Разработаны и представлены основные экраны конструктора сцен для создания и редактирования моделей конкретных ситуаций, возникающих в процессе функционирования основных элементов инфраструктуры РЖД. 2.5 Разработка архитектуры распределённой адаптивной р2р сети системы для согласованного планирования объектов инфраструктуры РЖД. Впервые термин «peer-to-peer» был использован в 1984 году компанией IBM в разработке сетевой архитектуры для построения динамической маршрутизации через компьютерные сети с произвольной топологией – «Advanced Peer to Peer Networking» [12]. P2P сеть состоит из равноправных узлов. Каждый узел может взаимодействовать с каждым. Рисунок 2.8 – P2P сеть В основе технологии лежит принцип децентрализации, то есть все узлы в сети P2P – равноправны. Этот принцип, обеспечил такие преимущества технологии P2P перед клиентсерверным подходом, как отказоустойчивость к потере связи с узлами сети, увеличение скорости копирования за счет копирования сразу из нескольких источников, возможность разделения ресурсов без привязки к конкретным IP-адресам, огромная мощность сети в целом и др. Отказоустойчивость, свойственная алгоритмам Р2Р, является причиной внедрения этой технологии для управления непрерывными или технологически опасными производствами, например, атомными электростанциями. Здесь важно, чтобы узлы Р2Р не располагались в одном и том же помещении и не были подключены к общим каналам питания. Выход из строя части управляющих машин может уменьшить функциональность, но не управляемость системы. Р2Р может предложить и достаточно высокий уровень катастрофоустойчивости, когда нужно гарантировать сохранность определенных данных в случае пожара или каких-то иных 158 природных или рукотворных инцидентов. Для таких приложений географическая удаленность узлов является важным преимуществом. Новую парадигму контроля и управления в новых технологических условиях определяет сетецентрический подход, разрабатываемый на основе мультиагентных технологий и онтологий с применением технологии Р2Р [13-18]. Сетецентрический подход предопределяет организацию управления сложными процессами в распределённой коммуникационной инфраструктуре, реализующей максимальную ситуационную осведомлённость каждого узла (Situational Awareness) и переход к работе каждого узла в режиме самоорганизации на достижение поставленных задач. Подход предполагает создание информационно-управляющей матрицы – системы систем. Успешное решение задач управления всей организацией в рамках сетецентрического подхода складывается из успешного выполнения своей задачи каждым узлом во взаимодействии с другими смежными узлами. В результате взаимодействия узлов друг с другом происходит динамическое перепланирование действий каждого узла под контролем узла (диспетчера), имеющего стратегический обзор ситуации. Эти диспетчерские узлы, в свою очередь, также могут образовывать связанную сеть взаимодействующих узлов. Процесс управления базируется не на традиционном иерархическом принципе, а на достижении результата за счёт согласованного выполнения задач управления с учетом реально складывающейся обстановки. Важным условием является самосинхронизация, под которой понимается возможность обеспечения наибольшей эффективности, как своих действий, так и действий других систем на основе их взаимного согласования. В качестве основного условия для достижения требуемой самосинхронизации рассматривается необходимость наличия единых правил согласования действий и единого языка (протокола взаимодействия). Такой принцип управления обеспечивает повышение оперативности реакции на изменившиеся параметры окружающей среды, возможность реализации адаптивного поведения каждого узла системы и, как следствие, революционный сдвиг в эффективности деятельности. Сетецентрический подход предопределяет организацию управления сложными процессами в распределённой коммуникационной инфраструктуре, реализующей максимальную ситуационную осведомлённость каждого узла (Situational Awareness) и переход к работе каждого узла в режиме самоорганизации на достижение поставленных задач. Подход предполагает создание информационно-управляющей матрицы – системы систем. Успешное решение задач управления всей организацией в рамках сетецентрического подхода складывается из успешного выполнения своей задачи каждым узлом во взаимодействии с другими смежными узлами. В результате взаимодействия узлов друг с другом происходит динамическое перепланирование действий каждого узла под контролем узла (диспетчера), имеющего 159 стратегический обзор ситуации. Эти диспетчерские узлы, в свою очередь, также могут образовывать связанную сеть взаимодействующих узлов. Процесс управления базируется не на традиционном иерархическом принципе, а на достижении результата за счёт согласованного выполнения задач управления с учетом реально складывающейся обстановки. Важным условием является самосинхронизация, под которой понимается возможность обеспечения наибольшей эффективности, как своих действий, так и действий других систем на основе их взаимного согласования. В качестве основного условия для достижения требуемой самосинхронизации рассматривается необходимость наличия единых правил согласования действий и единого языка (протокола взаимодействия). Такой принцип управления обеспечивает повышение оперативности реакции на изменившиеся параметры окружающей среды, возможность реализации адаптивного поведения каждого узла системы и, как следствие, революционный сдвиг в эффективности деятельности. Cетецентрический подход является основой таких известных концепций управления организациями, как С2 (command and control) и, более современной, EC2 (Enterprise command and control). Подход находит применение практически во всех направлениях и отраслях деятельности, как в военной сфере и крупном бизнесе, так и в крупных государственных институтах. Концепция сетецентрических систем может быть реализована на основе создания асинхронных многоуровневых p2p сетей мультиагентных систем (Рисунок 2.9). Каждая система представляет собой вложенную «матрешку» сети составных систем, и каждый уровень такой «матрешки» представляет собой р2р сеть подсистем, а в р2р сети подсистем каждый может работать с каждым. Например, планировщик дороги декомпозируется в планировщики станций, планировщики станций декомпозируется в набор планировщиков локомотивов, вагонов, бригад и т.д. Такая система может работать на одном сервере, а потом быстро перенесена на разные сервера, обеспечивая открытость к росту сложности, высокую производительность, надежность, живучесть, масштабируемость приложений. Таким образом, за счет использования сетецентрического подхода на основе новых информационно-коммуникационных технологий будут созданы условия для ко-эволюции нескольких самоорганизующихся мультиагентных систем (в отличие от более привычных отношений «мастер-ведомый» между системами), обменивающихся сообщениями и данными между собой и с пользователями в реальном времени для согласования или координации планов. 160 Рисунок 2.9 – Сетецентрическая архитектура системы управления производственными подразделениями станции в реальном времени Данный подход является новым и весьма перспективным для создания сложных систем управления такими крупными предприятиями, как РЖД («систем систем»), работающих в реальном времени и функционирующих как единый организм для обеспечения высокой согласованности, продуктивности и эффективности использования ресурсов предприятия. Модули сетецентрического стратегического и оперативного управления ресурсами станции и моделирования согласованной работы станций в сети обеспечат возможность индивидуального согласованного управления ресурсами каждой станции в реальном времени: а) стратегическое интерактивное планирование и оптимизацию использования ресурсов сортировочной станции на значительный период времени (маневровые локомотивы, вагоны, бригады, пути и другие); б) оперативное адаптивное планирование и перепланирование ресурсов для формирования и роспуска составов для обеспечения формирования с целью сокращения времени простоя под накоплением в реальном времени с быстрой, оперативной и гибкой реакцией на непредвиденные события (задержки, поломки ресурсов и т.д.); в) индивидуальный подход для каждого заказа и ресурса через учет различных стратегий и критериев, предпочтений и ограничений каждого участника; 161 г) согласование решений с лицами, принимающими или исполняющими решения, через двустороннее взаимодействие с пользователями (с использованием сотовых телефонов, коммуникаторов и т.д.); д) интерактивное управление планами в автоматическом, полуавтоматическом и ручном режиме в реальном времени; е) моделирование использования ресурсов на основе создаваемых планов по принципу «если-то» на исторических или модельных данных; ж) ручную и полуавтоматическую доработку планов ресурсов без останова и перезапуска системы, путем корректировки расписания «на лету» с использованием как свободных окон, так и подвижками и переброской ранее распределенных заказов (задач) р2р сеть взаимодействующих планировщиков на основе общей шины грузовых станций и отдельной станции, позволяющей планировщикам взаимодействовать «как равный с равным» и «каждый с каждым», обеспечивающие: 1) поддержку взаимодействия и передачи данных в сети планировщиков для согласования принимаемых решений по планированию ресурсов станции; 2) создание, автоматическую корректировку, согласование и утверждение связанных оперативных планов работы исполнителей; 3) проведение одновременного анализа нескольких вариантов планирования с соответствующим распределением ресурсов в целях оптимизации; 4) обеспечение многофакторного анализа работы станции и персонала. 2.6 Описание архитектуры решения через взаимодействие планировщиков разных уровней ЭО представляет собой распределенную систему из взаимосвязанных базовых подсистем (планировщиков станций ОАО «РЖД»), которые объединены в адаптивную р2р-сеть для взаимодействия по принципу «каждый с каждым» и «равный с равным» посредством общей шины данных предприятия (см. рисунок 2.10). За координацию такого взаимодействия и разрешение возникающих конфликтов отвечает стратегический планировщик, также связанный с каждым из планировщиков подразделений при помощи общей шины данных предприятия. 162 Рисунок 2.10 – Сетецентрическая архитектура системы управления производственными подразделениями ОАО «РЖД» в реальном времени Принцип действия такой новой программной структуры описывается следующими шагами: Шаг 1. Построение «грубого» стратегического плана Стратегический планировщик занимается построением расписания перевозок и контролирует содержание полученных в результате планов подразделений. При построении программы перевозочного процесса стратегический планировщик оперирует укрупненными данными – ориентируется только на основные операции перевозочного процесса ОАО «РЖД». Среди укрупненных операций перевозочного процесса можно выделить операции диспетчерского руководства движением поездов, планирования и анализа эксплуатационной работы. На первом этапе строится укрупненное расписание поездов по направлению на большой горизонт времени (например, на месяц) с учетом прогнозируемой нагрузки ресурсов станций. Заметим, что для всех этапов в производственной программе определяется ответственный руководитель. 163 Шаг 2. Декомпозиция стратегического плана на планы подразделений Очевидно, запланированные сроки, полученные на первом шаге, достаточно грубые и требуют дальнейшей детализации и уточнения – это происходит на уровне планировщиков станций, формирующих расписание для участка направления между двумя соседними станциями. Исходные данные для планировщика станции – расписание движения поездов по направлению. Запланированное расписание движения поездов по станции есть часть расписания по направлению. Иначе говоря, расписание по направлению расщепляется на планы участков и отсылается затем вниз соответствующим планировщикам станций. Шаг 3. Оперативное планирование в подразделениях На станциях строятся детализированные оперативные планы для каждого из ресурсов станции: а) машинистов, б) сцепщиков вагонов, в) операторов прибытия, отправления, учета и отчетности, г) вагонов/локомотивов, д) технологических операций. Например, рассмотрим оперативное планирование грузовых поездов. Предварительная информация о составе поезда поступает на станцию в виде натурного листа. Оператор размечает натурный лист, выделяя отцепы (группы вагонов, следующие на один путь сортировочного парка) и проставляя для каждого отцепа условную разметку по назначениям плана формирования поездов. План формирования поездов задают для сортировочной станции в виде перечня назначений формируемых поездов и ставят в соответствие каждому из них станцию назначения (выгрузки) вагонов. Далее оператор подсчитывает массу и количество вагонов для каждого отцепа и подготавливает сортировочный листок, где указываются данные об отцепах и условия роспуска. Сортировочный листок соответствует определенному сортировочному пути. По мере накопления вагонов на каждом из путей подсчитывают вес и длину вагонов нарастающим итогом и составляют натурный лист на формируемый станцией поезд. Далее сцепщики на основании сортировочных листков сцепляют вагоны, для сформированного поезда предоставляют локомотив и машиниста. Натурный лист передают машинисту поезда и, в виде телеграммы-натурного листа, – на соседнюю станцию по сетям информационной связи. 164 Шаг 4. Горизонтальные взаимодействия для согласования планов между ресурсами подразделения Оперативные планы ресурсов станции должны быть согласованы. Например, к моменту окончания формирования поезда должен иметься в наличии локомотив и машинист, а на блок-участке станции, по которому должен проследовать поезд, не должны находиться другие составы и не должны быть запланированы технологические окна. Шаг 5. Корректировка плана по каждому ресурсу подразделения Услуги, которые каждый ресурс подразделения предоставляет другим ресурсам, также планируются. Например, в план станционного рабочего могут быть включены работы по ремонту путей на блок-участках с учетом занятости блок-участков поездами и занятости станционного рабочего другими операциями. Например, если в результате погодных условий произошла поломка путей в одном из станционных блок-участков, на станции необходимо запланировать прием прибывающих составов на другие блок-участки. Шаг 6. Корректировка плана с учетом ответов других подразделений Построенный на шаге 3 план «своих» ресурсов корректируется с учетом времени, которое необходимо другим станциям на выполнение операций. Происходит это с помощью обработки специального вида событий. Например, если отправление поезда со станции по какой-то причине задерживается, или поезд задерживается на каком-либо блок-участке на перегоне между станциями, то в очереди событий станции прибытия возникнет событие «Задержка поезда». Возникновение этого события приводит к перепланированию расписания ресурсов на станции прибытия, например, задержка на станции пригородных поездов с целью освобождения блок-участков для транзитных поездов. Шаг 7. Принятие согласованного плана на уровне подразделений Если по какой-то причине блок-участок на пути движения некоторого пассажирского поезда оказался занят (например, вследствие аварии на другом поезде) и при этом нарушается расписание движения поезда, движение данного поезда может быть перепланировано на соседние блок-участки или с выездом на встречную полосу. Но при этом неизбежно возникнут конфликты с другими поездами и рассогласование между фактическим планом, сформированным стратегическим планировщиком, и детализированными планами поездов и других ресурсов, сформированными на станциях. В этом случае ресурс связывается со стратегическим планировщиком, забрасывая в него событие «задержка выполнения» по своей технологической операции. 165 Шаг 8. Реакция на события, вызывающая пересогласование планов подразделений События «задержка выполнения» обрабатываются за счет изменения расписания подразделений. В свою очередь, в подразделениях, например, на станциях, можно изменить график работы рабочих, либо ввести новых рабочих для выполнения операции. Например, если устранение аварии на блок-участке не может быть выполнено силами дежурной бригады, вызвать дополнительную бригаду. Подобная задержка приводит к сдвигу расписания блок-участка и поездов всего направления. Это может потребовать стратегического перепланирования по части или даже всему направлению. Рассмотрим взаимодействие между несколькими планировщиками по географическому принципу. Пусть в системе имеются два поезда: ВСП «Сапсан» и скорый пассажирский поезд №1000. Введем следующие упрощающие предположения: а) расстояния между городами на направлении Москва – Санкт-Петербург приняты из удобства расчетов и отличаются от истинных (без потери общности рассуждений); б) поезда делают две остановки: Тверь и Бологое; в) ВСП «Сапсан» движется со средней скоростью 200 км/ч; г) скорый поезд №1000 движется со средней скоростью 100 км/ч; д) длина блок-участка на перегоне – 99-100 км; е) длина станционного блок-участка – 1 км; ж) количество блок-участков на станциях – 2-3; и) на 300-м и 600-м километрах находятся стрелки. Разобьем направление Москва – Санкт-Петербург на две части: а) Москва – Бологое (Планировщик 1); б) Бологое – Санкт-Петербург (Планировщик 2). Потребности в элементах пути и временные отношения для планировщиков приведены в Таблица и Таблица . Планировщики взаимодействуют между собой через объекты потребности в станционном блок-участке Б.1, для которого они разделяют планирование: Планировщик 1 планирует прибытие на станцию Бологое, а Планировщик 2 – отправление со станции. Если ско- 166 рый поезд №1000 не отклоняется от графика движения, конфликт на станционном блокучастке Б.1 не возникает. Таблица 1 – Потребности в элементах пути для Планировщика 1 без отклонения от графика движения скорого поезда №1000 Потребность в элементах пути Блок-участок М.1 Блок-участок 1.1 Блок-участок 2.1 Блок-участок Т.1 Станция Тверь: Т.1 - останов Блок-участок Т.1 Блок-участок 3.1 Блок-участок Б.1 Станция Бологое: Б.1 - останов Временные отношения Скорый поезд №1000 План Факт 13:00 – 13:01 13:00 – 13:01 13:01 – 14:00 13:01 – 14:00 14:00 – 14:59 14:00 – 14:59 14:59 – 15:00 14:59 – 15:00 15:00 – 15:05 15:00 – 15:05 15:05 – 15:06 15:06 – 15:59 15:59 – 16:00 16:00 – 16:05 15:05 – 15:06 15:06 – 15:59 15:59 – 16:00 16:00 – 16:05 ВСП «Сапсан» 16:30 – 16:31 16:31 – 17:00 17:00 – 17:29 17:29 – 17:30 17:30 – 17:32 17:32 – 17:33 17:33 – 17:59 17:59 – 18:00 18:00 – 18:02 Таблица 2 – Потребности в элементах пути для Планировщика 2 без отклонения от графика движения скорого поезда №1000 Потребность в элементах пути Блок-участок Б.1 Cтрелка 1 Блок-участок 4.1 Блок-участок 5.1 Блок-участок 6.1 Cтрелка 2 Блок-участок СпБ.1 Временные отношения Скорый поезд №1000 План Факт 16:05 – 16:06 16:05 – 16:06 16:06 – 16:07 16:06 – 16:07 16:07 – 17:00 16:07 – 17:00 17:00 – 18:00 17:00 – 18:00 18:00 – 18:58 18:00 – 18:58 18:58 – 18:59 18:58 – 18:59 18:59 – 19:00 18:59 – 19:00 ВСП «Сапсан» 18:02 – 18:03 18:03 – 18:04 18:04 – 18:30 18:30 – 19:00 19:00 – 19:28 19:28 – 19:29 19:29 – 19:30 Пусть в систему приходит событие, что отправление поезда №1000 из Москвы по техническим причинам задерживается на 1 час. Потребности в элементах пути и временные отношения для Планировщика 1 приведены в Таблица с учетом задержки отправления поезда №1000. Таблица 3 – Потребности в элементах пути для Планировщика 1 с отклонением от графика движения скорого поезда №1000 на 1 час Потребность в элементах пути Блок-участок М.1 Блок-участок 1.1 Блок-участок 2.1 Временные отношения Скорый поезд №1000 План Факт 13:00 – 13:01 14:00 – 14:01 13:01 – 14:00 14:01 – 15:00 14:00 – 14:59 15:00 – 15:59 167 ВСП «Сапсан» 16:30 – 16:31 16:31 – 17:00 17:00 – 17:29 Потребность в элементах пути Блок-участок Т.1 Станция Тверь: Т.1 - останов Блок-участок Т.1 Блок-участок 3.1 Блок-участок Б.1 Станция Бологое: Б.1 - останов Временные отношения Скорый поезд №1000 План Факт 14:59 – 15:00 15:59 – 16:00 15:00 – 15:05 16:00 – 16:05 15:05 – 15:06 15:06 – 15:59 15:59 – 16:00 16:00 – 16:05 16:05 – 16:06 16:06 – 16:59 16:59 – 17:00 17:00 – 17:05 ВСП «Сапсан» 17:29 – 17:30 17:30 – 17:32 17:32 – 17:33 17:33 – 17:59 17:59 – 18:00 18:00 – 18:02 Согласно расписанию, первоначально составленному Планировщиком 2, в 16:05 поезд №1000 должен находиться на станционном блок-участке Б.1, а он находится на станционном блок-участке Т.1., т.е. имеется расхождение между планом и фактом. Планировщик 2 пересчитывает расписание поезда №1000 на своем участке пути (Таблица ). Таблица 4 – Потребности в элементах пути для Планировщика 2 с отклонением от графика движения скорого поезда №1000 на 1 час: конфликт на блок-участке 5.1 Потребность в элементах пути Блок-участок Б.1 Cтрелка 1 Блок-участок 4.1 Блок-участок 5.1 Блок-участок 6.1 Cтрелка 2 Блок-участок СпБ.1 Временные отношения Скорый поезд №1000 План Факт 16:05 – 16:06 17:05 – 17:06 16:06 – 16:07 17:06 – 17:07 16:07 – 17:00 17:07 – 18:00 17:00 – 18:00 18:00 – 19:00 18:00 – 18:58 19:00 – 19:58 18:58 – 18:59 19:58 – 19:59 18:59 – 19:00 19:59 – 20:00 ВСП «Сапсан» 18:02 – 18:03 18:03 – 18:04 18:04 – 18:30 18:30 – 19:00 19:00 – 19:28 19:28 – 19:29 19:29 – 19:30 Т.к. имеется конфликт потребностей поезда №1000 и ВСП «Сапсан» в блок-участке 5.1, Планировщик 2 перепланирует расписание поезда №1000 так, чтобы он начал движение со станции Бологое на 1 час позже и пропустил ВСП «Сапсан» (Таблица ). Таблица 5 – Потребности в элементах пути для Планировщика 2 с отклонением от графика движения скорого поезда №1000: задержка начала движения поезда №1000 со станции Бологое Потребность в элементах пути Блок-участок Б.1 Cтрелка 1 Блок-участок 4.1 Блок-участок 5.1 Блок-участок 6.1 Cтрелка 2 Блок-участок СпБ.1 Временные отношения Скорый поезд №1000 План Факт 16:05 – 16:06 18:05 – 18:06 16:06 – 16:07 18:06 – 18:07 16:07 – 17:00 18:07 – 19:00 17:00 – 18:00 19:00 – 20:00 18:00 – 18:58 20:00 – 20:58 18:58 – 18:59 20:58 – 20:59 18:59 – 19:00 20:59 – 21:00 168 ВСП «Сапсан» 18:02 – 18:03 18:03 – 18:04 18:04 – 18:30 18:30 – 19:00 19:00 – 19:28 19:28 – 19:29 19:29 – 19:30 Планировщик 1 должен перепланировать останов поезда №1000 для пропуска ВСП «Сапсан» так, чтобы интервал останова на станции Бологое увеличился на 1 час (Таблица ). Таблица 6 – Потребности в элементах пути для Планировщика 1 с отклонением от графика движения скорого поезда №1000: увеличение останова на станции Бологое на 1 час Потребность в элементах пути Блок-участок Б.1 Станция Бологое: Б.1 - останов Временные отношения Скорый поезд №1000 План Факт 15:59 – 16:00 16:59 – 17:00 16:00 – 16:05 17:00 – 18:05 ВСП «Сапсан» 17:59 – 18:00 18:00 – 18:02 При этом возникает конфликт между потребностями поезда №1000 и ВСП «Сапсан» в станционном блок-участке Б.1. Следовательно, Планировщик 1 должен запланировать перевод поезда №1000 со станционного блок-участка Б.1 на станционный блок-участок Б.2 и останов на станционном блок-участке Б.2 (Таблица ). Планировщик 2 должен запланировать перевод поезда №1000 со станционного блок-участка Б.2 на станционный блок-участок Б.1 (Таблица ). Таблица 7 – Планировщик 1: разрешение конфликта на станционном блок-участке Б.1 Временные отношения Потребность в элементах пути Блок-участок Б.1 Станция Бологое: Б.1 - останов Стрелка Б.1 – Б.2 Станция Бологое: Б.2 - останов Скорый поезд №1000 ВСП «Сапсан» План Факт 15:59 – 16:00 – 16:59 – 17:00 – 17:59 – 18:00 18:00 – 18:02 – 16:00 – 16:05 17:00 – 17:01 17:01 – 18:04 – – Таблица 8 – Планировщик 2: разрешение конфликта на станционном блок-участке Б.1 Временные отношения Потребность в элементах пути Стрелка Б.2 – Б.1 Блок-участок Б.1 Cтрелка 1 Блок-участок 4.1 Скорый поезд №1000 План Факт – – 16:06 – 16:07 16:07 – 17:00 18:04 – 18:05 18:05 – 18:06 18:06 – 18:07 18:07 – 19:00 169 ВСП «Сапсан» – 18:02 – 18:03 18:03 – 18:04 18:04 – 18:30 Шаг 9. Финальное согласование - уточнение исходного стратегического плана после согласований на уровне подразделений Полученные с уровня оперативного планирования расписания ресурсов каждой станции по выполнению отдельных технологических операций, срокам и требующейся загрузке ресурсов и работников определенных специальностей вновь попадают на уровень стратегического планирования. При этом стратегический планировщик пересчитывает текущее распределение ресурсов, выдавая план-прогноз о том, как и на сколько варьируются сроки выполнения тех или иных запланированных операций перевозочного процесса. Это позволит вовремя принять соответствующие меры на высшем уровне во избежание невыполнения контрактных обязательств. Таким образом, стратегический план, построенный на основе основных укрупненных технологий, по мере поступления поездов на станции, уточняется данными по загрузке ресурсов и срокам окончания выполнения операций в автоматическом режиме. Это позволяет наблюдать прогнозируемую системой МАС «Планирование» картину распределения ресурсов на всем горизонте планирования. Далее данный процесс не останавливается – а продолжается, активируясь событиям с любой из сторон, как сверху, так и снизу. Таким образом, МАС «Планирование» поддерживает три типа взаимодействий: а) горизонтальное взаимодействие – осуществляется между планировщиками станций. К этому типу взаимодействия относится переговоры между соседними станциями о прохождении поездов по блок-участкам и выполнении работ на блокучастках. б) вертикальное взаимодействие – осуществляется между планировщиком станции и стратегическим планировщиком. К этому типу взаимодействия относятся действия по постановке задач станциям на основе стратегического плана и уточнению и согласованию расписания движения с учетом «новых подробностей» о технологических операциях перевозочного процесса и ресурсах от станций. в) взаимодействие внутри подразделений РЖД по формированию расписания движения в соответствии с потребностями в перевозках с учетом данных горизонтального и вертикального взаимодействия. С помощью такой архитектуры системы каждый планировщик сможет работать автономно в своем подразделении (станции), реагируя на возникающие события, а при необходимости сможет взаимодействовать с планировщиками других подразделений (станций) через общую шину данных предприятия. В настоящее время предполагается, что общая система управления ресурсами предприятия будет строиться как двухуровневая адаптивная р2р 170 сеть планировщиков подразделений. Каждый уровень, в свою очередь, предполагает развертывание в виде р2р подсети планировщиков. Такое «матрешечное» развертывание позволит легко перейти от планирования в рамках «большого» производства (например, станции) к планированию в рамках «меньшего» производства (бригад рабочих, локомотивов, машинистов и т.п.) в случае, когда плановая нагрузка на это «меньшее» производство существенно возрастает. При этом каждый планировщик может размещаться физически на своем сервере и работать в режиме согласования решений вместе с другими планировщиками p2p сети параллельно, решая как распределять задачи у подвластного ему подразделения. Данный подход обеспечивает такие важные преимущества разрабатываемой системы как повышение качества и эффективности решений по планированию производственных ресурсов, открытость к поэтапному подключению планов новых подразделений, высокая оперативность, гибкость и производительность, надежность и живучесть, масштабируемость и интегрированность системы управления ресурсами в масштабах ОАО «РЖД», сокращает расходы на владение и сопровождение такой системой, а также уменьшает риски ее внедрения. В дальнейшем будем рассматривать перечисленные шаги 1 - 7 как основополагающие этапы планирования, приводя к некоторым из них необходимые дополнения и предложения по расширению функционала. 2.7 Разработка компонентов адаптивной р2р платформы для автоматизации планирования ресурсов РЖД В ходе работы над проектом были разработаны компоненты адаптивной p2p платформы, а именно стратегический планировщик всего направления, планировщик движения ресурсов на оном участке. Результаты представлены в виде экспериментального образца. Разработан сетецентрический мультиагентный подход к процессам управления ЖД ресурсами на основе создания адаптивной р2р сети мультиагентных систем управления отдельными подразделениями станции: а) разработаны формализованные модели индивидуального планирования ключевых ресурсов станции (локомотив, вагон, машинист, путь и др.), а также логика мультиагентной маршрутизации вагонов; 171 Рисунок 2.11 – Компоненты мультиагентной платформы для управления ресурсами в реальном времени б) разработаны агенты задач, операций и ресурсов, позволяющие реализовать полный цикл реакции на события, планирования и исполнения планов в реальном времени; в) разработаны структуры данных и алгоритмы принятия решений, а также протоколы проведения переговоров агентами в ходе динамического планирования ресурсов станции, включая выявление и разрешение конфликтов путем переговоров, согласованную подвижку и перераспределение операций ресурсов во времени; г) разработаны модели взаимодействий агентов, позволяющих осуществлять взаимные уступки во имя общей цели системы; д) разработаны принципы построения сетецентрических интеллектуальных систем для согласованного планирования ресурсов станции, способных к коллективному взаимодействию в реальном времени, на основе баз знаний и мультиагентных технологий; е) предложена «матрешечная» сетецентрическая архитектура системы управления подразделениями станции в реальном времени. 172 2.8 Разработка средств для обеспечения возможности двустороннего непрерывного человеко-машинного диалога системы с лицами, принимающими решения В ходе работы над проектом были разработаны средства обеспечения возможности двустороннего непрерывного человеко-машинного диалога системы с лицами, принимающими решения (диспетчерами) (рисунок 2.12). Поле ввода данных Панель отображения данных Панель отображения данных Рисунок 2.12 – Окно графического интерфейса системы Данный интерфейс предназначен для отображения текущего выполнения расписания движения поездов и окон для выполнения работ. Основную часть экрана занимает окно отображения запланированного и фактического расписания, которое разделено на 3 секции: а) потребность – представляет задачу движения поезда на конечную станцию маршрута или задачу выполнения работ в окне; б) план – представляет запланированный маршрут движения (т.е. заданный маршрут движения) поезда по элементам пути с указанием запланированного времени старта и финиша на каждом элементе пути, или запланированное время окна; в) факт – представляет фактическое местоположение поезда на маршруте или фактическое время окна. Поезда различных типов отображаются с помощью различных цветов: а) ВСП «Сапсан» – синий, б) пассажирский – зеленый, в) пригородный – фиолетовый. 173 Окно отображается оранжевым цветом. Элемент пути, на котором фактически находится поезд в текущий момент времени, выделяется розовым цветом. Элемент пути, на котором наблюдается отклонение плана от факта, выделяется красным цветом. В нижней части экрана расположено окно «Фильтры», позволяющее выбрать режим отображения: а) все – отображается расписание по всем поездам, б) поезд – отображается расписание выбранного поезда/поездов, выбранных с помощью выпадающего меню, в) блок-участок – отображается расписание движения поездов по блок-участкам, выбранным с помощью выпадающего меню, г) время – отображается расписание движения поездов на заданном интервале времени. В нижней части экрана расположено также окно KPI’s, в котором отображаются показатели эффективности планирования. Графический интерфейс представлен панелями с разделителем и кнопками управления. В левой части экрана находится панель для ввода данных в систему. В правой части экрана расположена панель для отображения данных, полученных в результате работы системы. Для запуска системы моделирования необходимо поместить скрипт инициализации в панель ввода данных, нажать кнопку «Запустить» для запуска модуля планирования и кнопку «Внедрить» для ввода информации в систему. Далее нужно перейти на вкладку «Схема инфраструктуры» и нажать кнопку «Обновить график». При этом выполнится загрузка сцены и в панели отображения данных появится схема инфраструктуры пути (Рисунок 2.13). Для начала планирования движения поездов необходимо задать скрипт, который создает поезда, и выполнить команды «Внедрить» и «Обновить графики». В панели отображения результатов системы открывается диаграмма Гантта, на которой отображается график движения поездов (Рисунок 2.14). По оси абсцисс откладывается время, а по оси ординат – блок-участки, пройденные различными поездами. На Рисунке 2.15 представлено расписание движения трех поездов: пассажирского поезда (зеленый цвет), грузового поезда (красный цвет), ВСП «Сапсан» (синий цвет). Более подробную информацию о прохождении поездами различных участков пути можно получить, если перейти во вкладку «Линейный график». 174 Структура пути движения Структура пути движения Рисунок 2.13 – Схема инфраструктуры участка пути Рисунок 2.14 – График движения поездов, представленный в виде диаграммы Гантта 175 Выбранный поезд Выбранный поезд Рисунок 2.15 – Линейный график На этом графике можно видеть количество километров, пройдённых поездом к определенному моменту времени. На оси абсцисс представлено время в часах, на оси ординат – расстояние в километрах. В нижней части экрана указаны наименования поездов и цветовые обозначения для графиков различных поездов. При выборе конкретного поезда соответствующий ему график движения маркируется. При переходе во вкладку «Расписание поездов» можно видеть расписание движения выбранного поезда, включающее список станций, в котором представлены даты прибытия и отправления данного поезда и отклонения его движения от запланированного графика (Рисунок 2.16 – 2.17). 176 Рисунок 2.16 – Расписание движения поездов Отклонение Отклонение Рисунок 2.17 – Отклонения в расписании движения поездов от запланированных значений В сцене можно отобразить ситуацию блокировки отдельных блок-участков. На Рисунке 2.18 заблокированный блок-участок показан красным цветом, система планирует для ВСП «Сапсан» переход по стрелке на параллельный блок-участок и объезд заблокированного блок-участка. 177 Сценарий моделирования Пассажирский поезд «Сапсан» бло- участок Пассажирский поезд кировки Заблокированн «Сапсан» Заблокированн Сценарий моделирования участок бло- кировки Рисунок 2.18 – Моделирование ситуации блокировки блок-участка Предложения по дальнейшей разработке интерфейса пользователя. Разработанная система может показывать авторизованному пользователю поступившие в последнее время события и текущее расписание работ, а также фактическое состояние работ, как на каждом конкретном блок-участке станции, так и по всему направлению. Это может демонстрироваться на большом экране в диспетчерском центре РЖД с любой степенью детализации, до уровня каждого отдельного подразделения станции или даже отдельного ресурса (поезда, электровоза, машиниста, мастера, рабочего и т.д.), причем с показом перепланирования и прогресса исполнения плана в реальном времени. При возникновении нового заказа или другого события пользователь вводит соответствующую информацию в систему, что приводит к динамической перестройке расписания с подсветкой измененных частей и, возможно, согласованию получаемых решений с другими подразделениями. При этом система по имеющимся технологическим процессам, регламентам и пооперационным нормам работы рассчитает требуемое количество ресурсов, построит план для каждой отдельной работы (заказа) и оценит ее стоимость, учитывая наличие требуемых ресурсов и определяя сроки проведения работ, которые по желанию могут быть скорректированы пользователем. Если ресурсов окажется недостаточно, планировщик данного подразделения свяжется с динамическими планировщиками других подразделений с целью поиска соответствующих ресурсов и построения нового плана, а также согласования цен и сроков с учетом расстояния и скорости выполнения заказа. 178 Получаемые решения, при необходимости, будут согласованы и санкционированы ответственными пользователями. 2.9 Разработка методов интеграционной платформы, обеспечивающей взаимодействие частей системы Под интеграционной платформой понимается программно-аппаратная инфраструктура, позволяющая поддержать сетецентрический подход и организовать обмен данными между распределёнными приложениями и информационными системами для поддержки, мониторинга и управления композитными бизнес-процессами предприятия. Подход к построению платформы определяется поставленными перед ней задачами сетецентрического управления ЖД перевозками. Дополнительно необходимо создавать и исполнять приложения самого широкого назначения, в том числе для автоматизации работы диспетчерских служб, задействованных в различных технологических и производственных процессах, комплексных систем безопасности, мониторинга и паспортизации объектов. В рамках единой интеграционной платформы должна быть обеспечена интеграция существующих промышленных систем и баз данных станции, комплексной автоматизации производственных бизнес-процессов и обеспечения доступа к данным для специализированных мультиагентных систем управления ресурсами подразделений станции в реальном времени. Исходя из этих задач, платформа должна быть максимально гибкой. В ситуации постоянного развития предприятия, модификации его бизнес функций, невозможно раз и навсегда сформулировать полный перечень функциональных требований к системе. В этом случае систему уровня предприятия необходимо проектировать исходя из модели данных, а не от функциональной модели. Внутренняя логика и связи прикладных данных гораздо более устойчивы во времени, чем функции. В такой модели реализация бизнес функций сводится к комбинации нескольких элементарных операций над сущностями модели и в большинстве случаев к изменению значений атрибутов объектов. Интеграционная платформа - программно-аппаратная инфраструктура, позволяющая поддержать сетецентрический подход и организовать обмен данными между распределёнными приложениями и информационными системами для поддержки, мониторинга и управления композитными бизнес-процессами предприятия. Подход к построению платформы определяется поставленными перед ней задачами: а) сетецентрическое управление ЖД перевозками;. б) создание и исполнение приложений самого широкого назначения, в том числе для автоматизации работы диспетчерских служб, задействованных в различных техно179 логических и производственных процессах, комплексных систем безопасности, мониторинга и паспортизации объектов; в) интеграция существующих промышленных систем и баз данных станции, комплексной автоматизации производственных бизнес-процессов и обеспечения доступа к данным для специализированных мультиагентных систем управления ресурсами подразделений станции в реальном времени; г) гибкость при расширении функциональности. Интеграционная платформа для комплексной автоматизации станции должна строиться на основе универсальных принципов, в основе которых лежит принцип построения систем на основе «Data-driven model» (систем, управляемых данными). Организация всех данных системы осуществляется в виде объектов с изменяемым набором и количеством свойств. Основные характеристики: а) адаптивность к многообразию подключаемого внешнего оборудования и подсистем; б) мониторинг и управление оборудованием в реальном масштабе времени; в) традиционные средства планирования, исполнения и контроля технологических процессов; г) распределённая, многоуровневая архитектура; д) возможность дополнения прикладной логики, расчётных задач в спектре задач MES-систем (Manufacturing Execution System); е) возможность многократного тиражирования системы на объектах заказчика с интеграцией в единый комплекс; ж) широкие возможности визуализации (ГИС, мнемосхемы и др.). В ходе работы по проекту были разработаны и реализованы методы интеграционной платформы, обеспечивающей взаимодействие частей системы и отработку базовых сценариев планирования. Представлены в виде экспериментального образца. 2.10 Разработка программы и методики экспериментальных исследований Представлена в документе «Программа и методика экспериментальных исследований». 180 2.11 Онтологическая настройка ЭО на предметную область для проведения исследований и экспериментов Рассмотрим пример использования классов онтологии в реальном примере применения. Для этого на рисунке 2.19 приведено схематическое онтологическое представление станции Подсолнечная: Рисунок 2.19 – Компоненты мультиагентной платформы для управления ресурсами в реальном времени Рассмотрим подробнее использование классов онтологии. Мы рассматриваем пример станции со встречным направлением, на примере станции Подсолнечная из 5-го круга следования. Из таблице классов берем концепт (класс) – станция и ставим его в редактируемое поле. Далее – берем блок участок и ставим его в нужное место - выбираем его свойства и проставляем – расстояние, место нахождение, в станции он или нет, свободен или занят и так со всеми последующими участками – участок по номером 10583, далее идет стрелка – устанавливаем его в нужное место, затем проставляем связи элементов, и выставляем направление движения для каждого элемента. Далее проставляем блок участки и стрелки, проставляем связи и редактируем поля нужным нам образом. Тоже самое и с другим направлением движения. Ставим блок участок, заполняем поля - место положения, название, путь и т.д., далее ставим стрелки и другие блок участки – формируем связи между ними. И так онтология станции готова – выставлены блок-участки, стрелки и проведены связи, определено направление движение. Далее проставляем поезда – проводим связи – местоположения. Заполняем необходимые поля. Проставляем необходимое количество поездов. Теперь мы видим картину – хоть и упрощённо для этого примера, но картину целостную онтологии станции Подсолнечная. Так же можно создать онтологию всего 5-го круга. 181 2.11.1Принципы создания онтологии Основными принципами создания онтологии являются: а) запрещено редактировать базовые концепты; б) концепты возможно копировать, удалять, создавать новые на базе старых; в) при создании нового концепта нужно указывать родительский концепт; г) заведение связей у нового концепта. 2.11.2Принцип редактирования онтологий Принцип формирования нового концепта на примера создания нового концепта онтологии – «Светофор». Для решение задачи регулировки движения и скорости прохождения на блок участке пути требуется создать новый концепт – «светофор». Используем концепт «Блок участок» как базовый так как у него реализована скорость прохождения по отрезку пути. Концепт «Светофор» выступает как наследник концепта «Блок участок». Концепт «Светофор» наследует все поля и методы от концепта «Блок участок». Добавляем свойство означающее перемену света поле bool trafficLight – где false = запрещающий сигнал светофора, true – разрешающий сигнал светофора. На этапе планирование через этот участок будет учитываться значение поля - bool trafficLight объекта концепта «Светофор». В случае запрещающего сигнала – скорость прохождения по данному блок участку будет равна нулю, при разрешающим сигнале – восстановлена на прежнее значение. Для данного концепта формируются связи, если требуется. Теперь концепт «Светофор» можно сохранить и использовать его в дальнейшем. Новый концепт сохраняется и храниться с другими концептами, которые в последствии можно использовать для формирования объектов сцены. Принципы создания сцены. а) Выбор существующих концептов и создание объектов. б) Создание нескольких объектов и построение связей между объектами. в) Заполнение полей объектов сцены. 182 2.11.3Принцип редактирования сцен Принцип формирования нового объекта сцены: Главным принципом построение новых объектов сцены является построение объектов на базе концептов имеющихся в системе. Для этого нужно выбрать концепт, который в свою очередь создаст объект нужного типа, далее поля объекта заполняются. Принцип редактирования существующей сцены: В системе не всегда нужно создавать сцену с нуля. Можно загрузить из системы рабочую сцену с заполненными данными. После загрузки в панели с загруженными объектами сцены появятся все объекты. На Центральной панели отобразиться сцена со связями с другими объектами. При двойном клике на объект выводиться таблица с полями объекта, такими как: а) базовый класс б) поля – поля у все объектов сцены могут разниться числом и значением. Далее есть возможность изменить значения полей, переназначить связи для этого объекта создав новый объект или связать с другими. 2.11.4Общий пример редактирования онтологии и сцены с конкретной ситуацией на участке направления. Создание новых концептов: Принцип формирования нового концепта онтологии на базе концепта «Ресурс»: Предположим появилась новая станция с новыми свойствами который нужно описать в онтологии. Старая станция не подходит для решения данной проблемы. Создаем концепт «Новая станция» базовым концептом для нее является концепт «Ресурс» - концепт «Новая станция» принимает все поля и методы концепта ресурс. В редакторе добавляется ряд свойств нужных для работы данной станции, так же добалуются виды связей для этой станции. После редактирования и сохранения появляется новый концепт «Новая станция» - которая будет обладать рядом уникальных свойств. Этот же концепт как объект можно использовать при создании и редактировании уже существующей сцены. Новый концепт – электропоезд Создаем новый концепт на базе «движущегося средства» – « электропоезд» добавляем ему свойства поля – электропитания, и создаем концепт на «блок участок» - добавляем ему свойство отражающие электропитание на линии. «Электропоезда» свойством электропитание будет связан с «Блок участок» по полю электропитания, так как учитывается просе183 дание напряжении на линии, при планировании перевозок, будет зависеть скорость поезда идущего по блок участку. Новый концепт уклона блок участка Допустим существует местность с углом наклона полотна не пригодного на некоторых видов поездов. Поезда просто не могут преодолеть данный участок из за технических особенностей конструкции и мощности двигательной установки. Для моделировании этой ситуации создаётся концепты на основе базовых, добавляются свойства отражающие ситуацию, в данном случае это – мощность силовой установки у поезда и угол наклона у блок участка. В ходе создание расписания выявляются поезда с силовой установкой которые могут пройти данной участок или перечень таких участков без потерь скорости и не отстать от расписания. В итоге получаем прибыль от доставленных вовремя грузов. Новый концепт пассажиропоток: Существуют ситуации когда нужно учитывать количество пассажиров, дальность хода поезда, загруженность станции пассажирами. Данная ситуация возможно решить следующим путем, а именно заведением нового концепта «поезда» и «станции». Добавлением полей у поезда – максимальное число перевозимых пассажиров, количество вагонов, типы вагонов для пассажиров разного класса. Для «станции» вводим поле –«число пассажиров». Данное решение отразит ситуацию перевозки пассажиров и сформирует связи между станциями и поездами, что позволит правильно спланировать перевозки. Редактирование концептов: Пример редактирования концепта. Главным принципом редактирования являются запрет редактирования базовых концептов системы. Можно вносить изменения только в их потомков.При редактирование потомков можно выбрать советующий концепт из списка доступных концептов. Перетащить его панель редактирования, открыть двойным кликом мыши и добавить или удалить свойства для объекта. Изменить наследование от базового концепта – тем самым изменив его свойства и методы. Добавить или удалить вид связи. При изменении ситуации в грузоперевозках есть возможность изменить параметры существующего концепта или создать новый с другими свойствами. Вывод. Редактирование онтологий приводит к быстрому реагированию на изменение внешних факторов. Рассмотренные примеры показывают легкость модификации концептов, что позволяет удобно и быстро менять отношение и добавлять свойства концептам и перестраивать сцену в соответствии с изменившейся ситуацией. Методы и средства редактирования сцен: 184 а) метод создания новой сцены – создает новую сцену и подгружает известные концепты, реализуется по средствам кнопки – «Создать сцену»; б) метод импорта данных «из вне» – загружает ранее созданную сцену; выполняется путем нажатия кнопки «Импорт…»; в) метод экспорта онтологии – осуществляет переведение онтологии в формат xml, или DB, или bin-file и сохраняет; выполнятся путем нажатия кнопки «Экспортировать онтологию»; г) метод редактирования ранее созданного объекта – осуществляется путем открытия формы редактирования; выполняется путем двойного нажатия на объект сцены и внесения изменений в поля редактора. 2.12 Проведение экспериментальных исследований. Оформление актов и протоколов экспериментальных исследований Протокол экспериментальных исследований представлен в приложении к документу «Программа и методика экспериментальных исследований». 185 3 ЭТАП 3. ОБОБЩЕНИЕ И ОЦЕНКА РЕЗУЛЬТАТОВ ИССЛЕДОВАНИЙ 3.1 Программная реализация разработанных методов в виде ЭО сетецентрической системы планирования, обеспечивающей согласованную работу двух модулей 3.1.1 Описание сетецентрического подхода при планировании ЭО представляет собой распределенную систему из взаимосвязанных базовых подсистем, которые объединены в адаптивную р2р-сеть для взаимодействия по принципу «каждый с каждым» и «равный с равным» посредством общей шины данных предприятия (см. рисунок 3.1). За координацию такого взаимодействия и разрешение возникающих конфликтов отвечает стратегический планировщик дорожного уровня, также связанный с каждым из планировщиков подразделений при помощи общей шины данных предприятия. Рисунок 3.1 – Сетецентрическая архитектура системы управления производственными подразделениями ОАО «РЖД» в реальном времени 186 3.1.2 Принцип работы Шаг 1. Построение «грубого» стратегического плана Стратегический планировщик занимается построением расписания движения и контролирует содержание полученных в результате планов. При построении расписания стратегический планировщик оперирует укрупненными данными, т.е. ориентируется только на основные элементы инфраструктуры и операции перевозочного процесса ОАО «РЖД». На первом этапе строится укрупненное расписание поездов по направлению на большой горизонт времени (на неделю) без учета прогнозируемой нагрузки на ресурсы станций. Шаг 2. Декомпозиция стратегического плана на планы станций Расписание, сформированное на шаге 1, является достаточно грубым и требует дальнейшей детализации и уточнения на уровне станционных планировщиков. Для их работы общий стратегический план по направлению разбивается на планы по отдельным станциям, каждый из которых передается по общей шине данных своему станционному планировщику. Шаг 3. Корректировка плана с учетом ответов других подразделений Полученные на шаге 2 планы для каждой станции просматриваются станционными планировщиками с учетом имеющихся у них данных о ресурсах своей станции и событиях на станционных и прилегающих путях. В случае отсутствия конфликтов стратегическому планировщику посылается сообщение о готовности выполнить спущенное расписание. При обнаружении же конфликтов станционный планировщик пытается решить их локально, внутри своей станции, путем изменения маршрутов прохождения поездов внутри станции или времени проведения «окон». Если расписание удалось согласовать внутри станции, не изменяя времен выхода поездов с нее, то стратегическому планировщику посылается сообщение о готовности выполнить спущенное расписание. В противном случае стратегическому планировщику посылается сообщение, содержащее скорректированное время прохождения станции для каждого поезда. Шаг 4. Принятие согласованного плана на уровне подразделений После получения сообщений от станций о готовности выполнить расписание или о необходимости его изменения, планировщик дорожного уровня строит новое расписание с учетом полученных корректировок и опять рассылает его по частям станционным планировщикам. Если все станции готовы выполнить новое расписание, то оно утверждается до187 рожным планировщиком. В противном случае процесс повторяется до построения согласованного всеми станциями расписания или до прерывания процесса планирования со стороны пользователя. В этом случае пользователю выдается наиболее согласованный из ранее полученных вариант расписания. Шаг 5. Реакция на события, вызывающие изменение в графике движения поездов При возникновении некоторого возмущения в утвержденном расписании на перегоне («окно» для ремонтных работ, отказ элементов инфраструктуры, опоздание поезда по любой причине и т.д.) планировщик дорожного уровня определяет, на какие поезда влияет данное возмущение, и перепланирует их расписание, разрешая возникшие конфликты при помощи станционных планировщиков. При возникновении возмущений на станции разрешением конфликтов занимается станционный планировщик, стараясь при этом не изменять время прохождения поездов через свою станцию. В случае невозможности удовлетворить это требование составляется скорректированное расписание для этой станции, которое передается планировщику дорожного уровня, при этом процесс планирования запускается с шага 4. Далее данный процесс не останавливается, а продолжается, активируясь событиями с любой из сторон, как сверху, так и снизу. Таким образом, Экспериментальный Образец поддерживает два типа взаимодействий: а) горизонтальное взаимодействие – осуществляется между планировщиками станций. К этому типу взаимодействия относятся переговоры между соседними станциями о прохождении поездов по блок-участкам и выполнении работ на блокучастках. б) вертикальное взаимодействие – осуществляется между планировщиком станции и стратегическим планировщиком. К этому типу взаимодействия относятся действия по постановке задач станциям на основе стратегического плана и уточнению и согласованию расписания движения с учетом «новых подробностей» о ресурсах и технологических операциях перевозочного процесса от станций. С помощью такой архитектуры системы каждый планировщик может работать автономно в своем подразделении (станции), реагируя на возникающие события, а при необходимости может взаимодействовать с планировщиками других подразделений (станций) через общую шину данных предприятия. 188 При этом каждый планировщик может размещаться физически на своем сервере и работать в режиме согласования решений вместе с другими планировщиками p2p сети параллельно, решая, как распределять задачи у руководимого им подразделения. Данный подход обеспечивает важные преимущества разрабатываемой системы: а) повышение качества и эффективности решений по планированию производственных ресурсов, б) открытость к поэтапному подключению планов новых подразделений, в) высокую оперативность, гибкость и производительность, надежность и живучесть, масштабируемость и интегрированность системы управления ресурсами в масштабах ОАО «РЖД», г) сокращение расходов на владение и сопровождение такой системы, уменьшение рисков ее внедрения. 3.1.3 Входные и выходные данные Сведения о входных данных На вход модуля планирования ЭО в виде программных объектов передаются: а) полное описание инфраструктуры ресурсов, включая их взаимосвязи, постоянные на горизонте планирования; б) полное описание начального состояния ресурсов, включая фактическое местонахождение поездов, состояния стрелок и другое; в) события (потребности), выполнение которых требуется запланировать. В процессе работы модуль планирования можно в любой момент приостановить и передать в него изменения в потребностях, новые потребности или новые фактические состояния ресурсов. Сведения о выходных данных Выходными данными ЭО будет являться описание набора взаимосвязанных во времени, т.е. переходящих из одного в другое, планируемых состояний и взаимоотношений физических объектов, не противоречащих друг другу на определенном горизонте планирования. Другими словами, на выходе модуля планирования в любой момент можно получить расписание в виде набора объектов, каждый из которых описывает, состояние некоторого ресурса и его отношения с другими ресурсами в различные моменты времени, чтобы удовлетворить потребности. 189 3.1.4 Развитие В настоящее время не реализованы горизонтальные связи между станционными планировщиками. Их взаимодействие при планировании происходит опосредованно через дорожный планировщик. Дальнейшее развитие системы предусматривает создание таких горизонтальных связей для более гибкого разрешения конфликтов с использованием модели микроэкономики. Развитие системы также подразумевает расширение функций станционных планировщиков. Кроме функций планирования, в станционный планировщик могут быть включены другие функции, отвечающие за отдельные виды работ станции, которые нуждаются в столь же четком планировании: работа маневровых локомотивов, работа по расчистке станционных путей, работы по формированию/расформированию составов, работа локомотивных и станционных бригад и пр. Все эти работы влияют на фактическую занятость путей, наличие доступного проезда для проходящего поезда и пр. и, таким образом, влияют на сам процесс планирования поездов. Учитывая и планируя данные работы, планировщик будет составлять более точные и устойчивые планы по прохождению станции поездами. При постановке задачи с расширенным набором функций станционного планировщика целесообразно использовать горизонтальные связи между станционными планировщиками в рамках модели микроэкономики для обмена некоторыми ресурсами, необходимыми для станционной работы: маневровыми локомотивами, локомотивными и ремонтными бригадами, свободными вагонами и пр. 3.2 Анализ полученных результатов и подготовка рекомендаций по дальнейшему развитию подхода и созданию промышленной версии системы для ее внедрения в эксплуатационную работу ОАО «РЖД» Эффективное управление ресурсами крупнейшей национальной компании ОАО «РЖД» не может обеспечиваться одной централизованной монолитной системой, равно как и множеством отдельных систем, не имеющих «надежных» связей между собой, единых алгоритмов и стандартов. При решении сложных задач автоматизации управления ресурсами представляется целесообразным использовать сетецентрический подход, получивший развитие для моделирования боевых действий, в совокупности совместной согласованной работы всей сети станций: «так локально, как только возможно, и так глобально, насколько это требуется для 190 успешного решения задачи» (as local as possible and as global – as required), по аналогии с взаимодействием подразделений родов войск в крупных боевых операциях [1, 2]. 3.2.1 Сетецентрический подход к управлению сложными системами Сетецентрический подход предопределяет организацию управления сложными процессами в распределённой коммуникационной инфраструктуре, реализующей максимальную ситуационную осведомлённость каждого узла (Situational Awareness) и переход к работе каждого узла в режиме самоорганизации на достижение поставленных задач на своем уровне. Успешное решение задач управления всей организацией в рамках сетецентрического подхода складывается из успешного выполнения своей задачи каждым узлом во взаимодействии с другими смежными узлами. В результате взаимодействия узлов друг с другом происходит динамическое согласование действий каждого узла под контролем особого узла (диспетчера командного штаба), имеющего стратегический обзор ситуации. Эти узлы, в свою очередь, также могут образовывать связанную сеть взаимодействующих узлов [3]. Основу сетецентрического управления составляют сквозные модели систем связанных объектов, взаимодействующих в едином информационном пространстве, в котором, в реальном времени и с высокой надежностью, обеспечивается циклическое повторение всех этапов исполнения различных контуров управления: а) многоканальный сбор, первичная обработка и накопление разноплановой фрагментарной информации, поступающей с различных компонентов системы, отражающих состояние внешней среды и их текущее внутреннее состояние; б) формирование посредством глубокой компьютерной переработки собираемой и накапливаемой информации целостной картины из информационных фрагментов, которая определяет текущее состояние системы в целом и её частей, и является основой для выработки управляющих воздействий; в) выработка и доставка управляющих воздействий, структурированных при формировании общей модели таким образом, что управляющая информация каждого такого канала воздействия выстроена в соответствии с «компетенцией» соответствующего управляемого компонента [4]. Для реализации сетецентрического подхода в системах управления ОАО «РЖД» используется интеграционная платформа, соответствующая принципам, заложенным данным подходом, и обеспечивающая единую информационную среду для автоматизации процессов поддержки принятия решений по планированию, выполнению и контролю сквозных производственных процессов [5-7]. Разработанный в рамках данного НИР прототип интеллекту191 альной системы для согласованного адаптивного планирования и связанного изменения планов движения поездов для минимизации отклонения высокоскоростных поездов класса «Сапсан» от графика движения под влиянием непредвиденных внешних событий может быть использован в рамках данной интеграционной платформы 3.2.2 Интеграционная платформа На основе платформы осуществляется интеграция с существующей информационной средой ОАО «РЖД», а также обеспечивается среда проектирования для отраслевых экспертов и разработчиков, которые смогут создавать новые функциональные подсистемы, существующие в едином информационном пространстве и взаимодействующие между собой. Интеграционная платформа содержит набор программно-аппаратных средств, компонентов, отраслевых стандартов, шаблонов и соглашений по проектированию, ориентирована на комплексную автоматизацию производственных процессов и позволяет создавать распределённые системы произвольной топологии. Каждый узел топологии платформы состоит из набора программно-аппаратных средств, включающих в качестве основного компонента резервируемый сервер приложений, а также опциональную реляционную или объектную базу данных. Все функциональные возможности платформы реализуются сервером приложений. Компонентная структура платформы и взаимодействие между узлами системы показаны на рисунке 3.2. Рисунок 3.2 – Компонентная структура платформы и организация распределённой системы 192 Программная архитектура одного узла топологии приведена на рисунке 3.3. ниже. Взаимодействие между функциональными модулями отражено стрелками с нумерацией. Рисунок 3.3 – Структура сервера приложений платформы На базе программной платформы общего назначения Вектор М формируется (1) внутренний язык программирования платформы (DSL-I). Внутренний язык обеспечивает конструкции, позволяющие формализовать и использовать шаблоны проектирования систем. В их число входят классы, модули, методы, объекты, фильтры, решающие правила, регуляторы, коммутаторы, технологические и бизнес процессы, модели, домены, события и сообщения, машины состояний, узлы топологии. Следует добавить также большое количество элементов создания пользовательского интерфейса. На базе системного языка и внутреннего языка платформы Вектор М строится (2)(3) онтология предметной области (понятийная модель). Онтология является единой для всей системы и доступна в каждом узле системы. Каждое изменение онтологии распространяется по всей сети узлов системы. Онтология выступает основой построения (4) отраслевого языка программирования. В свою очередь программный код на отраслевом языке может быть включён в элементы онтологии. Возможности отраслевого языка существенно увеличиваются, если он является продолжением внутреннего системного языка платформы (5) и языка общего назначения (6). 193 Такая организация отраслевого языка позволяет программисту-технологу использовать арсенал языков различных уровней абсолютно прозрачно, в едином текстовом представлении. Платформа строится по принципу управления данными. Все шаблоны проектирования и объекты предметной области являются динамическими данными. Такое построение позволяет реализовать высокую адаптивность поведения системы. Динамическая модель предметной области представлена объектами, созданными (7) на базе онтологии. Связь между объектами и онтологией динамическая. Объекты определяются изменяемым набором атрибутов и поведением. Изменение онтологии синхронно порождает изменения соответствующих объектов. Множество объектов организовано платформой по различным контекстам: пространствам данных, подсистемам и хранилищам. Функциональные задачи не программируются в традиционном понимании, а проектируются на множестве имеющихся шаблонов проектирования и конфигурирования с использованием отраслевого и базового языков. Платформа позволяет создавать и расширять не только отраслевой язык, но и набор шаблонов проектирования. Шаблоны строятся (13) с использованием языка программирования платформы и на основе выборки (8) объектов из общего множества. Эффективным шаблоном проектирования является модель. Модели представляют собой как различные настраиваемые стандартные и специальные типы структур данных, так и модели процессов и взаимодействий и позволяют эффективно конфигурировать (14) бизнес-логику, пользовательский интерфейс и сопряжение с другими системами и устройствами. Шаблоны выступают (12) строительными блоками при построении онтологии предметной области. Шаблоны могут быть определены с использованием онтологии. В состав платформы входит среда мультиагентного взаимодействия, реализующая функции динамического планирования и оптимизации ресурсов. В основе реализации лежит технология мультиагентных систем. Среда представляет собой распределенное сообщество агентов-планировщиков (оптимизаторов) с собственными расписаниями, действующих параллельно и на основе переговоров. Агенты построены (9) на базе онтологии предметной области и синхронизированы (10) с динамическими объектами предметной области. Среда конфигурируется (11) с использованием внутреннего языка программирования платформы. Конфигурация пользовательских интерфейсов реализуется на внутреннем языке системы (19), предоставляющем возможности описания элементов пользовательского интерфейса и построения из них сцен и приложений, исполняемых в едином информационном пространстве. Внутренняя логика приложений проектируется с использованием конструкций отраслевого языка (16). Возможности пользовательских приложений существенно расши- ряются за счет использования языка платформы (19) и базового языка программирования (17). Использование шаблонов проектирования (14) при конфигурировании пользователь194 ских приложений существенно снижает сложность разработки, привносит модульность и позволяет разрабатывать и поддерживать методологии проектирования. Система получает информацию о реальной ситуации из большого количества разнородных источников. Платформа обеспечивает механизм аккумуляции первичной информации и трансформацию разнородной первичной информации в унифицированное внутреннее представление. Задача сопряжения с внешними устройствами и системами решается унифицированным в рамках системы подходом - за счет создания и конфигурации соответствующих моделей взаимодействия и трансформации данных. Конфигурация сопряжения с другими узлами топологии определяет наборы событий и сущностей, по которым узел собирается оповещать другие узлы системы. Эти наборы могут быть представлены как перечень пересечений и(или) объединений типов, различным образом организованных контекстов или политик, либо как перечень моделей. Платформа обеспечивает единство онтологии и языков проектирования на всех узлах системы. 3.3 Проведение технико-экономической оценки рыночноэкономической оценки рыночного потенциала полученных результатов 3.3.1 Направления применения сетецентрических разработок 3.3.1.1 Анализ применения сетецентрических систем в России Единственной крупной разработкой по теме сетецентрических систем в РФ является программный продукт «Сетецентрическая G3-система управления G3-Бюджет РФ». Основными направлениями этой разработки стало: а) создание инструментов для взаимосвязи стратегического и бюджетного планирования; б) обеспечение транспарентности информации о плановых и фактических результатах управления общественными финансами; в) обеспечение интеграции процессов формирования, исполнения, контроля результативности бюджетных средств. Для системы «G3-Бюджет РФ» использовалась немодульная сетецентрическая архитектура программного обеспечения и соответствующих систем управления – G3A. Сетецентрический подход в архитектуре G3A заключается в создании единой сложной информационной модели. При этом особое внимание уделено системе сбора информа195 ции, ее структуризации и отсеиванию дублирующей или устаревшей информации. Так, изначально информация о бюджетировании была записана более чем на 2 000 страницах, после работы системы количество полезной информации сократилось почти в 10 раз. Таким образом, результатом использования сетецентрического подхода стала информационная модель с динамической семантической структуризацией многочисленных, и до этого малосвязанных, данных, с дальнейшей возможностью проведения анализа и построения необходимых отчетов. 3.3.1.2 Анализ применения сетецентрических систем в мире Среди крупных иностранных разработок можно выделить комплексную программу министерства обороны США Future Combat Systems, в которой предлагаются новые принципы и глобальные стандарты управления большими системами в военных применениях. Помимо США, концепция сетецентрических боевых действия принята на вооружение и у ряда других стран мира (Австралия, Англия, Франция, Китай и др.). Программа FCS определяет архитектуру перспективных глобально распределенных систем сетецентрического управления боевыми единицами, их группами, системами и средствами обеспечения. Она представляет собой многоуровневую систему сете центрической интеграции стационарных и мобильных объектов разного назначения, оснащенных встроенным компьютерным интеллектом, функционирующих и взаимодействующих между собой в едином информационно-функциональном пространстве управления в реальном времени. На рисунке 3.4 проиллюстрированы области комплексного применения сете центрического управления всеми видами (стационарных и мобильных) средств ведения боевых действий в общем информационно-временном пространстве, охватывающем все виды действий – сухопутных, воздушных, морских, космических. Одним из главных требований становится обеспечение в реальном времени всех участников достоверной и полной информацией соответствующего профиля компетенции, обеспечивающей своевременное достижение поставленных целей в условиях активного противодействия. 196 Рисунок 3.4 – Области комплексного применения сетецентрического управления всеми видами средств ведения боевых действий Программа FCS состоит из 18 компонентов и двух отдельных «надсистем». Все 18 компонентов разделены на 4 подгруппы: «сухопутные управляемые боевые машины», «сухопутные автоматические боевые машины», «автоматические летательные аппараты», «отдельные устройства». Ключевым системообразующим элементом программы являются средства связи и компьютерные сети, обеспечивающие поддержание функционально интегрированного информационного поля над зонами боевых действий посредством надежной работы мобильных беспроводных сетей. Автономные элементы подключены к общей сети и обмениваются информацией. Так, участники в реальном времени обеспечиваются данными о местоположении противника, поступающими с отдаленных автоматических датчиков, разведывательных машин, беспилотных аппаратов и т.п. Сетецентрический подход заключается в создании единого информационного поля, которое может получать данные из различных источников (от любого участника), обрабатывать их и предоставлять всегда актуальную информацию любым участникам системы. Подобное информационное поле позволяет каждому участнику, с одной стороны, действовать в определенной степени самостоятельно, исходя из текущей боевой обстановки, а, с другой стороны, быть в курсе действий других участников для синхронизации своих действий с ними. 197 3.3.1.3 Анализ применения сетецентрических систем по тематике в НИР Разработанная в США система «Сетецентрические железнодорожные перевозки с использованием интеллектуальных железнодорожных систем» (network-centric railroading utilizing intelligent railroad systems) представляет собой «объединенную теорию железнодорожных перевозок» с целью повышения безопасности и эффективности работы железных дорог, в которой для сбора, обработки и распространения информации используются системы позиционирования, датчики, компьютеры, современные математические методы и цифровые коммуникации. Система состоит из 29 технологий, программ и систем, среди которых: а) цифровая линия передач данных, служащая для сокращения времени передачи голосовых и факсимильных сообщений посредством цифровых сетей; б) национальная дифференциальная система GPS, являющаяся расширением глобальной системы позиционирования и обеспечивающая точность до 1-3 метров; в) система контроля поездов (Positive Train Control - PTC), служащая для контроля движения поезда и поддержания безопасности, точности и эффективности; г) контролируемые электроникой и пневматикой тормоза; д) Дисплей Знаний (Knowledge display interfaces), обеспечивающий информацию о положении и скорости поезда, его маршруте, ограничениях скорости, фактических и рекомендуемых параметрах для набора скорости и торможения и другую информацию для машинистов. также через эти дисплеи может осуществляться связь между диспетчерами и машинистами; е) системы регистрации учета времени работы экипажей; ж) система автоматической идентификации оборудования (RFID метки), устанавливаемые по обе стороны от всех грузовых вагонов и локомотивов; и) придорожные датчики оборудования, устанавливаемые вдоль трассы и сообщающие информацию о дефектах на блок-участках с целью проведения необходимого ремонта; к) системы мониторинга состояния локомотивов, состоящие из датчиков, установленных на двигателях, электрических и воздушных системах локомотива, а также топливных баках и другие системы. Сетецентрический подход заключается в создании единого информационного поля, в котором должен содержаться огромный объем информации, связанный с различными ресурсами железной дороги (вагоны, локомотивы, железнодорожные пути и т.д.). Подобное поле связывает 29 систем, а также согласовывает получаемую ими информацию и действия между собой. Например, если придорожные датчики передают данные о дефектах на блок-участке, 198 системы тормозов, получив эту информацию из единого информационного поля, могут либо уменьшить скорость поезда, либо вовсе его остановить. 3.3.1.4 Вывод В России и мире сетецентрические системы используются, главным образом, как единые поля данных для сбора и хранения информации от различных источников. Данные системы не содержат средств планирования и перепланирования взаимодействующих ресурсов. Предлагаемый Исполнителем подход состоит в том, чтобы объединить в общую сетецентрическую структуру не только информационные компоненты (посредством использования онтологий), но и модули планирования различного уровня, осуществляющие коммуникацию на основе интеграционной платформы, что является уникальной разработкой. 3.3.2 Возможности использования результатов НИР для решения других задач При проведении научно-исследовательской работы Исполнителем были разработаны принципы построения сетецентрической системы принятия решений на основе мультиагентных технологий и онтологий. В указанной работе сетецентрическая система состоит из следующих модулей планирования: а) поездной (стратегический) планировщик, работающий на всем направлении Москва – Санкт-Петербург. Этот планировщик оперирует «грубыми» данными и его задачей является обеспечить движение ВСП «Сапсан» и других поездов на данном направлении согласно графику; б) станционный (оперативный) планировщик, каждый из которых работает на своей станции с целью обеспечить прохождение поездов через конкретную станцию. Сетецентрический подход определяет следующие особенности разрабатываемой системы: а) возможность общения всех участников между собой peer-2-peer («каждый с каждым») через общую шину данных; б) общая шина данных обеспечивает общее информационное поле, через которое каждый участник может получить актуальную информацию о других участниках системы; в) каждому участнику приходится отказываться от своих оптимальных действий (планов) в пользу достижения общей цели всех участников; г) действие одного участника может повлиять на действия всех остальных. 199 Наработки, полученные в ходе реализации сетецентрической системы в рамках НИР, можно использовать при решении большого числа других задач. При этом отдельно следует выделить две группы задач: а) задачи, в которых можно использовать структуру системы, разработанную в данной НИР (стратегический и оперативный планировщики); б) задачи, для которых следует существенно изменить планировщик в соответствии с особенностями предметной области, сохранив только концепцию сетецентрической системы, состоящей из отдельных планировщиков. 3.3.3 Вариант использования сетецентрической системы на основе разработанной архитектуры 3.3.3.1 Сетецентрическая модель в производственной логистике Рассмотрим задачу планирования работы крупного завода для выполнения заданного объема продукции в целом по заводу, и по отдельным цехам. Ниже описано, как можно применить сетецентрический подход для решения указанной задачи и использовать разработанные ранее стратегический и оперативный уровни планирования. Стратегический уровень планирования Стратегическое планирование осуществляется по основным укрупненным производственным технологиям, оперирует производственными мощностями (токари, слесари, шлифовальщики и т.д.) и имеет целью получение наиболее равномерного распределения этих мощностей между цехами и заказами с учетом установленных сроков сдачи продукции. План стратегического уровня подвергается автоматической декомпозиции по цехам и преобразуется к набору номенклатурных планов цехов. Внутрицеховой (оперативный) уровень планирования Номенклатурный план, пришедший в цех с уровня стратегического планирования, подвергается уточнению, детализации, пооперационному планированию на рабочих и последующему контроллингу исполнения плана. Взаимодействие планировщиков разных уровней Система является сетецентрической и состоит из взаимосвязанных базовых подсистем (планировщиков цехов), которые объединены в адаптивную р2р-сеть для взаимодействия по 200 принципу «каждый с каждым» и «равный с равным» посредством общей шины данных предприятия (см. рисунок 3.5). За координацию такого взаимодействия и разрешение возникающих конфликтов отвечает стратегический планировщик, также связанный с каждым из планировщиков цехов при помощи общей шины данных предприятия. Рисунок 3.5 – Архитектура МАС «Планирование» Принцип действия такой новой программной структуры описывается следующими шагами: Шаг 1. Построение «грубого» стратегического плана Стратегический планировщик занимается построением производственной программы и контролирует содержание полученных в результате номенклатурных планов цехов. При построении производственной программы стратегический планировщик оперирует укрупненными данными – ориентируется только на основные операции в технологическом процессе и изготовление основных составляющих (узлов) планируемого изделия по основным маршрутным технологиям. Шаг 2. Декомпозиция стратегического плана на планы цехов Сроки сдачи по этапам, полученные на первом шаге, достаточно грубые и требуют дальнейшей детализации и уточнения – это происходит на уровне планировщиков цехов. Исходные данные для планировщика цеха – номенклатурный план. Номенклатурный план для цеха есть часть производственной программы, собранной для узлов, производимых этим конкретным цехом. 201 Шаг 3. Оперативное планирование в цехах При планировании на данном шаге в первую очередь составляется расписание для «своих» узлов и подузлов, считая, что все необходимые комплектующие для сборки уже есть (включая детали и сборочные единицы, поставляемые от цехов-смежников), а также считая, что все услуги от цехов смежников будут выполнены без опозданий. Шаг 4. Горизонтальные взаимодействия для согласования планов между цехами (межцеховые поставки) Заявка в цех-смежник реализуется в виде «плана межцеховых поставок» и отражается в виде позиции номенклатурного плана. Дата сдачи такой позиции устанавливается равной началу сборки соответствующего узла в цехе-потребителе (с учетом времени перемещения между цехами). Как и все позиции номенклатурного плана, она детализируется и планируется в план соответствующего цеха. Появляется определенный плановый срок сдачи комплектующих. Шаг 5. Корректировка плана в каждом цеху (услуги другим цехам) Услуги, которые цех предоставляет другим цехам, также имеют вид позиций номенклатурного плана. Формирование таких позиций происходит в рамках процесса планирования технологического процесса, содержащего услугу, планировщиком цеха-сдатчика узла. Появляется определенный плановый срок окончания услуги. Шаг 6. Корректировка плана с учетом ответов других цехов Построенный на шаге 3 план «своих» узлов корректируется с учетом времени, которое необходимо другим цехам на изготовление комплектующих и выполнение услуг. Шаг 7. Принятие согласованного плана на уровне цехов В случае если цеха-поставщики успевают поставить необходимые комплектующие так быстро, что сроки сдачи позиций номенклатурного плана цеха-потребителя не нарушаются (срок сдачи узла раньше, чем тот, который определен производственной программой) считается, что стороны нашли удачный компромисс и никаких событий о задержке не создается. В случае неразрешенного конфликта с цехом-поставщиком цех-потребитель связывается со стратегическим планировщиком, передавая ему событие «Задержка выполнения» по сборке своего узла. 202 Шаг 8. Реакция на события, вызывающая пересогласование планов цехов События «Задержка выполнения» обрабатываются при помощи пользователя. Он может «разрешить» или «отклонить» задержку. Если пользователь выбирает решение «отклонить» задержку, он может ввести корректировку плана, например, за счет ввода сверхурочных. Шаг 9. Финальное согласование - уточнение исходного стратегического плана после согласований на уровне цехов Полученные с уровня оперативного планирования данные по детальной разузловке, срокам и требующейся загрузке рабочих центров и людей определенных специальностей вновь попадают на уровень стратегического планирования. При этом стратегический планировщик пересчитывает текущее распределение мощностей, выдавая план-прогноз о том, как и на сколько варьируются сроки выполнения тех или иных этапов производственной программы. Таким образом, стратегический план, построенный на основе основных укрупненных технологий, по мере поступления агрегатов в цеха, из разборки и дефектации, уточняется данными по загрузке рабочих и срокам окончания этапов в автоматическом режиме. Далее данный процесс не останавливается – а продолжается, активируясь событиям с любой из сторон, как сверху, так и снизу. Таким образом, система будет поддерживать три типа взаимодействий: а) горизонтальное взаимодействие – осуществляется между планировщиками цехов. К этому типу взаимодействия относится переговоры между цехами смежниками о поставке комплектующих и оказании услуг. б) вертикальное взаимодействие – осуществляется между планировщиком цеха и стратегическим планировщиком. К этому типу взаимодействия относятся действия по постановке задач цехам на основе стратегического плана и уточнению и согласованию производственной программы с учетом «новых подробностей» о технологических процессах и ресурсах от цехов. в) внутрицеховое взаимодействие по формированию плана производства в соответствие с сетевыми и номенклатурными планами с учетом данных горизонтального и вертикального взаимодействия. С помощью такой сетецентрической архитектуры системы каждый планировщик сможет работать автономно в своем цехе, реагируя на возникающие события, а при необходимости сможет взаимодействовать с планировщиками других цехов через общую шину данных предприятия. Общая система управления ресурсами предприятия может строиться 203 как двухуровневая адаптивная р2р сеть планировщиков подразделений, а каждый уровень, в свою очередь, может быть развернут в виде р2р подсети планировщиков. Такой подход может распространяться не только на цеха, группы, и смены, но и на целые предприятия, в частности, может быть положен в основу общей автоматизированной системы управления, где может быть обеспечена поддержка взаимодействия не только отдельных цехов (бизнес центров или центров компетенций), но и целых предприятий. Подобный потенциал системы еще раз подчеркивает сетецентризм разработанной модели – возможность объединять различные системы в одну, при которой каждая включенная система начинает работать лучше, чем по отдельности и является одним из главных принципов сетецентризма. Данный подход обеспечивает такие важные преимущества разрабатываемой системы как повышение качества и эффективности решений по планированию производственных ресурсов, открытость к поэтапному подключению планов новых подразделений, высокая оперативность, гибкость и производительность, надежность и живучесть, масштабируемость и интегрированность общезаводской системы управления ресурсами. При этом сокращаются расходы на владение и сопровождение такой системой, а также уменьшаются риски ее внедрения. 3.3.4 Вывод о созданной архитектуре сетецентрической системы Предложенную архитектуру сетецентрической системы можно использовать для большого числа задач, при решении которых необходимо составлять один или несколько «больших» планов составленных на «грубом» уровне (уровень стратегического планирования), и которые должны быть детализованы разными исполнителями с учетом своих специфик (уровень оперативного планирования). При этом исполнители могут быть тесно связаны между собой и влиять на «большие» планы. Примеры таких задач: а) планирование общего объема продаж продукции, исходя из маркетинговой политики компании (стратегическое планирование) и планирование продаж в конкретном подразделении с учетом спроса в этом подразделении, проведении акций, повышающих продажи, и т.д. (оперативное планирование); б) планирование движения поездов на уровне отдельного направления или ЖД в целом (стратегическое планирование) и планирование движения между соседними станциями (оперативное планирование); 204 в) планирование боевых действий для всех войск (стратегическое планирование) и планирование боевых действий для отдельной группы войск (оперативное планирование). 3.3.5 Варианты использования сетецентрических систем с разработкой новой архитектуры системы Предложенная архитектура сетецентрической системы, состоящей из стратегического и оперативного уровней планирования, может подойти далеко не для всех решаемых задач. Рассмотрим варианты сетецентрических систем с модулями планирования, в которых каждый модуль планирования имеет собственную цель и задача состоит в согласовании двух или более противоречивых целей. 3.3.5.1 Сетецентрическая модель планирования грузоперевозок на железной дороге В рамках НИР была рассмотрена задача планирования пассажирских поездов на отдельном направлении железной дороги. В настоящее время ОАО «РЖД» внедряет концепцию хождения по расписанию грузовых поездов. Для реализации этой концепции предлагается доработка реализованного в НИР сетецентрического подхода для создания сети взаимодействующих интеллектуальных систем управления ресурсами сортировочных станций. При этом формирование вагонов грузового поезда в системе одной станции может потребовать обращения к ресурсам (например, за недостающими свободными вагонами) системы соседней станции и т.д. При этом каждая интеллектуальная система одной станции может рассматриваться, в свою очередь, как сеть взаимодействующих подсистем управления отдельными видами ресурсов станции (маневровыми локомотивами, вагонами, бригадами рабочих и другими ресурсами), также вырабатывающих согласованные решения по планированию использования ресурсов. Такой сетецентрический подход, предполагающий создание «системы систем» (или «сети сетей»), позволяет преодолеть фундаментальную проблему сложности задачи, решить которую в рамках одной «монолитной», централизованной, последовательной системы не представляется возможным. Однако, такой сетецентрический подход предъявляет новые требования к построению отдельных систем, призванных согласованно функционировать в создаваемой сети, а также к платформе, предназначенной для их интеграции как между собой, так и с существующими системами. Для решения рассматриваемой проблемы необходимо создание и исследование распределенных интеллектуальных систем, создаваемых в форме адаптивных р2р сетей инфор205 мационно-коммуникационных мультиагентных систем, для согласованного управления подразделениями грузовой сортировочной станции (маневровыми локомотивами, вагонами, бригадами рабочих и другими ресурсами), взаимодействующими по принципам «каждый с каждым» и «равный с равным» через общую шину станции в реальном времени в целях комплексной автоматизации производственных бизнес-процессов и обеспечения доступа к данным для специализированных мультиагентных систем управления ресурсами подразделений станции в реальном времени. Развиваемый мультиагентный подход и разрабатываемые на его основе методы и средства обеспечивают возможность решения сложных задач распределения, планирования и оптимизации ресурсов станции в реальном времени за счет применения принципов самоорганизации и эволюции, при котором решение задачи (согласованный сетевой план-график работ) строится и улучшается в ходе конкуренции и кооперации агентов заказов и ресурсов станции (маневровых локомотивов, путей, бригад машинистов и рабочих и других), способных действовать как полностью автономно, так и согласованно решать задачи управления, включая динамическое планирование ресурсов, причем под контролем диспетчерских. Рассмотрим возможное применение сетецентрического подхода на примере решения задачи управления поездными локомотивами и локомотивными бригадами. Для решения задачи необходимо ввести три вида планировщиков, отвечающий каждый за свой ресурс: а) поездной планировщик – для планирования движения поездов; б) локомотивный планировщик – для планирования движения локомотивов (как с поездами, так и без поездов); в) планировщик локомотивных бригад – для планирования работ локомотивных бригад. Поездной планировщик Поездной планировщик составляет расписание движения грузовых поездов с целью обеспечения заданного объема грузоперевозок. В плане содержится информация о характеристиках поездов, прибывающих на станцию (вес, длина, перевозимый груз), времени их отправления, следующая станция по маршруту. План, составленный поездным планировщиком, автоматически передается планировщику локомотивов. Локомотивный планировщик Локомотивный планировщик должен обеспечить в заданное время необходимое количество локомотивов требуемого типа на станциях формирования поездов для обеспечения плана движения поездов. 206 Планировщик локомотивных бригад Планировщик локомотивных бригад должен обеспечить необходимое количество локомотивных бригад на станциях формирования поездов для обеспечения бесперебойного плана движения поездов. Взаимодействие планировщиков между собой Система является сетецентрической и состоит из взаимосвязанных базовых подсистем, которые объединены в адаптивную р2р-сеть для взаимодействия по принципу «каждый с каждым» посредством общей шины данных системы. В общем случае, система будет поддерживать два типа взаимодействий: а) вертикальное взаимодействие – осуществляется между разными планировщиками. К этому типу взаимодействия относятся действия по согласованию единого плана между всеми планировщиками. б) внутреннее взаимодействие внутри планировщика по корректировке и согласованию своего плана с планами других планировщиков. Например, локомотивный планировщик может отправить локомотивы без поезда на соседнюю станцию, если на ней определена нехватка локомотивов, которая может привести к срыву графика движения поездов. С помощью такой сетецентрической архитектуры все планировщики находятся в тесном взаимодействии друг с другом, каждый планировщик должен согласовывать все свои решения с другими планировщиками. Отклонение от плана хотя бы у одного планировщика (например, локомотив не успевает во время подъехать для подцепки к поезду, к которому он был запланирован) может повлиять на реализацию планов всех остальных планировщиков. 3.3.5.2 Вывод Предложенную архитектуру сетецентрической системы можно использовать для ряда задач, при решении которых требуется найти согласованное решение в интересах многих участников, связанных между собой в решении единой глобальной задачи. При этом отклонение от плана любого участника влияет на решения других. Примеры областей применения и развития реализованной в НИР сетецентрической архитектуры: а) Сложные цепочки поставок. Адаптивное планирование в сети филиалов совершается непрерывно, объем поставок и время определяются динамически. Поступающие в систему события продаж меняют текущие состояния склада магазина по каждому продукту. Предиктор строит прогноз расходования каждого товара на задан207 ный период вперед по времени. Непрерывно работающий планировщик создает поставку, руководствуясь следующей логикой. На основании предсказанного потребления определяются товары, которые приносят максимальную прибыль и включаются в поставку в количестве, удовлетворяющем очередную потребность на каждом шаге итераций. В поставке учитываются текущее состояние склада, чтобы не было превышения, максимальный объем поставки, стоимость транспорта и стоимость хранения. Объем и состав этой будущей поставки изменяется по поступлению событий продаж и уточнению прогноза потребления. Эти изменения перестают влиять, когда до наступления поставки остается время, необходимое на её формирование, транспортировку и разгрузку. Поставка фиксируется, находясь еще в будущем относительно текущего времени. Затем формируется следующая поставка, состав и объем которой учитывают не только прогноз потребления, состояние склада, но и поставки, находящиеся в будущем относительно текущего времени, но уже находящиеся в пути. Планировщики различных уровней адаптивно отслеживают состояния товаров и оперативно реагируют на все изменения. При уменьшении спроса поставки происходят с большими промежутками, а при возрастании спроса — их частота увеличивается. б) Производственная логистика. За счет использования сети планировщиков в системе поддерживается полный цикл управления: от ввода событий – к планированию и контролю результатов через отметки факта выполнения работ и анализу план против факта. Преимущества применения сетецентрического подхода в производственной логистике: 1) план работы цеха может в любой момент перестраиваться и пересчитываться быстро, гибко и с учетом индивидуальных особенностей каждого заказа и ресурса. 2) автоматизированы все основные рутинные операции, что снижает трудоемкость управления: например, сменно-суточные задания могут формироваться автоматически, но могут быть удобно и просто доработаны в любом направлении. 3) стратегическое планирование также становится более простым, быстрым и удобным. 4) важные субъективные знания мастеров о станках, технологиях и рабочих (плохо формализуемые) становятся объективными и могут быть использованы для повышения качества планирования. 5) создается платформа для развития производственных ресурсов цеха без роста численности управленческого персонала. 208 в) Транспортная логистика. Сетецентрическая интеллектуальная система управления грузовой сортировочной станцией обеспечивает адаптивное р2р взаимодействие подсистем управления отдельными станциями, а также «внутри» каждой такой системы - адаптивная р2р сеть мультиагентных планировщиков различных ресурсов станции. Подобная сетецентрическая система основана на процессах ко-эволюции указанных самоорганизующихся систем, взаимно координирующих поведение друг друга по событиям в реальном времени, что позволит отказаться от неэффективных каскадных («водопадных») бизнес-процессов и по-новому решать задачи самой высокой сложности на железной дороге. Таким образом, сетецентрические системы способны эволюционно расширяться за счет подключения все новых систем и согласованно решать задачи возрастающей сложности. 209 ЗАКЛЮЧЕНИЕ В рамках научно исследовательской работы по теме «Разработка и исследование прототипа интеллектуальной системы для согласованного адаптивного планирования и связанного изменения планов движения поездов для минимизации отклонения высокоскоростных поездов класса «САПСАН» от графика движения под влиянием непредвиденны внешних событий» на третьем (заключительном) отчетном этапе была сформулирована и решена задача по завершению разработки экспериментального образца и его компонентов, оценки и формированию предложения по созданию полнофункциональной системы. Оценка полноты решений поставленных задач. Для решения поставленных задач в проекте был выполнен комплекс научноисследовательских работ, включая: а) выполнение аналитического обзора современной научно-технической, нормативной, методической литературы, затрагивающей научно-техническую проблему. б) проведение патентных исследований в соответствии ГОСТ Р 15.011-96 в) проведение теоретических исследований и анализа задачи управления пассажирскими перевозками, а также управления высокоскоростным транспортом; г) анализ задачи адаптивного планирования и динамического управления расписанием для минимизации отклонения от графика высокоскоростного железнодорожного транспорта. д) проведение анализа современного состояния методов и средств динамического планирования подвижных объектов применительно к инфраструктуре РЖД в реальном времени; е) разработку программного мультиагентного подхода к построению процессов управления ЖД ресурсами, содержащую в себе: 1) разработку формализованных моделей индивидуального планирования ключевых ресурсов инфраструктуры РЖД (поезд, путь, блок-участок, станция и др.); 2) разработку метода согласованного адаптивного управления расписанием движения поездов на основе мультиагентного подхода; 3) разработку логики агентов активных сущностей предметной области, позволяющих реализовать полный цикл реакции на события, планирования и исполнения планов в реальном времени; 4) разработку структуры данных и алгоритмов принятия решений, а также протоколов проведения переговоров агентами в ходе динамического планирования 210 ресурсов, включая выявление конфликтов, согласованную подвижку и перераспределение операций во времени; 5) разработку моделей взаимодействий агентов, позволяющих осуществлять взаимные уступки во имя общей цели системы; ж) разработку принципов построения сетецентрических интеллектуальных систем для согласованного планирования ресурсов РЖД, способных к согласованному коллективному взаимодействию в реальном времени, на основе баз знаний и мультиагентных технологий; и) разработку программной модели согласно требований п. 6.3.1 настоящего ТЗ. к) разработку экспериментального образца системы, позволяющего осуществлять адаптивное динамическое планирование в рамках одного модуля планирования. Результатами НИР заключаются в том, что: а) разработано частное техническое задание на создание экспериментального образца по ГОСТ 34.602-89; б) разработана структура онтологии инфраструктуры РЖД, включая базовые классы, концепты, отношения, свойства и атрибуты инфраструктуры РЖД, используемые в процессе планирования, для настройки на конкретные примеры применения; в) разработаны принципы создания и редактирования онтологий и сцен, содержащих оперативную информацию о ситуации на участке направления, в виде семантических сетей; г) разработаны методы и средства редактирования онтологий и сцен для решения задач управления ресурсами на участке направления; д) разработана архитектура распределенной адаптивной р2р сети системы для согласованного планирования объектов инфраструктуры РЖД; е) разработаны компоненты адаптивной р2р платформы для автоматизации планирования ресурсов РЖД; ж) разработаны средства для обеспечения возможности двустороннего непрерывного человеко-машинного диалога системы с лицами, принимающими решения; и) разработаны методы интеграционной платформы, обеспечивающей взаимодействия частей системы; к) разработаны программы и методики экспериментальных исследований; л) выполнена онтологическая настройка ЭО на предметную область для проведения исследований и экспериментов; м) проведены экспериментальные исследования. Оформлены акты и протоколы экспериментальных исследований. 211 н) произведена программная реализация разработанных методов в виде экспериментального образца сетецентрической системы планирования, обеспечивающей согласованную работу двух модулей планирования; п) выполнен анализ полученных результатов и подготовлены рекомендации по дальнейшему развитию подхода и созданию промышленной версии системы для ее внедрения в эксплуатационную работу ОАО «РЖД»; р) проведены дополнительные патентные исследования в соответствии с ГОСТ Р 15.011-96; с) проведена технико-экономическая оценка рыночного потенциала полученных результатов; т) разработан проект ТЗ на проведение ОКР по рассматриваемой теме; у) разработана программная документация на экспериментальный образец (в соответствии с требованиями п. 7.3. технического задания); ф) реализованы мероприятия по достижению значения программных индикаторов и показателей (в соответствии с п. 9.3 технического задания); х) разработан заключительный отчет о НИР; ц) подготовлена и оформлена отчетная документация в соответствии с требованиями технического задания и актов Заказчика. Поставленные задачи решены в полном объеме и в срок согласно ГК от «17» октября 2011 г. №07.514.11.4094. Таким образом, все задачи, которые ставились в рамках НИР, были полностью достигнуты, даны рекомендации и подготовлена база для дальнейшего развития подходов к решению возникающих проблем и использованию результатов работы на практике. 212 СПИСОК ИСПОЛЬЗУЕМЫХ ИСТОЧНИКОВ 1) Сетецентрическая война: Материалы Научно-исследовательского центра Военной ордена Ленина Краснознаменной ордена Суворова академии Генерального Штаба Вооруженных Сил Российской Федерации. – М., 2010. – с. 331; 2) Иващенко, А.В. Мультиагентные технологии для разработки сетецентрических систем управления / А.В. Иващенко, О.В. Карсаев, П.О. Скобелев, А.В. Царев, Р.М. Юсупов.– Известия ЮФУ. Технические науки.– 2011, №3 (116). – с. 11-23; 3) Скобелев, П.О. Сетецентрический подход к созданию больших мультиагентных систем для адаптивного управления ресурсами в реальном времени / П.О. Скобелев, А.В. Царев // Труды международной научно-практической конференции «Управление большими системами-2011» (УБС’2011). Т.3. – М.: ИПУ РАН, 2011. – с. 263-267; 4) Skobelev P. (Invited talk). Multi-Agent Systems for Real Time Resource Allocation, Scheduling, Optimization and Controlling: Industrial Application. / Petr Skobelev.- In Proceedings of the 5th Interna-tional Conference on Industrial Applications of Holonic and Multi-Agent Systems, HoloMAS 2011, Tolouse, France, August 2011. – Springer Verlag, Berlin: 2011. – pp.1-14; 5) Шабунин, А.Б. Сетецентрический подход к разработке системы управления производственными процессами ОАО «РЖД» / А.Б. Шабунин, А.В. Чехов, Д.В. Дмитриев, Е.В. Курбатов, С.В. Сазуров, П.О.Скобелев, Е.В.Симонова, А.В.Царев, М.Е.Степанов // Труды международной научно-практической конференции «Управление большими системами-2011» (УБС’2011). Т.3. – М.: ИПУ РАН, 2011. – с. 222-225; 6) Шабунин, А.Б. Разработка сетецентрического подхода к созданию интеграционной платформы и интеллектуальной системы управления ресурсами грузовых сортировочных станций в реальном времени / А.Б.Шабунин, А.В.Чехов, С.В.Сазуров, Е.В.Курбатов, Д.В.Дмитриев, Н.А.Кузнецов, П.О.Скобелев, И.О.Бабанин, С.С.Кожевников, Е.В.Симонова, М.Е.Степанов, А.В.Царев // Труды Третьей российской конференции с международным участием «Технические и программные средства систем управления, контроля и измерения» (УКИ’ 12). – М.:ИПУ РАН, 2012. – с. 1560-1572. – ISBN 978-5-91450-100-3; 213 7) Общий курс железных дорог [Электронный ресурс] / . – Электрон. журн. – М.: Помощник машиниста локомотива, 2010. – Режим доступа: http://pomogala.ru/okzd/okzd_19.html, свободный. – Загл. с экрана. – Яз. рус., англ.; 8) Leitao P., Barbosa J. Biological Inspiration to Solve Complexity in Intelligent and Adaptive Manufacturing Systems / 10th IFAC Workshop on Intelligent Manufacturing Systems (IMS'10). July 1-2, 2010 - Lisbon, Portugal. – pp. 221 – 226; 9) Капустян С.Г. Коллективное управление в распределенных сетецентрических системах / Материалы научно-технического семинара «Управление в распределенных сетецентрических и мультиагентных системах». СПб.: ОАО «Концерн ЦНИИ «Электроприбор», 2010 – с. 46 – 49; 10) Виттих В.А. Онтологические модели ситуаций в процессах принятия коллегиальных решений / Труды XII международной конференции «Проблемы управления и моделирования в сложных системах. Самара: СНЦ РАН. – 2007; 11) П.О. Скобелев. Мультиагентные технологии в промышленных применениях: к 20летию основания Самарской научной школы мультиагентных систем. Мехатроника, автоматизация, управление (МАУ) – 2010, №12; 12) Теряев Е.Д., Петрин К.В., Филимонов А.Б., Филимонов Н.Б. Агентные технологии в автоматизированных информационно-управляющих системах. Часть 1. Основы агентного подхода / Мехатроника. Автоматизация. Управление. – 2010. – № 7. – с 11 – 20; 13) Marek V. Preface to Proceedings of 5-th International Conference on Industrial Applications of Holonic and Multi-Agent Systems for Manufacturing HoloMAS 2009, Linz, Austria / Springer, 2009, pp. V-VII; 14) Абрамов Д.В., Андреев В.В., Симонова Е.В., Скобелев П.О. Разработка средств построения и использования онтологий для поддержки процессов принятия решений / Труды XII международной конференции «Проблемы управления и моделирования в сложных системах. Самара: СНЦ РАН. – 2007; 15) Смирнов А.В., Кашевник А.А., Левашова Т.В., Шилов Н.Г. Теоретические и технологические основы построения контекстно-управляемых систем поддержки принятия оперативных решений в открытой информационной среде / Мехатроника, Автоматизация, Управление. 2009. Вып. 96, № 3. с. 72 – 77; 16) Смирнов А.В., Пашкин М.П., Шилов Н.Г., Левашова Т. В. Контекстноуправляемая поддержка принятия решений в распределенной информационной среде / Информационные технологии и вычислительные системы. 2009. № 1. С. 38 – 48; 214 17) Найханова, Л.В. Применение методов нечеткого регулировании в соединении онтологий предметной области / Программные продукты и системы: междунар. журн. – Тверь: НИИ ЦПС. – 2008. – №2. – С. 41-44; 18) Paolo Umiliacchi, Didier van den Abeele, Pieter Dings, Valerio Recagno – “Turning Railways into an Intelligent Transportation System by better Integration, Management and Exchange of Information” - ITS World Congress – Stockolm – September 2009; 19) DIRECTIVE 2008/57/EC OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL on the interoperability of the rail system within the Community - 17 June 2008; 20) R. Shingler, G. Fadin, P. Umiliacchi – “From RCM to predictive maintenance: the InteGRail approach” - 4th IET International Conference on Railway Condition Monitoring – Derby - 18th June 2008; 21) Букин М. Глобальная навигация [Электронный ресурс] / М. Букин. – Электрон. журн. – М.: PC Week RE, 2008. – № 25. – Режим доступа: http://www.pcweek.ru/themes/detail.php?ID=111444, свободный. – Загл. с экрана. – Яз. рус., англ.; 22) A.Glashenko and other. Multi-Agent Real Time Scheduling System for Taxi Companies – Proceedings of 8-th International Conference on Autonomous Agents and Multi Agent Systems (AAMAS 2009). Hungary, Budapest, May 2009; 23) Организация железнодорожных пассажирских перевозок / А.А. Авдовский, А.С. Бадаев, К.А. Белов и др. ; под ред. В.А. Кудрявцева. – 2-е изд., стер. – М.: Издательский центр «Академия», 2008. – 256 с.; 24) Kallistratos Dionelis - Traffic Technology International – January 2011; 25) Michele Bernocchi, Emilio Miguelanez - “The contribution of European Research to more intelligent Railway Maintenance: the InteGRail project” - Euromaintenance 2010 International Congress - Verona Fiere - 14th May 2010; 26) Valckenaers P. Enriching manufacturing with bio-inspiration: Reconciling the complexadaptive and the complicated / 10th IFAC Workshop on Intelligent Manufacturing Systems (IMS'10). July 1-2, 2010 - Lisbon, Portugal. – pp. 379 – 380; 27) Найханова, Л.В. Применение методов нечеткого регулировании в соединении онтологий предметной области / Программные продукты и системы: междунар. журн. – Тверь: НИИ ЦПС. – 2008. – №2. – с. 41-44; 28) Артемьева И.Л., Рештаненко Н.В. Интеллектуальная система, основанная на многоуровневой онтологии химии / Программные продукты и системы. – 2008. – № 1. – с. 84 – 87; 215 29) Тузовский А. Ф. Создание и использование базы знаний профилей компетентности специалистов организации / Известия Томского политехнического университета. – 2007. – Т. 310. – № 2. – с. 186–189; 30) Inden U., Rzevski G., Skobelev P.O., Syusin I.A., Tsarev A.V., Vittikh V.A.. Multiagent adaptive planning platform for complex airport servicesystems / ТрудыX Международной конференции «Проблемы управления и моделирования в сложных системах»Самара: СНЦ РАН – с. 399 – 413; 31) Андреев М.В., Иващенко А.В., Скобелев П.О., Царев А.В. Построение адаптивной системы управления предприятием с использованием мультиагентных технологий / Вестник Самарского государственного технического университета, Серия «Технические науки» № 1 (23) – 2009 – с. 5 – 14; 32) Michael Andreev, Anton Ivaschenko Petr Skobelev, Alexander Tsarev. A Multi-Agent Platform Design for Adaptive Networks of Intelligent Production Schedulers / 10-th International IFAC Workshop on Intelligent Manufacturing Systems, Lisbon, Portugal, 2010, 1-2 July; 33) Иващенко А.В., Мартышкин Д.М., Скобелев П.О., Уланова Л.В., Царев А.В. Построение мультиагентной системы динамического планирования персональных задач для мобильных пользователей / Вестник Самарского государственного технического университета. Серия «Технические науки», 2009, № 3 (26) – 2009 – с. 32 – 37; 34) Бородин А.Ф. Эксплуатационная работа железнодорожных направлений (труды ВНИИАС, вып. 6) – М.: ВНИИАС, 2008. – 320 с. 216 ПРИЛОЖЕНИЕ 1 (обязательное к отчету о НИР) Отчет о дополнительных патентных исследованиях ОБЩЕСТВО С ОГРАНИЧЕННОЙ ОТВЕТСТВЕННОСТЬЮ «НПК «РАЗУМНЫЕ РЕШЕНИЯ» (ООО «НПК «РАЗУМНЫЕ РЕШЕНИЯ») УДК 004.942 № госрегистрации: 01201179187 Инв. № УТВЕРЖДАЮ Генеральный директор ООО "НПК "Разумные решения" А.В. Царев 2.11.2011 г ОТЧЕТ О ПАТЕНТНЫХ ИССЛЕДОВАНИЯХ: Разработка и исследование прототипа интеллектуальной системы для согласованного адаптивного планирования и связанного изменения планов движения поездов для минимизации отклонения высокоскоростных поездов класса «Сапсан» от графика движения под влиянием непредвиденных внешних событий по теме: ВЫБОР НАПРАВЛЕНИЯ ИССЛЕДОВАНИЙ. ТЕОРЕТИЧЕСКИЕ ИССЛЕДОВАНИЯ ПОСТАВЛЕННЫХ ПЕРЕД НИР ЗАДАЧ. (промежуточный) ГК от «17» октября 2011 г. №07.514.11.4094 Шифр: 2011-1.4-514-125-063 Руководитель НИОКР, директор по разработкам ООО "НПК "Разумные решения" ______________ Нормоконтроль, директор по общим вопросам ООО "НПК "Разумные решения" ______________ П.О. Скобелев 2.11.2011 г. 2.11.2011 г. Самара 2011 217 А.Н. Мочалкин СПИСОК ИСПОЛНИТЕЛЕЙ Руководитель темы: директор по разработкам ООО «НПК «Разумные решения» П.О. Скобелев (заключение) Исполнители: Ведущий аналитик ООО «НПК «Разумные решения» Е.В. Симонова (раздел 1) Аналитик С.С. Кожевников (общие данные об объекте исследований, заключение) ООО «НПК «Разумные решения» Нормоконтролер директор по общим вопросам, ООО «НПК «Разумные решения» А.Н. Мочалкин 218 СОДЕРЖАНИЕ НОРМАТИВНЫЕ ССЫЛКИ .........................................................................................................221 НОРМОКОНТРОЛЬ .......................................................................................................................222 ОПРЕДЕЛЕНИЯ .............................................................................................................................223 ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ ............................................................................................225 ОБЩИЕ ДАННЫЕ ОБ ОБЪЕКТЕ ИССЛЕДОВАНИЙ ..............................................................226 1 ОСНОВНАЯ (АНАЛИТИЧЕСКАЯ) ЧАСТЬ............................................................................230 1.1 Технический уровень и тенденции развития объекта хозяйственной деятельности...............................................................................................................................230 1.2 Выбор области для исследований ......................................................................................233 1.4 Поиск по базе данных Бюро по патентам и товарным знакам США .............................234 1.4.1 Патент на метод планирования движения поездов с использованием предварительного распределения ресурсов .......................................................................235 1.5 Поиск по базе данных Европейского патентного бюро ...................................................235 1.6 Поиск по базе данных Всемирной организации интеллектуальной собственности ............................................................................................................................237 1.6.1 Патент на процесс планирования коридора для поезда, включая различные стоимостные функции, связанные с железнодорожными операциями ............................................................................................................................238 1.7 Результаты исследования патентов....................................................................................238 1.8 Предпосылки к непатентным исследованиям ...................................................................240 1.9 Источники информации при выполнении непатентных исследований .........................240 1.10 Обзор выбранных систем планирования .........................................................................241 1.10.1 Автоматизированная интеллектуальная система диспетчерского управления движением поездов на скоростном направлении «Москва – Санкт-Петербург» .................................................................................................................241 1.10.2 Система безопасности, мониторинга и диспетчерского управления движением поездов с использованием систем ГЛОНАСС/GPS, разработанная МКБ «Компас» .............................................................................................245 1.10.3 Программный комплекс компании Siemens для автоматизации диспетчерского управления на железнодорожном транспорте ........................................246 1.10.4 Системы управления движением поездов в США ..................................................249 219 1.10.5 Европейские исследования в области интеллектуального управления на железной дороге: проект InteGrail ..................................................................................250 1.10.6 Децентрализованный подход к контролю инфраструктуры железных дорог, основанный на онтологии .........................................................................................252 1.11 Результаты исследования непатентных источников ......................................................253 1.12 Выводы ...............................................................................................................................254 ЗАКЛЮЧЕНИЕ...............................................................................................................................256 СПИСОК ИСПОЛЬЗУЕМЫХ ИСТОЧНИКОВ ..........................................................................258 ПРИЛОЖЕНИЕ 1.1 ФОРМА ЗАДАНИЯ НА ПРОВЕДЕНИЕ ПАТЕНТНЫХ ИССЛЕДОВАНИЙ ...................................................................................................................261 ПРИЛОЖЕНИЕ 1.2 ФОРМА РЕГЛАМЕНТА ПОИСКА ...........................................................262 ПРИЛОЖЕНИЕ 1.3 ФОРМА ОТЧЕТА О ПОИСКЕ...................................................................264 ПРИЛОЖЕНИЕ 1.4 АННОТАЦИИ ДОКУМЕНТОВ И ДРУГИЕ СПРАВОЧНЫЕ МАТЕРИАЛЫ, ОТОБРАННЫЕ ПРИ ПРОВЕДЕНИИ ПОИСКА ........................................267 220 НОРМАТИВНЫЕ ССЫЛКИ В настоящем отчёте о патентных исследованиях использованы ссылки на следующие стандарты: 1) ГОСТ 2.105-95 Межгосударственный стандарт. Единая система конструкторской документации. Общие требования к текстовым документам. 2) ГОСТ Р 15.011-96 Система разработки и постановки продукции на производство. Патентные исследования. Содержание и порядок проведения. 3) ГОСТ 15.101-98 Система разработки и постановки продукции на производство. Порядок выполнения научно-исследовательских работ 4) ГОСТ 7.32–2001 Система стандартов по информации, библиотечному и издательскому делу. Отчет о научно-исследовательской работе. Структура и правила оформления. 221 НОРМОКОНТРОЛЬ В соответствии с требованиями п.п. 3.4 ГОСТ 7.32-2001 - о необходимости обязательного нормоконтроля отчета о патентных исследованиях в организации-исполнителе, руководствуясь ГОСТ 2.111 был проведен нормоконтроль документации ответственным Мочалкиным А.Н. 222 ОПРЕДЕЛЕНИЯ В настоящем отчёте о патентных исследованиях использованы следующие определения: Агент Автономный программный объект, способный анализировать ситуацию, принимать решения, коммуницировать с другими агентами, вести переговоры друг с другом для разрешения возникающих конфликтов и затем информировать систему и пользователя о результатах своих действий. В процессе переговоров и принятия решений программные агенты пользуются знаниями, хранящимися в онтологии. Высокоскоростной поезд класса Высокоскоростной электропоезд (из семейства электро- "Сапсан" поездов Velaro производства компании Siemens AG), приобретённый ОАО «РЖД» для эксплуатации на российских скоростных железных дорогах. Динамическое планирование Метод, позволяющий изменять план работы системы в масштабе реального времени. Отличие от инкрементного планирования заключается в том, что в динамическом планировании используется не просто обычное распределение работ по интервалам на временной шкале, но и поддерживается возможность разрешать конфликтные ситуации путём внесения в план работ различного рода изменений, таких как перемещение, замена или прекращение операции. Знания Закономерности некой предметной области (принципы, связи, способы взаимодействия), полученные в результате практической деятельности и профессионального опыта, позволяющие моделировать бизнес-процессы в некоторой предметной области и решать задачи в этой области. Мультиагентные технологии Интегрируют последние достижения информационных технологий и программирования, методов и средств искусственного интеллекта, распределённых информаци223 онных систем и компьютерных сетей, в основе которых лежит понятие интеллектуального программного агента. С помощью мультиагентных технологий взаимодействие объектов реального мира моделируется переговорами их программных агентов, где настраиваемый программный агент человека действует в системе от имени и по поручению своего владельца, представляет его интересы во взаимодействии с органами исполнительной власти для наилучшей реализации его потребностей и возможностей. Расписание Последовательность выполнения запланированных задач (событий мероприятий) по времени. 224 ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ В настоящем отчёте о патентных исследованиях использованы следующие обозначения и сокращения: АСУ – автоматизированная система управления БЗ – база знаний ВОИС – Всемирная организация интеллектуальной собственности МАС – мультиагентная (многоагентная) система МАТ – мультиагентные технологии МПК – международная патентная классификация РЖД – российские железные дороги ФЦНТП – Федеральная целевая научно-техническая программа 225 ОБЩИЕ ДАННЫЕ ОБ ОБЪЕКТЕ ИССЛЕДОВАНИЙ Патентные исследования проводились с целью определения патентоспособности планируемых результатов научно-исследовательской работы по лоту «Проведение проблемноориентированных поисковых исследований в области информационно- телекоммуникационных систем для решения задач Технологической платформы "Высокоскоростной интеллектуальный железнодорожный транспорт"» – тема «Разработка и исследование прототипа интеллектуальной системы для согласованного адаптивного планирования и связанного изменения планов движения поездов для минимизации отклонения высокоскоростных поездов класса "Сапсан" от графика движения под влиянием непредвиденных внешних событий» (шифр «2011-1.4-514-125-063»), выполняемой в рамках Федеральной целевой научно-технической программы (ФЦНТП) «Исследования и разработки по приоритетным направлениям развития научно-технологического комплекса России на 2007–2012 годы» (мероприятие 1.4 Программы (IX очередь) "Проведение проблемно-ориентированных поисковых исследований и создание научно-технического задела по перспективным технологиям в области информационно-телекоммуникационных систем") по государственному контракту №07.514.11.4094, заключённому между Федеральным агентством по науке и инновациям и Научно-производственной компанией «Разумные решения» на основании решения Конкурсной комиссии Роснауки (протокол № 83 от 27.09.2011 г.), а также для получения сведений об охранных и иных документах, которые могут препятствовать применению результатов данной НИР в Российской Федерации, и условиях использования таких документов. Патентные исследования проводились в соответствии с ГОСТ Р. 15.011-96 «Система разработки и постановки продукции на производство. Патентные исследования» [1]. При этом в процессе исследований осуществлялся поиск, как патентных источников, так и непатентных источников, а также программных продуктов. Это должно помочь в разработке технологии, в которой будут учтены преимущества и недостатки уже существующих подходов к управлению производственными процессами ОАО «РЖД». Система управления движением поездов ОАО «РЖД» характеризуется большим разнообразием и количеством составных элементов и их взаимосвязей в рамках производственного процесса [4]. Кроме количественных характеристик, большое значение имеют качественные показатели сложности объекта автоматизации: а) неопределенность: трудно предсказать изменения спроса и предложения. б) событийность: часто случаются события, требующие оперативного изменения планов, решений в реальном масштабе времени. 226 в) ситуативность: решение надо принимать по ситуации. г) многофакторность: много разных критериев, предпочтений и ограничений. д) высокая связность: принятие оперативного решения на одном участке (станции) требует учёта принятых или планируемых решений на связанных участках (станциях) и вызывает изменение решений многих других. е) индивидуальность: участники требуют все более индивидуального подхода. ж) конфликты: все больше участников с противоречивыми интересами. и) трудоемкость: слишком много опций, чтобы просчитать последствия. к) оперативность: требуется высокая оперативность принятия решений. Эти особенности требуют новых современных стратегических подходов, методов и средств автоматизации производственной деятельности и обеспечения поддержки принятия решений в реальном времени. Анализ существующих систем управления движением поездов позволяет выделить основные направления развития: а) развитие информационных систем в направлении интеллектуализации систем управления ресурсами РЖД, б) развитие технических средств автоматизации. Анализ и опыт использования информационных систем управления движением поездов позволил выявить целый ряд проблем и недостатков, характерных на сегодняшний день. К числу таких недостатков, в первую очередь, относятся следующие: а) информационные системы функционально не удовлетворяют современным бизнеспроцессам железнодорожного транспорта, отсутствуют методы и средства, обеспечивающие согласованную работу участников производственной деятельности. б) отсутствует поддержка сквозных бизнес-процессов, системы не интегрированы, отсутствует комплексный подход к решению транспортных проблем. в) основу автоматизации управления перевозочным процессом составляют системы, разработанные 20-30 лет назад, реализованные по принципу хранилища данных. модернизация таких систем неэффективна, а часто и невозможна. г) информационная перегруженность лиц, принимающих решения, отсутствие средств поддержки принятия и реализации оперативных решений, особенно в части реакции на непредвиденные события. д) принятие решений при выходе поезда из расписания в настоящее время осуществляется только вручную. е) отсутствие опережающего прогнозирования возможности появления нештатных ситуаций путем моделирования процессов движения при различных условиях и др. 227 Указанные проблемы уже имеющихся на рынке систем во многом вызваны использованием традиционных алгоритмов и подходов к организации планирования и ведения задач, при которых все операции планирования выполняются единообразно независимо от типа и специфики задач. В проекте предлагается новый способ построения систем планирования движения поездов, который позволит обеспечить следующие преимущества: а) повышение актуальности текущего расписания - суммарного времени, в течение которого расписание находится в актуальном состоянии за счет своевременной обработки событий; б) повышение числа анализируемых вариантов и возможных решений, учтенных при анализе и перепланировании в ответ на события; в) повышение оперативности в принятии решений и, в частности, сокращение времени реакции на непредвиденные события; г) повышение точности оценки последствий непредвиденных событий и рассчитанных показателей эффективности расписания на горизонте планирования по сравнению с учетом опозданий без взаимных влияний в расписании; д) повышение готовности к изменениям в форме расчета показателей эффективности расписания (например, с учетом энергоэффективности); е) опережающее прогнозирование возможности появления нештатных ситуаций путем моделирования процессов движения при различных условиях; ж) своевременное выявление и устранение проблемных ситуаций путем планирования отражения событий, а также мониторинга и контроля выполнения планов, в том числе, по каждому поезду, вовлеченному в процесс управления ресурсами. и) прозрачность результатов планирования для управленцев. к) сокращение влияния человеческого фактора. Выводы. Стремительный технический прогресс в области Интернет-систем, семантического веба и мультиагентных технологий, мобильной связи, спутниковой GPS/ГЛОНАСС навигации и ряда других в последнее время открывает совершенно новые возможности для решения рассматриваемых проблем [5-8]. Предлагаемая технология адаптивного планирования и динамического управления расписанием поездов на основе сетецентрического подхода и интеграционной программной платформы комплексной автоматизации планирования ресурсов РЖД с использованием мультиагентных технологий и онтологий, средств GPS-навигации и GPRS имеет высокий потенциал [9]. В этой связи в настоящей работе наибольшее внимание будет уделено рас228 смотрению методов динамического планирования с использованием вышеуказанных технологий, позволяющих автоматически планировать и перепланировать формирующееся расписание движения поезда по событиям в реальном времени в зависимости от текущего местонахождения поезда, состояния пути и др. Патентные исследования (приложения А, Б, В) проводились с 17.10.2011 г. по 02.12.2011 г. 229 1 ОСНОВНАЯ (АНАЛИТИЧЕСКАЯ) ЧАСТЬ 1.1 Технический уровень и тенденции развития объекта хозяйственной деятельности В Транспортной стратегии Российской федерации на период до 2030 года отмечается, что железные дороги занимают важное место в транспортной системе. Протяженность железных дорог общего пользования транспортной системы России по состоянию на начало 2007 года составляла 85 тыс. км. Железнодорожный транспорт выполняет 84,3 процента общего грузооборота, осуществляемого всеми видами транспорта [3]. Важнейшей проблемой является техническое и технологическое отставание транспортной системы России по сравнению с развитыми странами. Она не готова к повсеместному применению современных технологий, в частности, в стране отсутствует высокоскоростное железнодорожное сообщение. Согласно инновационному варианту развития транспортной системы, значительный импульс получит развитие пассажирского транспорта общего пользования. Прежде всего, это относится к развитию скоростных и высокоскоростных железнодорожных перевозок. К приоритетным направлениям организации скоростного и высокоскоростного движения до 2015 года отнесены Москва - Санкт-Петербург (с максимальной скоростью на первом этапе 200 км/ч, а в дальнейшем до 250 км/ч), Санкт-Петербург - Бусловская (с максимальной скоростью на первом этапе 160 км/ч, а в дальнейшем до 200 км/ч), Москва - Нижний Новгород (с максимальной скоростью 160 км/ч). После 2015 года предусмотрена организация скоростного движения (140 - 160 км/ч) по направлениям Москва - Смоленск - Красное, Москва - Курск, Москва - Калуга - Брянск (Суземка), Москва - Ярославль, Москва - Рязань - Мичуринск - Саратов, Ростов - Краснодар, Ростов - Минеральные Воды, Краснодар - Минеральные Воды, Новосибирск - Омск, Новосибирск - Томск, Новосибирск - Кемерово, Новосибирск - Барнаул, Новосибирск - Новокузнецк, Екатеринбург - Челябинск, Самара - Саранск, Самара - Пенза, Самара - Саратов, Саратов - Волгоград, Уссурийск - Владивосток, Владивосток – Хабаровск. В Белой книге ОАО «РЖД» [4] указано, что концептуальной целью ОАО «РЖД» является обеспечение лидирующей позиции компании на рынке качественных и конкурентоспособных транспортных услуг, полностью удовлетворяющих потребности в грузовых и пассажирских перевозках при условиях минимизации нагрузки на окружающую среду. Реализация такой широкомасштабной цели, поставленной впервые, требует решения ряда крупных научно-технических проблем, определяющих успех достижения цели. 230 Многолетний мировой опыт показал, что при массовых перевозках в дневных поездах на расстояния 400 – 800 км и в спальных вагонах ночных поездов на расстояния 1700 – 2500 км по безопасности, затратам времени, стоимости, комфорту и экологии высокоскоростные поезда выгодны пассажирам по сравнению со всеми другими видами транспорта. Очевидно, что России с её огромными территориями необходимо иметь скоростные и высокоскоростные железнодорожные поезда. В соответствии с Федеральной целевой программой «Модернизация транспортной системы России на 2002 – 2010 годы» требуется осуществить поэтапное повышение скоростей движения пассажирских поездов с увеличением протяженности полигона скоростного движения до 8 тыс. км. Среди основных задач развития скоростного и высокоскоростного движения указаны: а) создание высокоскоростных электропоездов с конструкционной скоростью до 400 км/ч, скоростных межрегиональных электропоездов – 250 и 160 км/ч (в вариантах постоянного тока, переменного тока и двухсистемном); б) организация скоростного и высокоскоростного движения пассажирских поездов на приоритетных направлениях сети железных дорог; в) создание нормативной базы и системы технического обслуживания скоростного и высокоскоростного подвижного состава и инфраструктуры; г) создание технических средств для скоростного и высокоскоростного движения. Комплекс мероприятий по повышению скоростей движения на железнодорожном транспорте включает: а) повышение маршрутных скоростей дальних пассажирских поездов, следующих на расстояния более 700 км, до 70-90 км/ч; б) организацию скоростного железнодорожного движения после реконструкции действующих линий между крупными региональными центрами скоростными поездами, маршрутная скорость которых находится в пределах до 160-200 км/ч и время поездки не превышает 7 часов; в) создание высокоскоростных железнодорожных линий, на которых обеспечивается движение со скоростями до 350 км/час: 1) Санкт-Петербург – Москва, 2) Москва – Адлер. Цель инновационного развития ОАО «РЖД» направлена на достижение параметров экономической эффективности, экологической и функциональной безопасности и устойчивости отечественного железнодорожного транспорта общего пользования, определенных Транспортной стратегией Российской Федерации и стратегией развития ОАО «РЖД». 231 Среди важнейших направлений инноваций в научно-техническом развитии высокоскоростного движения на период до 2015 г. в Белой Книге ОАО «РЖД» определены: а) нормативы и требования к подвижному составу и инфраструктуре для высокоскоростного движения; б) система управления и обеспечения безопасности движения на высокоскоростных магистралях; в) автоматизированные технологии проектирования инфраструктуры. Основные результаты, достигнутые в 2007-2011 гг.: а) ввод в эксплуатацию высокоскоростного электропоезда RUS-250 и инфраструктуры для скоростей движения до 250 км/ч на участке Санкт-Петербург-Москва; б) создание системы технического обслуживания высокоскоростной инфраструктуры и подвижного состава; в) разработка проектов высокоскоростных магистралей на выделенных направлениях. К 2012-2015 гг. поставлена задача достижения следующих основных результатов: а) организация высокоскоростного движения со скоростями до 350-400 км/ч с освоением отечественного производства основных элементов инфраструктуры и подвижного состава; б) создание системы технического обслуживания инфраструктуры и подвижного состава для скоростей до 350-400 км/ч. Ускоренная модернизация существующей материально-технической базы железнодорожного транспорта к 2015 году предполагает увеличение маршрутных скоростей пассажирских поездов на основных направлениях на 12-15%. Стратегия инновационного развития ОАО «РЖД» реализуется через ежегодные планы научно-технического развития компании, включающие, в том числе, разработку новых технических решений и приоритетных технологий, таких как интеллектуальная система управления железнодорожным транспортом. Интеллектуальная система управления железнодорожным транспортом предназначена для организации централизованного автоматизированного управления движением поездов на линиях РЖД и организации всей производственной деятельности на РЖД на базе широкого использования современных методов анализа, управления, моделирования, логистики и прогнозирования, а также средств вычислительной техники и информационных технологий. Выполнение НИР, целью которой является разработка интеллектуальной системы для согласованного адаптивного планирования расписания железнодорожного транспорта на основе сетецентрического подхода и мультиагентных технологий, является актуальной зада- 232 чей, решение которой будет способствовать совершенствованию системы управления движением на высокоскоростных железнодорожных магистралях. 1.2 Выбор области для исследований Продуктами, разрабатываемыми в ходе данной научно-исследовательской работы, являются технология и система динамического планирования с использованием сетецентрической и интеграционной программной платформы комплексной автоматизации планирования ресурсов РЖД, мультиагентных технологий, онтологий, применённая к адаптивному планированию и динамическому управлению расписанием для минимизации отклонения от графика высокоскоростного железнодорожного транспорта за счет связанного изменения расписаний менее приоритетных поездов. Предпосылки к данным разработкам приведены в предыдущем разделе. Темы, по которым проводился поиск, определялись исходя из состояния исследуемой области. Такими темами стали: а) контроль и управление процессами, связанными с планированием ресурсов; б) методы составления расписания; в) разработка моделей индивидуального планирования ключевых ресурсов инфраструктуры РЖД (поезд, путь, блок-участок, станция) и др. Соответственно этому определились и разделы международной патентной классификации, по которым был проведён поиск патентов. Перечень данных разделов включает: а) B61L 27/00 (Системы диспетчерского управления движением поездов); б) B61L 27/02 (Системы диспетчерского управления движением поездов – ручные); в) B61L 27/04 (Системы диспетчерского управления движением поездов – автоматические, например управляемые поездом; с переключением на ручное управление); г) G08G (Системы регулирования движения транспортных средств (управление железнодорожным движением, обеспечение безопасности железнодорожного движения)); д) G06F (Обработка цифровых данных). Поиск патентной информации проводился в патентных базах данных Федеральной службы по интеллектуальной собственности, патентам и товарным знакам Российской Федерации (Роспатент, www.fips.ru), Бюро по патентам и товарным знакам США (USPTO, www.uspto.gov), Европейского патентного бюро (EPO, ep.espacenet.com) и Всемирной организации интеллектуальной собственности (ВОИС, www.wipo.int). 233 1.3 Поиск по базе данных Федеральной службы по интеллектуальной собственности, патентам и товарным знакам РФ В данном разделе приводится информация о результатах патентного поиска по темам, указанным в подразделе 1.2 настоящего приложения, в базе данных Федеральной службы по интеллектуальной собственности, патентам и товарным знакам РФ. В указанной базе данных был произведен поиск в электронном бюллетене №3 Электронный бюллетень - Программы для ЭВМ, базы данных, топологии интегральных микросхем № 3 2011 г. По результатам поиска в указанной базе данных не было найдено релевантных патентов, соответствующих разрабатываемой технологии планирования движения высокоскоростных поездов. Все патенты, касающиеся алгоритмов и методов планирования, относятся к потреблению электроэнергии, производству по добыче нефти, объему и ассортименту закупок, сервисному обслуживанию программно-технических средств комплексов средств автоматизации, капитальным вложениям в строительство, продажам по номенклатуре продукции и др., причем задачи планирования с использованием мультиагентных технологий и онтологий не рассматриваются. 1.4 Поиск по базе данных Бюро по патентам и товарным знакам США В данном подразделе приводится описание патентов, найденных в базе данных Бюро по патентам и товарным знакам США и относящихся к теме исследования. В ходе поиска были найдены несколько в определённой степени релевантных патентов. Данные патенты представлены ниже в порядке убывания релевантности: а) Метод планирования движения поездов с использованием предварительного распределения ресурсов (Method of planning the movement of trains using pre-allocation of resources, US Patent №11/591521, current US Class: 701/19; 246/2R, current International Class: G06F 17/00 (20060101)). б) Планирование ресурсов для железнодорожных перевозок (Resource schedule for scheduling rail way train resources, US Patent №10/438909, current US Class: 705/7.25, current International Class: G06F 17/60). В определенной степени близким к разрабатываемой системе является решение, описанное в патенте, который был выдан патентным бюро США корпорации General Electric Company. 234 1.4.1 Патент на метод планирования движения поездов с использованием предварительного распределения ресурсов Патент США №11/591521 «Метод планирования движения поездов с использованием предварительного распределения ресурсов». Владелец: General Electric Company (корпорация General Electric Company) [10]. Краткое описание патента. В патенте рассматривается метод планирования движения поездов, использующий создание и предварительное распределение виртуальных ресурсов в целях оптимизации графика фактического движения поезда. Метод планирования движения множества поездов включает в себя следующие этапы: (а) определение множества поездов, которые необходимо запланировать; (б) генерация первоначального плана движения множества поездов; (в) определение эффективности первоначального плана; (г) выделение виртуальных ресурсов, по крайней мере, одному поезду, который необходимо запланировать; (д) генерация второго плана движения для множества поездов; (е) определение эффективности второго плана движения; (ж) получение оценок эффективности первого и второго планов движения; (з) выбор первого или второго плана для управления движением поездов в зависимости от оценки эффективности. Настоящая заявка направлена на планирование движения поездов через использование виртуальных ресурсов для достижения более стабильного и эффективного планирование ресурсов. Замечания. В данном патенте описывается метод планирования, основанный на минимизации издержек, связанных с предварительным распределением ресурсов в системе железнодорожных перевозок, и предназначенный для управления движением поездов. Информация о том, каким образом система реагирует на непредвиденные события и перестраивает расписание поездов, отсутствует. Упоминание об использовании мультиагентных технологий и онтологий при реализации данного планировщика также отсутствует. 1.5 Поиск по базе данных Европейского патентного бюро В данном подразделе приводится описание патентов, найденных в базе данных Европейского патентного бюро. В ходе поиска были найдены несколько в определённой степени релевантных патентов. Данные патенты представлены ниже в порядке убывания релевантности: а) Метод для оптимизации железнодорожного трафика на одном пути (METHOD TO OPTIMISE TRAIN TRAFFIC ON SINGLE LINE, Patent № RU 2008147837 (A), current International Class: B61L27/00). б) Система и метод для автоматической генерации подтверждения решения о движении в железнодорожных системах (System and Method for the Automatic Generation of 235 Movement Authority Solutions in a Rail System, Patent № US 2011035083 (A1), current International Class: G05D3/00). в) Система для повышения безопасности трафика при централизации диспетчерского управления (SYSTEM TO INCREASE TRAFFIC SAFETY IN DISPATCHER CENTRALISATION, Patent № RU 2390456 (C1), current International Class: B61L27/04). г) Аппаратура для оценки расписания поездов (APPARATUS FOR EVALUATING TRAIN TIMETABLE, Patent № JP 2010264978 (A), current International Class: B61L27/00). Наибольший интерес среди них представляет патент, выданный корпорации ОАО «РЖД», а также патент, выданный корпорации LOCKHEED CORP. 1.5.1 Патент на метод для оптимизации железнодорожного трафика на одном пути Патент № RU 2008147837 (A) «Метод для оптимизации железнодорожного трафика на одном пути». Владелец: ОАО «РЖД» (корпорация Открытое акционерное общество «Российские железные дороги» [11]). Краткое описание патента. Изобретение относится к железнодорожному транспорту и может быть использовано в АСУ диспетчерской для управления движением на однопутном направлении. Обгон поезда и пересечение линий движения выполняются, когда поезда находятся на станции, где имеются, по крайне мере, два пути. Поезд будет принят на незанятом пути станции, причем управление железнодорожными путями выполняется с помощью рельсовых цепей и устройств блокировки. Для безостановочного обгона и пересечения прибытие поезда на станцию должно быть своевременным. Во время движения поезда периодически проверяются его параметры и пересчитывается прогноз времени прохождения отдельных участков. Время прохождения участков корректируется по факту. Одновременно с корректировкой обновляются параметры движения поезда и рассчитываются критерии для оптимизации диспетчерского управления состоянием пути и движением поезда. Замечания. Данный патент описывает метод корректировки расписания движения поезда по факту против плана, причем предусмотрено прогнозирование процесса прохождения отдельных участков. Однако данный метод предназначен для решения частной задачи, связанной с управлением движением поездов на однопутном направлении. В описании патента не упоминается использование мультиагентных технологий и онтологий при реализации системы. 236 1.5.2 Патент на систему и метод для автоматической генерации подтверждения решения о движении в железнодорожных системах Патент № US 2011035083 (A1) «Система и метод для автоматической генерации подтверждения решения о движении в железнодорожных системах». Владелец: LOCKHEED CORP (корпорация LOCKHEED [12]). Краткое описание патента. Система с двумя процессами для автоматической генерации железнодорожных маршрутов и соответствующих ресурсов включает центральный сервер, который подтверждает определенные диспетчером начальное и конечное время маршрута и выполняет два независимых процесса маршрутизации, чтобы обеспечить два независимых решения. Два решения сравниваются и выбирается решение, минимизирующее затраты на использование локомотива или поезда. Замечания. Данный патент охватывает лишь задачи, специфичные для построения маршрутов на основе имеющейся информации о доступных ресурсах, и используется для помощи диспетчеру в формировании маршрута движения поезда с наименьшими затратами. Данная система не решает задачи перепланирования расписания поездов в случае нарушения графика движения. В описании патента не упоминается использование мультиагентных технологий и онтологий при реализации системы. 1.6 Поиск по базе данных Всемирной организации интеллектуальной собственности В данном подразделе приводится описание патентов, найденных в базе данных Всемирной организации интеллектуальной собственности. В ходе поиска были найдены несколько в определённой степени релевантных патентов. Данные патенты представлены ниже в порядке убывания релевантности: а) Процесс планирования коридора для поезда, включая различные стоимостные функции, связанные с железнодорожными операциями (A TRAIN CORRIDOR SCHEDULING PROCESS INCLUDING VARIOUS COST FUNCTIONS ASSOCIATED WITH RAILWAY OPERATIONS, Patent № PA/a/2002/006558, current International Class: G06F 17/60, B61L 27/00). б) Процесс планирования коридора для поезда (A TRAIN CORRIDOR SCHEDULING PROCESS, Patent № WO/2001/049550, current International Class: B61L 27/00, G06Q 10/00). в) Метод актуальной информации об отклонениях в публикуемом расписании (Method of actual information about deviations in a published schedule, Patent № EP1541442, current International Class: B61L 27/00). 237 Наибольший интерес среди них представляет патент, выданный корпорации GE TRANSPORTATION SYSTEMS GLOBAL SIGNALING, LLC. 1.6.1 Патент на процесс планирования коридора для поезда, включая различные стоимостные функции, связанные с железнодорожными операциями Патент № PA/a/2002/006558 «Процесс планирования коридора для поезда на основе различных стоимостных функций, связанных с железнодорожными операциями». Владелец: GE TRANSPORTATION SYSTEMS GLOBAL SIGNALING, LLC (корпорация GE TRANSPORTATION SYSTEMS GLOBAL SIGNALING [13]). Краткое описание патента. Патент рассматривает процесс планирования движения поездов в железнодорожных коридорах. Железнодорожный коридор включает в себя множество путей, по которым поезда перемещаются в одну сторону. Чтобы график движения одного поезда не пересекался с графиком движения другого поезда, корректируется время возможного пересечения графиков, а также выполняется перевод поезда на другой путь. Для определения оптимального графика используется метод поиска градиента с использованием функции стоимости. Индивидуальные графики поездов формируются за счет изменения скорости движения поезда и времени отправления поезда (т.е. момента времени, когда поезд входит в коридор). Замечания. В данном патенте описывается метод планирования движения поездов в железнодорожном коридоре за счет корректировки скоростей движения поездов, момента времени вхождения их в коридор, перевода на другой путь с целью разрешения конфликтов при движении по одному пути. Данный метод использует метод градиентного поиска на основе стоимостных функций, оценивающих железнодорожные ресурсы. Однако патент не рассматривает возможность применения мультиагентных технологий и онтологий для согласованного планирования и перепланирования расписания поездов. 1.7 Результаты исследования патентов В результате предварительного исследования существующих патентов было решено исследовать разделы международной патентной классификации (МПК): а) Системы диспетчерского управления движением поездов (B61L 27/00), б) Системы диспетчерского управления движением поездов – ручные (B61L 27/02), в) Системы диспетчерского управления движением поездов – автоматические, например управляемые поездом; с переключением на ручное управление (B61L 27/04), 238 г) Системы регулирования движения транспортных средств (управление железнодорожным движением, обеспечение безопасности железнодорожного движения (G08G), д) Обработка цифровых данных (G06F). Поиск дал отрицательный результат: в данных разделах МПК не было найдено патентов, которые препятствовали бы на данном этапе проводить разработку технологии. Вместе с тем, следует отметить, что Бюро по патентам и товарным знакам США в 2010 году выдало патент на метод планирования движения поездов с использованием предварительного распределения ресурсов (Method of planning the movement of trains using preallocation of resources, US Patent №11/591521, current US Class: 701/19; 246/2R, current International Class: G06F 17/00 (20060101)). Однако данный патент не может создать сложностей при применении разрабатываемой технологии планирования движения высокоскоростного железнодорожного транспорта, поскольку не рассматривает перепланирование расписания в ответ на непредвиденные события и не использует мультиагентные технологии и онтологии при реализации планировщика. Краткое описание данного патента содержится в подразделе 1.4.1. Кроме того, Всемирной организацией по интеллектуальной собственности был выдан патент на процесс планирования коридора для поезда, на основе различных стоимостных функций, связанных с железнодорожными операциями (A TRAIN CORRIDOR SCHEDULING PROCESS INCLUDING VARIOUS COST FUNCTIONS ASSOCIATED WITH RAILWAY OPERATIONS, Patent № PA/a/2002/006558, current International Class: G06F 17/60, B61L 27/00). Данный патент также не может создать сложностей при применении разрабатываемой технологии планирования, поскольку рассматривает метод градиентного поиска с использованием стоимостных функций для изменения расписания за счет изменения скорости движения поезда. Краткое описание данного патента приводится в подразделе 1.6.1. Сказанное, однако, не означает, что в других разделах МПК, которые не относятся напрямую к рассматриваемой области, не существует патентов, которые не могут быть потенциально нарушенными в процессе эксплуатации разрабатываемой технологии. Вместе с тем, научная новизна предлагаемого в качестве основы мультиагентного подхода, основанного на знаниях и получающего развитие лишь в самое последнее время, позволяют надеяться, что предлагаемое решение превосходит все потенциально имеющиеся аналоги и имеет большой научно-технический потенциал для будущих разработок. 239 1.8 Предпосылки к непатентным исследованиям В соответствии с патентным законом Российской Федерации [2], уровень техники, в сравнении с которым выявляется новизна изобретения, определяется не только зарегистрированными в России патентами, но также имеющейся во всём мире общедоступной информацией. В отношении предлагаемой технологии планирования движения поездов такой информацией могут являться сведения о свободно распространяемых в сети Интернет программных продуктах, коммерческих программных продуктах и решениях, в той или иной степени реализующих функциональные возможности и технологии, аналогичные разрабатываемым. Таким образом, в силу требования технического задания о получении свидетельств об официальной регистрации программ для ЭВМ, возникает необходимость исследовать аналоги создаваемой технологии и сравнить её с этими аналогами. Поэтому данное исследование направлено на: а) анализ уже имеющихся на рынке систем диспетчерского управления движением поездов; б) определение критериев, по которым можно сравнивать данные системы; в) отбор систем, полностью или частично реализующих функциональные возможности, предоставляемые с помощью разрабатываемой технологии. 1.9 Источники информации при выполнении непатентных исследований В качестве основных источников информации по тематике «системы планирования движением высокоскоростного транспорта» использовались ресурсы сети Интернет, такие как Интернет-проект энциклопедии свободного доступа Wikipedia, веб-сайты компанийразработчиков программных решений для управления и планирования движением поездов. На основе анализа данных ресурсов был сформирован общий перечень существующих на рынке систем для планирования движения поездов. Данные системы существенно отличаются от предлагаемой технологии принципами работы, функциональными возможностями и полнотой решения задач планирования, а также пользовательскими интерфейсами. Кроме основных, были использованы и другие источники информации – различные информационные ресурсы, найденные с помощью поисковых систем. 240 1.10 Обзор выбранных систем планирования В данном подразделе представлен обзор систем планирования движения поездов, которые были найдены в процессе поиска: а) Автоматизированная интеллектуальная система диспетчерского управления движением поездов на скоростном направлении «Москва – Санкт-Петербург; б) Система безопасности, мониторинга и диспетчерского управления движением поездов с использованием систем ГЛОНАСС/GPS, разработанная МКБ «Компас»; в) Программный комплекс компании Siemens для автоматизации диспетчерского управления на железнодорожном транспорте; г) Системы управления движением поездов в США. Были проанализированы также следующие проекты: а) проект InteGrail, представляющий европейские исследования в области интеллектуального управления на железной дороге; б) проект Европейского консультативного совета по железнодорожным исследованиям и разработкам (ERRAC) для европейской железнодорожной инфраструктуры до 2020 г. Все данные системы были подробно изучены и проанализированы с точки зрения функциональных возможностей. По результатам анализа составлен краткий обзор разработок, включающий функциональные возможности систем и краткое заключение, отражающее общее впечатление о каждой разработке. Каждая из них имеет ту или иную важную особенность, реализует функциональные возможности или использует теоретические положения, которые могут быть полезны для исследования, проводимого по контракту. Далее приводится общий результат анализа, включающий список всех систем, близких к системе, разрабатываемой по контракту, с указанием того, что позволяет каждая из них. 1.10.1 Автоматизированная интеллектуальная система диспетчерского управления движением поездов на скоростном направлении «Москва – Санкт-Петербург» Для управления скоростным движением на участке Москва-Санкт-Петербург протяженностью 645 километров, создан специализированный диспетчерский центр. Центр управления скоростным движением призван повысить безопасность движения поездов и уровень выполнения графика, сократить энергозатраты. Руководством ОАО «РЖД» была поставлена задача создать современную систему по автоматизированному управлению движением поездов на скоростном направлении. В летнее 241 время между обеими столицами ежесуточно проходит до 85 пар пассажирских поездов, в пригородных зонах – около 110 пар электричек. Поезд «Сапсан» идет со скоростью до 250 км/ч. Система «Автодиспетчер» предназначена для управления движением поездов на базе оперативного суточного графика, с ее помощью осуществляется диспетчерский мониторинг, регулировка движения в соответствии с заданной программой, автоматическая подготовка маршрутов и принятие управляющих решений при возникновении конфликтных ситуаций [14]. Основой новой технологии является централизованное интеллектуальное управление движением поездов. Ядром системы является центральный управляющий комплекс, который с помощью специальных программ и математических методов вырабатывает регулировочные решения и по высокоточным скоростным каналам (система ТЕТРА) передает на управляемые объекты (ДЦ, автоведение, поезда, диспетчерский аппарат). Основные цели системы – максимальное выполнение графика, экономия энергоресурсов, безопасность пропуска поездов. Достижение поставленных целей обеспечивается решением трех основных функций: автоматическое построения ЭВМ варианта-графика на скоростном направлении (выработка управленческих решений), централизованное управление пропусками поездов на базе интеллектуального диспетчерского поста (автоматическая система подготовки поездных маршрутов), автоведения поездов с учетом энергосберегающих технологий. Информационное обеспечение представляет собой совокупность массивов информации, составляющих базу знаний об объекте, схемах движения и преобразования информации. Входная информация включает в себя данные с указанием номера поезда и состояния блокучастков, данные о плановых и фактически выполненных «окнах», о текущих неисправностях вагонов, об ограничениях скорости, отказах в энергоснабжении. Из АСОУП-2 поступают сведения о состоянии локомотивов, бригад, составе поезда. Важным элементом, обеспечивающим точную и своевременную информацию, должна стать система «ГЛОНАС»/GPS. Система «Автодиспетчер» активно использует информационное взаимодействие со специализированными системами по получению данных о состоянии инфраструктуры. Информация о предупреждениях, ограничивающих скорость на каком-либо участке, поступает в СУБД из системы АПВО службы пути и содержит тип контролируемого объекта, идентификатор блок-участка, данные о состоянии объекта и организации-инициаторе, полный текст предупреждения и т.д. 242 Информация о срабатывании средств контроля подвижного состава поступает в СУБД из системы АСК ПС вагонной службы; данные о состоянии объектов электроснабжения – через машину обмена со смежными системами (формат передачи информации включает в себя тип и состояние контролируемого объекта, идентификаторы блок-участка и отключенной секции, время события, сведения о продолжительности аварии или времени планового отключения). Программное обеспечение условно разделено на три модуля: клиентский модуль, сервер приложений и модуль отображения на табло коллективного пользования. Клиентский модуль предоставляет информацию в виде, удобном для восприятия и работы пользователя, генерирует запросы к модулю подключения на основе операций пользователя или по таймеру. Общесистемный модуль включает администрирование, функции, наработку тематических таблиц, синхронизацию данных, получение данных из АРМ ДНЦ (сердцевина системы). Модуль, реализующий отображение перевозочного процесса на табло коллективного пользования, включает два подраздела. Первый подраздел отображает состояние блокучастков, светофоров и т.д. (оперативное отображение для поездных диспетчеров) и второй подраздел, который отображает основные показатели работы дороги (прием, сдача, погрузка, выгрузка и т.д.). Табло коллективного пользования, которое установлено в специализированном диспетчерском зале Центра, является важнейшим элементом в системе «Автодиспетчер». Для реализации новых технологий управления скоростным движением необходимо обеспечить сигнальное отображение информации о пропуске поездов и состоянии инфраструктуры направления Москва – Санкт-Петербург. Система работает в режиме активного контроля и все отклонения от нормы показывает цветом (цветовая гамма меняется в зависимости от степени тяжести ситуации). Цель диспетчеров – не доводить ситуацию до темно-красного цвета. Частота обновления ситуации на табло составляет пять секунд. Экономический эффект от внедрения Автоматизированной интеллектуальной системы диспетчерского управления движением поездов на скоростном направлении «Москва – Санкт-Петербург достигается за счет: а) автоматизации процесса диспетчерского управления (сокращение диспетчерского персонала на 32 чел.), экономия составит – 25 млн. руб. в год; б) экономии электроэнергии составит – 41 млн. руб.; 243 в) сокращения голосовых переговоров в 7–10 раз, улучшения условий труда машинистов и диспетчерского аппарата без снижения уровня безопасности. Система предусматривает дальнейшее развитие, совершенствование и должна быть тиражирована на направлении Москва – Нижний Новгород – Москва – Адлер. В 2010 году на опытном полигоне Электросталь — Ногинск Московской железной дороги успешно завершена проверка нового алгоритма работы системы интервального регулирования с подвижными участками без проходных светофоров. В настоящее время ведется усовершенствование данной системы, связанное с расширением ее функциональных возможностей и отказоустойчивости. По результатам эксплуатации системы "Автодиспетчер" получены положительные результаты: при обеспечении энергооптимальных режимов обеспечивается гарантированный график движения скоростных поездов. Информация о системе «Автодиспетчер» содержится также в публикациях [15,16]. Замечания. На участке Петербург — Москва Октябрьской железной дороги реализована технология автоматизированного управления поездной работой на участках скоростного и высокоскоростного движения "Автодиспетчер". При помощи нее осуществляется автоматическое ведение поезда по графику, выбор графиков торможения, определение местоположения локомотивов по маршруту следования, задание точных координат остановки, автоматический контроль движения и технического состояния локомотивов, исключение необоснованных экстренных торможений, выполнение временных ограничений скорости движения и др. Особенность данной технологии состоит в регулировании не одиночных, а потоков поездов при условии диспетчерского управления из единого центра всеми технологическими процессами и взаимодействие с подвижными единицами посредством цифровой радиосвязи TETRA с применением системы спутниковой навигации ГЛОНАСС/GPS. Таким образом, основой технологии, реализованной в системе «Автодиспетчер», является централизованное интеллектуальное управление движением поездов. Основополагающим отличием предлагаемой технологии адаптивного планирования и динамического управления расписанием поездов на основе сетецентрического подхода и интеграционной программной платформы комплексной автоматизации планирования ресурсов РЖД с использованием мультиагентных технологий и онтологий, средств GPS-навигации и GPRS от технологии, реализованной в системе «Автодиспетчер», является то, что в рамках сетецентрического подхода система управления движением поездов должна изначально строиться как распределенная, открытая для наращивания и состоящая из автономных, но согласованно и координировано действующих интеллектуальных систем отдельных станций, которые в случае выявления непредвиденных событий, отклонений от расписания, конфлик244 тов по ресурсам должны выполнять согласованные изменения планов путем проведения переговоров, действуя при этом под контролем диспетчерских. 1.10.2 Система безопасности, мониторинга и диспетчерского управления движением поездов с использованием систем ГЛОНАСС/GPS, разработанная МКБ «Компас» Работы по созданию и внедрению системы "Красная стрела" выполняются с 2007 года в рамках Федеральной целевой программы "Глобальная навигационная система" в интересах железнодорожного транспорта [17]. Система "Красная стрела" позволяет в режиме реального времени обеспечивать смежные системы управления на железнодорожном транспорте информацией о номере пути следования, местоположении, скорости и направлении движения локомотива. Система состоит из двух основных частей: бортовая аппаратура и постовая аппаратура. Блок бортовой аппаратуры построен на основе операционной системы реального времени QNX Neutrino и вычислительного модуля Fastwel CPC304, выполненного в форм-факторе PC/104. Информация от локомотива передается по радиоканалу сотовой GSM-связи на три базовые GPS/ГЛОНАСС приемника, установленные на железнодорожной станции. Блок постовой аппаратуры включает: приемники GPS/ГЛОНАСС, расчетный сервер и рабочее место диспетчера. Местоположение локомотива определяется на расчетном сервере на основании данных от локомотива и трех базовых GPS/ГЛОНАСС-приемников и отображается на рабочем месте диспетчера. Данные от базовых приемников передаются по Ethernet, что позволяет использовать существующие линии связи. Для обеспечения точности и оперативности предоставления и обработки данных их передача и расчет местоположения сразу для нескольких локомотивов должны производиться в режиме реального времени, поэтому сервер работает под управлением операционной системы QNX Neutrino. QNX Neutrino позволяет обеспечить высокий уровень надежности. Четкие уровни приоритетов задач и дисциплина их планирования обеспечивают многопоточную обработку данных с заранее определенной циклограммой работы. Микроядерная архитектура операционной системы гарантирует высокую производительность. Данные о местоположении и скорости перемещения локомотивов отображаются на рабочем месте диспетчера. Также ведется архив в базе данных, по которому может быть показано движение локомотивов в заданный момент времени, а также проведены расчеты по интегральным показателям использования локомотивов: пройденный путь за определенный интервал времени, время стоянок и моточасов в пределах станции и на смежных предприятиях. 245 Система "Красная стрела" внедрена на Красноярском транспортном узле. По результатам предварительных испытаний подтверждены: точность определения местоположения локомотива с СКО 1 м; точность построения цифровых моделей путевого развития с СКО 0,3 м. Задержка в получении информации о местоположении не превышает 2 секунд. В настоящее время ведутся работы по установке на локомотивах датчиков измерения уровня и расхода топлива. Информация, получаемая с помощью системы "Красная стрела", может быть использована для контроля перемещений локомотивов, вагонов, поездов, сопровождения грузов, для построения систем оповещения о приближении поездов к переездам. Система "Красная стрела" позволяет значительно (до 60%) сократить ручной ввод информации в информационно-управляющие системы, а также повысить оперативность передачи информации о перемещениях локомотивов и вагонов. За счет автоматического получения указанной информации появляется возможность повысить скорость подачи/уборки вагонов на погрузку и выгрузку, оптимизировать работу локомотивов и железнодорожных станций, повысить эффективность их использования и снизить эксплуатационные расходы. Замечания. Система «Красная стрела» представляет собой программно-аппаратный комплекс, предназначенный для сбора информации о местоположении и скорости перемещения локомотивов, который используется для контроля перемещений локомотивов, вагонов, поездов. Информация, предоставляемая данной системой, может быть использована для более эффективного планирования расписания движения поездов, но, в целом, данная система для планирования не предназначена. 1.10.3 Программный комплекс компании Siemens для автоматизации диспетчерского управления на железнодорожном транспорте Компания Siemens разработала программный комплекс, обеспечивающий оптимизацию в реальном масштабе времени расписаний движения поездов [18]. При этом преследовалась цель минимизировать задержки поездов при возникновении сбоев в перевозочном процессе в условиях ограниченной пропускной способности инфраструктуры, в частности на однопутных линиях с двухпутными вставками для скрещения и обгона поездов. Компания Siemens предложила новый подход к автоматизации диспетчерского управления движением поездов, разработав программный комплекс, который в реальном времени непрерывно сравнивает фактические данные о движении поездов с плановым графиком и при отклонениях от него вносит поправки в онлайн-расписание. Основная цель корректировки расписания — сокращение опозданий поездов в связи с эксплуатационными ограничениями. Моделирование движения поездов на высокозагруженном участке продемонстрировало 246 эффективность применения методов дискретной оптимизации. В разработанной системе применяется новый метод оптимизации автоматического диспетчерского управления движением поездов. Для обеспечения оптимального результата поправки вносятся не локально, а создается полностью новый график движения. Кроме того, в рамках системы рассматривается не только изменение времени отправления (как в стандартных модулях управления движением поездов), но также альтернативные маршруты и изменение порядка следования поездов. Для работы в реальном времени (т. е. обеспечения быстроты расчетов) используются сложные модели и алгоритмы дискретной оптимизации. Предлагаемая система управления движением поездов состоит из следующих компонентов: База данных по графикам предназначена для хранения нормативных, оперативных и исполненных графиков диспетчерской системы. Программа управления графиком формирует оперативный график, включая в него полученные от программы слежения за поездами данные об их текущем местоположении. Расчет прогнозируемого движения для одного или нескольких поездов производится на основе данных о фактическом движении и существующих ограничениях (например, ограничениях скорости или занятости путей). Существенные отклонения фактического движения от заданного могут привести к нестыковкам в прогнозируемом графике: одновременному подходу встречных поездов к однопутному участку и т. п. Программа управления графиком автоматически выявляет подобные конфликты и самостоятельно запускает их разрешение компонентами автоматического диспетчера. Сформированный оперативный график передается в систему управления для автоматической установки поездных маршрутов. Автоматический диспетчер является основным механизмом регулирования конфликтов, возникающих в оперативном графике. Кроме того, для общей оптимизации движения поездов периодически может выполняться полная смена графика. Основной целью процедуры оптимизации является сокращение опозданий поездов (увеличение пропускной способности), вызванных эксплуатационными ограничениями. Результаты оптимизации, произведенной автоматическим диспетчером, вносятся в оперативный график программой управления графиком. Также автоматический диспетчер отвечает за обработку команд, вводимых вручную оператором через графический интерфейс графика движения. Графический интерфейс пользователя отображает графики разных типов и позволяет оператору вносить изменения в график-прогноз. Главным окном является интерфейс диспетчерского графика, в котором движение поездов по ниткам отображается как функция времени. Пользователь может работать непосредственно в самом окне, создавая, выбирая, изменяя или удаляя объекты графика (отдельные нитки, маршруты, остановки, скрещения и т. д.). Для работы программного комплекса необходима актуальная информация о местоположении 247 поезда и основных параметрах подвижного состава и пути, которая может поступать в диспетчерскую систему как от локомотивных, так и от напольных устройств. Кроме того, при планировании работ на путях или в других особых случаях она может вноситься в систему диспетчером. После проведения расчетов и корректировки либо формирования нового графика движения предусматривается воздействие автодиспетчера на системы установки маршрутов для обеспечения нагона одних или снижения скорости движения других поездов. Нагон поезда может, например, достигаться пропуском его по маршрутам с наименьшими скоростными ограничениями, а также сокращением запланированного времени остановок на промежуточных пунктах. Для своевременного снижения скорости проследования поезда с целью пропуска опаздывающего может предусматриваться, например, передача маршрута следования по главному пути двухпутной вставки встречному поезду, а также установка маршрутов за меньшее число блок-участков перед поездом, либо включение менее разрешающего сигнального показания. Выбор вариантов воздействия определяется применяемыми системами ЖАТ, а также установленными на железных дорогах правилами организации движения поездов. Разработанный комплекс автоматизации диспетчерского управления движением поездов основан на глобальной оптимизации графика движения в сочетании с применением моделей и алгоритмов теории графов. Он позволяет существенно сократить опоздания поездов по сравнению с ручным диспетчерским управлением при возникновении технических сбоев, что подтверждено моделированием близких к действительности сценариев для реальных железнодорожных линий. При этом можно ожидать также снижения энергозатрат благодаря исключению дополнительных остановок и троганий с места, вызванных задержками других поездов. Замечания. Программный комплекс компании Siemens для автоматизации диспетчерского управления на железнодорожном транспорте выполняет в реальном времени перепланирование онлайн-расписания движения поездов в случае расхождения фактических данных о местоположении поезда с плановым графиком. Данная система реализует не только изменение времени отправления поезда, но также нагон поезда, альтернативные маршруты, изменение порядка следования поездов. Однако применяемые в данной системе методы существенно отличаются от сетецентрического подхода, основанного на применении мультиагентных технологий и онтологий, разрабатываемых по контракту: а) в программном комплексе компании Siemens используются методы дискретной оптимизации; б) при возникновении отклонения графика движения поезда от плана, в расписание не вносятся локальные изменения, а создается полностью новый график движения. 248 1.10.4 Системы управления движением поездов в США Системы PTC [19] относятся к технологиям, которые предотвращают столкновения поездов, сход подвижного состава с рельсов из-за превышения скорости, травматизм занятых в ремонтных работах на пути, проследование стрелочных переводов по неправильному пути. Сложность этих систем зависит от заданной степени автоматизации и функциональности. Применительно к условиям использования на грузовых железных дорогах первого класса система PTC должна давать машинисту разрешения на движение, основанные на информации о местонахождении поезда. Бортовое оборудование контролирует выполнение этих команд, предотвращая возникновение опасных ситуаций. PTC могут работать поверх существующих систем обеспечения безопасности на осигнализированных или неосигнализированных участках, используя специальные технические средства. В число задач системы управления входит также развертывание общенациональной дифференцированной глобальной спутниковой навигационной системы (NDGPS) как единой системы непрерывного и точного позиционирования, пригодной для управления движением поездов. Для PTC предложены и реализованы различные архитектуры: от крупных и сложных централизованных систем до прикладных, необходимых только для совершенствования существующих методов эксплуатационной деятельности, например с устной передачей поездных приказов. Большая часть таких систем сфокусирована на передаче и обеспечении исполнения поездных приказов, отдаваемых диспетчером или передаваемых из компьютеризированных центров управления, а не на том, как можно использовать существующие принципы сигнализации для повышения уровня безопасности и эффективности. В настоящее время на разных этапах реализации находится 11 проектов различных систем PTC, которыми заняты девять железных дорог на территории 16 штатов. Общая протяженность опытных участков превышает 6400 км. Все системы решают следующие задачи: а) предотвращение столкновений поездов; б) соблюдение постоянных и временных ограничений скорости; в) обеспечение безопасности путевых работ. Замечания. Система управления движением поездов в США реализует технологии слежения (в том числе, с использованием глобальной спутниковой навигационной системы) за перемещением поездов в целях предотвращения аварийных ситуаций. Информация, предоставляемая единой системой непрерывного и точного позиционирования поездов, может быть использована для управления движением поездов, но непосредственно для планирования данная система не предназначена. 249 1.10.5 Европейские исследования в области интеллектуального управления на железной дороге: проект InteGrail Информационные технологии и технологии связи (ICT) уже привнесли важные инновации в работу сетей железных дорог в терминах повышенной безопасности (системы сигнализации типа ERTMS), поддержки эксплуатации дорог (системы управления и контроля) и оказания услуг клиентам (информация для пассажиров, электронная покупка билетов и так далее). Они были и будут важны в преобразовании железных дорог в интеллектуальные системы перевозок, следуя основным принципам, заявленным в соответствии с новой Директивой по функциональной совместимости железных дорог в рамках ЕС. Область, где усовершенствования необходимы и могут быть достигнуты, используя решения технологий ICT, связана с обслуживанием подвижного состава и контролем его состояния. Основная цель состоит в том, чтобы минимизировать вероятность критических ошибок во время движения поездов с серьезными последствиями, в терминах качества обслуживания и дополнительных затрат, и в то же время поддерживая затраты на техобслуживание настолько низко, насколько это возможно, чтобы уменьшить расходы жизненного цикла и улучшить рентабельность инвестиций. Известен ряд европейских проектов, направленных на улучшение диагностических систем, чтобы лучше поддерживать процессы техобслуживания. Для представления диагностических данных в них используются семантические дескрипторы. Разработки ICT (информационные технологии и технологии связи), основанные на онтологии, в настоящее время используются на борту транспортных средств. Системный подход на базе онтологии на железных дорогах имеет немного примеров. Самый важный пример представлен в проекте InteGRail (интеллектуальная интеграция железнодорожных систем) [20,21], который определил архитектуру коллективного использования информации, на основе онтологии и архитектуры SOA. Данный подход может эффективно и широко применяться в железнодорожных системах для подвижного состава, инфраструктуры, для управления поездом и движением поездов в целях повышения эффективности работы всей железной дороги. Проект InteGRail определил новую парадигму, основанную на комбинации инновационных технологий, которые вместе могут создать решение, реализуемое во встроенной системе. Основной элемент новой парадигмы состоит в том, что необходимо сотрудничество и информационный обмен между подсистемами. Ключевой технологией для обеспечения широкого обмен информации между подсистемами является подход SOA. Системы, основанные на SOA, используют технологию Web-сервисов, реализованных в WSDL (язык описания Web-сервисов), который обеспечивает стандартное средство взаимодействия между различными приложениями программного обеспечения при работе на разных платформах. 250 Второй существенный элемент парадигмы состоит в базировании процесса диагностики на абстрактной поведенческой модели подсистемы, которая в состоянии ввести важные понятия, формирующие основу функциональных возможностей подсистемы, удаляя детали отдельного продукта. Недавние разработки в хранении семантики и использовании информации и ее контекста привели к созданию методов моделирования, которые используют онтологию для моделирования технических систем. Онтология хранит отношения между физическими компонентами в системе, а также более абстрактные понятия о компонентах и их условиях. Ключевая выгода по сравнению с простыми базами данных состоит в том, что может иметь место обоснование логического вывода о последствиях определенных действий или изменений в онтологии. В обнаружении неисправности и диагностике это обоснование является ключевой способностью, которая позволяет идентифицировать причины и последствия неисправностей, даже при том, что они не были предсказаны априорно. Важный аспект моделирования на основе онтологии - его способность включить в модель текущий диагностический опыт, полученный от экспертов и от диагностической системы непосредственно, обеспечивая усовершенствование диагностической работы и повторяемость используемых методов для всего парка или для всей системы. Третий элемент парадигмы - прямое следствие первых двух: распределенное основание вынесенного решения. Распределенная природа подсистем на борту поездов, в железнодорожной сети и хранилища информации в железнодорожной системе требует обширной и полной обработки информации, чтобы определить местонахождение информации и получить доступ к полезной информации везде, где это возможно. Некоторые предложения по европейским научно-исследовательским работам были уже представлены или находятся в процессе подготовки в рамках седьмой Программы. Отобранные предложения могут стать группой многих небольших проектов, которые могут действовать в качестве моста между обширными результатами, порожденными огромным проектом InteGRail и конкретным развертыванием систем, сосредоточенных на отдельных достижениях и развивающихся продуктах. Замечания. Проект InteGRail реализует онтологический подход к описанию инфраструктуры, подвижного состава, поездов, а также новую парадигму, основанную на комбинации инновационных технологий, включающую следующие аспекты: а) сотрудничество и информационный обмен между подсистемами; б) использование абстрактной поведенческой модели подсистем, основанной на онтологии, которая хранит отношения между физическими компонентами подсистемы и правила взаимодействия подсистем, что позволяет диагностировать неисправно- 251 сти в подсистемах, являющиеся следствием определенных действий, на основании правил логического вывода, заданных в онтологии; в) распределенное принятие решений. Разрабатываемая по контракту система также использует онтологический подход и распределенное принятие решений для описания управления движением поездов, но, в отличие от проекта InteGRail, реализует логику агентов активных сущностей инфраструктуры, подвижного состава и персонала железной дороги для разработки полного цикла реакции на события, планирования и исполнения планов в реальном времени в рамках метода согласованного адаптивного управления расписанием. 1.10.6 Децентрализованный подход к контролю инфраструктуры железных дорог, основанный на онтологии Задачи, поставленные советом ERRAC (Европейским консультативным советом по железнодорожным исследованиям и разработкам) для европейской железнодорожной инфраструктуры в 2020 году, включают в себя удвоение относительной доли на рынке грузовых / пассажирских перевозок и утроение объема абсолютных грузовых / пассажирских перевозок. Эта задача требует оптимизации эксплуатации инфраструктуры и снова полагается на наличие современной и качественной информация о текущем состоянии инфраструктуры, что является основой для принятия информированных решений. Данный подход предлагает модель информационной системы на основе онтологии и децентрализованной архитектуры системы [22]. Его особый вклад имеет три направления: а) применение описания представления знаний на основе логики и обоснование мониторинга инфраструктуры; б) идентификация необходимых функциональных слоев для реализации этой идеи; в) проект структуры для ответа на запрос через описание распределенных логически основанных данных. На основе этого анализа предлагаем принять формальные методы представления знаний для информационного моделирования (моделирования информации) в системах мониторинга инфраструктуры. Представление знаний и логические суждения (KRR) является активной областью исследований в сфере искусственного интеллекта (ИИ). По своей сути, эта область связана с определением разумных компромиссов между выразительностью представления и сложностью рассуждений. В качестве формализма KRR для предметной области описания железнодорожной инфраструктуры выбрана описательная логика DL. Функциональная архитектура системы является децентрализованной на основе онтологии. Функциональная архитектура представляет слои или уровни таким образом, что каж252 дый слой зависит только от следующего нижнего слоя и определяет интерфейсы для каждого слоя. Таким образом, достигается высокая степень гибкости, так как слои могут быть заменены без ущерба для общей архитектуры. Децентрализованная архитектура облегчает повторное использование компонентов в рамках того же самого слоя благодаря однородным интерфейсам. Текущая реализация прототипа включает в себя службу логического суждения, которая подвергается обработке (например, запросы к базе знаний) несколько раз, и службу каталогов. Служба логического суждения обеспечивает HTTP-интерфейс для приема внешних запросов на языке SPARQL и возвращает ответы в форме RDF документа. Служба каталогов, использует Jena Semantic Web Framework и предоставляет интерфейс HTTP для управления запросами в соответствующей службе логического рассуждения. Таким образом, рассмотренный децентрализованный подход включает описание инфраструктуры на основе онтологий и слоистую функциональную архитектуру системы. Замечания. Проект Европейского консультативного совета по железнодорожным исследованиям и разработкам (ERRAC) для европейской железнодорожной инфраструктуры до 2020 г. предлагает модель информационной системы для описания инфраструктуры железной дороги, основанную на использовании онтологии и децентрализованной архитектуры системы. Эта перспективная разработка, предназначенная для оптимизации режима эксплуатации инфраструктуры, может быть полезна для получения информации об особенностях инфраструктуры конкретного направления для диспетчерского управления движением поездов, и может рассматриваться как одна из подсистем информационного обеспечения системы планирования и исполнения планов в реальном времени. 1.11 Результаты исследования непатентных источников По результатам исследования непатентных источников можно сделать вывод о том, что в то время как внушительный технологический прогресс железных дорог очевиден, основной акцент делается на совершенствование системы управления железной дорогой и повышение ее эффективности, чтобы существенно повысить конкурентоспособность и производительность обычных поездов и современных высокоскоростных поездов. Проведенный анализ имеющихся на рынке в России и во всем мире систем и долгосрочных проектов развития железных дорог показал, что современная тенденция развития и совершенствования управления движением поездов состоит в инновационном подходе, который включает разработку интеллектуальных систем, использующих передовые информационные технологии. Среди таких передовых технологий можно отметить следующие: 253 а) применение онтологий для формализованного представления знаний об инфраструктуре и ресурсах железной дороги; б) разработка распределенной архитектуры систем поддержки принятия решений для управлении железнодорожными перевозками; в) автоматизация диспетчерского управления. Основная цель состоит в том, чтобы минимизировать вероятность критических ошибок во время движения поезда с серьезными последствиями, повысить качество обслуживания и рентабельность железнодорожных перевозок. 1.12 Выводы В соответствии с техническим заданием по этапу №1 НИР было проведено патентное исследование и исследование непатентных источников в следующих областях: а) контроль и управление процессами, связанными с планированием ресурсов; б) методы составления расписания; в) разработка моделей индивидуального планирования ключевых ресурсов инфраструктуры РЖД. Релевантные патенты были найдены в базах данных следующих организаций: Бюро по патентам и товарным знакам США, Европейского патентного бюро Всемирной организации интеллектуальной собственности. На основании изучения непатентных источников был выделен ряд систем диспетчерского управления, которые реализуют функции по составлению расписания и перепланированию движения поездов в случае отклонения от графика: а) автоматизированная интеллектуальная система диспетчерского управления движением поездов на скоростном направлении «Москва – Санкт-Петербург; б) программный комплекс компании Siemens для автоматизации диспетчерского управления на железнодорожном транспорте; в) проект InteGrail, представляющий европейские исследования в области интеллектуального управления на железной дороге; г) проект Европейского консультативного совета по железнодорожным исследованиям и разработкам (ERRAC) для европейской железнодорожной инфраструктуры до 2020 г. По результатам анализа патентных и непатентных источников, а также изучения функциональности приведенных выше систем можно сделать следующие выводы: а) разрабатываемая по контракту интеллектуальная система для согласованного адаптивного планирования движения поездов решает актуальную задачу для мировой 254 практики управления железнодорожным пассажирским движением и, в частности, высокоскоростных пассажирских перевозок; б) интеллектуальная система для согласованного адаптивного планирования движения поездов соответствует мировому уровню разработок в данной области; в) в разделах МПК и среди непатентных источников не найдено патентов и систем, препятствующих разработке по контракту; г) системы, в определенной степени релевантные разрабатываемой по контракту и предназначенные для выполнения соответствующих функций, реализуют централизованные принципы управления, алгоритмы планирования и составления расписаний, основанные на классических принципах; д) среди рассмотренных систем не обнаружены системы, которые бы использовали сетецентрическую программную платформу и мультиагентные технологии для управления производственными процессами железной дороги. 255 ЗАКЛЮЧЕНИЕ Таким образом, после проведения анализа существующих патентов, систем диспетчерского управления и составления расписания движения поездов, был сделан вывод, что на данный момент нет полных аналогов предлагаемой мультиагентной технологии адаптивного планирования и связанного изменения планов движения поездов, построенных с применением онтологий и сетецентрического подхода. Кроме того, тенденции имеющихся на рынке разработок подтверждают правильность выбранного направления, поскольку демонстрируют появление новых более интеллектуальных возможностей согласованного управления всей железнодорожной инфраструктурой. Среди имеющихся на рынке систем управления движением поездов следует выделить, прежде всего, систему «Автодиспетчер», позволяющую осуществлять управление движением поездов на базе оперативного суточного графика, осуществлять диспетчерский мониторинг, регулировку движения в соответствии с заданной программой, автоматическую подготовку маршрутов и принятие управляющих решений при возникновении конфликтных ситуаций (см. пункт 1.10.1). Также следует выделить европейский проект InteGrail (см. пункт 1.10.5), основанный на использовании интеллектуальной системы управления для подвижного состава, инфраструктуры, для управления поездом и движением поездов в целях повышения эффективности работы всей железной дороги. Следует отметить новый подход компании Siemens к автоматизации диспетчерского управления движением поездов в рамках программного комплекса, который в реальном времени непрерывно сравнивает фактические данные о движении поездов с плановым графиком и при отклонениях от него вносит поправки в онлайн-расписание (см. пункт 1.10.3). Необходимо отметить также перспективные разработки компании Siemens в области использования онтологий для описания технических и эксплуатационных характеристик, а также извлечения знаний для управления железнодорожной инфраструктурой (см. пункт 1.10.6) Можно утверждать, что на данном этапе исследования рассмотренные системы являются ближайшими аналогами мультиагентной системы адаптивного управления и связанного изменения планов движения поездов. Во всех этих системах с очевидностью проявляется тенденция интеллектуализации управления всеми аспектами железнодорожных перевозок. Опыт разработки рассмотренных систем безусловно станет важным основанием для проведения настоящей разработки. Вместе с тем, можно отметить, что прямых аналогов разрабатываемой технологии и программного продукта среди всех рассмотренных готовых к использованию программных решений не обнаружилось. Ни одна из рассмотренных систем не использует мультиагентные 256 технологии и сетецентрическую программную платформу для создания единой информационной среды, обеспечивающей автоматизацию выполнения и контроля сквозных производственных процессов железной дороги и высокую адаптивность к реализации перспективных задач в условиях динамически изменяющейся внешней среды. 257 СПИСОК ИСПОЛЬЗУЕМЫХ ИСТОЧНИКОВ 1) ГОСТ Р 15.011-96 «Система разработки и постановки продукции на производство. Патентные исследования». 2) Патентный закон Российской Федерации [Электронный ресурс] / . – Электрон. журн. – М.: Патентный закон Российской Федерации. – Режим доступа: http://nalog.consultant.ru/doc58232.html, свободный. – Загл. с экрана. – Яз. рус. 3) Транспортная стратегия Российской Федерации на период до 2030 года [Электронный ресурс] / . – Электрон. каталог.– Режим доступа: http://rosavtodor.ru/information/Osnovnye_dokumenty/transportnaya_strategiya_rf_na_p eriod__do_2030_goda.html , свободный. – Загл. с экрана. – Яз. рус., англ. 4) Белая книга ОАО «РЖД». – 2010. 5) G.Rzevski. Multi-Agent Technology: An Introduction // Lecture notes, 2006. 6) V. Andreev, A. Glashchenko, A. Ivashchenko, S. Inozemtsev, G. Rzevski, P. Skobelev, P. Shveykin Magenta Multi-Agent Systems for Dynamic Scheduling - First International Conference on Agents and Artificial Intelligence (ICAART 2009). - Portugal, January 2009. 7) M. Andreev, A. Ivaschenko, P. Skobelev, A. Tsarev Multi-Agent Platform Design for Adaptive Networks of Intelligent Production Schedulers. 10-th International IFAC Workshop on Intelligent Manufacturing Systems, Lisbon, Portugal, 2010. 8) Скобелев П.О.. Мультиагентные технологии в промышленных применениях: к 20летию основания Самарской научной школы мультиагентных систем. Мехатроника, автоматизация, управление (МАУ) – 2010, №12. 9) А.В. Иващенко, О.В. Карсаев, П.О. Скобелев, А.В. Царев, Р.М. Юсупов. Мультиагентные технологии для разработки сетецентрических систем управления. – Известия ЮФУ. Технические науки, ISSN 1999-9429, №3 (116), 2011, стр. 11-23. 10) US Patent №11/591521 – Method of planning the movement of trains using preallocation of resources, Method of planning the movement of trains using pre-allocation of resources 11) Патент № RU 2008147837 (A) – METHOD TO OPTIMISE TRAIN TRAFFIC ON SINGLE LINE , RU 2008147837 (A) - METHOD TO OPTIMISE TRAIN TRAFFIC ON SINGLE LINE 12) US Patent №2011035083 (A1) – System and Method for the Automatic Generation of Movement Authority Solutions in a Rail System, US 2011035083 (A1) - System and Method for the Automatic Generation of Movement Authority Solutions in a Rail System 258 13) Patent № PA/a/2002/006558 – A TRAIN CORRIDOR SCHEDULING PROCESS INCLUDING VARIOUS COST FUNCTIONS ASSOCIATED WITH RAILWAY OPERATIONS, A TRAIN CORRIDOR SCHEDULING PROCESS INCLUDING VARIOUS COST FUNCTIONS ASSOCIATED WITH RAILWAY OPERATIONS 14) Автоматизированная интеллектуальная система диспетчерского управления движением поездов на скоростном направлении «Москва – Санкт-Петербург [Электронный ресурс] / . – Электрон. журн. – М.: Евразия Вести VII 2009. – Режим доступа: http://www.eav.ru/publ1.php?publid=2009-07a09, свободный. – Загл. с экрана. – Яз. рус. 15) В.А. Гапанович. Управление линией Москва - Санкт-Петербург при организации высокоскоростного движения [Электронный ресурс] / В.А. Гапанович. – Электрон. журн. – Режим доступа: http://www.loglink.ru/massmedia/analytics/record/?id=451, свободный. – Загл. с экрана. – Яз. рус. 16) Лябах Н. Интеллектуальные технологии на транспорте: сущность и развитие, [Электронный ресурс] / Лябах Н.Н. – Электрон. журн. – Режим доступа: http://scbist.com/zh-d-stati/7760-statya-intellektualnye-tehnologii-na-transportesuschnost-i-razvitie.html, свободный. – Загл. с экрана. – Яз. рус. 17) Система безопасности, мониторинга и диспетчерского управления движением поездов с использованием систем ГЛОНАСС/GPS, разработанная МКБ «Компас», [Электронный ресурс] / Лябах Н.Н. – Электрон. журн. – Режим доступа: http://mkbkompas.ru/index.php?mact=News,cntnt01,detail,0&cntnt01articleid=23&cntnt01returnid =56, свободный. – Загл. с экрана. – Яз. рус. 18) С. Протцнер (S. Protzner). Автоматизация диспетчерского управления как средство повышения пропускной способности железных дорог. [Электронный ресурс] / С. Протцнер (S. Protzner), С. В. Власенко, К.Х. Эрхард (K.H. Erhard), Й. Шмидтке (Y. Schmidtke). – Железные дороги мира, 2010, №9, с.36-39, Режим доступа: https://869789182725854870-a-zdmira-com-ssites.googlegroups.com/a/zdmira.com/www/archive-files/_dm2010-09_3639.pdf?attachauth=ANoY7cpX7DKnbgQpQ44iFrnRbwTA1_ohblsjxLaK3ymP2MIx7L3 OX9ZU2UoawFqv1coWtW7vpa5p5xOugZ3WETyZDQQxh4w8wjwQT6qSqdO2Jctual_ ikUt9Ye7xtd79OjyF34WSIqxm8FKGsB3xSAp73q7mUiSTqz8jjMp9DNWXhMBJZblz8 5x1JLnXXDa-bs0tFBHaV_Z_eclTaIVnVtjBgiMlVzqkGg%3D%3D&attredirects=0, свободный. – Загл. с экрана. – Яз. рус. 19) W. Vantuono. Системы управления движением поездов в США, [Электронный ресурс] / W. Vantuono. – International Railway Journal, 2009, № 10, p. 32 – 34, 36 – 259 Электрон. журн. – Режим доступа: https://869789182725854870-a-zdmira-com-ssites.googlegroups.com/a/zdmira.com/www/archive-files/_dm2010-09_4043.pdf?attachauth=ANoY7cqCdyP9iIdDyzCwQZuJ7QifdHNFPRpP2NKsatdfiNywGOg0icH8ymkxYMM0UQzfqYYJ0fXQ6BOwFiODf0faoJ_JCE0NEK zekG9CjbzvMUfwuPEs15WOleg9UaQdnSYBJd6fWTBPRj9L6ZFmBTWN896TBHevJBAiF7 h41a1UQg3sCk8SQ-uYZw3FPHlRqw9btfnkwP-Jvqpa7UC4N07v8LGBSExg%3D%3D&attredirects=0, свободный. – Загл. с экрана. – Яз. рус. 20) Michele Bernocchi, Emilio Miguelanez - “The contribution of European Research to more intelligent Railway Maintenance: the InteGRail project” - Euromaintenance 2010 International Congress - Verona Fiere - 14th May 2010. 21) Паоло Умильакки, Дэвид Лэйн, Феличе Романо. Прогнозируемое техническое обслуживание железнодорожных подсистем с использованием подхода моделирования на основе онтологии. – 9-ая всемирная конференция по исследованию железных дорог, 22-26 мая 2011. - Лилль, Франция. 22) Флориан Фукс, Михаил Бергер. Децентрализованный, основанный на онтологии подход к контролю инфраструктуры. - Siemens AG, Corporate Technology. 260 ПРИЛОЖЕНИЕ 1.1 (обязательное к отчету о патентных исследованиях) ФОРМА ЗАДАНИЯ НА ПРОВЕДЕНИЕ ПАТЕНТНЫХ ИССЛЕДОВАНИЙ УТВЕРЖДАЮ Руководитель работ, Директор по разработкам ООО "НПК "Разумные решения" П.О. Скобелев ЗАДАНИЕ № 2011.10.17-01 на проведение патентных исследований Наименование работы (темы): Разработка и исследование прототипа интеллектуальной системы для согласованного адаптивного планирования и связанного изменения планов движения поездов для минимизации отклонения высокоскоростных поездов класса “Сапсан” от графика движения под влиянием непредвиденных внешних событий в рамках исполнения ГК от «17» октября 2011 г. №07.514.11.4094 Шифр работы (темы): 2011-1.4-514-125-063. Этап работы №1 (промежуточный): Выбор направления исследований. Теоретические исследования поставленных перед НИР задач. Сроки выполнения: 17.10.2011-02.11.2011. Задачи патентных исследований: определение уровня развития техники и патентоспособности разрабатываемой технологии, получение сведений об охранных и иных документах, которые могут препятствовать применению этих результатов на территории Российской Федерации. КАЛЕНДАРНЫЙ ПЛАН Виды патентных ис- Подразделенияследований исполнители Ответственные исполнители Определение уровня развития техники и патентоспособности Симонова Е.В. Генеральный директор ООО "НПК "Разумные решения" Руководитель патентного подразделения, ведущий аналитик ООО "НПК "Разумные решения" 261 Сроки выполнения патентных исследований 17.10.201102.11.2011 Отчётные документы Отчёт о патентных исследованиях А.В. Царев 2.11.2011 А.Р. Диязитдинова 2.11.2011 ПРИЛОЖЕНИЕ 1.2 (обязательное к отчету о патентных исследованиях) ФОРМА РЕГЛАМЕНТА ПОИСКА РЕГЛАМЕНТ поиска № 2011.10.17-02 17 октября 2011 г. 1 Контроль и 2 Рос- 262 Классификационные индексы Ретроспективность Код товара: ГС*, СМТК*, БТН* Наименование Наименование Рубрики УДК* и другие Стра на поиска Источники информации, по которым будет проводиться поиск патентные НТИ* конъ- другие юнкгурные Наименование Классификационные рубрики: МПК (МКИ)*, МКПО*, НКИ* и другие 3 4 5 6 7 8 9 10 База данных Феде- B61L - - Наименование Предмет поиска (объект исследования, его составные части, товар) 11 20 Наименование информационной базы (фонда) Наименование работы (темы): Разработка и исследование прототипа интеллектуальной системы для согласованного адаптивного планирования и связанного изменения планов движения поездов для минимизации отклонения высокоскоростных поездов класса “Сапсан” от графика движения под влиянием непредвиденных внешних событий в рамках исполнения ГК от «17» октября 2011 г. №07.514.11.4094 Шифр работы (темы): 2011-1.4-514-125-063. Этап работы №1 (промежуточный): Выбор направления исследований. Теоретические исследования поставленных перед НИР задач. Номер и дата утверждения задания: 2011.10.17-01 – 18.10.2011 Цель поиска информации: формирование перечня документов, которые потенциально могут нарушить патентоспособность разрабатываемой технологии и препятствовать их применению на территории Российской Федерации. Обоснование регламента поиска: поиск должен проводиться через сеть Интернет в базах данных Федеральной службы по интеллектуальной собственности, патентам и товарным знакам Российской Федерации, Бюро по патентам и товарным знакам США, Европейского патентного бюро и Всемирной организации интеллектуальной собственности. Начало поиска: 17.10.2011 Окончание поиска: 02.11.2011 12 Роспа- управление процессами, связанными с планированием ресурсов. Планирование задач с помощью мобильных устройств. Применение мобильных устройств для адресного доступа к сервисам. сия, США , Европа ральной службы по интеллектуальной собственности, патентам и товарным знакам РФ, Бюро по патентам и товарным знакам США, Всемирной организации интеллектуальной собственности, Европейского патентного бюро. лет 27/00 B61L 27/02 B61L 27/04 G08G G06F тент, www.fi ps.ru. USPTO, www.us pto.gov. ВОИС, www.wi po.int EPO, ep.espac enet.co m ___________ *МПК (МКИ) — международная патентная классификация (международная классификация изобретений); НКИ — национальная классификация изобретений; МПКО — международная классификация промышленных образцов; НТИ — научно-техническая информация; ГС— гармонизированная система (гармонизированная товарная номенклатура); СМТК — стандартная международная торговая классификация ООН; Руководитель работ, директор по разработкам ООО "НПК "Разумные решения" Генеральный директор ООО "НПК "Разумные решения" Руководитель патентного подразделения, ведущий аналитик ООО "НПК "Разумные решения" 263 П.О. Скобелев 2.11.2011 А.В. Царев 2.11.2011 А.Р. Диязитдинова 2.11.2011 ПРИЛОЖЕНИЕ 1.3 (обязательное к отчету о патентных исследованиях) ФОРМА ОТЧЕТА О ПОИСКЕ ОТЧЁТ о поиске № 2011.10.17-03 B1. Поиск проведён в соответствии с заданием руководителя работ, директора по производству ООО «НПК «Разумные решения» Скобелева П.О. на проведение патентных исследований № 2011.10.17-01 от 17 октября 2011 г. и регламентом поиска № 2011.11.17-02 от 17 октября 2011 г. в рамках выполнения ГК от «17» октября 2011 г. №07.514.11.4094 B2. Этап работы №1 (промежуточный): Выбор направления исследований. Теоретические исследования поставленных перед НИР задач. B3. Начало поиска: 17 октября 2011 г. Окончание поиска: 02 ноября 2011 г. B4. Сведения о выполнении регламента поиска: поиск выполнен полностью. Документов, которые могут препятствовать применению разрабатываемой технологии на территории Российской Федерации, найдено не было. B5. На дальнейших этапах работ по указанному контракту необходимо проведение дополнительных патентных исследований для выявления новых патентов и технологий в рассматриваемой области. B6. Материалы, отобранные для последующего анализа, отсутствуют. Таблица П1.3.1 - Патентная документация Страна выдачи, вид Предмет поиска и номер охранного (объект исследодокумента. Классивания, его софикационный инставные части) декс* 1 1) Контроль и 2 US Patent Сведения о действии Заявитель (патентоохранного дообладатель), страна. Название кумента или Номер заявки, дата изобретения причина его приоритета, конвен- (полной моде- аннулирования ционный приоритет, ли, образца) (только для дата публикации* анализа патентной чистоты) 3 4 5 General Electric, 264 Method of действителен управление №11/591521, процессами, current US Class: USA planning the movement of связанными с 701/19; 246/2R, cur- trains using планирова- rent International pre-allocation нием ресур- Class: G06F 17/00 of resources сов; (20060101) 2) Методы со- Patent № RU OTKRYTOE AK- Method to op- действителен ставления 2008147837 (A), TSIONERNOE OB- timize train расписания; current International SHCHESTVO "ROS- traffic on single Class: B61L27/00) SIJSKIE line 3) Разработка моделей ин- ZHELEZNYE дивидуально- DOROGI" (OAO го планиро- "RZHD"), ; OT- вания ключе- KRYTOE AKTSION- вых ресурсов ERNOE OB- инфраструк- SHCHESTVO туры РЖД. "NAUCHNOISSLEDOVATEL'SKIJ I PROEKTNOKONSTRUKTORSKIJ INSTITUT INF, Russia Patent № US LOCKHEED CORP System and 2011035083 (A1), Method for the current International Automatic Class: G05D3/00) Generation of Movement Authority Solutions in a Rail System 265 действителен Patent № GE TRANSPORTA- A TRAIN PA/a/2002/006558, TION SYSTEMS CORRIDOR current International GLOBAL SIGNAL- SCHEDULING Class: G06F 17/60, ING, LLC PROCESS IN- B61L 27/00) действителен CLUDING VARIOUS COST FUNCTIONS ASSOCIATED WITH RAILWAY OPERATIONS * Заполняется при необходимости. Таблица П1.3.2 - Научно-техническая, конъюнктурная, нормативная документация и материалы государственной регистрации (отчеты о научно-исследовательских работах) Предмет поиска 1 1) Контроль и Наименование источниАвтор, фирма (держака информации с указатель) технической донием страницы источникументации ка 2 3 Год, место и орган издания (утверждения, депонирования источника) 4 Автоматизированная ин- ОАО «НИИАС» Электрон. журн. – М.: управление теллектуальная система Евразия Вести процессами, диспетчерского управ- VII 2009. связанными с ления движением поезпланировани- дов на скоростном ем ресурсов; направлении «Москва – 2) Методы состав- Санкт-Петербург ления распи- Управление линией В.А. Гапанович. сания; Москва - Санкт- ОАО «НИИАС» 3) Разработка мо- Петербург при организаделей индиви- ции высокоскоростного дуального движения 266 Электрон. журн. планирования Интеллектуальные тех- Лябах Н.Н. ключевых ре- нологии на транспорте: ОАО «НИИАС» Электрон. журн. сурсов инфра- сущность и развитие структуры РЖД Система безопасности, МКБ «Компас» Электрон. журн. С. Протцнер (S. Железные дороги мира, мониторинга и диспетчерского управления движением поездов с использованием систем ГЛОНАСС/GPS, разработанная МКБ «Компас» Автоматизация диспет- черского управления как Protzner), С. В. Власен- 2010, №9, с.36-39 средство повышения ко, К.Х. Эрхард (K.H. пропускной способности Erhard), Й. Шмидтке железных дорог (Y. Schmidtke) Системы управления W. Vantuono International Railway движением поездов в Journal, 2009, № 10, p. США 32 – 34, 36 The contribution of Euro- Michele Bernocchi, Euromaintenance 2010 pean Research to more International Congress - Emilio Miguelanez intelligent Railway Verona Fiere - 14th May Maintenance: the Inte- 2010 GRail project Прогнозируемое техни- Паоло Умильакки, Дэ- 9-ая всемирная конфеческое обслуживание вид Лэйн, Феличе Ро- ренция по исследова- железнодорожных под- мано нию железных дорог, систем с использованием 22-26 мая 2011. - подхода моделирования Лилль, Франция на основе онтологии 267 Децентрализованный, Флориан Фукс, Миха- 9-ая всемирная конфе- основанный на онтоло- ил Бергер гии подход к контролю Siemens AG, Corporate нию железных дорог, инфраструктуры Technology ренция по исследова22-26 мая 2011. Лилль, Франция Таблица П1.3.3 -Перечень покупных комплектующих изделий, по которым запрошена документация Запрашиваемая документация (Ответ о Дата заНаименование и обо- ПИ, выписка из Отпроса. значение покупных чета, ТУ, ПФ, выРеквизиты комплектующих из- писка из ПФ)*. Цель письма делий получения запрашизапроса ваемой документации 1 2 3 - - - Вид и номер до- Наименование закумента, полу- прашиваемой орченного при заганизации или просе или причипредприятия с на отказа. Рекви- указанием местозиты письманахождения (адответа рес) 4 5 - - * ПИ - патентные исследования; ТУ - технические условия; ПФ - патентный формуляр. Руководитель работ, директор по разработкам ООО "НПК "Разумные решения" Генеральный директор ООО "НПК "Разумные решения" Руководитель патентного подразделения, ведущий аналитик ООО "НПК "Разумные решения" 268 П.О. Скобелев 2.11.2011 А.В. Царев 2.11.2011 А.Р. Диязитдинова 2.11.2011 ПРИЛОЖЕНИЕ 1.4 (к отчету о патентных исследованиях) Аннотации документов и другие справочные материалы, отобранные при проведении поиска согласно РЕГЛАМЕНТУ № 2011.10.17-02 2 ноября 2011 г. Таблица П1.4.1 – Результаты патентного поиска Документ Аннотация Патент США №11/591521 «Метод В патенте рассматривается метод планирования движепланирования движения поездов с ния поездов, использующий создание и предварительиспользованием предварительного ное распределение виртуальных ресурсов в целях оптираспределения ресурсов». Владе- мизации графика фактического движения поезда лец: General Electric Company (корпорация General Electric Company) Патент № RU 2008147837 (A) Изобретение относится к железнодорожному транспор«Метод для оптимизации желез- ту и может быть использовано в АСУ диспетчерской нодорожного трафика на одном для управления движением на однопутном направлении пути». Владелец: ОАО «РЖД» (корпорация Открытое акционерное общество «Российские железные дороги» 269 Документ Аннотация Патент № US 2011035083 (A1) В патенте рассматривается система с двумя процессами «Система и метод для автомати- для автоматической генерации железнодорожных ческой генерации подтверждения маршрутов и соответствующих ресурсов решения о движении в железнодорожных системах». Владелец: LOCKHEED CORP (корпорация LOCKHEED) Патент № PA/a/2002/006558 Патент рассматривает процесс планирования движения «Процесс планирования коридора поездов в железнодорожных коридорах для поезда на основе различных стоимостных функций, связанных с железнодорожными операциями». Владелец: GE TRANSPORTATION SYSTEMS SIGNALING, GE LLC GLOBAL (корпорация TRANSPORTATION SYS- TEMS GLOBAL SIGNALING) Электрон. ресурс «Автоматизиро- Описывается система «Автодиспетчер», предназначенванная интеллектуальная система ная для управления движением поездов на базе операдиспетчерского управления дви- тивного суточного графика, с ее помощью осуществляжением поездов на скоростном ется диспетчерский мониторинг, регулировка движения направлении «Москва – Санкт- в соответствии с заданной программой, автоматическая Петербург» подготовка маршрутов и принятие управляющих решений при возникновении конфликтных ситуаций Электрон. ресурс «Система без- Описывается система "Красная стрела", которая позвоопасности, мониторинга и диспет- ляет в режиме реального времени обеспечивать смежчерского управления движением ные системы управления на железнодорожном транспоездов с использованием систем порте информацией о номере пути следования, местоГЛОНАСС/GPS, МКБ «Компас» разработанная положении, скорости и направлении движения локомотива 270 Документ Аннотация Электрон. ресурс «Автоматизация Описывается программный комплекс компании диспетчерского управления как Siemens, предназначенный для автоматизации диспетсредство повышения пропускной черского управления на железнодорожном транспорте, способности железных дорог» обеспечивающий оптимизацию в реальном масштабе времени расписаний движения поездов Электрон. ресурс «Система Описывается система управления движением поездов в управления движением поездов в США, которая реализует технологии слежения (в том США» числе, с использованием глобальной спутниковой навигационной системы) за перемещением поездов в целях предотвращения аварийных ситуаций Электрон. ресурс «The contribution Описывается европейский проект InteGrail исследоваof European Research to more intel- ний в области интеллектуального управления на железligent Railway Maintenance: the In- ной дороге teGRail project» Электрон. ресурс «Прогнозируе- Описываются разработки в области представления данмое техническое обслуживание ных диагностических систем в виде семантических дежелезнодорожных подсистем с скрипторов, рассматриваются примеры системного под- использованием подхода модели- хода на базе онтологии на железных дорогах рования на основе онтологии» Электрон. ресурс «Децентрализо- Описывается проект Европейского консультативного ванный, основанный на онтоло- совета по железнодорожным исследованиям и разработгии подход к контролю инфра- кам (ERRAC) для европейской железнодорожной инструктуры» фраструктуры до 2020 г. предлагающий модель информационной системы для описания инфраструктуры железной дороги, основанную на использовании онтологии и децентрализованной архитектуры системы 271 Документ Аннотация Электрон. ресурс «Транспортная Описывается место и роль транспорта, в том числе и стратегия Российской Федерации железнодорожного, в социально-экономическом развина период до 2030 года» тии РФ, анализ современного состояния и проблем развития транспорта в РФ, основные направления развития транспорта в РФ «Белая книга ОАО «РЖД» Описывается место и роль железнодорожного транспорта в социально-экономическом развитии РФ, анализ современного состояния и проблем развития железнодорожного транспорта в РФ, основные направления развития железнодорожного транспорта в РФ Руководитель работ, директор по разработкам ООО "НПК "Разумные решения" Генеральный директор ООО "НПК "Разумные решения" Руководитель патентного подразделения, ведущий аналитик ООО "НПК "Разумные решения" 272 П.О. Скобелев 2.11.2011 А.В. Царев 2.11.2011 А.Р. Диязитдинова 2.11.2011 ПРИЛОЖЕНИЕ 2 (обязательное к отчету о НИР) Отчет о дополнительных патентных исследованиях ОБЩЕСТВО С ОГРАНИЧЕННОЙ ОТВЕТСТВЕННОСТЬЮ «НПК «РАЗУМНЫЕ РЕШЕНИЯ» (ООО «НПК «РАЗУМНЫЕ РЕШЕНИЯ») УДК 004.942 № госрегистрации: 01201179187 Инв. № УТВЕРЖДАЮ Генеральный директор ООО "НПК "Разумные решения" А.В. Царев 10.08.2012 г. ОТЧЕТ О ДОПОЛНИТЕЛЬНЫХ ПАТЕНТНЫХ ИССЛЕДОВАНИЯХ Разработка и исследование прототипа интеллектуальной системы для согласованного адаптивного планирования и связанного изменения планов движения поездов для минимизации отклонения высокоскоростных поездов класса «Сапсан» от графика движения под влиянием непредвиденных внешних событий по теме: ОБОБЩЕНИЕ И ОЦЕНКА РЕЗУЛЬТАТОВ ИССЛЕДОВАНИЙ (заключительный, этап №3) ГК от «17» октября 2011 г. №07.514.11.4094 Шифр: 2011-1.4-514-125-063 Руководитель НИОКР, директор по разработкам ООО "НПК "Разумные решения" ______________ П.О. Скобелев 10.08.2012 г. Нормоконтроль, директор по общим вопросам ООО "НПК "Разумные решения" ______________ А.Н. Мочалкин 10.08.2012 г. Самара 2012 273 СПИСОК ИСПОЛНИТЕЛЕЙ Руководитель темы: директор по разработкам ООО «НПК «Разумные решения» П.О. Скобелев (заключение) Исполнители: Ведущий аналитик ООО «НПК «Разумные решения» Е.В. Симонова (раздел 1) Директор по аналитике ООО «НПК «Разумные решения» С.С. Кожевников (общие данные об объекте исследований, заключение) Нормоконтролер директор по общим вопросам, ООО «НПК «Разумные решения» А.Н. Мочалкин 274 СОДЕРЖАНИЕ НОРМАТИВНЫЕ ССЫЛКИ .........................................................................................................277 НОРМОКОНТРОЛЬ .......................................................................................................................278 ОПРЕДЕЛЕНИЯ .............................................................................................................................279 ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ ............................................................................................281 ОБЩИЕ ДАННЫЕ ОБ ОБЪЕКТЕ ИССЛЕДОВАНИЙ ..............................................................282 1 ОСНОВНАЯ (АНАЛИТИЧЕСКАЯ) ЧАСТЬ............................................................................286 1.1 Технический уровень и тенденции развития объекта хозяйственной деятельности...............................................................................................................................286 1.2 Выбор области для исследований ......................................................................................289 1.3 Поиск по базе данных Федеральной службы по интеллектуальной собственности, патентам и товарным знакам РФ ...................................................................290 1.4 Поиск по базе данных Бюро по патентам и товарным знакам США .............................291 1.4.1 Патент на адаптивную сетецентрическую автономную систему управления цепочками поставок в реальном времени ......................................................291 1.4.2 Патент на систему и метод адаптивного планирования пути движения транспортного средства ........................................................................................................292 1.5 Поиск по базе данных Европейского патентного бюро ...................................................292 1.5.1 Патент на расписание ресурсов для системы планирования железнодорожных поездов ...................................................................................................293 1.6 Поиск по базе данных Всемирной организации интеллектуальной собственности ............................................................................................................................293 1.6.1 Патент на метод оптимизации параметров управления несколькими поездами в пересекающихся железнодорожных сетях .....................................................294 1.7 Результаты исследования патентов....................................................................................295 1.8 Предпосылки к непатентным исследованиям ...................................................................296 1.9 Источники информации при выполнении непатентных исследований .........................296 1.10 Обзор выбранных систем планирования .........................................................................297 1.10.1 Разработка устойчивой к чрезвычайным ситуациям автоматизированной системы управления железнодорожным транспортом с функциями поддержки принятия решений ........................................................................297 1.10.2 Автоматизированная система управления перевозочным процессом железнодорожного транспорта в оперативном режиме ....................................................299 275 1.10.3 Направления развития железнодорожного транспорта в мире на основе интеллектуальных систем (по материалам IBM Institute for Business Value) 300 1.10.4 Система управления железнодорожным трафиком в реальном времени: диспетчеризация в сложных, больших и нагруженных железнодорожных сетях .......................................................................................................301 1.10.5 Сетецентрические интеллектуальные системы управления железной дорогой 303 1.11 Результаты исследования непатентных источников ......................................................306 1.12 Выводы ...............................................................................................................................307 ЗАКЛЮЧЕНИЕ...............................................................................................................................310 СПИСОК ИСПОЛЬЗУЕМЫХ ИСТОЧНИКОВ ..........................................................................312 ПРИЛОЖЕНИЕ 2.1 ФОРМА ЗАДАНИЯ НА ПРОВЕДЕНИЕ ПАТЕНТНЫХ ИССЛЕДОВАНИЙ ...................................................................................................................314 ПРИЛОЖЕНИЕ 2.2 ФОРМА РЕГЛАМЕНТА ПОИСКА ...........................................................315 ПРИЛОЖЕНИЕ 2.3 ФОРМА ОТЧЕТА О ПОИСКЕ...................................................................317 ПРИЛОЖЕНИЕ 2.4 АННОТАЦИИ ДОКУМЕНТОВ И ДРУГИЕ СПРАВОЧНЫЕ МАТЕРИАЛЫ, ОТОБРАННЫЕ ПРИ ПРОВЕДЕНИИ ПОИСКА ........................................322 276 НОРМАТИВНЫЕ ССЫЛКИ В настоящем отчёте о патентных исследованиях использованы ссылки на следующие стандарты: 1) ГОСТ 2.105-95 Межгосударственный стандарт. Единая система конструкторской документации. Общие требования к текстовым документам. 2) ГОСТ Р 15.011-96 Система разработки и постановки продукции на производство. Патентные исследования. Содержание и порядок проведения. 3) ГОСТ 15.101-98 Система разработки и постановки продукции на производство. Порядок выполнения научно-исследовательских работ 4) ГОСТ 7.32–2001 Система стандартов по информации, библиотечному и издательскому делу. Отчет о научно-исследовательской работе. Структура и правила оформления. 277 НОРМОКОНТРОЛЬ В соответствии с требованиями п.п. 3.4 ГОСТ 7.32-2001 - о необходимости обязательного нормоконтроля отчета о патентных исследованиях в организации-исполнителе, руководствуясь ГОСТ 2.111 был проведен нормоконтроль документации ответственным Мочалкиным А.Н. 278 ОПРЕДЕЛЕНИЯ В настоящем отчёте о патентных исследованиях использованы следующие определения: Агент Автономный программный объект, способный анализировать ситуацию, принимать решения, коммуницировать с другими агентами, вести переговоры друг с другом для разрешения возникающих конфликтов и затем информировать систему и пользователя о результатах своих действий. В процессе переговоров и принятия решений программные агенты пользуются знаниями, хранящимися в онтологии. Высокоскоростной поезд класса Высокоскоростной электропоезд (из семейства электро- "Сапсан" поездов Velaro производства компании Siemens AG), приобретённый ОАО «РЖД» для эксплуатации на российских скоростных железных дорогах. Динамическое планирование Метод, позволяющий изменять план работы системы в масштабе реального времени. Отличие от инкрементного планирования заключается в том, что в динамическом планировании используется не просто обычное распределение работ по интервалам на временной шкале, но и поддерживается возможность разрешать конфликтные ситуации путём внесения в план работ различного рода изменений, таких как перемещение, замена или прекращение операции. Знания Закономерности некой предметной области (принципы, связи, способы взаимодействия), полученные в результате практической деятельности и профессионального опыта, позволяющие моделировать бизнес-процессы в некоторой предметной области и решать задачи в этой области. Мультиагентные технологии Интегрируют последние достижения информационных технологий и программирования, методов и средств искусственного интеллекта, распределённых информаци279 онных систем и компьютерных сетей, в основе которых лежит понятие интеллектуального программного агента. С помощью мультиагентных технологий взаимодействие объектов реального мира моделируется переговорами их программных агентов, где настраиваемый программный агент человека действует в системе от имени и по поручению своего владельца, представляет его интересы во взаимодействии с органами исполнительной власти для наилучшей реализации его потребностей и возможностей. Расписание Последовательность выполнения запланированных задач (событий мероприятий) по времени. 280 ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ В настоящем отчёте о патентных исследованиях использованы следующие обозначения и сокращения: АСУ – автоматизированная система управления БЗ – база знаний ВОИС – Всемирная организация интеллектуальной собственности МАС – мультиагентная (многоагентная) система МАТ – мультиагентные технологии МПК – международная патентная классификация РЖД – российские железные дороги ФЦНТП – Федеральная целевая научно-техническая программа 281 ОБЩИЕ ДАННЫЕ ОБ ОБЪЕКТЕ ИССЛЕДОВАНИЙ Патентные исследования проводились с целью определения патентоспособности планируемых результатов научно-исследовательской работы по лоту «Проведение проблемноориентированных поисковых исследований в области информационно- телекоммуникационных систем для решения задач Технологической платформы "Высокоскоростной интеллектуальный железнодорожный транспорт"» – тема «Разработка и исследование прототипа интеллектуальной системы для согласованного адаптивного планирования и связанного изменения планов движения поездов для минимизации отклонения высокоскоростных поездов класса "Сапсан" от графика движения под влиянием непредвиденных внешних событий» (шифр «2011-1.4-514-125-063»), выполняемой в рамках Федеральной целевой научно-технической программы (ФЦНТП) «Исследования и разработки по приоритетным направлениям развития научно-технологического комплекса России на 2007–2012 годы» (мероприятие 1.4 Программы (IX очередь) "Проведение проблемно-ориентированных поисковых исследований и создание научно-технического задела по перспективным технологиям в области информационно-телекоммуникационных систем") по государственному контракту №07.514.11.4094, заключённому между Федеральным агентством по науке и инновациям и Научно-производственной компанией «Разумные решения» на основании решения Конкурсной комиссии Роснауки (протокол № 83 от 27.09.2011 г.), а также для получения сведений об охранных и иных документах, которые могут препятствовать применению результатов данной НИР в Российской Федерации, и условиях использования таких документов. Патентные исследования проводились в соответствии с ГОСТ Р. 15.011-96 «Система разработки и постановки продукции на производство. Патентные исследования» [1]. При этом в процессе исследований осуществлялся поиск, как патентных источников, так и непатентных источников, а также программных продуктов. Это должно помочь в разработке технологии, в которой будут учтены преимущества и недостатки уже существующих подходов к управлению производственными процессами ОАО «РЖД». Система управления движением поездов ОАО «РЖД» характеризуется большим разнообразием и количеством составных элементов и их взаимосвязей в рамках производственного процесса [4]. Кроме количественных характеристик, большое значение имеют качественные показатели сложности объекта автоматизации: а) Неопределенность: трудно предсказать изменения спроса и предложения. б) Событийность: часто случаются события, требующие оперативного изменения планов, решений в реальном масштабе времени. 282 в) Ситуативность: решение надо принимать по ситуации. г) Многофакторность: много разных критериев, предпочтений и ограничений. д) Высокая связность: принятие оперативного решения на одном участке (станции) требует учёта принятых или планируемых решений на связанных участках (станциях) и вызывает изменение решений многих других. е) Индивидуальность: участники требуют все более индивидуального подхода. ж) Конфликты: все больше участников с противоречивыми интересами. и) Трудоемкость: слишком много опций, чтобы просчитать последствия. к) Оперативность: требуется высокая оперативность принятия решений. Эти особенности требуют новых современных стратегических подходов, методов и средств автоматизации производственной деятельности и обеспечения поддержки принятия решений в реальном времени. Анализ существующих систем управления движением поездов позволяет выделить основные направления развития: а) развитие информационных систем в направлении интеллектуализации систем управления ресурсами РЖД, б) развитие технических средств автоматизации. Анализ и опыт использования информационных систем управления движением поездов позволил выявить целый ряд проблем и недостатков, характерных на сегодняшний день. К числу таких недостатков, в первую очередь, относятся следующие: а) Информационные системы функционально не удовлетворяют современным бизнеспроцессам железнодорожного транспорта, отсутствуют методы и средства, обеспечивающие согласованную работу участников производственной деятельности. б) Отсутствует поддержка сквозных бизнес-процессов, системы не интегрированы, отсутствует комплексный подход к решению транспортных проблем. в) Основу автоматизации управления перевозочным процессом составляют системы, разработанные 20-30 лет назад, реализованные по принципу хранилища данных. Модернизация таких систем неэффективна, а часто и невозможна. г) Информационная перегруженность лиц, принимающих решения, отсутствие средств поддержки принятия и реализации оперативных решений, особенно в части реакции на непредвиденные события. д) Принятие решений при выходе поезда из расписания в настоящее время осуществляется только вручную. е) Отсутствие опережающего прогнозирования возможности появления нештатных ситуаций путем моделирования процессов движения при различных условиях и др. 283 Указанные проблемы уже имеющихся на рынке систем во многом вызваны использованием традиционных алгоритмов и подходов к организации планирования и ведения задач, при которых все операции планирования выполняются единообразно независимо от типа и специфики задач. В проекте предлагается новый способ построения систем планирования движения поездов, который позволит обеспечить следующие преимущества: а) повышение актуальности текущего расписания - суммарного времени, в течение которого расписание находится в актуальном состоянии за счет своевременной обработки событий; б) повышение числа анализируемых вариантов и возможных решений, учтенных при анализе и перепланировании в ответ на события; в) повышение оперативности в принятии решений и, в частности, сокращение времени реакции на непредвиденные события; г) повышение точности оценки последствий непредвиденных событий и рассчитанных показателей эффективности расписания на горизонте планирования по сравнению с учетом опозданий без взаимных влияний в расписании; д) повышение готовности к изменениям в форме расчета показателей эффективности расписания (например, с учетом энергоэффективности); е) опережающее прогнозирование возможности появления нештатных ситуаций путем моделирования процессов движения при различных условиях; ж) своевременное выявление и устранение проблемных ситуаций путем планирования отражения событий, а также мониторинга и контроля выполнения планов, в том числе, по каждому поезду, вовлеченному в процесс управления ресурсами. и) прозрачность результатов планирования для управленцев. к) сокращение влияния человеческого фактора. Выводы. Стремительный технический прогресс в области Интернет-систем, семантического веба и мультиагентных технологий, мобильной связи, спутниковой GPS/ГЛОНАСС навигации и ряда других в последнее время открывает совершенно новые возможности для решения рассматриваемых проблем [5-8]. Предлагаемая технология адаптивного планирования и динамического управления расписанием поездов на основе сетецентрического подхода и интеграционной программной платформы комплексной автоматизации планирования ресурсов РЖД с использованием мультиагентных технологий и онтологий, средств GPS-навигации и GPRS имеет высокий потенциал [9]. В этой связи в настоящей работе наибольшее внимание будет уделено рас284 смотрению методов динамического планирования с использованием вышеуказанных технологий, позволяющих автоматически планировать и перепланировать формирующееся расписание движения поезда по событиям в реальном времени в зависимости от текущего местонахождения поезда, состояния пути и др. Патентные исследования (приложения А, Б, В) проводились с 17.10.2011 г. по 02.12.2011 г. 285 1 ОСНОВНАЯ (АНАЛИТИЧЕСКАЯ) ЧАСТЬ 1.1 Технический уровень и тенденции развития объекта хозяйственной деятельности В Транспортной стратегии Российской федерации на период до 2030 года отмечается, что железные дороги занимают важное место в транспортной системе. Протяженность железных дорог общего пользования транспортной системы России по состоянию на начало 2007 года составляла 85 тыс. км. Железнодорожный транспорт выполняет 84,3 процента общего грузооборота, осуществляемого всеми видами транспорта [3]. Важнейшей проблемой является техническое и технологическое отставание транспортной системы России по сравнению с развитыми странами. Она не готова к повсеместному применению современных технологий, в частности, в стране отсутствует высокоскоростное железнодорожное сообщение. Согласно инновационному варианту развития транспортной системы, значительный импульс получит развитие пассажирского транспорта общего пользования. Прежде всего, это относится к развитию скоростных и высокоскоростных железнодорожных перевозок. К приоритетным направлениям организации скоростного и высокоскоростного движения до 2015 года отнесены Москва - Санкт-Петербург (с максимальной скоростью на первом этапе 200 км/ч, а в дальнейшем до 250 км/ч), Санкт-Петербург - Бусловская (с максимальной скоростью на первом этапе 160 км/ч, а в дальнейшем до 200 км/ч), Москва - Нижний Новгород (с максимальной скоростью 160 км/ч). После 2015 года предусмотрена организация скоростного движения (140 - 160 км/ч) по направлениям Москва - Смоленск - Красное, Москва - Курск, Москва - Калуга - Брянск (Суземка), Москва - Ярославль, Москва - Рязань - Мичуринск - Саратов, Ростов - Краснодар, Ростов - Минеральные Воды, Краснодар - Минеральные Воды, Новосибирск - Омск, Новосибирск - Томск, Новосибирск - Кемерово, Новосибирск - Барнаул, Новосибирск - Новокузнецк, Екатеринбург - Челябинск, Самара - Саранск, Самара - Пенза, Самара - Саратов, Саратов - Волгоград, Уссурийск - Владивосток, Владивосток – Хабаровск. В Белой книге ОАО «РЖД» [4] указано, что концептуальной целью ОАО «РЖД» является обеспечение лидирующей позиции компании на рынке качественных и конкурентоспособных транспортных услуг, полностью удовлетворяющих потребности в грузовых и пассажирских перевозках при условиях минимизации нагрузки на окружающую среду. Реализация такой широкомасштабной цели, поставленной впервые, требует решения ряда крупных научно-технических проблем, определяющих успех достижения цели. 286 Многолетний мировой опыт показал, что при массовых перевозках в дневных поездах на расстояния 400 – 800 км и в спальных вагонах ночных поездов на расстояния 1700 – 2500 км по безопасности, затратам времени, стоимости, комфорту и экологии высокоскоростные поезда выгодны пассажирам по сравнению со всеми другими видами транспорта. Очевидно, что России с её огромными территориями необходимо иметь скоростные и высокоскоростные железнодорожные поезда. В соответствии с Федеральной целевой программой «Модернизация транспортной системы России на 2002 – 2010 годы» требуется осуществить поэтапное повышение скоростей движения пассажирских поездов с увеличением протяженности полигона скоростного движения до 8 тыс. км. Среди основных задач развития скоростного и высокоскоростного движения указаны: а) создание высокоскоростных электропоездов с конструкционной скоростью до 400 км/ч, скоростных межрегиональных электропоездов – 250 и 160 км/ч (в вариантах постоянного тока, переменного тока и двухсистемном); б) организация скоростного и высокоскоростного движения пассажирских поездов на приоритетных направлениях сети железных дорог; в) создание нормативной базы и системы технического обслуживания скоростного и высокоскоростного подвижного состава и инфраструктуры; г) создание технических средств для скоростного и высокоскоростного движения. Комплекс мероприятий по повышению скоростей движения на железнодорожном транспорте включает: а) повышение маршрутных скоростей дальних пассажирских поездов, следующих на расстояния более 700 км, до 70-90 км/ч; б) организацию скоростного железнодорожного движения после реконструкции действующих линий между крупными региональными центрами скоростными поездами, маршрутная скорость которых находится в пределах до 160-200 км/ч и время поездки не превышает 7 часов; в) создание высокоскоростных железнодорожных линий, на которых обеспечивается движение со скоростями до 350 км/час: 1) Санкт-Петербург – Москва, 2) Москва – Адлер. Цель инновационного развития ОАО «РЖД» направлена на достижение параметров экономической эффективности, экологической и функциональной безопасности и устойчивости отечественного железнодорожного транспорта общего пользования, определенных Транспортной стратегией Российской Федерации и стратегией развития ОАО «РЖД». 287 Среди важнейших направлений инноваций в научно-техническом развитии высокоскоростного движения на период до 2015 г. в Белой Книге ОАО «РЖД» определены: а) нормативы и требования к подвижному составу и инфраструктуре для высокоскоростного движения; б) система управления и обеспечения безопасности движения на высокоскоростных магистралях; в) автоматизированные технологии проектирования инфраструктуры. г) Основные результаты, достигнутые в 2007-2011 гг.: д) ввод в эксплуатацию высокоскоростного электропоезда RUS-250 и инфраструктуры для скоростей движения до 250 км/ч на участке Санкт-Петербург-Москва; е) создание системы технического обслуживания высокоскоростной инфраструктуры и подвижного состава; ж) разработка проектов высокоскоростных магистралей на выделенных направлениях. К 2012-2015 гг. поставлена задача достижения следующих основных результатов: а) организация высокоскоростного движения со скоростями до 350-400 км/ч с освоением отечественного производства основных элементов инфраструктуры и подвижного состава; б) создание системы технического обслуживания инфраструктуры и подвижного состава для скоростей до 350-400 км/ч. Ускоренная модернизация существующей материально-технической базы железнодорожного транспорта к 2015 году предполагает увеличение маршрутных скоростей пассажирских поездов на основных направлениях на 12-15%. Стратегия инновационного развития ОАО «РЖД» реализуется через ежегодные планы научно-технического развития компании, включающие, в том числе, разработку новых технических решений и приоритетных технологий, таких как интеллектуальная система управления железнодорожным транспортом. Интеллектуальная система управления железнодорожным транспортом предназначена для организации централизованного автоматизированного управления движением поездов на линиях РЖД и организации всей производственной деятельности на РЖД на базе широкого использования современных методов анализа, управления, моделирования, логистики и прогнозирования, а также средств вычислительной техники и информационных технологий. Выполнение НИР, целью которой является разработка интеллектуальной системы для согласованного адаптивного планирования расписания железнодорожного транспорта на основе сетецентрического подхода и мультиагентных технологий, является актуальной зада- 288 чей, решение которой будет способствовать совершенствованию системы управления движением на высокоскоростных железнодорожных магистралях. В 2012 г. поезда "Сапсан" ежедневно совершают по семь рейсов на направлении Москва - Санкт-Петербург и по два рейса в сообщении Москва - Нижний Новгород. Первое расстояние поезд преодолевает в среднем за 3 часа 45 минут, второй маршрут - за 3 часа 55 минут. За 2 года с начала эксплуатации поезда "Сапсан" на участке Москва – Нижний Новгород перевезено более 1,2 млн. пассажиров. С начала эксплуатации на участке Москва Санкт-Петербург "Сапсанами" перевезено уже более 5 млн. 300 тыс. пассажиров. Таким образом, всего высокоскоростными поездами перевезено более 6,5 млн. пассажиров. В том числе с начала 2012 года "Сапсаны" перевезли более 1 млн. 690 тыс. пассажиров: около 1 млн. 320 тыс. пассажиров – в сообщении Москва – Санкт-Петербург и около 370 тыс. 200 пассажиров – в сообщении Москва – Нижний Новгород. Для обеспечения спроса на перевозки пассажиров 5 августа 2012 года ОАО "РЖД" назначает дополнительный рейс скоростного поезда "Сапсан" сообщением Нижний Новгород – Москва и с 24 августа по 1 сентября 2012 года назначает дополнительные рейсы скоростных поездов "Сапсан" по маршруту Москва Санкт-Петербург – Москва. Компания ОАО «РЖД» объявила, что готов проект первой в России выделенной высокоскоростной железнодорожной магистрали Москва – Санкт-Петербург [Информационный портал «РЖД Партнер». – Режим доступа: http://www.rzd-partner.ru/magazine/rzdpartner/233-234/7840.html]. 1.2 Выбор области для исследований Продуктами, разрабатываемыми в ходе данной научно-исследовательской работы, являются технология и система динамического планирования с использованием сетецентрической и интеграционной программной платформы комплексной автоматизации планирования ресурсов РЖД, мультиагентных технологий, онтологий, применённая к адаптивному планированию и динамическому управлению расписанием для минимизации отклонения от графика высокоскоростного железнодорожного транспорта за счет связанного изменения расписаний менее приоритетных поездов. Предпосылки к данным разработкам приведены в предыдущем подразделе. Темы, по которым проводился поиск, определялись исходя из состояния исследуемой области. Такими темами стали: а) контроль и управление процессами, связанными с планированием ресурсов; б) методы составления расписания; 289 в) разработка моделей индивидуального планирования ключевых ресурсов инфраструктуры РЖД (поезд, путь, блок-участок, станция) и др. Соответственно этому определились и разделы международной патентной классификации, по которым был проведён поиск патентов. Перечень данных разделов включает: а) B61L 27/00 (Системы диспетчерского управления движением поездов); б) B61L 27/02 (Системы диспетчерского управления движением поездов – ручные); в) B61L 27/04 (Системы диспетчерского управления движением поездов – автоматические, например управляемые поездом; с переключением на ручное управление); г) G08G (Системы регулирования движения транспортных средств (управление железнодорожным движением, обеспечение безопасности железнодорожного движения)); д) G06F (Обработка цифровых данных). Поиск патентной информации проводился в патентных базах данных Федеральной службы по интеллектуальной собственности, патентам и товарным знакам Российской Федерации (Роспатент, www.fips.ru), Бюро по патентам и товарным знакам США (USPTO, www.uspto.gov), Европейского патентного бюро (EPO, http://www.epo.org/) и Всемирной организации интеллектуальной собственности (ВОИС, www.wipo.int). 1.3 Поиск по базе данных Федеральной службы по интеллектуальной собственности, патентам и товарным знакам РФ В данном подразделе приводится информация о результатах патентного поиска по темам, указанным в подразделе 1.2., в базе данных Федеральной службы по интеллектуальной собственности, патентам и товарным знакам РФ. В указанной базе данных был произведен поиск в электронном бюллетене RU ОБПБТ № 2(79) 20.06.2012 Электронный бюллетень - Программы для ЭВМ, базы данных, топологии интегральных микросхем № 2 2012 г. По результатам поиска в указанной базе данных не было найдено релевантных патентов, соответствующих разрабатываемой технологии планирования движения высокоскоростных поездов. Патенты в области управления транспортом относятся к программам для регистрации прохождения транспорта любого вида (автомобильного, железнодорожного, специального). Патентов, связанных с применением сетецентрического подхода, мультиагентных технологий и онтологий в каких-либо областях, не найдено. 290 1.4 Поиск по базе данных Бюро по патентам и товарным знакам США В данном подразделе приводится описание патентов, найденных в базе данных Бюро по патентам и товарным знакам США и относящихся к теме исследования. В ходе поиска были найдены несколько в определённой степени релевантных патентов. Данные патенты представлены ниже в порядке убывания релевантности: а) Адаптивная сетецентрическая автономная система управления цепочками поставок в реальном времени (Adaptive network-centric online autonomic supply chain management system. US Patent № 10/755,246, current US Class: 235/385, current International Class: G06F 19/00 (20060101)). б) Система и метод адаптивного планирования пути (System and method for adaptive path planning. US Patent № 10/811,460, current US Class: 701/301; current International Class: G08G 1/16 (20060101)). В определенной степени близкими к разрабатываемой системе являются решения, описанные в патентах, которые были выданы патентным бюро США корпорациям Raytheon Company и Kenneth Jongebloed, Inc. 1.4.1 Патент на адаптивную сетецентрическую автономную систему управления цепочками поставок в реальном времени Патент США №10/755,246 «Адаптивная сетецентрическая автономная система управления цепочками поставок в реальном времени». Владелец: Kenneth Jongebloed, Inc. (Cocoa Beach, FL) [10]. Краткое описание патента. Патент описывает гибкую, адаптивную, интеллектуальную сетецентрическую систему управления цепочками поставок в реальном времени, в которой полный цикл планирования поставок с жестко ограниченными сроками выполняется в автоматическом или полуавтоматическом режимах. В любом режиме работы планирование осуществляется за счет выбора ресурсов (транспортных средств), обеспечивающего соблюдение сроков поставки и минимизацию транспортных расходов. Адаптивное планирование приводит к сокращению сроков поставок и снижению уровня запаса на складах. Замечания. В данном патенте описывается адаптивная система управления цепочками поставок на основе сетецентрического подхода. Мультиагентные технологии для реализации алгоритмов планирования в данной системе не используются. Система, разрабатываемая в проекте, отличается от системы, описанной в патенте, возможностью настройки логики планирования через онтологии, а также реализацией стратегического и оперативного планирования. Стратегический планировщик реализует стратегическое интерактивное планирова291 ние и оптимизацию использования ресурсов на значительный период времени. Оперативный планировщик реализует оперативное адаптивное планирование и перепланирование ресурсов с целью обеспечения графика движения, сокращения времени простоя в реальном времени, быструю, оперативную и гибкую реакцию на непредвиденные события (задержки, поломки ресурсов и т.д.); 1.4.2 Патент на систему и метод адаптивного планирования пути движения транспортного средства Патент США №10/811,460 «Система и метод адаптивного планирования пути». Владелец: Raytheon Company (Waltham, MA) [11]. Краткое описание патента. Патент описывает систему для адаптивного планирования пути перемещения транспортного средства в реальном времени, в динамично изменяющейся и неопределенной среде с вероятностным описанием препятствий движению. Планирование пути движения транспортного средства в пространстве состояний от исходной позиции до целевой позиции выполняется за счет построения вероятностного дерева в пространстве состояний движущегося объекта. Вершины дерева представляют собой состояния, от каждой вершины строится множество ребер заданной длины в заданных направлениях с использованием множества детерминированных и вероятностных правил расширения дерева и ограничений. Замечания. В данном патенте описывается метод планирования, основанный на графовой модели определения пути движения объекта. Упоминание об использовании мультиагентных технологий и онтологий для хранения знаний о движущихся объектах и правил/ограничений, определяющих логику адаптивного планирования, при реализации данного метода планирования отсутствует. Система, разрабатываемая в проекте, отличается от системы, описанной в патенте, также возможностями согласованного планирования ресурсов через сеть взаимодействующих планировщиков, что обеспечивает высокую производительность и реакцию на непредвиденные события в реальном времени, а не в соответствии с заранее заданной стохастической математической моделью. 1.5 Поиск по базе данных Европейского патентного бюро В данном подразделе приводится описание патентов, найденных в базе данных Европейского патентного бюро. В ходе поиска были найдены несколько в определённой степени релевантных патентов. Данные патенты представлены ниже в порядке убывания релевантности: 292 а) Расписание ресурсов для системы планирования железнодорожных поездов (Resource schedule for scheduling rail way train resources. Patent № US2004111309 (A1), current International Class: B61L27/00; G06Q10/00)). б) Метод планирования и управления системой железных дорог на основе формального описания сети железнодорожных путей (Method for planning and operating a railway system based on a formal description of the track network. Patent № EP0796778 (A1), current International Class: B61L21/00). Наибольший интерес среди них представляет патент, выданный корпорации HARRIS CORPORATION. 1.5.1 Патент на расписание ресурсов для системы планирования железнодорожных поездов Патент №US2004111309 «Расписание ресурсов для системы планирования железнодорожных поездов». Владелец: HARRIS CORPORATION [12]). Краткое описание патента. Рассматривается система планирования железнодорожных перевозок, в которой реализован метод перемещения движущихся объектов в системе многопутных железных дорог. Система планирования использует планировщик, основанный на минимизации ресурсов и глобальных издержек, связанных с принятым решением. Составленное системой расписание движения может быть использовано для оказания помощи в автоматическом управлении движением поездов в системе железных дорог. Замечания. Данный патент описывает планировщик железнодорожных ресурсов для поддержки принятия решений при составлении расписаний движения поездов в системе многопутных железных дорог. В описании патента не упоминается использование сетецентрического подхода, мультиагентных технологий и онтологий при реализации системы. Отличием разрабатываемой системы от системы, описанной в патенте, является реализация многоуровневого планирования движения поездов за счет использования стратегического (на длительный горизонт) и оперативного (реагирующего на возмущения в реальном времени) планировщиков, основанных на знаниях о состоянии ресурсов и настраиваемой логики планирования, что обеспечивает мониторинг процессов управления ресурсами железной дороги в реальном времени. 1.6 Поиск по базе данных Всемирной организации интеллектуальной собственности В данном подразделе приводится описание патентов, найденных в базе данных Всемирной организации интеллектуальной собственности. 293 В ходе поиска были найдены несколько в определённой степени релевантных патентов. Данные патенты представлены ниже в порядке убывания релевантности: а) Метод оптимизации параметров управления несколькими поездами в пересекающихся железнодорожных сетях (Method for optimizing parameters of multiple rail vehicles operating over multiple intersecting railroad networks, Patent № EP2423070, current International Class: B61L 27/00). б) Метод и система для независимого управления транспортными средствами (METHOD AND SYSTEM FOR INDEPENDENT CONTROL OF VEHICLES, Patent № WO2011059817, current International Class: B61L 27/00 (2006.01)). Наибольший интерес среди них представляет патент, выданный корпорации GENERAL ELECTRIC COMPANY. 1.6.1 Патент на метод оптимизации параметров управления несколькими поездами в пересекающихся железнодорожных сетях Патент № EP2423070 «Метод оптимизации параметров управления несколькими поездами в пересекающихся железнодорожных сетях». Владелец: GENERAL ELECTRIC COMPANY [13]). Краткое описание патента. Патент рассматривает метод расчета параметров поезда, с учетом параметров других поездов в железнодорожной сети для определения оптимальных параметров на определенном участке пути движения поезда. Метод также включает перепланирование оптимальных параметров поезда при изменении ситуации на текущем участке дороги и на пересекающихся участках. Замечания. В данном патенте описывается метод согласованного планирования движения поездов на пересекающихся участках железной дороги. Однако патент не рассматривает возможность применения сетецентрического подхода на основе мультиагентных технологий и онтологий для согласованного планирования и перепланирования расписания поездов. Реализуемый в разрабатываемом проекте сетецентрический подход позволяет решать задачу согласованного планирования ресурсов за счет обращения к взаимосвязанным планировщикам, если решить задачу перепланирования расписания локально не удается. За счет такой возможности обеспечивается гибкость, открытость к изменениям, высокая производительность системы планирования, предлагаемой в разрабатываемом проекте. 294 1.7 Результаты исследования патентов В результате предварительного исследования существующих патентов было решено исследовать разделы международной патентной классификации (МПК): а) Системы диспетчерского управления движением поездов (B61L 27/00), б) Системы диспетчерского управления движением поездов – ручные (B61L 27/02), в) Системы диспетчерского управления движением поездов – автоматические, например управляемые поездом; с переключением на ручное управление (B61L 27/04), г) Системы регулирования движения транспортных средств (управление железнодорожным движением, обеспечение безопасности железнодорожного движения (G08G), д) Обработка цифровых данных (G06F). Поиск дал отрицательный результат: в данных разделах МПК не было найдено патентов, которые препятствовали бы на данном этапе проводить разработку технологии. Вместе с тем, следует отметить, что Бюро по патентам и товарным знакам США в 2010 году выдало патент на адаптивную сетецентрическую автономную систему управления цепочками поставок в реальном времени (Adaptive network-centric online autonomic supply chain management system, US Patent № 10/755,246, current US Class: 235/385, current International Class: G06F 19/00 (20060101)). Однако данный патент не может создать сложностей при применении разрабатываемой технологии планирования движения высокоскоростного железнодорожного транспорта, поскольку не использует мультиагентные технологии и онтологии при реализации планировщика. Краткое описание данного патента содержится в подразделе 1.4.1. Кроме того, Европейским патентным борю в 2012 году был выдан патент на метод оптимизации параметров управления несколькими поездами в пересекающихся железнодорожных сетях (Method for optimizing parameters of multiple rail vehicles operating over multiple intersecting railroad networks, Patent № EP2423070, current International Class: B61L 27/00). Данный патент также не может создать сложностей при применении разрабатываемой технологии планирования, поскольку не рассматривает сетецентрический подход на основе мультиагентных технологий и онтологий для согласованного планирования и перепланирования расписания поездов. Краткое описание данного патента приводится в подразделе 1.6.1. Сказанное, однако, не означает, что в других разделах МПК, которые не относятся напрямую к рассматриваемой области, не существует патентов, которые не могут быть потенциально нарушенными в процессе эксплуатации разрабатываемой технологии. 295 Вместе с тем, научная новизна предлагаемого в качестве основы сетецентрического подхода, основанного на применении мультиагентных технологий и онтологий для представления знаний о предметной области и получающего развитие лишь в самое последнее время, позволяют надеяться, что предлагаемое решение превосходит все потенциально имеющиеся аналоги и имеет большой научно-технический потенциал для будущих разработок. 1.8 Предпосылки к непатентным исследованиям В соответствии с патентным законом Российской Федерации [2], уровень техники, в сравнении с которым выявляется новизна изобретения, определяется не только зарегистрированными в России патентами, но также имеющейся во всём мире общедоступной информацией. В отношении предлагаемой технологии планирования движения поездов такой информацией могут являться сведения о свободно распространяемых в сети Интернет программных продуктах, коммерческих программных продуктах и решениях, в той или иной степени реализующих функциональные возможности и технологии, аналогичные разрабатываемым. Таким образом, в силу требования технического задания о получении свидетельств об официальной регистрации программ для ЭВМ, возникает необходимость исследовать аналоги создаваемой технологии и сравнить её с этими аналогами. Поэтому данное исследование направлено на: а) анализ уже имеющихся на рынке систем диспетчерского управления движением поездов; б) определение критериев, по которым можно сравнивать данные системы; в) отбор систем, полностью или частично реализующих функциональные возможности, предоставляемые с помощью разрабатываемой технологии. 1.9 Источники информации при выполнении непатентных исследований В качестве основных источников информации по тематике «системы планирования движением высокоскоростного транспорта» использовались ресурсы сети Интернет, такие как Интернет-проект энциклопедии свободного доступа Wikipedia, веб-сайты компанийразработчиков программных решений для управления и планирования движением поездов. На основе анализа данных ресурсов был сформирован общий перечень существующих на рынке систем для планирования движения поездов. Данные системы существенно отличаются от предлагаемой технологии принципами работы, функциональными возможностями и полнотой решения задач планирования, а также пользовательскими интерфейсами. 296 Кроме основных, были использованы и другие источники информации – различные информационные ресурсы, найденные с помощью поисковых систем. 1.10 Обзор выбранных систем планирования В данном подразделе представлен обзор систем планирования движения поездов, которые были найдены в процессе поиска: а) автоматизированная система управления железнодорожным транспортом с функциями поддержки принятия решений, устойчивая к чрезвычайным ситуациям; б) автоматизированная система управления перевозочным процессом железнодорожного транспорта в оперативном режиме; в) система управления железнодорожным трафиком в реальном времени: диспетчеризация в сложных, больших и нагруженных железнодорожных сетях. Были проанализированы также следующие проекты: а) направления развития железнодорожного транспорта в мире на основе интеллектуальных систем (по материалам IBM Institute for Business Value); б) проекты в области сетецентрических интеллектуальных систем управления железной дорогой в сша. Все данные системы были подробно изучены и проанализированы с точки зрения функциональных возможностей. По результатам анализа составлен краткий обзор разработок, включающий функциональные возможности систем и краткое заключение, отражающее общее впечатление о каждой разработке. Каждая из них имеет ту или иную важную особенность, реализует функциональные возможности или использует теоретические положения, которые могут быть полезны для исследования, проводимого по контракту. Далее приводится общий результат анализа, включающий список всех систем, близких к системе, разрабатываемой по контракту, с указанием того, что позволяет каждая из них. 1.10.1 Разработка устойчивой к чрезвычайным ситуациям автоматизированной системы управления железнодорожным транспортом с функциями поддержки принятия решений Целью исследования является обоснование принципов построения и реализация устойчивой к чрезвычайным ситуациям автоматизированной системы управления железнодорожным транспортом с функциями поддержки принятия решений. Предметом исследования в данной работе являются модели и методы поддержки принятия решений, алгоритмы 297 оценки решений, методы разработки систем поддержки принятия решений в соответствии с существующей организационно-функциональной структурой ЖДТ [14]. На основе специализированной модели, учитывающей основные объекты зарождения, передачи и потребления данных при управлении локомотивным хозяйством сети железных дорог, разработана модель процесса поддержки принятия решений в локомотивном хозяйстве, позволяющая определить основные элементы и этапы функционирования СППР локомотивного хозяйства, в том числе и в условиях чрезвычайных ситуаций (ЧС). На основе общего подхода к оценке эффективности управленческих решений разработан алгоритм оценки решения по критериям качества, где учтены основные классы критериев оценки управленческих решений в локомотивном хозяйстве, соответствующие иерархической системе стратегических целей развития локомотивного хозяйства. Предложена система поддержки принятия решений локомотивного хозяйства, соответствующая принятой организационно-функциональной структуре ОАО «РЖД» и учитывающая условия работы локомотивного хозяйства в ЧС. Разработана научно обоснованная структура АСУТ ОАО «РЖД» с функциями поддержки принятия решений, которая позволяет определять приоритетные направления развития указанной системы и методы реализации ее основных элементов на практике, в том числе и в условиях ЧС. За счет внедрения современных интенсивных технологий управления на базе информационно-аналитической системы с функциями поддержки принятия решений. повышается эффективность работы ОАО «РЖД» Замечания. В работе использованы методы системного анализа, математического моделирования, теории вероятностей и математической статистики, математические методы теории поддержки принятия решений, теории управления и теории множеств, а также методы проектирования систем управления. В данной работе рассматривается АСУ ЖДТ, основанная на иерархических принципах, в части управления работой локомотивного хозяйства, при этом не упоминается о реализации методов адаптивного планирования ресурсов локомотивного хозяйства в условиях ЧС, сетецентрический подход, мультиагентные технологии и онтологии в работе не применяются. Разрабатываемая система обеспечивает значительно более широкие функциональные возможности по управлению ресурсами ЖД за счет гибкой настройки стратегий и логики планирования под специфику работы различных подразделений ЖД и обеспечения согласованного принятия решений. 298 1.10.2 Автоматизированная система управления перевозочным процессом железнодорожного транспорта в оперативном режиме В данной работе рассматриваются принципы построения, функционирования и развития автоматизированной системы управления перевозочным процессом в оперативном режиме (АИСО), а также разработка практических решений по обеспечению эффективной работы ее управляющих устройств – диспетчерских центров ОАО «РЖД» на сетевом и дорожном (региональном) уровнях [15]. На основе принципов АСУ ТП отраслевого уровня создана автоматизированная система управления перевозочным процессом в оперативном режиме (АИСО) с использованием в качестве управляющих устройств иерархически структурированных диспетчерских центров ОАО «РЖД». На сетевом и дорожном уровнях практически осуществлен переход к интегрированному диспетчерскому оперативному управлению с учетом новых направлений деятельности – оперативного обеспечения функционирования элементов инфраструктуры, взаимодействия с внешней средой, решения специфических задач оперативного управления перевозочным процессом в условиях рыночной экономики. Внедрена подсистема слежения за текущим состоянием управляемых параметров (ОСКЛР-М) с использованием распределенных программно-технических комплексов в ЦУП и ДЦУП и реализацией функции активного пользовательского интерфейса. Разработана структура АИСО, как замкнутая система с обратной связью, включающая: управляемые объекты – совокупность потоков поездов, вагонов и грузов; управляющие устройства – иерархию диспетчерских центров сетевого (ЦУП) и дорожного (ДЦУП) уровней; исполнительные устройства. Управляющие решения принимаются на основе предложенной целевой функции оперативного управления, сравнения текущих значений контролируемых показателей с плановыми, учета внутренних и внешних возмущающих воздействий. Замечания. Методика исследования основана на положениях теории управления большими производственными системами, методах исследования операций, теории множеств, теории графов, теории надежности и математической статистики. Предложенный комплекс математических моделей элементов перевозочного процесса и порядок их разработки обеспечивают переход к наиболее эффективному решению имеющихся оптимизационных задач. В данной работе исследуются методы управления в системе, основанной на иерархических принципах, управляющие решения принимаются на основе решения оптимизационных задач на множестве контролируемых параметров. В данной работе, в отличие от разрабатываемого проекта, реализована замкнутая система управления с обратной связью, действующая на классических принципах с использованием моделей возмущающих воздействий 299 в виде математических функций. В отличие от разрабатываемой системы, сетецентрический подход, онтологическое описание предметной области и агентные технологии, позволяющие достичь значительно более высокой оперативности, гибкости и надежности в принятии решений в реальном времени, не используются. 1.10.3 Направления развития железнодорожного транспорта в мире на основе интеллектуальных систем (по материалам IBM Institute for Business Value) В течение ближайших 5 лет в США будет вложено 300 млрд. долларов глобальных инвестиций в обновление, расширение и строительство железных дорог. Рост инвестиций в железнодорожную отрасль происходит во всем мире [16]. Доход железнодорожной отрасли в США в 2012 прогнозируется на уровне $ 514 млрд., совокупный среднегодовой темп роста (CAGR) с 2007 г. до 2012 г. составит 3,3%. Мировой рынок железнодорожных перевозок вырос на 9 процентов с 2006 по 2007 г. и, как ожидается, прирост будет составлять 2,0-2,5 процента по сравнению в течение следующих 9 лет. В Азиатско-Тихоокеанском регионе CAGR будет расти в среднем на 6 процентов, в то время как в Китае CAGR с 2007 г. по 2012 г. составит 11,8%. В США объем грузовых железнодорожных перевозок увеличится на 88 % к 2035 году, что потребует около 148 млрд. долл. инвестиций для существующих линий. Европейский рынок пассажирских железнодорожных перевозок составит 116,5 млрд. долл. в 2012 году, увеличится на 19,3 процента с 2007 года, CAGR составит 3,6 %. Встроенный интеллект, применение методов анализа и оптимизации изменяют железнодорожную отрасль и предоставляют новые возможности. В то время как спрос на услуги железнодорожного транспорта растет, железнодорожная отрасль имеет уникальные возможности для развития инфраструктуры за счет использования технических средств, коммуникаций и интеллекта: а) технические средства – новое оборудование для слежения, сбора информации, оповещения и т.п., которое поможет повысить производительность труда, обеспечивая повышенную безопасность на железнодорожных линиях и безопасность для пассажиров: RFID, GPS, European Rail Traffic Management Signal (ERTMS), интеллектуальные системы видеонаблюдения и т.п. б) средства коммуникаций – объединяют транспортные системы в сети железных дорог, что приведет к обеспечению своевременного принятия решений по таким вопросам, как управление движением поездов, безопасность и техническое обслуживание: высокоскоростные и беспересадочные пассажирские перевозки, грузоперевозки по расписанию и т.п. 300 в) интеллектуальные системы – предназначены для сбора, анализа и обработки соответствующей информации с целью обеспечения более эффективного планирования, принятия решений, оповещения и управления. Железнодорожная компания 21 века концептуально рассматривается как железнодорожная экосистема – сложная глобальная система, состоящая из внутренней сети железных дорог и внешней сети железных дорог. Внутренняя железнодорожная сеть состоит из транспортных средств, инфраструктуры и сотрудников. Внешняя сеть железных дорог включает в себя широкую сеть поставщиков грузов, поставщиков логистических услуг, интермодальных перевозчиков, регулирующих органов и клиентов. «Разумная» железнодорожная дорога базируется на интеллектуальных системах, объединенных в коммуникационные сети в рамках железнодорожной экосистемы. Информация должна совместно использоваться всеми заинтересованными сторонами, включая железнодорожные компании, грузоотправителей, муниципалитеты, интермодальных перевозчиков и клиентов. Интеллектуальные системы на железнодорожном транспорте, использующие интегрированную информацию, сложную аналитику и моделирования данных, повысят эффективность стратегических и оперативных решений. Мобильные системы мониторинга технического состояния будут обеспечивать в реальном времени непрерывный сбор и анализ критически важных параметров, обнаружение повреждений и чрезвычайных ситуаций. Подсистемы моделирования и аналитики должны интерпретировать полученную информацию и распространять ее в диспетчерские службы для удаленной диагностики, планирования технического обслуживания и перепланирования расписания движения поездов. Замечания. Исследования тенденций развития железнодорожной отрасли во всем мире, проведенные компанией IBM, свидетельствуют о том, что одним из приоритетных направлений является развитие интеллектуальных систем на базе современных информационных и коммуникационных технологий, что подтверждает актуальность разработки по контракту и соответствие мировому уровню реализуемого в проекте сетецентрического подхода к планированию на базе мультиагентных технологий, основанных на знаниях. 1.10.4 Система управления железнодорожным трафиком в реальном времени: диспетчеризация в сложных, больших и нагруженных железнодорожных сетях В данной работе рассматривается система поддержки принятия решений для управления железнодорожным транспортом ROMA (Railway traffic Optimization by Means of Alternative graphs), которая реализована в Голландии [17]. Эта система предоставляет продвинутые средства поддержки принятия решений, что позволяет точно контролировать текущее положение поезда и динамику его перемещения в реальном времени, предсказывать 301 потенциальные конфликты и перепланировать расписание поездов в режиме реального времени, чтобы задержки были сведены к минимуму. Диспетчер может взаимодействовать с системой поддержки принятия решений ROMA, добавляя/удаляя ограничения или вводя изменения в расписание движения поездов. ROMA реализует следующие функции: а) загрузка данных: существующая инфраструктура, статус поезда, существующее расписание, фактическое положение и скорость всех поездов; б) прогнозирование времени, необходимого для завершения следующей запланированной операции (например, задержка поезда в сети, длительность непредвиденной ситуации и т.д.), точное местоположение и скорость каждого поезда обновляются в режиме реального времени; в) определение маршрута для каждого поезда, чтобы исключить блокирование участков пути на данном направлении; г) постоянная оптимизация трафика: на основе набора динамических стратегий управления трафиком, при поступлении новых заказов и возникновении непредвиденных ситуаций, производится реструктуризации и/или изменение маршрута поезда с целью минимизации задержек поездов в сети и построения бесконфликтного расписания поездов; д) автоматическое формирование расписания и инфраструктуры данных; е) обнаружение и разрешение возможных конфликтов на блок-участках; ж) разработка альтернативных вариантов расписания поезда в режиме реального времени на взаимосвязанных блок-участках маршрута; и) удобный графический интерфейс между системой ROMA и диспетчером. Процедура планирования маршрута движения поезда возвращает оптимальное решение, когда достигнуто ограничение на максимальную продолжительность времени вычислений, или нет возможности улучшить сформированные маршруты. ROMA использует следующие алгоритмы планирования на графах: а) алгоритм ветвей и границ ( ВВ) – этот алгоритм исследует все возможные маршруты и выбирает маршрут по критерию минимизации суммарного времени задержек. Усеченный алгоритм ветвей и границ возвращает график, близкий к оптимальному, для задач большой размерности при ограничении на время вычислений. б) алгоритм поступления заявок согласно дисциплине «первым пришел – первым обслужен» (FCFS) – это известное правило диспетчерского управления, которое дает приоритет поезду, который первым прибыл на блок-участок, т.е. поезда проходят в 302 соответствии с фактическим порядком прибытия и не обязательно, как в расписании. Централизованная система поддержки принятия решений ROMA интегрируется в распределенную структуру. Каждый диспетчерский район находится в ведении местной системы ROMA, в то время как проблема координации смежных областей решается с использованием распределенного подхода. Каждая местная система ROMA формирует решение для своей области. На границе между областями система получает информацию по трафику потоков на границе между областями и использует ее для получения решения, соответствующего соседней области, которое передается для уточнения системе ROMA соседней области. Такие распределенные параллельные вычисления поддерживаются стандартным протоколом связи. Замечания. Система управления железнодорожным трафиком ROMA решает задачу согласованного планирования и перепланирования расписания движения поездов в одной области диспетчерского управления и в нескольких соседних областях. Однако, в отличие от системы, разрабатываемой по контракту, использует классические алгоритмы оптимизации на графах для составления оптимального расписания движения поездов. Сетецентрический подход и интеграционная платформа для реализации распределенного управления в сети железных дорог не используются. Взаимодействие между системами ROMA в географически соседних областях реализуется за счет стандартных протоколов связи. В системе ROMA не используются онтологии для индивидуальной настройки параметров ресурсов через учет различных стратегий и критериев, предпочтений и ограничений каждого участника планирования. 1.10.5 Сетецентрические интеллектуальные системы управления железной дорогой Сетецентрические системы железнодорожного транспорта и интеллектуальных систем железнодорожного транспорта представляют собой единую систему управления железнодорожным транспортом, в которой системы позиционирования, датчики, компьютеры, современные математические методы и цифровые коммуникации, используются для сбора, обработки и распространения информации в целях повышения безопасности, эффективности и производительности железных дорог. Интеллектуальные железнодорожные системы могут быть реализованы как независимые системы, и в этом случае их преимущества будут ограничены, или они могут быть реализованы в виде комплексных «систем систем», в этом случае их преимущества будут усиливаться. 303 Источники [18-20] описывают современный уровень исследований и разработок в области сетецентрических интеллектуальных систем управления железной дорогой в США. Cистемы управления железной дорогой, основанные на сетецентрическом подходе, представляют собой «системы систем», в которых реализовано взаимодействие многих систем и интеграция многих процессов. Железнодорожные сетецентрические системы включают: а) Цифровые сети связи, предоставляющие средства для передачи информации и команд управления между узлами всей железной дороги, а также локомотивами, вагонами, переездами, рабочими, датчиками на путях, диспетчерскими центрами, сортировочными станциями, интермодальными терминалами, пассажирскими станциями, станциями технического обслуживания и т.д.; б) Global Positioning System (GPS), определяющие местоположение объектов с точностью до 1 м; в) Radio Frequency Identification (RFID), выполняющие функции контроля за движением объектов; г) Positive Train Control (PTC) системы для управления движением поездов, обеспечивающего безопасность, точность и эффективность движения; д) PTC displays для отображения информации о состоянии поезда и команд управления й в графической и текстовой форме; е) Track Forces Terminals (TFT) – мобильные устройства для отображения информации и представления инструкций путевым работникам и рабочим, обслуживающим поезда; ж) Датчики движения, установленные на поездах; и) Датчики, установленные на локомотивах для определения их рабочих характеристик; к) Системы управления мощностью двигателей (EMS) – отдельные компьютерные программы, установленные на локомотивах для оптимизации расхода топлива и выбросов; л) Системы для отправки инструкций по цифровой линии передачи данных в сети связи из центра управления движением поездов поездным бригадам; м) Системы тактического планирования движения в центрах управления движением поездов составляют схемы, показывающие, когда поезда должны прибыть в каждый пункт на территории диспетчерского круга, где поезда должны встретиться и пройти, и какие подъездные пути необходимо обеспечить для приема и пропуска составов; 304 н) Системы стратегического планирования движения, которые предоставляют рас- писание каждого поезда для Систем тактического планирования; п) Интеллектуальные системы прогнозирования погоды; р) Системы аварийного оповещения; с) Системы планирования расписания локомотивов с учетом данных о расписании поездов, местности, характеристик локомотив; т) Системы планирования работы поездных бригад; у) Системы управления сортировочной станцией; ф) Системы позиционирования мобильных железнодорожных ресурсов, передающие информацию в режиме реального времени. Сетецентрические железнодорожные системы позволят управлять непредвиденными ситуациями, предоставляя в режиме реального времени информацию о текущей деятельности и текущей ситуации. Это позволит менеджерам и диспетчерам иметь больше знаний о состоянии всей железной дороги, тем самым повышая эксплуатационную безопасность и защиту инфраструктуры. Информация будет приходить лицам, принимающим решения, которые имеют возможность принять корректирующие меры. Клиенты получат значительные выгоды от улучшения работы железной дороги, повышения качества и надежности предоставляемых услуг, что приведет к увеличения доходов железнодорожных компаний. Таким образом, повышение безопасности железной дороги, эффективности и прибыльности являются достижимыми с использованием сети интеллектуальных систем управления железнодорожными операциями. Замечания. Использование интеллектуальных сетецентрических систем обеспечивает: а) использование среды интегрированной цифровой передачи данных, систем позиционирования, датчиков и компьютеров на железные дороги; б) улучшение безопасности; в) повышение эффективности использования ресурсов; г) повышение удовлетворенности клиентов; д) измерение и контроль затрат ресурсов; е) сокращение потребления энергии и выбросов вредных веществ; ж) увеличение рентабельности и прибыли железнодорожных компаний; и) своевременную реакцию на непредвиденные события. Разрабатываемая по контракту система также использует сетецентрический подход и распределенное принятие решений для разработки полного цикла реакции на события, планирования и исполнения планов в реальном времени в рамках метода согласованного адап305 тивного управления расписанием движением поездов, мониторинга инфраструктуры, подвижного состава и персонала железной дороги, что позволяет сделать вывод о соответствии разработок мировому уровню. В отличие от сетецентрических систем, описанных в [18-20], система, разрабатываемая по контракту, использует преимущества мультиагентных технологий для организации согласованного принятия решений: если проблема не может быть решена локально планировщиком одного подразделения ЖД, агенты вступают в переговоры с системами управления подразделений, участвующих в коллективном принятии решения. При этом возмущающее воздействие, зафиксированное в одной из систем управления, может вызвать волну перепланирования взаимосвязанных расписаний ресурсов в тех подразделениях, с которыми данное подразделение взаимодействует. Таким образом, проблема решается настолько локально, насколько возможно, и так глобально, как требуется. В отличие от рассмотренных систем, в проекте, разрабатываемом по контракту, сетецентрическая интеллектуальная система использует онтологическое представление знаний о ресурсах, описание стратегий, ограничений и логики принятия решений для согласованного планирования ресурсов ЖД, способных к коллективному взаимодействию в реальном времени. Разрабатываемая система обеспечивает повышение обоснованности и достоверности результатов долгосрочного и оперативного планирования ресурсов с учетом действующих технологических или бизнес-процессов, регламентов взаимодействия сотрудников, имеющихся в наличии ресурсов, компетенций и опыта специалистов, а также продолжительности выполнения операций; Разрабатываемая система обеспечивает повышение оперативности в принятии решений, в частности, сокращение времени реакции на непредвиденные события, требующей согласованного изменения планов путем цепочек изменений, подвижек и перераспределения задач с учетом связей между операциями в реальном времени. 1.11 Результаты исследования непатентных источников Проведенный по непатентным источникам анализ имеющихся в России и во всем мире систем и долгосрочных проектов развития железных дорог показал, что стратегические и тактические направления развития отрасли в целом заключаются в том, чтобы обеспечить новые высокоэффективные технологии использования подвижного состава, управления движением, многоуровневую структуру предоставления информации, обеспечивающую решение задач мониторинга технических средств и технологических процессов. Среди таких передовых технологий можно отметить следующие: а) разработка систем поддержки принятия решений, имеющих распределенную архитектуру, с целью повышения качества и надежности перевозочного процесса; 306 б) все более широкое использование интеллектуальных систем во всех аспектах деятельности железной дороги; в) применение сетецентрического подхода для интеграции множества железнодорожных процессов. Цель применения новых технологий планирования и оптимизации перевозок состоит в том, чтобы решить основную задачу обеспечения перевозок пассажиров и грузов в соответствии с принципами «точно в срок» и «от двери до двери». 1.12 Выводы В соответствии с техническим заданием по этапу №3 НИР было проведено патентное исследование и исследование непатентных источников в следующих областях: а) контроль и управление процессами, связанными с планированием ресурсов; б) разработка интеллектуальных систем для поддержки принятия решений по управлению перевозочным процессом и ресурсами РЖД; в) разработка сетецентрического подхода к созданию интеллектуальных систем управления ресурсами подразделений железной дороги. Релевантные патенты были найдены в базах данных следующих организаций: Бюро по патентам и товарным знакам США, Европейского патентного бюро, Всемирной организации интеллектуальной собственности. На основании изучения непатентных источников был выделен ряд систем диспетчерского управления, которые реализуют функции по составлению расписания и перепланированию движения поездов в случае отклонения от графика, а также направления развития интеллектуальных систем управления железной дорогой на основе сетецентрического подхода: а) автоматизированная система управления железнодорожным транспортом с функциями поддержки принятия решений, устойчивая к чрезвычайным ситуациям; б) автоматизированная система управления перевозочным процессом железнодорожного транспорта в оперативном режиме; в) система управления железнодорожным трафиком в реальном времени: диспетчеризация в сложных, больших и нагруженных железнодорожных сетях. г) направления развития железнодорожного транспорта в мире на основе интеллектуальных систем (по материалам IBM Institute for Business Value); д) проекты в области сетецентрических интеллектуальных систем управления железной дорогой в США. По результатам анализа патентных и непатентных источников, а также изучения функциональности приведенных выше систем можно сделать следующие выводы: 307 а) разрабатываемая по контракту интеллектуальная система для согласованного адаптивного планирования движения поездов решает актуальную задачу для мировой практики управления железнодорожным пассажирским движением и, в частности, высокоскоростных пассажирских перевозок; б) интеллектуальная система для согласованного адаптивного планирования движения поездов, основанная на принципах сетецентризма, соответствует мировому уровню разработок в данной области; в) в разделах МПК и среди непатентных источников не найдено патентов и систем, препятствующих разработке по контракту; г) системы, в определенной степени релевантные разрабатываемой по контракту и предназначенные для выполнения соответствующих функций, реализуют алгоритмы планирования и составления расписаний, основанные на классических методах оптимизации; д) среди рассмотренных систем не обнаружены системы, которые бы использовали мультиагентные технологии для управления производственными процессами железной дороги; За счет использования сетецентрического подхода, основанного на онтологиях и мультиагентных технологиях, в системе, разрабатываемой по контракту, обеспечиваются важные преимущества над релевантными системами: а) cтратегическое интерактивное планирование и оптимизацию использования ресурсов сортировочной станции на значительный период времени (маневровые локомотивы, вагоны, бригады, пути и другие); б) оперативное адаптивное планирование и перепланирование ресурсов для формирования и роспуска составов для обеспечения формирования с целью сокращения времени простоя под накоплением в реальном времени с быстрой, оперативной и гибкой реакцией на непредвиденные события (задержки, поломки ресурсов и т.д.); в) индивидуальный подход для каждого заказа и ресурса через учет различных стратегий и критериев, предпочтений и ограничений каждого участника; г) согласование решений с лицами, принимающими или исполняющими решения, через двустороннее взаимодействие с пользователями; д) интерактивное управление планами в автоматическом, полуавтоматическом и ручном режиме в реальном времени; е) моделирование использования ресурсов на основе создаваемых планов по принципу «если-то» на исторических или модельных данных; 308 ж) ручная и полуавтоматическая доработка планов ресурсов без останова и перезапуска системы, путем корректировки расписания «на лету» с использованием как свободных окон, так и подвижками и переброской ранее распределенных заказов (задач) з) поддержка взаимодействия и передачи данных в сети планировщиков для согласования принимаемых решений по планированию ресурсов ЖД; и) создание, автоматическая корректировка, согласование и утверждение связанных оперативных планов работы исполнителей в различных подразделениях ЖД; к) проведение одновременного анализа нескольких вариантов планирования с соответствующим распределением ресурсов в целях оптимизации. 309 ЗАКЛЮЧЕНИЕ Таким образом, после проведения анализа существующих патентов, систем диспетчерского управления и составления расписания движения поездов, был сделан вывод, что на данный момент нет полных аналогов предлагаемой мультиагентной технологии адаптивного планирования и связанного изменения планов движения поездов, построенных с применением онтологий и сетецентрического подхода. Кроме того, тенденции имеющихся на рынке разработок подтверждают правильность выбранного направления, поскольку демонстрируют появление новых более интеллектуальных возможностей согласованного управления всей железнодорожной инфраструктурой. Среди имеющихся на рынке систем управления движением поездов следует выделить, прежде всего, систему ROMA, в которой реализованы средства поддержки принятия решений, позволяющие точно контролировать текущее положение поезда и динамику его перемещения в реальном времени, предсказывать потенциальные конфликты и перепланировать расписание поездов в режиме реального времени, чтобы задержки были сведены к минимуму (см. пункт 1.10.4). Необходимо отметить также перспективные разработки, проводимые в США в области использования сетецентрического подхода к созданию интеллектуальных систем управления ресурсами и подразделениями железной дороги (см. пункт 1.10.5). Анализ направлений развития железных дорог в мире (см. пункт 1.10.3) показал, что наиболее перспективной тенденцией является разработка интеллектуальных систем управления ресурсами и производственными процессами железной дороги, которые взаимодействуют и интегрируются между собой для решения задач планирования, мониторинга, реакции на непредвиденные события и чрезвычайные ситуации. Можно утверждать, что на данном этапе исследования рассмотренные системы являются ближайшими аналогами мультиагентной системы адаптивного управления и связанного изменения планов движения поездов. Во всех этих системах с очевидностью проявляется тенденция интеллектуализации управления всеми аспектами железнодорожных перевозок. Опыт разработки рассмотренных систем безусловно станет важным основанием для проведения настоящей разработки. Вместе с тем, можно отметить, что прямых аналогов разрабатываемой технологии и программного продукта среди всех рассмотренных готовых к использованию программных решений не обнаружилось. Ни одна из рассмотренных систем не использует в комплексе мультиагентные технологии и сетецентрическую программную платформу для создания единой информационной среды, обеспечивающей автоматизацию выполнения и контроля 310 сквозных производственных процессов железной дороги и высокую адаптивность к реализации перспективных задач в условиях динамически изменяющейся внешней среды. 311 СПИСОК ИСПОЛЬЗУЕМЫХ ИСТОЧНИКОВ 1) ГОСТ Р 15.011-96 «Система разработки и постановки продукции на производство. Патентные исследования». 2) Патентный закон Российской Федерации [Электронный ресурс] / . – Электрон. журн. – М.: Патентный закон Российской Федерации. – Режим доступа: http://nalog.consultant.ru/doc58232.html, свободный. – Загл. с экрана. – Яз. рус. 3) Транспортная стратегия Российской Федерации на период до 2030 года [Электронный ресурс] / . – Электрон. каталог.– Режим доступа: http://rosavtodor.ru/information/Osnovnye_dokumenty/transportnaya_strategiya_rf_na _period__do_2030_goda.html , свободный. – Загл. с экрана. – Яз. рус., англ. 4) Белая книга ОАО «РЖД». – 2010. 5) G.Rzevski. Multi-Agent Technology: An Introduction // Lecture notes, 2006. 6) V. Andreev, A. Glashchenko, A. Ivashchenko, S. Inozemtsev, G. Rzevski, P. Skobelev, P. Shveykin Magenta Multi-Agent Systems for Dynamic Scheduling - First International Conference on Agents and Artificial Intelligence (ICAART 2009). - Portugal, January 2009. 7) M. Andreev, A. Ivaschenko, P. Skobelev, A. Tsarev Multi-Agent Platform Design for Adaptive Networks of Intelligent Production Schedulers. 10-th International IFAC Workshop on Intelligent Manufacturing Systems, Lisbon, Portugal, 2010. 8) Скобелев П.О.. Мультиагентные технологии в промышленных применениях: к 20летию основания Самарской научной школы мультиагентных систем. Мехатроника, автоматизация, управление (МАУ) – 2010, №12. 9) А.В. Иващенко, О.В. Карсаев, П.О. Скобелев, А.В. Царев, Р.М. Юсупов. Мультиагентные технологии для разработки сетецентрических систем управления. – Известия ЮФУ. Технические науки, ISSN 1999-9429, №3 (116), 2011, стр. 11-23. 10) US Patent №10/755,246 – Adaptive network-centric online autonomic supply chain management system, Adaptive network-centric online autonomic supply chain management system 11) US Patent № 10/811,460 – System and method for adaptive path planning, System and method for adaptive path planning 12) US Patent № US2004111309 – Resource schedule for scheduling rail way train resources, Resource schedule for scheduling rail way train resources 312 13) Patent № EP2423070 – Method for optimizing parameters of multiple rail vehicles operating over multiple intersecting railroad networks, Method for optimizing parameters of multiple rail vehicles operating over multiple intersecting railroad networks 14) Катцын Дмитрий Владимирович. Разработка устойчивой к чрезвычайным ситуациям автоматизированной системы управления железнодорожным транспортом с функциями поддержки принятия решений : диссертация ... кандидата технических наук : 05.13.10 / Катцын Дмитрий Владимирович; [Место защиты: С.Петерб. гос. ун-т ГПС МЧС России].- Санкт-Петербург, 2008.- 284 с.: ил. РГБ ОД, 61 09-5/991. 15) Поплавский Андрей Адольфович. Автоматизированная система управления перевозочным процессом железнодорожного транспорта в оперативном режиме : сетевой и региональный уровни : автореферат дис. ... доктора технических наук : 05.13.06, 05.22.08 / Поплавский Андрей Адольфович; [Место защиты: Моск. гос. ун-т путей сообщ. (МИИТ) МПС РФ]. - Москва, 2009. - 47 с. РГБ ОД. 16) Keith Dierkx. The smarter railroad. An opportunity for the railroad industry. – Режим доступа: http://www.ibm.com/smarterplanet/global/files/cz__cz_cs__rail__ideas_rail.pdf 17) Francesco Corman. Real-time Railway Traffic Management: dispatching in complex, large and busy railway networks. - TRAIL Thesis Series T2010/14, the Netherlands TRAIL Research School. – pp. 212. 18) Steven R. Ditmeyer. Network Сentric Railroading Utilizing Intelligent Railroad Systems. World Bank Transport Forum 2006 “Rail Transport for Development”. March 31, – 2006. Режим доступа: http://siteresources.worldbank.org/INTTRANSPORT/Resources/3362911152714163458/2744896-1152794646430/ditmeyer2.pdf 19) Alford, Kenneth L. and Steven R. Ditmeyer, “Network-Centric Operations: Defense and Transportation Synergy”. CROSSTALK: The Journal of Defense Software Engineering, January 2007. pp. – 20-23. Режим доступа: http://www.crosstalkonline.org/storage/issue-archives/2007/200701/200701-Alford.pdf 20) Steven R. Ditmeyer. Network-Сentric Railways Operations Utilizing Intelligent Railway Systems. Journal of Transportation Law, Logistics and Policy. 2010. Volume 77, Number 3. pp. 197-219. – Режим доступа: http://www.transportation.northwestern.edu/docs/2011/2011.03.15.Ditmeyer_Paper.pdf . 313 ПРИЛОЖЕНИЕ 2.1 (обязательное к отчету о патентных исследованиях) ФОРМА ЗАДАНИЯ НА ПРОВЕДЕНИЕ ПАТЕНТНЫХ ИССЛЕДОВАНИЙ УТВЕРЖДАЮ Руководитель работ, Директор по разработкам ООО "НПК "Разумные решения" П.О. Скобелев 16.06. 2012 г. ЗАДАНИЕ № 2012.06.16-01 на проведение патентных исследований Наименование работы (темы): Разработка и исследование прототипа интеллектуальной системы для согласованного адаптивного планирования и связанного изменения планов движения поездов для минимизации отклонения высокоскоростных поездов класса “Сапсан” от графика движения под влиянием непредвиденных внешних событий в рамках исполнения ГК от «17» октября 2011 г. №07.514.11.4094 Шифр работы (темы): 2011-1.4-514-125-063. Этап работы №1 (промежуточный): Выбор направления исследований. Теоретические исследования поставленных перед НИР задач. Сроки выполнения: 16.06.2012-10.08.2012. Задачи патентных исследований: определение уровня развития техники и патентоспособности разрабатываемой технологии, получение сведений об охранных и иных документах, которые могут препятствовать применению этих результатов на территории Российской Федерации. КАЛЕНДАРНЫЙ ПЛАН Виды патентных ис- Подразделенияследований исполнители Ответственные исполнители Определение уровня развития техники и патентоспособности Симонова Е.В. Генеральный директор ООО "НПК "Разумные решения" Сроки выполнения патентных исследований 16.06.201210.08.2012 А.В. Царев 314 Отчётные документы Отчёт о патентных исследованиях 16.06.2012 ПРИЛОЖЕНИЕ 2.2 (обязательное к отчету о патентных исследованиях) ФОРМА РЕГЛАМЕНТА ПОИСКА РЕГЛАМЕНТ поиска № 2012.06.16-02 16 июня 2012 г. 1 Контроль и 2 Рос- 315 Классификационные индексы Ретроспективность Код товара: ГС*, СМТК*, БТН* Наименование Наименование Рубрики УДК* и другие (объект исследо- Стра вания, его сона ставные части, потовар) иска Источники информации, по которым будет проводиться поиск патентные НТИ* конъ- другие юнкгурные Наименование Классификационные рубрики: МПК (МКИ)*, МКПО*, НКИ* и другие 3 4 5 6 7 8 9 10 База данных Феде- B61L - - Наименование Предмет поиска 11 20 Наименование информационной базы (фонда) Наименование работы (темы): Разработка и исследование прототипа интеллектуальной системы для согласованного адаптивного планирования и связанного изменения планов движения поездов для минимизации отклонения высокоскоростных поездов класса “Сапсан” от графика движения под влиянием непредвиденных внешних событий в рамках исполнения ГК от «17» октября 2011 г. №07.514.11.4094 Шифр работы (темы): 2011-1.4-514-125-063. Этап работы №1 (промежуточный): Выбор направления исследований. Теоретические исследования поставленных перед НИР задач. Номер и дата утверждения задания: 2012.06.16-01 – 16.06.2012 Цель поиска информации: формирование перечня документов, которые потенциально могут нарушить патентоспособность разрабатываемой технологии и препятствовать их применению на территории Российской Федерации. Обоснование регламента поиска: поиск должен проводиться через сеть Интернет в базах данных Федеральной службы по интеллектуальной собственности, патентам и товарным знакам Российской Федерации, Бюро по патентам и товарным знакам США, Европейского патентного бюро и Всемирной организации интеллектуальной собственности. Начало поиска: 16.06.2012 Окончание поиска: 10.08.2012 12 Роспа- управление процессами, связанными с планированием ресурсов. Планирование задач с помощью мобильных устройств. Применение мобильных устройств для адресного доступа к сервисам. сия, США , Европа ральной службы по интеллектуальной собственности, патентам и товарным знакам РФ, Бюро по патентам и товарным знакам США, Всемирной организации интеллектуальной собственности, Европейского патентного бюро. лет 27/00 B61L 27/02 B61L 27/04 G08G G06F тент, www.fip s.ru. USPTO, www.usp to.gov. ВОИС, www.wi po.int EPO, www.epo .org ___________ *МПК (МКИ) — международная патентная классификация (международная классификация изобретений); НКИ — национальная классификация изобретений; МПКО — международная классификация промышленных образцов; НТИ — научно-техническая информация; ГС— гармонизированная система (гармонизированная товарная номенклатура); СМТК — стандартная международная торговая классификация ООН; Руководитель работ, директор по разработкам ООО "НПК "Разумные решения" П.О. Скобелев Генеральный директор ООО "НПК "Разумные решения" А.В. Царев Руководитель патентного подразделения, ведущий аналитик ООО "НПК "Разумные решения" А.Р. Диязитдинова 316 ПРИЛОЖЕНИЕ 2.3 (обязательное к отчету о патентных исследованиях) ФОРМА ОТЧЕТА О ПОИСКЕ ОТЧЁТ о поиске № 2012.06.16-03 B1. Поиск проведён в соответствии с заданием руководителя работ, директора по производству ООО «НПК «Разумные решения» Скобелева П.О. на проведение патентных исследований № 2012.06.16-01 от 16 июня 2012 г. и регламентом поиска № 2012.06.16-02 от 16 июня 2012 г. в рамках выполнения ГК от «17» октября 2011 г. №07.514.11.4094 B2. Этап работы №3 (заключительный): Обобщение и оценка результатов исследований B3. Начало поиска: 16 июня 2012 г. Окончание поиска: 10 августа 2012 г. B4. Сведения о выполнении регламента поиска: поиск выполнен полностью. Документов, которые могут препятствовать применению разрабатываемой технологии на территории Российской Федерации, найдено не было. B5. Материалы, отобранные для последующего анализа, отсутствуют. Таблица П2.3.2 - Патентная документация Заявитель (патентоСтрана выдачи, вид Предмет поиска обладатель), страна. и номер охранного (объект исследоНомер заявки, дата документа. Классивания, его составприоритета, конвенфикационный инные части) ционный приоритет, декс* дата публикации* 1 2 3 Сведения о действии охранного доНазвание кумента или изобретения причина его (полной мо- аннулирования дели, образца) (только для анализа патентной чистоты) 4 5 4) Контроль и US Patent № Kenneth Jongebloed, Adaptive net- управление про- 10/755,246, current Inc. (Cocoa Beach, work-centric 317 действителен цессами, связан- US Class: 235/385, ными с планиро- current International FL), USA online autonomic supply ванием ресурсов; Class: G06F 19/00 chain man- 5) Разработка мо- (20060101) agement sys- делей индивиду- tem ального планиро- US Patent № Raytheon Company вания ключевых (Waltham, MA), USA method for 10/811,460, current System and ресурсов; инфра- US Class: 701/301; adaptive path структуры РЖД; current International planning 6) Интеллек- Class: G08G 1/16 действителен туальные системы (20060101) управления ж/д транспортом; 7) Сетецентрический подход к реализации интеллектуальных систем управления ж/д транспортом Patent № EP0796778 HARRIS CORPORA- Method for (A1), current Interna- TION planning and tional Class: operating a B61L21/00 railway system based on a formal description of the track network 318 действителен Patent № EP2423070, GENERAL ELEC- Method for current International optimizing pa- TRIC COMPANY Class: B61L 27/00 действителен rameters of multiple rail vehicles operating over multiple intersecting railroad networks * Заполняется при необходимости. Таблица П2.3.2 - Научно-техническая, конъюнктурная, нормативная документация и материалы государственной регистрации (отчеты о научно-исследовательских работах) Предмет поиска 1 Наименование источниАвтор, фирма (держака информации с указатель) технической донием страницы источникументации ка 2 3 Год, место и орган издания (утверждения, депонирования источника) 4 4) Контроль и Разработка устойчивой к Катцын Дмитрий Вла- С.-Петерб. гос. ун-т управление про- чрезвычайным ситуаци- димирович. ГПС МЧС России.- цессами, связан- ям автоматизированной С.-Петерб. гос. ун-т Санкт-Петербург, ными с планиро- системы управления же- ГПС МЧС России 2008.- РГБ ОД, 61 09- ванием ресурсов; лезнодорожным транс- 5/991 5) Разработка мо- портом с функциями делей индивиду- поддержки принятия ального планиро- решений: диссертация ... вания ключевых кандидата технических ресурсов инфра- наук: 05.13.10 структуры РЖД; Автоматизированная си- Поплавский Андрей Моск. гос. ун-т путей 6) Интеллек- стема управления пере- Адольфович. сообщ. (МИИТ) МПС туальные системы возочным процессом Моск. гос. ун-т путей РФ. - Москва, 2009. управления ж/д сообщ. (МИИТ) МПС РГБ ОД железнодорожного 319 транспортом; транспорта в оператив- 7) Сетецентри- ном режиме : сетевой и ческий подход к региональный уровни : реализации ин- автореферат дис. ... док- теллектуальных тора технических наук : систем управле- 05.13.06, 05.22.08 РФ ния ж/д транспор- The smarter railroad. An Keith Dierkx. том IBM Company opportunity for the rail- Электрон. ресурс road industry Real-time Railway Traffic Francesco Corman. TRAIL Thesis Series Management: dispatching The Netherlands TRAIL T2010/14, the Netherin complex, large and busy Research School lands TRAIL Research railway networks School. Network Сentric Railroad- Steven R. Ditmeyer. World Bank Transport ing Utilizing Intelligent Michigan State Universi- Forum 2006 «Rail Railroad Systems. ty Transport for Development». March 31, 2006. Network-Centric Opera- Alford, Kenneth L. and CROSSTALK: The tions: Defense and Trans- Steven R. Ditmeyer. Journal of Defense Soft- portation Synergy Michigan State ware Engineering, Janu- University ary 2007. pp. 20-23. Network-Сentric Railways Steven R. Ditmeyer. Journal of Transportation Operations Utilizing Intel- Michigan State Universi- Law, Logistics and Poliligent Railway Systems ty cy. 2010. Volume 77, Number 3. pp. 197-219. 320 Таблица П2.3.2 -Перечень покупных комплектующих изделий, по которым запрошена документация Запрашиваемая документация (Ответ о Дата заНаименование и обо- ПИ, выписка из Отпроса. значение покупных чета, ТУ, ПФ, выРеквизиты комплектующих из- писка из ПФ)*. Цель письма делий получения запрашизапроса ваемой документации 1 2 3 - - - Вид и номер до- Наименование закумента, полу- прашиваемой орченного при заганизации или просе или причипредприятия с на отказа. Рекви- указанием местозиты письманахождения (адответа рес) 4 5 - - * ПИ - патентные исследования; ТУ - технические условия; ПФ - патентный формуляр. Руководитель работ, директор по разработкам ООО "НПК "Разумные решения" П.О. Скобелев Генеральный директор ООО "НПК "Разумные решения" А.В. Царев Руководитель патентного подразделения, ведущий аналитик ООО "НПК "Разумные решения" А.Р. Диязитдинова 321 ПРИЛОЖЕНИЕ 2.4 (к отчету о патентных исследованиях) Аннотации документов и другие справочные материалы, отобранные при проведении поиска согласно РЕГЛАМЕНТУ № 2012.06.16-02 20 июня 2012 г. Документ Аннотация Патент США №10/755,246 «Адап- Патент описывает гибкую, адаптивную, тивная сетецентрическая интеллекту- авто- альную сетецентрическую систему управления цепоч- номная система управления це- ками поставок в реальном времени, в которой полный почками поставок в реальном цикл планирования поставок с жестко ограниченными времени». Владелец: Kenneth сроками выполняется в автоматическом или полуавто- Jongebloed, Inc. (Cocoa Beach, FL) матическом режимах Патент США №10/811,460 «Си- Патент описывает систему для адаптивного планировастема и метод адаптивного плани- ния пути перемещения транспортного средства в реальрования пути». Владелец: ном времени, в динамично изменяющейся и неопреде- Raytheon Company (Waltham, MA) ленной среде с вероятностным описанием препятствий движению. Планирование пути движения транспортного средства в пространстве состояний от исходной позиции до целевой позиции выполняется за счет построения вероятностного дерева в пространстве состояний движущегося объекта Патент США №US2004111309 Рассматривается система планирования железнодорож- «Расписание ресурсов для систе- ных перевозок, в которой реализован метод перемещемы планирования железнодорож- ния движущихся объектов в системе многопутных женых поездов». Владелец: HARRIS лезных дорог. Система планирования использует пла322 нировщик, основанный на минимизации ресурсов и гло- CORPORATION бальных издержек, связанных с принятым решением Патент № EP2423070 «Метод оп- Патент рассматривает метод расчета параметров поезда, тимизации параметров управле- с учетом параметров других поездов в железнодорожния несколькими поездами в пе- ной сети для определения оптимальных параметров на ресекающихся железнодорожных определенном участке пути движения поезда. Метод сетях». Владелец: GENERAL также включает перепланирование оптимальных пара- ELECTRIC COMPANY метров поезда при изменении ситуации на текущем участке дороги и на пересекающихся участках Автореферат дис. «Разработка Описываются принципы построения и реализация устойчивой к чрезвычайным ситу- устойчивой к чрезвычайным ситуациям автоматизироациям автоматизированной систе- ванной системы управления железнодорожным трансмы управления железнодорожным портом с функциями поддержки принятия решений. транспортом с функциями под- Предметом исследования в данной работе являются модержки принятия решений» дели и методы поддержки принятия решений, алгоритмы оценки решений, методы разработки систем поддержки принятия решений в соответствии с существующей организационно-функциональной структурой ЖДТ Автореферат дис. «Автоматизиро- Описываются принципы построения, функционироваванная система управления пере- ния и развития автоматизированной системы управлевозочным процессом железнодо- ния перевозочным процессом в оперативном режиме рожного транспорта в оператив- (АИСО), а также разработка практических решений по ном режиме» обеспечению эффективной работы ее управляющих устройств – диспетчерских центров ОАО «РЖД» на сетевом и дорожном (региональном) уровнях Статья «The smarter railroad. An Описываются направления развития железнодорожного opportunity for the railroad indus- транспорта в мире на основе интеллектуальных систем try» (исследования IBM Institute for Business Value) Монография «Real-time Railway Описывается система поддержки принятия решений для Traffic Management: dispatching in управления железнодорожным транспортом ROMA complex, large and busy railway (Railway traffic Optimization by Means of Alternative 323 networks» graphs), которая реализована в Голландии. Эта система предоставляет развитые средства поддержки принятия решений, что позволяет точно контролировать текущее положение поезда и динамику его перемещения в реальном времени, предсказывать потенциальные конфликты и перепланировать расписание поездов в режиме реального времени, чтобы задержки были сведены к минимуму Статья «Network Сentric Railroad- Описываются сетецентрические системы железнодоing Utilizing Intelligent Railroad рожного транспорта и интеллектуальных систем железSystems» Статья «Network-Centric Opera- нодорожного транспорта, представляющие собой единую систему управления железнодорожным транспортом, в которой системы позиционирования, датчики, tions: Defense and Transportation компьютеры, современные математические методы и Synergy» цифровые коммуникации, используются для сбора, об- Статья «Network-Сentric Railways работки и распространения информации в целях повыOperations Utilizing Intelligent шения безопасности, эффективности и производительRailway Systems» ности железных дорог. Руководитель работ, директор по разработкам ООО "НПК "Разумные решения" П.О. Скобелев Генеральный директор ООО "НПК "Разумные решения" А.В. Царев Руководитель патентного подразделения, ведущий аналитик ООО "НПК "Разумные решения" А.Р. Диязитдинова 324 ПРИЛОЖЕНИЕ 3 (обязательное к отчету о НИР) ОБЩЕСТВО С ОГРАНИЧЕННОЙ ОТВЕТСВЕННОСТЬЮ "НПК "РАЗУМНЫЕ РЕШЕНИЯ" (ООО «НПК «РАЗУМНЫЕ РЕШЕНИЯ») УДК 004.942 № госрегистрации: 01201179187 Инв. № УТВЕРЖДАЮ Генеральный директор ООО "НПК "Разумные решения" А.В. Царев ТЕХНИЧЕСКОЕ ЗАДАНИЕ НА ОКР: Разработка и исследование интеллектуальной системы для согласованного адаптивного планирования и связанного изменения планов движения поездов для минимизации отклонения высокоскоростных поездов класса «Сапсан» от графика движения под влиянием непредвиденных внешних событий ГК от «17» октября 2011 г. №07.514.11.4094 Шифр: 2011-1.4-514-125-063 Руководитель НИОКР, директор по разработкам ООО "НПК "Разумные решения" ______________ П.О. Скобелев Нормоконтроль, директор по общим вопросам ООО "НПК "Разумные решения" ______________ А.Н. Мочалкин Самара 2012 325 ТЕХНИЧЕСКОЕ ЗАДАНИЕ на выполнение опытно-конструкторских работ (ОКР) по теме: "Разработка интеллектуальной системы для согласованного адаптивного планирования и связанного изменения планов движения поездов для минимизации отклонения высокоскоростных поездов класса "Сапсан" от графика движения под влиянием непредвиденных внешних событий" 1 Основание для проведения ОКР 1.1 Государственный Контракт № 07.514.11.4094. 1.2 Начало работ: Срок окончания работ: 2 Исполнитель ОКР Общество с ограниченной ответственностью «НПК «Разумные решения», г. Самара 3 Цель выполнения ОКР Разработка полнофункциональной системы для согласованного адаптивного планирования и связанного изменения планов движения поездов и проведения ремонтных работ для минимизации отклонения поездов в порядке приоритета, в том числе высокоскоростных поездов класса "Сапсан" как самых приоритетных, от графика движения под влиянием плановых ремонтных работ и непредвиденных внешних событий. 4 Назначение и цели создания продукции 4.1 Назначение продукции 4.1.1 Разрабатываемая система адаптивного планирования движения железнодорожного транспорта в реальном времени на основе мультиагентных технологий (далее - Система) предназначена для: а) оперативного планирования и контроля управления движением поездов по высокоскоростному железнодорожному направлению «Москва – Санкт-Петербург» с целью минимизацией отклонений от графика всех поездов в порядке их приоритета, в том числе высокоскоростных поездов класса "Сапсан" как самых приоритетных; 326 б) планирования и контроля предоставления окон на железнодорожном направлении «Москва – Санкт-Петербург» с целью выполнения заданного ежемесячного плана по ремонту дорог и поддержанию дорог в надлежащем состоянии; в) согласования планов между собой с целью их выполнения и сокращения конфликтов между ними; г) мониторинга и контроля исполнения намеченных планов. 4.2 Цели создания продукции Основными целями создания системы являются: а) повышение качества и эффективности процессов планирования движения поездов; б) уменьшение сложности и трудоемкости планирования движения поездов; в) уменьшение сложности и трудоемкости планирования ремонтных работ; г) сокращение случаев опозданий поездов в порядке убывания их приоритетности; д) сокращение времени опозданий поездов в случае их конфликта с более приоритетными, в том числе с ВСП «Сапсан»; е) сокращение случаев невыполнения планов по ремонтным работам; ж) оптимизация общего расписания движения поездов за счет доработки «жестких» правил в планировании: 1) передвижение окон по времени; 2) вывод по возможности ВСП «Сапсан» на встречное направление; 3) изменение стоянки поездов (время стоянки, время отправления); и) поддержание надлежащего состояния железных дорог. 5 Технические требования к программе или программному комплексу 5.1 Состав продукции 5.1.1 В состав разрабатываемой Системы должны входить: а) дорабатываемый Модуль планирования – предназначен для ввода входных данных, планирования и предоставления результатов в удобной графической и текстовой форме. Модуль планирования должен включать в себя: 1) подсистему планирования движения поездов; 2) подсистему планирования ремонтных работ; б) дорабатываемый Конструктор онтологии – предназначен для формализации предметной области и описания базовых концептов планирования. Редактор онтологии должен включать интерфейс взаимодействия с пользователем; 327 в) дорабатываемый Конструктор сцен – предназначен для ввода инфраструктуры движения и внесения изменений непосредственно в сцену планирования. Редактор сцен должен включать интерфейс взаимодействия с пользователем; г) дорабатываемая База Данных – предназначена для хранения информации об объектах движения, инфраструктуре и расписании; д) эксплуатационная документация. 5.2 Требования к функциональным характеристикам 5.2.1 Требования к составу выполняемых функций 5.2.1.1 Требования к функциям модуля планирования в целом Модуль планирования должен обеспечивать выполнение следующих функций: а) Ввод начальной ситуации по движению поездов (инфраструктуры движения, расписание поездов); б) Ввод и автоматическую обработку событий об изменениях состояний ресурсов; в) Ручную корректировку планов при необходимости; г) Отображение исходных и создаваемых планов движения поездов и планов ремонтных работ; д) Сохранение планов в базе данных; е) Восстановление планов из базы данных; ж) Построение отчетов по использованию ресурсов; и) Мониторинг и контроль выполнения плана против факта; к) Учет технических характеристик скоростного поезда ВСП "Сапсан" и всех объектов участвующих в планировании. 5.2.1.1.1 Требования к функциям подсистемы планирования движения поездов Подсистема планирования движения поездов должна обеспечивать выполнение следующих функций: а) динамическое планирование поездов в режиме реального времени, т.е. в темпе изменений ситуации, соответствующем реальному потоку изменений свойств и взаимосвязей объектов участка ЖД в направлении Москва – Санкт-Петербург; б) согласованное адаптивное перераспределение запланированных операций во времени и по ресурсам за счет выявления и разрешения конфликтов в расписаниях поездов, вызываемых непредвиденными событиями; в) составление расписания для нового поезда при его добавлении, не вступающего в конфликт с общим расписанием; 328 г) оценка устойчивости расписания на непредвиденные события; д) учет в планировании особенностей инфраструктуры на направлении: 1) количество путей на перегонах; 2) максимальная скорость движения на блок участках; 3) участки с автоблокировкой и полуавтоблокировкой; 4) наличие автомобильных переездов и запрет стоянок поезда на них; 5) мощность перегона; 6) усталость рельсов. 5.2.1.1.2 Требования к функциям подсистемы планирования ремонтных работ Подсистема планирования ремонтных работ должна обеспечивать выполнение следующих функций: а) планирование ремонтных работ с учетом усталости рельсов и текущего расписания поездов с учетом минимизации его изменения; б) ввод планов по объему месячных ремонтных работ дорог; в) распределение месячного объема ремонтных работ; г) планирование работ ремонтных бригад. 5.2.1.2 Требования к функциям Конструктора онтологий Конструктор онтологий должен представлять собой приложение с графическим интерфейсом с возможностью редактирования и навигации по онтологии. Конструктор онтологий должен позволять: а) описывать основные элементы инфраструктуры железных дорог, а именно: блокучастки путей, стрелки, перегоны, станции, переезды; б) проектировать онтологии в виде семантических сетей. Используя конструктор онтологий, разработчик и пользователь должен иметь возможность создавать и редактировать онтологии, специфицируя свои концепты (классы), устанавливая связи между ними и формируя сценарии действий; в) осуществлять навигацию по семантическим сетям онтологий (получение связанных сущностей и т.д.); г) хранить онтологии в реляционной базе данных, либо в XML хранилище; д) импорт/экспорт онтологий в XML; е) позволять добавлять новые элементы, влияющие на планирование движения поездов и проведение ремонтных работ. Конструктор онтологий должен состоять из следующих компонент: 329 а) хранилища онтологий, объединяющие в себе знания об объекте автоматизации; б) средства отображения и навигации по онтологиям, позволяющего пользователям просматривать корпоративные знания (с поддержкой отображения онтологии в виде словаря понятий, либо семантической сети); в) средства редактирования онтологий; г) ядро системы, которое обеспечивает работу с онтологиями. 5.2.1.3 Требования к функциям Конструктора сцен Конструктор сцен предназначен для создания и редактирования сцен, основанных на онтологии и должен представлять собой приложение с графическим интерфейсом. Конструктор сцен должен позволять: а) создавать сцены и работать с ними; б) редактировать загруженную в систему сцену; в) загружать, создавать инфраструктуру движения; г) осуществлять навигацию по семантическим сетям сцен; д) хранить сцены в реляционной базе данных, либо в XML хранилище. 5.2.1.4 Качество реализации функций должно обеспечивать полное выполнение входящих в их состав операций и задач и гарантировать корректную с точки зрения предметной области обработку данных и представление результатов. 5.2.2 Требования к организации входных данных Входными данными разрабатываемой Системы должны являться данные в виде объектов в памяти: а) полное описание инфраструктуры ресурсов, включая их взаимосвязи, постоянные на горизонте планирования; б) полное описание начального состояния ресурсов; в) события (потребности), выполнение которых требуется запланировать. В процессе работы модуль планирования можно в любой момент приостановить и передать в него изменения в потребностях, новые потребности или новые фактические состояния ресурсов. 5.2.3 Требования к организации выходных данных Выходными данными разрабатываемой Системы должно являться расписание в виде набора объектов, каждый из которых описывает, в каком состоянии и в каких отношениях будут находиться ресурсы в разные моменты времени, чтобы удовлетворить потребности. 330 5.2.4 Требования к временным характеристикам 5.2.4.1 Время отклика Системы планирования при обработке событий, не вызывающих новых конфликтов в расписании, должно быть менее 10 сек. 5.2.4.2 При обработке событий, вызывающих конфликты, время отклика должно быть меньше 3 минут. 5.2.4.3 Время полной перестройки расписания с горизонтом на сутки и получения первой, неоптимизированной версии плана, должно быть не более 30 мин. 5.2.4.4 Моделирование работы движения поездов должно осуществляться в реальном масштабе времени в качестве основного режима (реальный масштаб времени характеризуется частотой обновления данных о текущем состоянии поезда), а также должна быть предусмотрена возможность останова процесса моделирования, изменения масштаба времени протекания определенных процессов. 5.2.5 Требования к режимам функционирования 5.2.5.1 Разрабатываемая Система должна функционировать в следующих режимах: а) нормальный режим функционирования, при котором: 1) системное и прикладное программное обеспечение АРМов и технические средства пользователей обеспечивают возможность круглосуточного функционирования семь дней в неделю, с перерывами на обслуживание; 2) серверное программное обеспечение и технические средства северов обеспечивают возможность круглосуточного функционирования семь дней в неделю, с перерывами на обслуживание; 3) исправно работает оборудование, составляющее комплекс технических средств; б) аварийный режим функционирования, который характеризуется отказом одной или нескольких подсистем и (или) технических средств обеспечения. 1) тип аварийной ситуации: выход из строя одной из систем, подсистем или модулей. В этом случае остальные части должны оставаться работоспособными и обеспечивать ввод-вывод текущих данных для последнего построенного расписания каждого отдельного модуля. Система должна обеспечивать возможность возобновления работы путем перезапуска в течение 30 минут. 2) Тип аварийной ситуации: нет отклика от сервера приложений на всех рабочих местах или потеряна связь с физическим сервером. Система должна опрашивать сеть и возобновлять свою работу автоматически, восстанавливая соединение не более чем за 10 минут по возобновлению работы сервера или сети. 331 3) Тип аварийной ситуации: Отказ Операционной системы рабочего места. Система должна сохранить предыдущее состояние, отключиться либо вывести сообщение о невозможности продолжении работы. После восстановления операционной системы продолжить работу в нормальном режиме. 5.2.6 Требования по диагностированию 5.2.6.1 Программные и технические средства разрабатываемой Системы должны обеспечивать диагностику целостности компонентов структуры базы данных, хранящей сведения о заказах и ресурсах с глубиной поиска места отказа до одного из модулей Системы и последней выполненной операции. 5.2.6.2 С помощью средств диагностики должны фиксироваться следующие ситуации: а) ошибки соединения с БД; б) ошибки сохранения в БД; в) ошибки загрузки из БД; г) ошибки интеграции; д) необработанные исключения; е) недоступность сервера приложений (нарушена работа сервера); ж) отсутствие связи удаленных компьютеров с физическим сервером в ЛВС. 5.2.6.3 В разрабатываемой Системе должны формироваться следующие диагностические сообщения: а) ошибка БД; б) нарушение интеграции; в) ошибка соединения с сервером; г) ошибка доступа к элементам Системы; д) отказы в системе электропитания. 5.2.6.4 При возникновении аварийных ситуаций и ошибок в прикладном программном обеспечении, Система должна сохранять набор информации, необходимой для идентификации нештатной ситуации в логе (хронологической записи с различной настраиваемой степенью детализации сведений о происходящих в Сиситеме событиях, текущем состоянии памяти и файловой системы). 5.2.7 Требования к показателям назначения 5.2.7.1 Общие требования к показателям назначения: 332 а) Система должна поддерживать работу пользователей, находящихся на территориально разделенных участках; б) должен быть реализован принцип открытой архитектуры построения системы, обеспечивающий возможность встраивания новых модулей и взаимодействия с другими системами; в) Система должна обрабатывать и планировать движение до 500 поездов и до 50 ремонтных «окон» в день. 5.2.7.2 Степень приспособляемости системы к изменению процессов и методов управления, к отклонениям параметров объекта управления. 5.2.7.2.1 При изменении процессов и принципов планирования в ОАО «РЖД» изменение логики планирования должно осуществляться путем проведения структурной и параметрической настройки соответствующих функциональных подсистем Системы; 5.2.7.2.2 Процесс настройки и адаптации должен проводиться инженерами - программистами службы эксплуатации Системы. 5.2.7.3 Требования к вероятностно-временным характеристикам, при которых сохраняется целевое назначение программного образца: а) минимальный срок эксплуатации должен составлять: 1) Системы в целом - не менее 10 лет; 2) модулей функциональных подсистем - не менее 3 лет. 5.2.8 Требования к модернизации и развитию 5.2.8.1 Система должна обеспечивать возможность модернизации и масштабируемости для повышения степени приспособляемости при увеличении пределов изменений параметров объекта автоматизации свыше указанных ранее, а также при необходимости изменения состава требований к выполняемым функциям и видам обеспечения. 5.2.8.2 Масштабируемость по количеству конечных пользователей – до 300 зарегистрированных пользователей в Системе. 5.2.8.3Масштабируемость по количеству обрабатываемой информации: а) пиковая нагрузка - до 100 обращений в час; б) период накопления архивных данных на сервере - до 5 лет; в) период накопления данных для оперативной обработки – до 1 года г) минимально допустимый срок эксплуатации Системы должен составлять не менее 10 лет. 333 5.3 Требования к надежности 5.3.1 Разрабатываемая Система и ее подсистемы должны обеспечивать следующие показатели надежности: 5.3.1.1 коэффициент готовности: а) Система в целом – 0,97; 5.3.1.2 Система в целом должна обеспечивать следующие показатели надежности: а) вероятность безотказной работы Системы при функционировании системы в пользовательском режиме должна быть не менее 0,97 с учетом временной избыточности. б) среднее время восстановления работоспособности – 10 мин.; 5.3.2 Перечень аварийных ситуаций, по которым должны быть регламентированы требования к надежности, и значения соответствующих показателей: 5.3.3 Надежность технических средств и программного обеспечения должна обеспечивать показатели надежности, установленные для разрабатываемой Системы в целом. 5.3.4 Надежность серверов СУБД должна обеспечивать время однократного простоя не более 20 мин, суммарного времени на регламентное обслуживание не более 32 часов в год. 5.3.5 Числовые значения показателей надежности уточняются на стадии «Технический проект». 5.3.6 Критерии отказа и предельного состояния разрабатываемой Системы: а) отказом Системы считают прекращение выполнения Системой функций, заданных требованиями настоящего технического задания; 5.3.7 В предварительных проектных решениях, разрабатываемых на стадии эскизного проектирования, должны быть предусмотрены меры по обеспечению требуемой надежности Системы; 5.3.8 Подтверждение требований к надежности разрабатываемой Системы проводится: а) расчетным методом в соответствии с ГОСТ 24.701-86 - на этапе технического проекта и на этапе предварительных испытаний; б) экспериментальным (расчётно-экспериментальным) методом по методике, согласованной с Заказчиком - на этапе опытной эксплуатации и на этапе приёмочных испытаний. 5.3.9 На этапе технического проекта должна быть разработана и согласована с заказчиком программа обеспечения надежности. 334 5.4 Условия эксплуатации 5.4.1 Климатические условия эксплуатации 5.4.1.1 Технические средства разрабатываемой Системы должны выполнять свои функции и сохранять свои показатели в пределах установленных значений при следующих условиях эксплуатации: магнитные поля постоянные и переменные с частотой 50 Гц напряженностью до 400 А/м. 5.4.1.2 Для нормального функционирования технических средств разрабатываемой Системы должны быть обеспечены следующие условия: а) температура окружающего воздуха (20 ± 5 ) °С; б) относительная влажность окружающего воздуха (60 ± 15)%; в) атмосферное давление от 84 до 107 кПа (680-800 мм. рт. ст.); 5.4.2 Требования к видам обслуживания 5.4.2.1 Функционирование разрабатываемой Системы должно быть рассчитано на круглосуточный режим работы, с остановкой на профилактику 5.4.2.2 Техническое обслуживание разрабатываемой Системы должно включать в себя: а) текущее обслуживание; б) профилактическое обслуживание; в) регламентное обслуживание при условий, что объект обслуживания можно вывести на время из процесса непрерывного планирования. 5.4.2.3 Текущее обслуживание должно включать контроль функционирования технических средств Системы и восстановление ее работоспособности при неисправностях и отказах технических и программных средств. 5.4.2.4 Объем, трудозатраты и порядок выполнения профилактического и регламентного обслуживания технических средств Системы должны соответствовать эксплуатационным документам применяемых средств. 5.4.3 Требования к численности и квалификации персонала 5.4.3.1 Разрабатываемый Система должен обслуживаться персоналом в количестве и с квалификацией, указанными в таблице 1: 335 Таблица 1 № Наименование должности, специ- п/п альности, профессии Количество Требуемая квалификация Оперативный персонал Ведущий системный админи- 1 1 стратор высшее техническое образование по специальности, релевантной IT направленности, стаж работы не менее 2-х лет Эксплуатационный персонал: Инженер-программист 2 2 высшее техническое образование по специальности, релевантной IT направленности, стаж работы не менее 2-х лет 5.4.3.2 Оперативный и эксплуатационный персонал должен быть обучен правилам техники безопасности при эксплуатации серверного оборудования и персональных компьютеров. 5.5 Требования к составу и параметрам технических средств 5.5.1 Разрабатываемый Система должен функционировать на следующих технических средствах: а) серверное оборудование – 1 шт со следующими характеристиками: 1) тактовая частота серверного процессора не менее – 3.0 ГГц; 2) технология изготовления процессора – не менее 4х ядер на процессор; 3) объем оперативной памяти – не менее 32 Гб; 4) объем свободной памяти жесткого (-их) диска (-ов) – не менее 20 Тб; 5) пропускная способность сетевого интерфейса – не менее 100 Мбит/с. б) рабочее место пользователя, обеспечивающее доступ к ресурсам сервера – 1 шт. с параметрами: 1) ПК с процессором Intel Pentium-4 3000 (+) MHz; 2) ОС MS Windows Vista/7 (32/64 bit); 336 3) Оперативная память: 16 Gb; 4) HDD: 160 Gb; 5) Источник бесперебойного питания: 500 ВА / 300 Вт, количество выходных разъемов – 4 (3 с питанием от батареи), время работы – 4.5 мин. 5.5.2 Состав и характеристики технических средств, необходимых для обеспечения функционирования разрабатываемого Система, должны быть окончательно определены на этапе Технического проектирования. 5.6 Требования к информационной и программной совместимости 5.6.1 Разрабатываемая Система должна функционировать под управлением следующих операционных систем: а) Windows Vista/ 7 или выше; б) RedHat Enterprise Linux 4.x. 5.6.2 Для разработки разрабатываемой Системы должны использоваться следующие языки программирования, запросов, представления, визуального моделирования: а) Java. 5.6.3 Для разработки разрабатываемой Системы должны использоваться следующие среды разработки: а) Idea. 5.6.4 Разрабатываемая Система должна совместно функционировать и взаимодействовать со следующими сторонними программными средствами: а) Система управления базами данных PostgreSQL; б) Программный сервер приложений JBoss. 5.6.5 Состав и характеристики сторонних программных средств, необходимых для обеспечения функционирования разрабатываемого Система, должны быть окончательно определены на этапе проектирования. 5.6.6 Разрабатываемый Система должен обеспечивать сохранность информации в случаях: 5.6.6.1 Сохранность информации в Система должна обеспечиваться при следующих аварийных ситуациях: а) импульсные помехи, сбои и кратковременные (до 5 мин) перерывы в электропитании; б) нарушение или выход из строя каналов связи локальной сети Система; в) сбой программного обеспечения Система; г) ошибки в работе персонала; 337 д) отказ технических средств (одного из накопителей на жестких магнитных дисках, оперативной памяти, блока питания сервера и пр.) любой подсистемы по любой причине (в том числе из-за механических повреждений – удар, падение и пр.). 5.6.6.2 Для сохранности данных в Системе должны быть предусмотрены специальные средства сопровождения БД, которые должны обеспечивать: а) периодическое создание резервной копии данных на случай отказа; б) восстановление данных в целостное состояние посредством резервной копии; в) создание архива данных; г) восстановление данных посредством разархивирования. 5.6.7 Должны быть разработаны меры по обеспечению требований по информационной безопасности, в том числе защита от несанкционированного доступа. 5.7 Требования к упаковке и маркировке 5.7.1 Требования к упаковке Упаковка программного изделия должна осуществляться в упаковочную тару Исполнителя. 5.7.2 Требования к маркировке Программное изделие должно иметь маркировку с обозначением товарного знака компании – разработчика, наименования, номера версии, порядкового номера и даты изготовления. 5.8 Требования к транспортированию и хранению 5.8.1 Допускается транспортирование программного изделия в транспортной таре всеми видами транспорта (в том числе в отапливаемых герметизированных отсеках самолетов без ограничения расстояний). 5.8.2 При перевозке в железнодорожных вагонах вид отправки - мелкий малотоннажный. 5.8.3 При транспортировании и хранении программного изделия должна быть предусмотрена защита от попадания пыли и атмосферных осадков. 5.8.4 Не допускается кантование программного изделия. 5.8.5 Климатические условия транспортирование приведены ниже: а) температура окружающей среды: от минус 50 до 50 °С; б) относительная влажность до 95 % при температуре 30 °С; в) атмосферное давление от 84 до 107 кПа (от 630 до 800 мм рт. ст.); 338 г) воздействие ударных нагрузок многократного действия с пиковым ускорением не более 15g (147 м/с2) при длительности действия ударного ускорения 10–15 мс. 5.9 Требования по стандартизации и унификации 5.9.1 Унификация технического обеспечения должна обеспечиваться за счет применения стандартных технических средств и стандартных конструктивных элементов. 5.9.2 Взаимодействие пользователей с Системой должно осуществляться через экранные формы. 5.9.3 Экранные формы разрабатываемой Системы должны проектироваться с учетом требований унификации: а) все экранные формы пользовательского интерфейса должны быть выполнены в едином графическом дизайне, с одинаковым расположением основных элементов управления и навигации; б) для обозначения сходных операций должны использоваться сходные графические значки, кнопки и другие управляющие (навигационные) элементы. Термины, используемые для обозначения типовых операций (добавление информационной сущности, редактирование поля данных), а также последовательности действий пользователя при их выполнении, должны быть унифицированы; в) внешнее поведение сходных элементов интерфейса (реакция на наведение указателя «мыши», переключение фокуса, нажатие кнопки) должны реализовываться одинаково для однотипных элементов. 5.9.4 Для работы с базой данных Системы должен использоваться язык SQL в рамках стандарта ANSI SQL-92. 5.9.5 Должен использоваться протокол обмена данными TCP/IP. 6 Требования к документации 6.1 Комплектность разрабатываемой технической документации, согласованная с Заказчиком (при наличии соответствующих объектов разработки в ТЗ) выполняется на этапе 1, если сроки разработки документа не установлены в календарном плане (в установленные Заказчиком сроки). 6.2 Техническая (программная и эксплуатационная) документация должна соответствовать требованиям стандартов ЕСКД, ЕСПД, а также требованиям другой нормативнотехнической документации в части требований к документированию программного обеспечения. 339 6.3 Перечень технической и другой отчетной документации, подлежащей оформлению и сдаче Исполнителем Заказчику на этапах выполнения работ, определяется требованиями настоящего технического задания и нормативными актами Заказчика. 6.4 Техническая и другая отчетная документация представляется Заказчику или уполномоченной им организации на бумажном носителе в двух экземплярах и в электронном виде на оптическом носителе в одном экземпляре. 7 Специальные требования 7.1 Требования к проведению испытаний 7.1.1 На всех этапах разработки разрабатываемой Системы должна производиться оценка качества программных средств в соответствии с требованиями ГОСТ 28195-99. 7.1.2 Для подтверждения соответствия разрабатываемой продукции требованиям настоящего технического задания и нормативно-технической документации должны быть проведены следующие испытания: а) предварительные автономные испытания для определения работоспособности разрабатываемой Системы и решения вопроса о возможности ее приемки в опытную эксплуатацию; б) опытная эксплуатация разрабатываемой Системы с целью определения фактических значений количественных и качественных характеристик, фактической эффективности Системы и корректировки (при необходимости) технической документации; в) приемочные испытания для определения соответствия Системы настоящему техническому заданию, оценки качества опытной эксплуатации и решения вопроса о возможности приемки Системы в постоянную эксплуатацию. 7.1.3 Для проведения испытаний должно быть изготовлено следующее количество опытных образцов: а) для предварительных испытаний – 1 шт.; б) для государственных приемочных испытаний - 1 шт. 7.1.4 Предварительные испытания опытных образцов должны быть проведены по утвержденным программам и методикам головного исполнителя ОКР. 7.1.5 Государственные приемочные испытания опытных образцов должны быть проведены по утвержденным программам и методикам головного исполнителя ОКР, согласованным с Минобрнауки РФ. 7.1.6 Для обеспечения испытаний должны быть разработаны следующие средства: 340 а) отладочный стенд, предназначенный для комплексной отладки и настройки разрабатываемой Системы и для функционирования тестовых задач; 7.1.7 Место проведения испытаний должны быть определены в Программе и методиках соответствующих испытаний. 7.2 Требования к работам, выполняемым с участием иностранных партнёров. 7.2.1 Все работы должны быть осуществлены без участия иностранных партнёров. 8 Технико-экономические показатели 8.1 Основные технико-экономические требования 8.1.1 Разрабатываемая Система должна обеспечивать: а) автоматизацию процессов принятия решений при выходе поезда из расписания, что в настоящее время осуществляется только вручную; б) повышение актуальности текущего расписания - суммарного времени, в течение которого расписание находится в актуальном состоянии за счет своевременной обработки событий; в) повышение числа анализируемых вариантов и возможных решений, учтенных при анализе и перепланировании в ответ на события; г) повышение оперативности в принятии решений и, в частности, сокращение времени реакции на непредвиденные события, что требует согласованного изменения планов путем цепочек изменений, подвижек и перераспределения задач с учетом связей между поездами в реальном времени – не менее, чем на 40%; д) повышение точности оценки последствий непредвиденных событий и рассчитанных показателей эффективности расписания на горизонте; е) сокращение сроков планирования и перепланирования движения поездов. 8.2 Требования к достижению программных индикаторов и показателей В процессе выполнения ОКР должны быть достигнуты значения программных индикаторов и показателей: Наименование ед. изм. год 2012 2013 0 1 Индикаторы И2._.1 Число разработанных техноло- единиц гий, соответствующих мировому уровню либо превосходящих его 341 2014 2015 И2._.2 Число завершенных проектов, единиц 0 1 единиц 0 1 человек 0 10 единиц 0 1 единиц 0 4 Объем привлеченных внебюджетных млн. 0 0 средств руб. Объем дополнительного производства млн. 0 0 новой и усовершенствованной высо- руб. 0 0 0 0 перешедших в стадию коммерциализации И2._.3 Число патентов (в том числе международных) на результаты интеллектуальной деятельности, полученные в рамках выполнения комплексных проектов И2._.4 Численность молодых специалистов, привлеченных к проведению исследований в рамках комплексных проектов (докторов наук, кандидатов наук, докторантов, аспирантов, сотрудников без ученой степени, специалистов, студентов) И2._.5 Число диссертаций на соискание ученых степеней, защищенных в рамках выполнения комплексных проектов И2._.6 Число публикаций, содержащих результаты интеллектуальной деятельности, полученные в рамках выполнения комплексных проектов Показатели котехнологичной продукции за счет коммерциализации созданных передовых технологий Дополнительный объем экспорта вы- млн. сокотехнологичной продукции руб. Количество новых рабочих мест, со- единиц 342 зданных в рамках реализации проектов, для высококвалифицированных работников 9 Требования к патентной чистоте и патентоспособности 9.1 На этапах первом и заключительном проведения ОКР должны быть проведены патентные исследования в соответствии с ГОСТ Р 15.011-96. 9.2 Должны быть представлены сведения об охранных и иных документах, которые будут препятствовать применению результатов работ в Российской Федерации (и в других странах – по требованию заказчика), и условия их использования с представлением соответствующих обоснованных предложений и расчетов. 9.3 Патентная чистота на методы изготовления и конструктивные решения должна быть обеспечена в отношении Российской Федерации и стран, куда возможна поставка изделий, а также передача технической, информационной и другой документации. 9.4 РИД, полученные в ходе выполнения ОКР, подлежат регистрации и охране в соответствии с действующим законодательством Российской Федерации. 10 Перечень, содержание, сроки выполнения и стоимость этапов 10.1 Наименование этапов и выполняемые работы Этап 1. Техническое предложение: 1.1 Разработка и согласование с Заказчиком "Комплектности технической документации, разрабатываемой в рамках государственного контракта" (далее Комплектность ТД). 1.2 Проведение патентных исследований в соответствии с ГОСТ Р 15.011. 1.3 Разработка технического предложения, в том числе: а) проработка результатов предшествующих НИР; б) проработка результатов прогнозирования; в) предварительные расчеты; г) сравнительная оценка рассматриваемых вариантов; д) обоснование и выбор оптимального варианта (вариантов) технического решения (решений). 1.4 Разработка технической документации в соответствии с согласованной комплектностью. 1.5 Оформление документации технического предложения в соответствии с ГОСТ 2.118, его рассмотрение и утверждение на научно-техническом совете. 343 1.6 Реализация мероприятий по достижению технико-экономических показателей (п. 8 ТЗ). 1.7 Разработка отчетной документации в соответствии с Порядком приемки работ, выполненных по государственным контрактам, заключенным в рамках федеральной целевой программы «Исследования и разработки по приоритетным направлениям развития научнотехнического комплекса России на 2007-2013 годы», принятым 27.06.2011г. (далее – Порядок приемки). Этап 2. Эскизный проект: 2.1 Разработка эскизного проекта, в том числе: а) обоснование и выбор оптимального варианта (вариантов) технического решения, принятие принципиальных решений; б) проведение расчетов и оценок; в) эскизное алгоритмирование; г) разработка и обоснование блок-схем и временных графиков функционирования; д) изготовление и испытания макетов. 2.2 Проведение патентных исследований. 2.3 Разработка технической документации в соответствии с согласованной комплектностью. 2.4 Оформление документации эскизного проекта в соответствии с ГОСТ 2.119, его рассмотрение и утверждение на научно-техническом совете. 2.5 Реализация мероприятий по достижению технико-экономических показателей (п. 8 ТЗ). 2.6 Разработка отчетной документации в соответствии с Порядком приемки. Этап 3. Технический проект: 3.1 Разработка технического проекта, в том числе: а) разработка алгоритмов решения программных задач; б) разработка программных решений разрабатываемой Системы; в) уточнение структуры входных и выходных данных; г) определение форм представления входных и выходных данных; д) определение семантики и синтаксиса языка; е) разработка структуры программных компонентов и Системы в целом; ж) выполнение необходимых расчетов; 344 и) определение конфигурации технических (аппаратных) средств функционирования Системы (ПК); к) программная реализация и испытание макетов (прототипов); л) оценка технологичности изготовления. 3.2 Проведение патентных исследований. 3.3 Разработка технической документации в соответствии с согласованной комплектностью. 3.4 Оформление документации технического проекта в соответствии с ГОСТ 2.120, его рассмотрение и утверждение на научно-техническом совете. 3.5 Реализация мероприятий по достижению технико-экономических показателей (п. 8 ТЗ). 3.6 Разработка отчетной документации в соответствии с Порядком приемки. Этап 4. Разработка рабочей программной документации (РПД): 4.1 Разработка программной документации на Систему, программная отладка разрабатываемой Системы. 4.2 Разработка проектов эксплуатационной документации (ЭД). 4.3 Экспертиза разработанной рабочей программной документации. 4.4 Разработка программы и методик предварительных испытаний. 4.5 Реализация мероприятий по достижению технико-экономических показателей (п. 8 ТЗ). 4.6 Разработка отчетной документации в соответствии с требованиями Системы. Этап 5. Изготовление опытного образца и проведение предварительных испытаний: 5.1 Подготовка опытного производства для изготовления специального оборудования. 5.2 Изготовление специального оборудования для проведения предварительных испытаний. 5.3 Изготовление (компиляция) опытного образца Системы. 5.4 Проведение предварительных испытаний опытного образца Системы, проверка и оценка проектов ЭД в ходе предварительных испытаний. 5.5 Корректировка РПД, ЭД Системы по результатам предварительных испытаний, присвоение РПД литеры "О". 5.6 Доработка (перекомпиляция) опытных образцов Системы в целом по результатам предварительных испытаний и корректировки РПД. 5.7 Разработка программы и методик приемочных (государственных) испытаний. 345 5.8 Реализация мероприятий по достижению технико-экономических показателей (п. 8 ТЗ). 5.9 Разработка отчетной документации в соответствии с Порядком приемки. Этап 6. Проведение приемочных (государственных) испытаний: 6.1 Подготовка РПД опытного образца Системы к приемочным (государственным) испытаниям. 6.2 Проведение приемочных (государственных) испытаний опытного образца Системы. 6.3 Проверка и оценка проектов ЭД. 6.4 Корректировка РПД, ЭД Комплекса по результатам приемочных (государственных) испытаний, присвоение РПД литеры "О1". 6.5 Доработка (перекомпиляция) опытных образцов Системы по результатам приемочных (государственных) испытаний и корректировки РПД. 6.6 Реализация мероприятий по достижению технико-экономических показателей (п. 8 ТЗ). 6.7 Разработка отчетной документации в соответствии с Порядком приемки. 10.2 Сроки исполнения и финансирование по этапам 10.2.1 Перечень документов, разрабатываемых на этапах выполнения ОКР, сроки исполнения и контрактная цена должны быть согласованы в календарном плане. 11 Порядок выполнения и приемки этапов ОКР 11.1 Работа должна выполняться в соответствии с требованиями ГОСТ 34.601-90, РД 50680-88 (с учетом требований ГОСТ 15.005-86). 11.2 Сдача и приемка выполненных работ (этапов работ) осуществляется в порядке, установленном актами Заказчика, и в соответствии с требованиями настоящего технического задания. Руководитель организации (подпись) М.П. 346 (Ф.И.О.)