Закончились Олимпийские и Паралимпийские игры. Для десятков тысяч человек, подготовивших Игры, завершился крупнейший проект. Позволю себе поделиться своим опытом по разработке и внедрению навигационной системы диспетчерского управления в рамках проекта «Логистический транспортный центр» (ЛТЦ) Автономной Некоммерческой Организации «Транспортная Дирекция Олимпийских Игр» (АНО «ТДОИ») в г.Сочи.
Предыстория
Примерно четыре года тому назад началась активная фаза подготовки документации и технических заданий по созданию центра управления олимпийским, городским и специализированным легковым транспортом при подготовке и проведении Олимпийских и Паралимпийских Игр. Тогда же появились подобные статьи. Создание технической документации «с нуля» заняло примерно 1,5 года, и включало в себя широкий спектр вопросов, начиная от разработки требований к бортовым навигационно-связным блокам, кончая строительством здания для ЛТЦ.
Мне довелось участвовать в реализации этапа по созданию навигационной автоматизированной системы диспетчерского управления. Но обо всем по порядку.
Несколько общих слов
Требованиям Международного Олимпийского комитета (МОК) к организации транспортного обслуживания достаточно строги, однако уровень детализации не велик. Такие требования формируются по мере приближения к Играм и сводятся к обеспечению определенной гибкости разрабатываемого ПО.
Как устроена типичная навигационная система, уверен, сегодня представляет каждый. Существуют бортовые устройства, определяющие координаты, азимут, скорость и передающие эти данные с заданной периодичностью (либо по пройденному расстоянию, повороту на заданный угол и т.п.) в ЦОД. ЦОД – это некая надежная серверная площадка, способная «держать» пиковые нагрузки. Данные непрерывно проходят многоуровневую обработку, и диспетчер на конечном устройстве получает актуальную «картинку» и различные массивы обработанной информации, позволяющей принимать адекватные, своевременные решения по управлению транспортом в режиме реального времени. Например, когда из-за заторов «ломается» интервал на маршруте либо срывается выполнение заказа. GPS/ГЛОНАСС для телематики, GSM для голоса, GPRS для передачи пакетов «устройство-оператор сотовой связи-ЦОД».
Типичных систем мониторинга только у нас в стране насчитывается сотня-другая (тут, тут: тысячи их). Что нужно обычному небольшому предприятию? «Посмотреть на карте, рассчитать пробег и определить незапланированные сливы топлива» — так ответит типичный диспетчер. В таких системах за редким исключением нет информации о плане перевозок. Таким образом, отсутствует эффективный контроль и управление. Важные обратные связи между анализом исполненного движения и последующим планированием часто слабо формализованы, а иногда просто отсутствуют.
Что нужно для системы диспетчеризации при проведении массовых мероприятий, особенно в пиковые периоды? Например, эффективное управление резервом, жесткий контроль расписания / интервалов движения, гарантированное хранение информации для анализа «форс-мажорных» ситуаций и т.д.
Начало
На основе требований к АСУ, зарубежного опыта предыдущих Олимпиад и нашего собственного опыта внедрения навигационных систем диспетчерского управления у нас в стране (в т.ч. Универсиада в Казане, «МАКС», города-миллионники), мы начали думать над архитектурой, реализацией и конечным обликом навигационной системы Олимпийского транспорта.
Бесконечные встречи с заинтересованными лицами, различное видение системы различными контрагентами значительно усложняли жизнь. Однако в итоге, была произведена декомпозиция на составные части.
Мы выделили все типы подвижного состава, четко разделив их по технологиям. Внутри технологий удалось выделить особенности каждой из них. На основе предварительной оргструктуры АНО «ТДОИ» было произведено деление по ролям пользователей (около 60 ролей).
Под всевидящее око навигационных технологий должны были попасть разнообразные типы подвижного состава, обобщенно представленные в таблице:
| Тип подвижного состава | Перевозчик | Количество единиц | Технология |
|---|---|---|---|
| Городской транспорт (автобусы) | Сочиавтотранс Лазаревскоеавтотранс и т.д. |
~1000 | Работа по маршруту |
| Олимпийский транспорт (автобусы) | Мострансавто (г.Москва) Пассажиравтотранс (г.Санкт-Петербург) Буревестник (г.Казань) |
~1000 | Работа по маршруту и по заказу клиентских групп |
| Легковой транспорт | Оргкомитет «Сочи-2014» | ~3700 | Работа по заказу клиентских групп – 50% Только мониторинг — 50% |
| Уборочная техника | Различные | ~300 | Только мониторинг (особенно, во время снегопадов на горных дорогах) |
| Всего:~6000 |
Требовалось создать навигационную систему на 6 (расширение до 8-9) тысяч транспортных средств в рамках единого информационного пространства для большого количества пользователей. Выдохнув, мы приступили.
Нижний уровень ядра и системное ПО
Сперва была выделена общая программная часть (ядро системы), которая отвечала за нижний уровень: обработка входного массива и сохранение его в режиме реального времени в архив, определение местонахождения транспортного средства на основе виртуальных географических зон, голосовая коммуникация и коммуникация с бортовыми устройствами через отправку формализованных и неформализованных текстовых сообщений и многое другое.
Нижний уровень ядра должен был обеспечить надежную и оперативную обработку 12 тысяч отметок в минуту. Для этого пришлось выделять отдельные отказоустойчивые коммуникационные кластера. Два таких кластера должны были сохранять в буферах массивы отметок и сообщений в случае отказа соответствующих кластеров БД.
Отдельное внимание было уделено разработке логической БД. На физическом уровне были использованы известные подходы к реализации распределенных БД. В конечном итоге, у нас получилось 8 кластеров БД, которые стали равнозначными узлами распределенной системы.
При реализации картографии требовалось выполнить стыковку с картами Yandex, Google, OpenStreetMaps и основной «подложкой» — картой ГК «Олимпстрой» на основе ArcGIS.
В качестве ОС на этапе предварительного проектирования была выбрана Microsoft Windows Server 2008 R2, в качестве СУБД — Microsoft SQL Server 2008 R2 Enterprise Edition. ОС была кластеризована на 20 однотипных «лезвиях» от HP. СУБД также была кластеризована. Коммуникационные службы (всего 56 служб) были включены в отказоустойчивые пулы средствами ОС. СХД построено на базе RAID10. По понятным причинам нас заботила отказоустойчивость. Распределение нагрузки между узлами было выполнено отчасти программно, отчасти благодаря четкому пониманию оргструктуры Дирекции.
Верхний уровень
Немалых усилий потребовала реализация двух разных технологий перевозок:
1) Технология маршрутных перевозок сводилась к большому объему подготовительной работы перед осуществлением управления. На первом этапе специализированное ПО должно было позволить создавать электронные паспорта маршрутов, включающие в себя последовательности остановок, линии маршрутов и прочие характеристики самих маршрутов. В итоге было создано 152 Олимпийских и 112 Городских паспорта маршрута (нарисовано более 17 тыс.км. линий). На основе данных модуля паспортизации в модуле расписаний были построены упрощенные, обычные и пиковые расписания движения.
Эта информация стала исходной плановой информацией для осуществления эффективной диспетчеризации на маршрутах.
Кроме того, нам пришлось выполнить ряд требований по формированию прогнозов прибытия автобусов на остановки по маршруту с выдачей прогнозной информации на портал информирования и электронные табло, установленные на остановочных пунктах.
За передачу телематической информации отвечало оборудование от компании Сантел-Навигация: Гранит 2.07.
2) При работе по заказу должна была быть выполнена стыковка с системой Olympic Games Management System, источником информация о прибытии и убытии. Специфические требования для передачи информации о заказе на бортовое устройство привело к выбору навигационных блоков на базе ОС Android с последующей стыковкой на основе Thrift-протокола с оболочкой от компании Shturmann. Потребовалась реализация 4 различных средств по вводу/импорту заказов в систему.
Для обеспечения необходимости получения планируемого точного времени и расстояния заказа был разработан аналитический модуль отображения «пробок» и расчета кратчайшего расстояния, в том числе на основе ретроспективной информации о «пробках». Спасибо дедушке Дейкстре!
Верхний уровень представлял собой детальную проработку элементов отображения в клиентском ПО, и особенно в отчетности. Нам пришлось реализовать около 160 отчетных форм различного уровня агрегации, включая отчеты самого верхнего уровня для руководства АНО «ТДОИ». Необходимым условием для управления на верхнем уровне являлась возможность оперативного анализа транспортной ситуации, для чего были разработаны соответствующие модули контроля исполнения транспортной работы.
Необходимым условием для управления на верхнем уровне являлась возможность оперативного анализа транспортной ситуации, для чего были разработаны соответствующие модули контроля исполнения транспортной работы.
Что в итоге получилось
Первое крупное боевое крещение системы случилось на Тестовых соревнованиях, проходивших в Сочи в феврале 2013 г. По результатам соревнований заказчик уточнил требования, мы исправили известные баги и критические ошибки. После Тестовых соревнований августа 2013 г. последовала следующая и последняя итерация.
К декабрю вычислительный комплекс в новом здании ЛТЦ был полностью развернут. Системы были реконфигурированы в строгом соответствии с техно-рабочим проектом.
К 7 января 2014 г. (по рекомендациям МОК ровно за месяц до начала Игр Олимпиада начинается) все было готово. Наша OLTP-система перешла в режим промышленной эксплуатации.
Основной зал ЛТЦ на 33 рабочих места (август 2013 г.)
Кроме основных технологических функций были также реализованы дополнительные требования, такие как: информирование заказчика услуг средствами SMS, интеграция по SOAP-протоколу со страховой службой для мгновенной передачи SOS-сигнала, голосовая коммуникация посредством SIP VoIP и многие другие.
Как и в любой сложной системе, подсистема диагностики являлась неотъемлемой составляющей. Наряду с Zabbix, был реализован целый ряд диагностических модулей ядра системы с возможностью самодиагностики и мгновенного информирования ответственных лиц о проблемах в соответствии с их приоритетом. Подсистема 3 раза предупреждала отказ узлов, идентифицировав на ранней стадии превышение допустимых значений параметров.
Ответственный, большой и сложный проект завершился.
Система предоставила возможность оперативного анализа движения, позволила повысить эффективность перевозок, явилась средством инструментального контроля и подтверждения выполненной перевозчиками транспортной работы (сотни тысяч рейсов и десятки тысяч заказов).
Так выглядит небольшая часть теперь уже истории по названием «Жаркие. Зимние. Твои».
Спасибо за внимание
Автор: aklerk
