Система диспетчерского управления движением поездов метрополитена «СИТРОЛ»
В 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 устроен так, что глубина хранения данных в оперативном доступе не влияет на производительность работы Системы.