не успеваю читать всю ветку.
на мой взгляд нормативная база для чего нужна:
- создаем гост или отраслевой стандарт на условно графические элементы для отображения на АРМ-ДСП. необходимо определить минимальный перечень, а точнее всё то что необходимо для индикации и работы ДСП, все остальное в армы ШН. (данные стандарты позволят на разных МПЦ иметь одинаковый интрефейс для работы ДСП)

- четко прописать стандарты электропитания, а то получается ставим МПЦ, МАБ и прочие микропроцессорные СЦБ системы и на каждую по своей питающей.

- установить стандарт для обмена между разными МПЦ. также я бы стандартизировал ДЦ протокол, который можно встроить в МПЦ тем самым мы избавляемся от кучи лишнего оборудования на линейных пунктах на мой взгляд очень нужный документ

это уже по своему довольно массивная работа и решает целый ряд задач.

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

касательно элементной базы и упомянутыми процессорами эльбрус, производители МПЦ как я думаю производят свои системы модульно, будут модули на эльбрус будет вам МПЦ на них. сам производитель мпц проектировать модуль и производить его не будет (НН согласитесь, что овощи которые вы кушате дома не все с вашего огорода).

PS: Н.Н. еще меня вот заинтересовал вопрос, почему вы так настаиваете на архитектуре системы 2 из 4? чем она лучше 2 из 3 или 1 из 2D?
А так в целом стоит начать с того, что нужно провести расчет экономической выгоды и сделать анализ на соответствие безопасности будущей МПЦ. кстати это была бы неплохая дипломная работа, притом ее можно разбить на несколько человек.

кстати, мне очень не нравится ваша позиция про ПО.
1. вы как заказчик очень себя ограничиваете в выборе
2. не возможность поспевать за вычислительной техникой и возможностями
3. торможение развития архитектуры МПЦ и применение новых возможностей
4. низкая кибер безопасность
5. экономически не эффективно, ваши программисты будут ездить на майбахах =)))

это как я как вижу проблемы, а профессионал в этой области думаю сможет вам представить более весомые доводы.

Вы совершенно правы: СЦБ всего лишь "довесок" к дорогостоящему подвижному составу.

Не соглашусь. В наши дни подвижной состав уходит китайцам, а СЦБ становится высокоинтеллектуальным продуктом, который китайцам не под силу (пока).
Как быстро все меняется, еще недавно был действительно довеском.

По теме: попытка монополизировать разработку ПО ни к чему хорошему не приведет. Тем более все равно придется адаптировать его под разное железо. Лучше бы интерфейсы максимально стандартизировали, пользы было бы больше.
Все остальные предлагаемые решения в целом соответствуют некоторым существующим мировым тенденциям (не считая упорной приверженности рельсовым цепям).

Рельсовые цепи - это наше все!
И главным образом - рельсопроводный канал передачи информации на борт!

Николай Николаевич, я еще помню времена, когда Вы говорили, что нужно переходить к радиоканалу и уходить от рельсовых цепей как канала передачи на борт.
Если отвлечься от пресловутой кибербезопасности, то почему именно по рельсам так хочется передавать данные на поезд?

AlexeyE, между прочим, в конце 90-х именно рц и халатность путейцев предотвратила (не опечатка! халатность предотвратила!) крушение скоростного поезда. "Аврора" или "Невский экспресс" - я не помню. Вроде "Аврора".

Есть еще множество повреждений пути, которые могут привести к сходу. Помимо излома рельса с разрывом электрической рельсовой цепи.
Но и здесь есть альтернативные решения, вот, например. Со своими ограничениями пока, но все же.

Поскольку базисный постулат не верен, то и надстройки внимания не достойны.

Вы это Альстому с Сименсом и Бомбардье расскажите, может успокоятся.

Молодец: понимаешь;)

Да, я тоже помню это! Я уже описывал наше устройство, которое мы сделали, а сейчас просто всё разобрали. На борт, можно было передать поездное положение станции, древний код АЛСН-ЕН и ещё более древние коды КПТ.
Время обновления станции не более 5 с,
Время передачи изменения поездного положения не более 1 с.
Время передачи кода АЛСН-ЕН и простого кода АЛСН не более 10 мс.
Кроме того, планы станций не надо прошивать в бортовые системы локомотива, они подгружаются автоматически в зависимости от местоположения локомотива.
И всё это можно передать по рельсам, как многие говорят по грязному каналу.
Почему-то все зациклились на древних методах кодирования РЦ, которые были разработаны под то железо, которое на то время было!

Интервальное регулирование на отдельном комплексе программ и аппаратов строить будем или нет?

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

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

Цель разработки и принимаемые ограничения
Цель разработки
◦ Стандартизированная система ЖД централизации.
◦ Актуальность на длительный срок (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, криптография по ГОСТ и т. п.)

Просто так, к слову - на примере ВСМ Москва - Казань стоимость высокоскоростного поезда примерно равна стоимости строительства ДВУХ километров высокоскоростной линии.

Николай Николаевич добавил 12.12.2017 в 10:06
Я бы различал задачи...
Для обычного, привычного нам смешанного пассажирского и грузового движения обычной АЛС недостаточно в силу малой информативности. Мы никак не может передать на борт информацию о маршрутах при следовании на боковые пути станций, особенно на крупных участковых и сортировочных станциях. Можно посредством САУТа или АЛС-ЕН -
но это дорого и громоздко. Поэтому нужен радиоканал. И в свете решения этой задачи - мы не боимся "деструктивных воздействий" на радиоканал извне, поскольку скорости "на бок" небольшие.
Для ВСМ - все иначе. Большие скорости, потециально много информации о состоянии объектов инфраструктуры от систем диагностики и мониторинга, информацию на борт о параметрах движения нужно передавать не с промежуточной станции, а из центра радиоблокировки (РБЦ) - поэтому без радиоканала никак. Но при таких скоростях приходится бояться пропадания или подавления радиоканала - поэтому неизбежно дублирование радиоканала посредством АЛС-ЕН через рельсовую линию.
Тезисно - вот как-то так...

Если допустить, что информативности обычной АЛС хватает, то количество сбоев и тенденции к снижению(исключению) во внимание не принимаем?