А когда они сейчас вычищаются?!

на разных этапах (согласно ПМ) на иммитаторах, макетах, при пусконаладке...

Ну и там также возможны проверки.

"Там" - это где? В горловине? На послу ЭЦ крохотного разъезда на ДУ где-нибудь в тайге? ПО "там" допиливать будем? Или электронные "блоки" допаивать?
Не туда Вы нас зовете, не туда...

Звать я не могу, не тот уровень.
А показать возможности альтернативного децентрализованного варианта, да хочу. Любая централизация системы должна быть логичной и обоснованной.
Проводя ассоциацию. Если бы головной мозг должен был управлять каждой клеткой, думать как согнуть палец, какие мышцы напрячь, чтобы сделать шаг - мы бы просто не смогли шевелится!
При реализации Вашего проекта, на станциях всё-ровно появляются Объектные Контроллеры, которым нужно качественное питание, нужна линия связи. В децентрализованном варианте те же контроллеры, только с большими возможностями по проверке условий безопасности непосредственно на станции, а не передавая в центр каждый свой программный шаг.

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

За что обижаться, за то, что есть иное мнение - так это счастье! Хуже, когда его нет, это как в шахматы играть со слабым противником (я знаю, что шашматами Вы не увлекаетесь). Когда есть альтернативные варианты, то каждый вариант становится только сильнее, ибо ему приходится доказывать свою правоту, а это здорово!

В БМРЦ нет обобщающего блока. В предлагаемом варианте ОК работают все вместе, например, находясь на общей шине обмена (например, всеми любимой CAN шине) и могут обмениваться информацией между собой, без участия ведущего блока (никто же не говорил, что должен быть только один порт (имеется ввиду физический порт) для связи). Более того, понадобится ещё один порт для технологической связи, для диагностики (для проверки, настройки и технологического тестирования ОК) и связи СТДМ (можно, конечно, весь обмен организовать по одному порту, но это будет неудобно). Можно работать по одному порту, но в разных протоколах (правда, не все такое умеют программировать!), да и зачем, если без проблем можно добавить физический порт, сейчас стоимость железа достаточно низкая.

Как бы Ваши ОК не обменивались информацией, где-то, в каком-то месте должно быть решающее устройство, которое скажет: трасса маршрута свободна, можно переводить стрелки в требуемое положение. А до этого - получить от ДСП заявку - хочу маршрут от светофора А до светофора Б. А еще до этого - проверить, что в этот момент времени не переводятся стрелки для установки другого маршрута. И так далее.
Я понимаю, что физически можно сделать подобную схемотехнику и на электронной элементной базе - только "конфетки" во всем этом я не вижу! Будет "блочная электронная БМРЦ", еще менее надежная, чем релейная.

Это в идеальном варианте. Реально проблемы бывает появляются через несколько лет. Например, изменились временнЫе характеристики сети передачи (перешли с 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 хватит. Хотел написать утрирую, но подумал, что составителю будет в самый раз. Самое главное тут--один раз зашили безопасность в очень ограниченное количество прошивок блоков, и это сделали очень крутые спецы. Остальное могут делать любые разработчики, используя компьютеры, операционные системы, сети, протоколы общего назначения--отлаженные и дешевые.

xmel, возьмите в качестве примера не станцию, но перегон. У него топография выгодна.

УВК - это слишком громко сказано! Многие подумают, что это обязательно должен быть какой-то суперкомпьютер, а на самом деле в ОК, например, управления светофором дописывается часть ПО контролирующая зависимости ЭЦ, по связи с другими ОК (РЦ, стрелок).

Просто инженер АиТ добавил 15.12.2017 в 09:28
И сразу же решим задачу с подвижными блок-участками.

Николай Николаевич! "А предлагаемое "железо" - потребует постоянного обслуживания. Ну и так далее - поэтому концентрация в одном месте." - В Вашем решении тоже самое, только функциональность ОК, чуть проще!

Николай Николаевич,
Продублирую свое сообщение (похоже, что никто особо на него не обратил внимание):
"Внесу свои пять копеек.
Распределенная система имеет следующий недостаток. При реализации такой схемы надо учитывать время реакции "мозгов", которое, как выясняется, не микросекунды. Так при пуске Уяра по нашему проекту (примерно 2000 год, КрасЖД) наступили на граблю с задержкой включения кодирования на границе зон ответственности. Решили укладкой физической пары и установкой "живого" кодововключающего реле. На ту же граблю наступили (уже не мы) при АЛСО-Е (восточный полигон, информация от Бомбардиров) с размещением оборудования на двух прилегающих станциях на границе деления (причина та же - быстродействие работы ОК и ЦП). Решение то же - укладка физики и установка живого повторителя путевого реле - офигенное решение для полностью микропроцессорных систем (МПЦ + ЦМ КРЦ с бесконтактным интерфейсом). Про кабель в алюминии молчу (оказались нужны линейные цепи между станциями и соответствующие мероприятия по защите от ЭТ переменного тока).
Еще одна проблема - стрелки с двойным управлением при МПЦ. Кто сталкивался, тот поймет. В расчете длины предстрелочных участков нужно учесть "время реакции устройств МПЦ (объектные контроллеры, ЦП ) на получение контроля занятости секции", значение которого никто не может гарантировать - все зависит от текущей загрузки вычислительных средств (Бомбардиры предложили принимать 0,9 с, но "руку на отсечение не дадут", т.к. нет полной уверенности). В проекте сделали согласно рекомендациям Бомбардиров - ждем первого взреза или схода (тьфу-тьфу-тьфу). Для полной уверенности нужно собирать "живую" схему стрелки с релейно-контактным интерфейсом.
И последнее. В статье упоминается "силовая линия питания (с кольцевой топологией)". Это кабельная линия 0,4 кВ? Тогда две проблемы: падение напряжения и наведенка. Падение можно уменьшить увеличением сечения (сомнительно, цена вопроса). С наведенкой сложнее. При удалении горловин на 1-1,5 км от поста ЭЦ на участках с ЭТ переменного тока это кольцо можно даже не запитывать, будет работать от наведенки (шутка, но про качество электроэнергии можно забыть). Применять силовые кабели с алюминиевым экраном? Существуют ли такие в природе? Еще вариант - поднять напряжение питающей линии пост ЭЦ - горловины до 6-10 кВ. А оно нам надо разводить энергетическое хозяйство с двойным преобразованием по сути ради экономии пары бесперебойников и одного дизеля? Как будет работать кольцевая схема в случае повреждения? В автоматическом режиме? Тогда нужно дополнительное железо у энергетиков. В ручном режиме? Тогда нужен человек и, опять же, дополнительное железо".

Два ключевых момента - быстродействие мозгов централизованной системы и организация питания мест установки ОК. Кто что думает?

Она и так решена...

Николай Николаевич добавил 15.12.2017 в 09:39
Нет, не тоже самое!!!
В "коллективной" МПЦ, когда в одном месте собраны УВК всей дистанции - условно - будет постоянное квалифицированное сменное дежурство и постоянный квалифицированный мониторинг. А также - шикарное электропитание, кондиционирование и др.
Чего на линии не будет никогда...

ОК - минимум функционала. Исполнение в виде - ТЭЗ. С двумя светодиодами - зеленым и красным. Замена - не сложнее замены батареек в фонарике. Путейцы на линии - будут всегда, специфика такая. А вот СЦБист, с куда более высокой квалификацией - уже не нужен. ИЧ - первый шаг в этом направлении.