Не сомневаюсь, что и может, и будет реализовано в недалеком будущем.
Но функции РБЦ - МПЦ на себя не возьмет, не её эта задача...

вас вводит в заблуждение то что один разрабртчик (напр. Бомбардье) разрабатывает и МПАБ и МПЦ

А стОит ли делить? Может, целесообразно создать единую систему, раз уж речь о внедрении новой элементной базы и новых алгоритмов работы?

Мое мнение - иметь МПЦ и не иметь интегрированную в эту МПЦ автоблокировку на прилегающих перегонах - как минимум странно.
А в случае с мультистанционной МПЦ - странно вдвойне.

Николай Николаевич добавил 19.12.2017 в 11:44
Даже если это будет в одном конструктиве - функционально МПЦ и а/б будут оставаться абсолютно разными системами, каждая из которых живет по своим правилам игры.

Это пользовательские функции. Функционально системы будут разными только для ДСП и ДНЦ, т.е. на уровне графических интерфейсов их АРМов.

Пора Вам начинать изучать СЦБ...:sm496:
Функционально ЭЦ и а/б разные прежде всего - для машиниста!
И задачи МПЦ и а/б решают совершенно различные!

Вот только сами машинисты участки между маршрутными светофорами на главных путях крупнейших сортировочных станций называют "блок-участками", как на перегонах при АБ. Хотя в официальной литературе такая терминология не применяется. Так что с точки зрения именно машинистов, структура СЦБ - это только для СЦБистов важно, а их напрямую не касается :raD:

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

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

Актуален, это один из постулатов сложившейся системы управления движением поездов!

Похоже, это связано с алгоритмом смены направления на путях перегона и станции?

Нет, это никак не связано с алгоритмом смены направления движения по перегону. На путях станций "смены направления" - не бывает.

Это можно об'едает о простой логикой, не требующей знаний в области СЦБ. Поскольку на перегоне отсутствует путевое развитие, то препятствие может быть только по ходу движения. А на станции имеется вероятность помехи как справа, так и слева. К тому же визуально из кабины нет возможности оценить немпревышение допустимых 4 мм зазора и опасность отжатия остряка. Поэтому на переговорах возможно допустить проезд машинистом самостоятельно, а на станциях это недопустимо категорически.

Добрый вечер. Честно говоря, мне кажется, что дискуссия разъехалась. Поэтому предлагаю последовательно, от общей архитектуры к конкретным техническим решениям.

Есть три ключевых момента, которые оказывают влияние на архитектуру системы:
1. Обеспечение безопасности движения поездов.
2. Деньги.
3. Время.

Безопасность движения поездов это, безусловно, то основное, от чего отталкиваются при проектировании систем СЦБ. Вследствие этого, для любого компонента системы, а также для совокупности взаимодействующих компонентов необходимо доказывать эту безопасность. В моем понимании безопасность движения поездов это выполнение некоторых очень простых требований, конечным результатом которых является невозможность, с определенной очень высокой вероятностью, допустить столкновение подвижного состава, а также сход его с рельсов в результате превышения установленных скоростей движения. Эти требования прописаны в трех книжках, а интерфейс машинист--система ЭЦ прописан в РУ. Всё остальное в вопросы обеспечения безопасности движения поездов со стороны СЦБ де-факто не входит.
Также, я принимаю, что возможность несанкционированного использования системы при выполнении требований безопасности движения поездов несет существенно меньший вред, чем собственно нарушение безопасности движения поездов.

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

Возьмем крайние случаи:
1. ЭЦ на объектных контроллерах с местными зависимостями. Требуется СПЕЦИАЛЬНО разработать и доказать безопасность:
- Объектные контроллеры со схемами увязки с железом и линиями связи (например, оптика) со своим программным обеспечением
- Линии связи (доказать, что засветка оптики при её откапывании и повреждении не приведет к приему ложных сообщений)

2. "Сверхцентрализация". Опять-таки, требуется СПЕЦИАЛЬНО разработать и доказать безопасность:
- Объектные контроллеры и программное обеспечение объектных контроллеров.
- Линии связи и коммуникационное оборудование на участках объектный контроллер-пост ЭЦ-какой-то хаб-совсем крупный хаб-ГВЦ РЖД, а также программное обеспечение, управляющее передачей сообщений.
- "Мейнфрейм", управляющий сетью и реализующий зависимости, а также его программное обеспечение.

В любом случае, будет какое-то место, куда подключаются АРМ с ОС общего назначения, и где заканчивается система, обеспечивающая безопасность.
На самом деле, оптимальное решение будет, как всегда, где-то посередине, и оно будет зависеть от многих факторов, в том числе и не технического характера.

Но я могу сделать примерный расчет для "распределенной ЭЦ", в млн руб. Цены сопоставимы с разработками ПО по госконтрактам и железу оттуда же. Берем только управляющую систему, без светофоров, кабелей, приводов и всего остального, что одинаково для всех решений.

Единовременные затраты:
1. Разработка стандартов - 120
2. Принятие ПНСТ - ? пусть 300
2. Разработка нескольких моделей ОК (светофор, стрелка, путевой приемник) 3*50
3. Сертификация ОК 3*10
4. Разработка АРМ ДСП, ШНС, ДНЦ плюс софт для проектирования 300*3года поэтапно
Итого единовременно 1500

Стоимость ОК 0,2
Принимаем количество объектов на сети как 20 000 централизованных стрелок, по 2 светофора на стрелку, 3 РЦ на стрелку. Общее количество 120 000.
Итого ОК: 24 000
Выходит, что примерно за 25,5 миллиардов рублей можно полностью поменять всю ЭЦ РЖД на современную.

Ну и по времени. Может-ли РЖД потратить на систему управления движением 26 млрд руб за 10 лет? Думаю, может. Может-ли РЖД потратить по миллиарду рублей на МПЦ каждой из 2000 станций? Сомневаюсь.

Да не нужно будет ничего допаивать. ОК должен быть тупой как пробка. Включили правильно--работает. Включили неправильно--не работает. Предыдущие РУ были выпущены в 1980 году, действующие в 2012. Прошло 32 года. Все блоки вЫходят срок службы за это время. Инструкция по сигнализации меняется примерно также. Не нужно никаких постов ЭЦ, для серверной достаточно помещения, например, в контейнере КТСМ или на посту ДПП, заодно и под присмотром будет. Сами ОК должны быть вообще необслуживаемые.

Хорошая мысль. На досуге сделаю модель на java. Только раньше января не ждите.

Это будет тоже, но только это железо должно обеспечивать только управление по алгоритмам любой сложности. Зачем выносить обеспечение безопасности на верхний уровень--непонятно. Светофорный контроллер априори должен быть безопасным. Ну и пусть обеспечивает и безопасность зависимостей, задача одной сложности.

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

В МПЦ ОС не нужно. Но нужно доказывать безопасность ПО и его конфигурации. И, поправьте меня, если я не прав, но для каждой станции/участка.

Каждый лишний бит данных это увеличение количества возможных состояний системы вдвое. Вопрос, как будем безопасность доказывать?

Давайте отделять мух от котлет. Безопасность движения обеспечивается конечным автоматом. Прочие примочки должны быть отдельно.

Вопросы управления правами в компьютерных системах это вообще отдельный разговор. Всё, остальное завтра :lopata:

нисколько. дискусия судя по всему на верном пути

у приемника ТРЦ внутри микропроцессор или ПЛК???
не, не слышал.
можете продемонстрировать???