Система диспетчерского управления движением поездов метрополитена «СИТРОЛ»

Система диспетчерского управления движением поездов метрополитена «СИТРОЛ»

Система диспетчерского управления движением поездов метрополитена «СИТРОЛ»


В 2010-2013 гг компанией «ТоксСофт» была разработана система «СИТРОЛ» как платформа для создания и разворачивания систем диспетчерского управления движениями поездов на железнодорожных станциях и станциях метрополитена.

В 2013-2014 гг на платформе «СИТРОЛ» была создана и запущена в эксплуатацию система диспетчерской централизации Тбилисского метрополитена. Проект охватывал две линии, 22 станции, одно депо и несколько спецобъектов.

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

В октябре 2017 года сдана в эксплуатацию новая (23-я) станция Тбилисского метрополитена «Государственный Университет». Отличительной особенностью станции является использование микропроцессорной централизации (МПЦ) компании Siemens вместо МРЦ еще советского проектирования. В этом проекте система показала свои возможности по «бесшовной» интеграции нового МПЦ одной станции в метрополитен, работающий на МРЦ.

С ноября 2017 года в Московском метрополитене проходили испытания САУ ДЦ (Системы Аварийного Управления Диспетчерской централизацией) на станции «Битцевский парк». САУ ДЦ для Московского метрополитена является частью и построена по технологии системы «СИТРОЛ».

20 марта 2018 года в Московском метрополитене подписан Акт об успешном завершении испытаний системы САУ ДЦ на станции «Битцевский парк». САУ ДЦ является функциональным аналогом «пульта-табло» старых станций. Как и все вышеперечисленные системы она реализована на платформе «СИТРОЛ».

Описание системы

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

Готовая функциональность реализуется в виде модулей в составе АРМа и/или подсистем, ориентированных на выполнение конкретной производственной задачи. Примеры подсистем: АС РВП, подсистема единого времени, САУ ДЦ. Примеры модулей: кино, журналы, тревоги, работа с расписанием, монитор исполнения графика, расписание поездов, панель машиниста.

При внедрении системы «СИТРОЛ» не обязательно включать все доступные подсистемы и модули, а можно интегрировать новые подсистемы «СИТРОЛ» с уже существующими, даже если они созданы другими разработчиками.

Структура системы

КТС (комплекс технических средств) системы

Система логически делиться на следующие уровни:

Станционный уровень
  • Шкаф контроллера ШК) — два шкафа (основной и резервный), подключенные к МРЦ. ШК считывает сигналы ТС выдает сигналы ТУ на МРЦ. Также осуществляет подключение к другому оборудованию на станции (часы, таймеры, измерители подсистемы телеметрии и т.п.);
  • Шкаф часов (ШЧ) — служит для подключения часов (и другого оборудования) на объектах, где нет движения поездов, например, в офисных помещениях метрополитена. ШЧ не показан на рисунке;
  • Компьютеры АРМов станции — компьютеры, на которых работают АРМ дежурного персонала на станции;
  • Локальный сервер станции (ЛСС) — шкаф с резервированным локальным сервером служит для обеспечения работы станционного уровня (ШК, АРМов) в отсутствие связи с основными серверами системы. На станциях с ограниченным местом расположения оборудования (а также по желанию заказчика) оборудования ЛСС и ШК размещаются в двух или в одном физическом шкафу;
  • Локальная сеть станции — Ethernet сеть, объединяющая оборудование станционного уровня в единую сеть, физически изолированного от всего остального. Связь с верхним (серверным) уровнем осуществляется через физически другие сетевые интерфейсы ШК и ЛСС. Кроме того, в системе может присутствовать дополнительное (необязательное) оборудование:
  • Средства сопряжения с другим оборудованием — включая шкаф сбора сигналов (например, с электрооборудования эскалаторов), OPC-серверы локальных АСУТП (если таковые есть на станции);
  • Мобильные АРМы — планшеты / смартфоны с программным обеспечением АРМов уровня станции для персонала, перемещающегося в пределах локальной беспроводной сети станции.
  • АРМ машиниста — при наличии каналов связи с поездом, машинисту предоставляется полная информация о движении поезда, включая расписание движения поезда, расстояние до впереди идущего состава, плановое и расчетное время прибытия на станцию, и т. п.

