xmel

Это в идеальном варианте. Реально проблемы бывает появляются через несколько лет. Например, изменились временнЫе характеристики сети передачи (перешли с 10 мегабит--ну нету больше таких железок--на 100) проявилась ошибка, которая никогда до этого не появлялась, например.
Извините за сленг.

Кстати, для сверхцентрализации возможны такие ошибки, которые сегодня в страшном сне не приснятся. Например, кто-то попрыгал на крышке привода УЗП на неохраняемом переезде. А в результате перекрылся входной перед поездом за 1000 км.

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

Использование протокола TCP/IP не проблема, если использовать соотвествующие технологии. Например, VPN, QoS. Банки и госструктуры как-то живут. Тут скорее проблема с качеством разработки решений на отечественной криптографии--отдельная больная тема.

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

Примерный алгоритм, как все должно работать:
1. ДСП задает маршрут, например, на проход от Н через Н1.
2. Программа АРМ ДСП предварительно проверяет условия допустимости установки маршрута в данной обстановке.
3. При возможности задать маршрут (свободность секций), АРМ выдает команды на перевод стрелок по маршруту для каждой стрелки. Стрелочные контроллеры выполняют команду только в случае, если соответствующие рельсовые цепи свободны и не замкнуты в маршрутах, в противном случае выдают квитанцию о нарушении условий безопасности.
4. АРМ ДСП выдает команду на открытие светофоров по маршруту, начиная с Н1 (для исключения проблеска желтого огня)
5. Контроллер светофора проверяет, что можно проехать (свободность, стрелки) до следующего сигнала, с проверками установленного направления движения по перегону и т. п.
6. Контроллер светофора выдает команду на предварительное блокирование блоков по маршруту. Если в это же время другой светофор попытается заблокировать те же участки, возникнет конфликт, об этом уведомляется второй светофор, он же отзывает предварительную блокировку с тех блоков, которые он успел заблокировать. Возможно состояние deadlock, но обычно эти проблемы решаются таймером. Кроме того, при управлении с одного АРМ это маловероятно, но эту возможность нужно предусмотреть.
7. Контроллер светофора проверяет, что на всех блоках маршрута до следующего сигнала установлена предварительная блокировка. В этом состоянии ни один другой сигнал уже не может использовать блоки. Светофор дает команду на окончательное замыкание маршрута.
8. Контроллер светофора проверяет блокировку маршрута и открывает сигнал.
9. Впередилежащие блоки постоянно отправляют свое состояние по шине, светофор контролирует наличие блоков, их состояние и заблокированность в маршруте. Если что пошло не так--перекрывает сигнал.
10. АРМ ДСП постоянно видит, что происходит на поле, отображает состояние в интерфейсе пользователя.

Можно примерно так же расписать размыкание маршрута.

Алгоритм, может быть, достаточно сложный. Но его нужно реализовать и оттестировать только один раз для всех светофоров. С другой стороны, протоколы обмена по компьютерным шинам типа PCI как минимум не проще. Там тоже адресация, захват шины, арбитраж, приоритеты, работа по фронтам/спадам сигналов и прочие радости. И железо успешно эти протоколы поддерживает. И все совместимо со всем (ньюансы вроде 32/64бита, 33/66/133 МГц и питание 3.3/5V рассматривать не будем).

В МПЦ реализуются похожие алгоритмы. Но все это происходит не с реальными блоками, а с моделью в памяти. И с необходимостью как-то надежно поддерживать актуальное состояние модели, передавать отвественные команды, защищаться от возможной модификации памяти соседними процессами и так далее.

Электронная Исполнительная БМРЦ это хорошо. Она разрабатывается один раз. А все ньюансы управления, которые не относятся именно к ЖД безопасности могут быть решены разными способами. Кому-то нужны промежуточные сервера и дистанционное резервированное управление. Кому-то и планшета по wifi хватит. Хотел написать утрирую, но подумал, что составителю будет в самый раз. Самое главное тут--один раз зашили безопасность в очень ограниченное количество прошивок блоков, и это сделали очень крутые спецы. Остальное могут делать любые разработчики, используя компьютеры, операционные системы, сети, протоколы общего назначения--отлаженные и дешевые.