xmel

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

Есть три ключевых момента, которые оказывают влияние на архитектуру системы:
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. Только раньше января не ждите.

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

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

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

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

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

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