Сервер

  • Основной серверный кластер — логический один сервер СУБД и приложений, размещенный на кластере из нескольких физических серверов. ПО осуществляет все функции хранения и обработки всей информации со всех станции метрополитена.
  • АРМы системы — все АРМы (кроме станционных) относятся к верхнему уровню системы. Вне зависимости от назначения (ДЦХ, ДЦХДМ, ЦДПШ, ШЧ, ШЧИЭ, ШН и т. п.) и типа (обычный или резервированный, все АРМ ы устроены одинаково и работаю с сервером системы. Более того, программное обеспечение АРМ тоже одно, обеспечивая отличие в функциональности на уровне пользователей и их ролей.
  • Web-сервер(ы) — один или несколько (в зависимости от требуемой нагрузки) серверов, осуществляют работу Web-клиентов (Web-АРМов, «тонких клиентов») через внутреннюю сеть метрополитена или через интернет. Способ подключения серверов к основному серверу исключает возможность передачи управляющих воздействий в систему.

Верхний уровень

  • Компьютеры АРМов — в том числе АРМ старшего диспетчера, АРМ диспетчеров линии, АРМ инженеров СЦБ и т.п. Компьютеры включены в единую сеть метрополитена и получают информацию от основного сервера системы;
  • Видеостена(ы) — многопанельные видеостены, отображающие схемы движения поездов по линиям или всего метрополитена. Каждая видеостена обслуживается отдельным компьютером, ПО которого имеет возможность кроме мнемосхем отображать любую информацию с любого АРМа.
Тренажер — комплект оборудования состоит из ШК, сервера и АРМа. ШК подключается к оборудованию, эмулирующему оборудование на станции. Тренажер предназначен для обучения диспетчеров и эксплуатационного персонала.

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

Аппаратная часть живет неограниченно в контексте концепции «замена спецификации на требования». Вместо ПЛК, где неизбежна привязка к вендору, используются свободно программируемые компьютеры. При разработке программной части максимально использованы готовые программные решения (например, AppServer), не требуется «изобретать велосипеды», все средства разработки и runtime могут использоваться от разных разработчиков.

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

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

Программное обеспечение системы

Программное обеспечение системы состоит из следующих частей:

  • сервер S5 — центральная часть системы, базовый программный компонент инфраструктуры;
  • ПО АРМ — одна программа ЧМИ, пользовательский интерфейс которого зависит от того, какой пользователь и с какой ролью входит в систему;
  • ПО контроллера ШК/ШЧ — работает на станционном уровне, та же программа работает и контроллеров часов для дополнительных объектов.

ПО Сервера

С помощью технологии J2EE (Java 2 Enterprise Edition) создана Объектно-ориентированная технология S5 Компании «ТоксСофт» для программной реализации информационных, диспетчерских и автоматизированных систем. В качестве J2EE-сервера приложении используется одна из поддерживаемых AppServer-ов. В настоящем проекте используется свободная реализация Wildfly.

Работа с СУБД происходит только с помощью J2EE технологии, а именно, все данные Системы моделируются Java-классами по стандартам EJB 3. Сервер S5 спроектирован так, что при модернизации и развитии Системы (например, при добавлении новых подсистем), существующие EJB компоненты не меняются, и соответственно не меняется структура таблиц СУБД.

Отличительные свойства системы

Отличительными свойствами системы «СИТРОЛ» является модульность и наличие ядра системы (рисунок структуры системы).

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

Модульность на всех уровнях (DLM, IS5Service, MWS) подразумевает изолированность частей системы друг от друга и соответственно возможность добавления или исправления одной функциональности без вмешательства при этом в другие части системы. Предусмотрен механизм автообновления АРМов.

Добавление функциональности включает:

  • добавление классов и объектов в описание системы (без программирования);
  • конфигурирование процесса чтения/записи данных (Modbus или другие протоколы);
  • опционально:
    • добавление DLM НУ (программирование);
    • добавление серверной службы (программирование);
  • добавление или обновление мнемосхем (без программирования);
  • добавление MWS-модуля отображения (программирование).

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

Ядро сервера оперирует объектной моделью предметной области приложения, на рисунке (Структурная схема ПО «СИТРЛ») — модуль sysdescr (SYStem DESCRiption). Объектная модель описывает все данные и понятия предметной области, с чем работает система, иерархия классов (типов) объектов. В частности, все существующие объекты автоматизации представлены как типизированные объекты с набором свойств. Например, типами (классами) являются «маршрут», «рельсовая цепь», «светофор», «пользователь», «станции метро» и т. п.

Каждый тип (класс) описывается как совокупность следующих свойств:

  • Атрибут — неизменяемые во времени параметры объекта. Например, тип (класс) «пользователь» имеет атрибут «Фамилия». У разных объектов этого типа отличаются значения атрибута «Иванов». «Петров» и т.п.;
  • Связь — взаимосвязь, которую объект данного типа имеет с другими объектами разных типов. Например, объект типа «станция» имеет связь «содержит в себе» с объектами типов «светофор», «перегон» и др.;
  • Данное — это свойства, значение которых меняется во времени. Например, «поезд» имеет данное «скорость», «светофор» данное «состояние» и т.п.;
  • Событие — описывает то, что происходит с объектами. Можно сказать, что объекты предметной области «генерируют» события. Например, при открытии двери «шкаф-контроллера» генерирует событие «открыта дверь»;
  • Команда — описывает то, что может делать указанный объект по команде Системы. Все управляющие команды описываются как одна из свойств «команда» типов (классов) предметной области.

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

Естественно, все вышеприведенное верно для программного обеспечения всех уровней системы. Для того, чтобы реальные данные появились на сервер и АРМах, необходимо новое оборудование физически подключить к ШК (например, завести сигнал на один из дискретных входов ШК).

Сервер S5 также содержит в себе модуль работы с данными в реальном времени (RT services). Модуль в реальном времени получает, хранит и выдает потребителям информацию и данных объектов, происходящих событиях, получает и отрабатывает исполнение как автоматически сгенерированных, так и выданных оператором (диспетчером) команд.

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

Все данные реального времени хранятся без ограничения времени в оперативном доступе (без переноса в архив). Сервер S5 устроен так, что глубина хранения данных в оперативном доступе не влияет на производительность работы Системы.