xmel

Добрый вечер! Разрешите вставить свои пять копеек как разработчику распределенного ПО с приличным стажем.
Данный документ был написан в свое время как "разминка для мозгов", но, тем не менее, может быть интересен уважаемому сообществу.

Основные свойства предлагаемого решения ЭЦ/АБ:
- Открытость стандартов.
- Совместимость устройств разных производителей аппаратуры и ПО.
- Распределенная сеть объектных контроллеров реализующая функции исполнительной группы блочной ЭЦ.
- Безопасность движения поездов на основе серийных изделий без дополнительной настройки и, тем более, программирования, кроме соединения объектных контроллеров по топологии путевого развития станции/перегона.

Цель разработки и принимаемые ограничения
Цель разработки
◦ Стандартизированная система ЖД централизации.
◦ Актуальность на длительный срок (100 лет).
◦ Обеспечение безопасности движения поездов «из коробки» на основе серийно произведённых сертифицированных изделий.

Принимаемые ограничения
◦ Система должна удовлетворять требованием ПТЭ, ИДП, ИСИ и здравому смыслу.
◦ Объем «железнодорожной» части должен быть минимально необходимым. Всё, что не относится к безопасности движения поездов и управлением полем, реализуется средствами общего назначения.
◦ Обеспечивается совместимость между программными и аппаратными средствами разных производителей на основе открытого стандарта.

Предлагаемый порядок разработки
1. Анализ руководящих документов и существующих решений.
2. Выбор архитектуры.
3. Разработка стандартов.
4. Доказательство безопасности стандартов.
5. Реализация.
6. Тестирование и сертификация решений.
7. Внедрение и эксплуатация.

Архитектурное решение
Учитывая вышеизложенные требования, предлагается следующее архитектурное решение:

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

Система делится на 4 уровня. Наиболее сложные алгоритмы, такие как планирование движения поездов, накопление маршрутов и т. п., реализуются на верхнем уровне. На нижних уровнях выполняется непосредственное управление объектами и обеспечение безопасности. От верхнего уровня к нижнему уменьшается сложность алгоритмов и увеличиваются требования к безопасности и надёжности.

Уровень/наименование/функции

3. Диспетчерский круг/регион
АРМ ДСП, ШНС, ДНЦ, ГИД, АПК/ДК и т. п.

Среда передачи данных: Сеть телеуправления/телесигнализации (сегмент intranet, VPN и т. п.)

2. Станция/горловина
Приём команд высокого уровня.
Верификация действий пользователя.
Формирование команд низкого уровня.
Приём информации от объектных контроллеров и формирование модели состояния объектов.
Выдача информации состояния объектной модели на верхний уровень.
Диагностика неисправностей.
Резервное управление.
Журналирование состояния объектов, действий пользователей, управляющих сообщений верхнего уровня.

Среда передачи данных: Сеть объектных контроллеров. (fiber, CAN, RS* etc)

1. Объектный контроллер
Прием команд низкого уровня на управление объектом.
Передача состояния объекта. Управление объектом. Обеспечение безопасности в распределенной сети контроллеров.

Среда передачи данных: Физический уровень (напряжение/ток)

0. Привод/датчик
Взаимодействие с физическими объектами (подвижные части переводов, РЦ, лампы светофоров и т. п.)

Краткое описание функциональных возможностей и возможных решений по уровням

Привод/датчик

Используются как существующие напольные устройства, так и новые разработки.
Новые разработки напольных устройств могут иметь встроенные объектные контроллеры. Выбор физического интерфейса устройство—ОК выполняется разработчиками объектных контроллеров и устройств. Интерфейс не стандартизирован, для существующих устройств применяются существующие интерфейсы (N-проводная схема управления стрелочным приводом, контакты путевого/огневого реле, и т. п.)

Объектный контроллер.

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

Внутренняя структура объектного контроллера

Объектный контроллер состоит следующих элементов:
Интерфейс сети объектных контроллеров
Схема обработки сообщений и обеспечения безопасности
Интерфейс датчиков состояния объекта.
Интерфейс управления объектом

Алгоритмы, реализуемые объектным контроллером

