Legon

не представляю ее(матрицы) размер когда станция перевалит за 100 стрелок

tyubik

И не нужно:
- Матрица на блок.

bsabsa

Более "забавна" будет выглядеть ситуация, когда надо будет добавить новый статус, который будет отчего то "там" зависеть.

Tyubik, видимо хочет сделать абстрактные программные блоки с "конечным набором" функционалом из бмрц или эц12-90 и абстрактными связями.

А так идея не плоха, но и не нова ... Но реализация будет тяжела в конечном итоге, т.к. будет включать только известные "фичи" эц, и судя по разговору (конечность статусов) расширение функционала не предусматривается, что в итоге не есть "гуд".

tyubik

Однако... .

Legon

В корпусе НМШ?

tyubik

Не принципиально.

Legon

...запатентовать корпус

Николай Николаевич

Поскольку микропроцессорному девайсу переворачивание не критично - в корпусе НР...

Legon

были случаи?

tyubik

Патентуй.
Кто вообще сказал, что модуль (блок) должен быть в едином конструктиве?

Николай Николаевич

С переворачиванием реле НР?
К сожалению, были...

Omega

Каким-то образом и где-то придется прописывать взаимозависимости между объектами. Где будет это место, как его сделать распределенным? Например, как задать негабаритности и охранности, организовать район местного управления, сделать увязку с переездом, КГУ, УТС и т.д и т.п. Или вот еще: как будет работать маршрутный набор? В БМРЦ, как известно, для установки маршрутов применяется общий на станцию или район управления наборный блок НН. Видится, что в предлагаемом варианте распределенной системы МПЦ понадобится некий менеджер, который должен будет решать обозначенные вопросы. Т.е. опять общий для всей станции блок, при выходе из строя которого вся станция ляжет... В этом случае не очевидны достоинства системы с распределенной логикой.

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

tyubik

Вижу: по существу.

Omega

В самом начале ветки Николай Николаевич в качестве наиболее удачной среди систем ЭЦ, приводит в пример систему ЭЦМ КБЦШ и предлагает к обсуждению вопрос: почему бы не создать такую же универсальную и требующую минимальных усилий на адаптацию к путевому развитию конкретной станции систему МПЦ. Был провозглашен тезис: "Сегодня - время МПЦ, завтра тем более!". Все правильно, все именно так. В связи с этим хотелось бы обсудить дополнительный вопрос: какими еще свойствами должна обладать перспективная система МПЦ, что бы она получилась удачной. Есть ли такая или почти такая система среди тиражируемых сегодня МПЦ?

Николай Николаевич

"Такой" или "почти такой" - в РЖД сегодня нет!
Про то, какой же должна быть "перспективная МПЦ" - вся эта ветка, правда - с большим количеством высказываний интересных, но не по обсуждаемой теме.
И вынужден констатировать, что в разговор не включились разработчики имеющихся (в РЖД) МПЦ, что, в общем-то, вполне ожидаемо...