В том и фишка, что команда - не от УВК, а от объекта. Если хотим установить маршрут от Н1 до ЧД - команда от Н1, после проверки состояний всех объектов, входящих в матрицу Н1, вбитую "ручками" конкретно для этого Н1 этой станции.
Хотим "погонять" стрелку- команда от блока этой стрелки после проверки возможности её "погонять" согласно матрице состояний данной стрелки для конкретной станции.

Aleksey_Vladimirovich добавил 23.01.2018 в 12:27
Совершенно верно, что прописано в ПЗУ каждого объекта и сейчас, только проверяются иные условия для работы. И в случае выхода из строя этого "маленького УВК" станция "раком" не встанет.

Я привел выше десяток вариантов открытия одного и того же светофора - кто "выберет" нужный?
"Вбитая ручками" - куда, в какое устройство? В каждое? Тогда кто "все это" соберет воедино и примет решение?

Николай Николаевич добавил 23.01.2018 в 12:31
Ну это - надуманная проблема.
ГВЦ - "раком" не встает же...

"Струны"... Точно так же, как никто не принимает решение в БМРЦ, где маршруты "прописаны" в струне ... блин, ужЕ и не помню, в какой из 4-х наборной группы )))

Таки она и так не встанет. Резерв УВК же есть...

Ой, дяденька, а расскажите мне что-нибудь про неисправности ЦП (УВК) на станциях с МПЦ... )))
И про корректировку взаимозависимостей, связанную с изменением количества управляемых/контролируемых объектов, без "глухого" окна на них же ;)

Повторюсь: делать на физическом (т.е. ненадежном) уровне то, что можно сделать на программном уровне - никакого смысла не имеет...

Николай Николаевич добавил 23.01.2018 в 12:59
В МПЦ, имеющих "высокий дух" (терминология китайских коллег) - их практически нет.

Николай Николаевич добавил 23.01.2018 в 13:00
И с этим - тоже проблем нет при "правильной" архитектуре ЦП.

Более того, в предлагаемом варианте таблица зависимостей должна быть "нарезана" на отдельные "лоскуты" и соответствующий "лоскут" должен быть "залит" в каждый физический блок. При изменении зависимостей - это будет такой геморрой, что даже представить сложно...

в ракурсе обсуждаемой темы ключевое слово - взаимозависимостей...

Общий итог пока - лет двадцать назад это могло бы быть интересным и, наверное, перспективным.
Сейчас - это шаг назад...

Задачи поспорить и что-то доказать не ставилось, тут, как говорится, каждый имеет право на собственное мнение, поэтому своё видение этот непонятный Aleksey_Vladimirovich представил )))

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

))) Значит продлевать не будете? Ну, я тогда пошла.

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

И если у одного светофора 10 вариантов открытия - то что?

Ну, это же элементарно!

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