Объектный контроллер должен реализовывать минимально необходимые алгоритмы безопасности, диагностики и управления. Например, не должно быть команды установить маршрут от светофора до светофора. Должны быть команды типа перевести стрелку или открыть светофор поездным/маневровым порядком.

1. Приём и отправка сообщений как от верхнего уровня, так и от соседних контроллеров.
2. Обработка команд управления низкого уровня, таких как:
2.1. Перевод стрелки
2.2. Открытие сигнала
2.3. Искусственная разделка маршрута.
3. Замыкание элементарного маршрута с проверкой безопасности путём опроса соседних объектных контроллеров, связанных по топологии станции. Замыкание маршрута делается по технологии двухфазного подтверждения транзакции.
4. Проверка безопасности установленного маршрута путём периодического опроса соседних объектных контроллеров и собственного состояния. Приведение устройства в безопасное состояние при нарушении условий безопасности движения или выхода из строя элементов системы.
5. Размыкание маршрута в процессе движения подвижного состава.
6. Искусственная разделка элементарного маршрута с выдержками времени и т. д.
7. Непосредственное управление объектом и приём диагностики с объекта.

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

УВК (сервер станции/горловины)

Выполняет функцию интерфейса к группе контроллеров. Со стороны ОК этот уровень принимает элементарные сообщения диагностики объектов и отправляет элементарные команды. Сверху уровень имеет стандартные интерфейсы на основе протокола TCP/IP. По верхнему интерфейсу выполняет аутентификацию/авторизацию АРМ, умеет отдавать диагностику в соответствующие АРМ. Работа с АРМ верхнего уровня выполняется по стандартным для компьютерных сетей протоколов и методов таких как HTTPS, REST, SOAP и пр.
На этом уровне может проверяться правильность действий пользователя, приниматься запросы на установку маршрута и разделение этих запросов на элементарные команды и пр.
Безопасность движения уровень не обеспечивает. Разрабатывается как серверное ПО.

Диспетчерский круг/ДСП.
АРМ по управлению и сбору диагностики во всех видах.
безопасность движения уровень не обеспечивает. Разрабатывается как прикладное ПО.

Открытые стандарты
Стандартизируемыми являются:
1. Алгоритм работы ОК.
2. Сообщения между ОК.
3. Управляющие и диагностические сообщения ОК-УВК (сервер станции/горловины).
4. Формат сообщений ОК.
5. Сообщения верхнего уровня АРМ-УВК (сервер станции/горловины)
Значимыми в плане безопасности являются алгоритм работы ОК и сообщения, передаваемые по сети ОК.

Алгоритм работы ОК
Для разработки алгоритма работы ОК делается анализ требований документов и алгоритмов работы существующих ЭЦ. Данный стандарт должен быть разработан в математических терминах. Для алгоритмов должно быть математическое доказательство безопасности. Этот стандарт является «абстрактным».

Сообщения ОК
На основе алгоритмов работы ОК разрабатывается стандарт на сообщения ОК. В стандарте предусматривается описание всех возможных сообщений, отправляемых и принимаемых ОК сообщений и состояние управляющих сигналов в зависимости от этих сообщений и их последовательности. Должно быть математическое доказательство безопасности для всех последовательностей сообщений. Является первичным документом для тестирования/сертификации изделий. Сертификация по примеру устройств PCI, USB или сетевых контроллеров, т. е. всё должно работать со всем.

Формат сообщений ОК
Для обеспечения реализации ОК и логической совместимости ОК и ОК-УВК формат разрабатывается на основе стандартов X.500 на языке ASN.1 (активно используется в криптографии и связи для побитового описания структуры сообщений). Для обеспечения физической совместимости ОК должна быть выбрана среда передачи сообщений на основе существующих стандартов физического уровня.

Также возможна стандартизация конструктивного исполнения ОК/УВК (стативы, шкафы, питание, разъёмы, кабели и т. п.)

Форматы управляющих сообщений
Форматы сообщений АРМ-УВК разрабатываются на основе стандартов корпоративных сетей, таких как XML/XSD, JSON. Для передачи сообщений и обеспечения защиты от НСД и пр. используются действующие стандарты передачи сообщений, шифрования, аутентификации и авторизации (HTTP/HTTPS, SOAP, криптография по ГОСТ и т. п.)