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

Это только Тюбик (не в обиду будет сказано) таким образом пытаеться сделать МПЦ.
Сомимтельно например что Вестинхгауз толже шел таким путем.

ОК ГУГЕЛ

Предлагайте новое, прежде чем хаять существующее.

МПЦ — система!!!, которая функционирует по известным алгоритмам.

Известно разработчикам, экспертам и эксплуатационному штату (которые проявляют интерес к новой системе).

Любые алгоритмы, если они правильно написаны, можно реализовать на разных устройствах: релейных, микропроцессорных, молекулярных и т.п.

Авот*Иванов**Иванов**Иванов*! Это утопия. Так делали лет 15-20 назад. Сейчас всё иначе.
Остальное впадлу комментировать, Omega, но *Иванов**Иванов**Иванов**Иванов**Иванов*бол ты редкостный.

Появились другие осязаемые предложения?

tyubik добавил 10.09.2019 в 20:31
Так, интересно просто:
— Может кто взялся за технические решения, формулировку алгоритмов, не?

:lol: :laduh: :shocking:

В чём ирония?

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

Теперь к предложению. В качестве примера я привел положительный опыт развития АСУ ТП. Существует огромное количество производителей ПЛК и стандартных сред разработки программного обеспечения, в основе которых лежат МЭК-овские языки программирования. Вдруг, кто не в курсе, вот например, что быстро нашлось: http://www.adastra.ru/products/overview/IEC61131/. Можно поискать другие среды разработки, все они в той или иной степени похожи друг на друга, есть даже возможность с определенными оговорками переносить код из одной системы разработки в другую. Как следует из истории, МЭК-овские языки разрабатывались для инженеров-технологов. Заманчиво применить ПЛК для построения систем МПЦ. Почему бы и нет? Некоторые производители так и поступают, успешно внедряются. Однако такой вариант вряд ли применим на РЖД, т.к. для экспертиз нужна открытость. Но кто из производителей ПЛК будет этим заморачиваться? Поэтому, как минимум, кибербезопасность, НДВ такие системы вряд ли пройдут. Да и МЭК-овские языки программирования не очень хорошо подходят для построения ПО МПЦ. Например. Релейно-контактная схема будет выполняться в последовательности слева направо и сверху вниз, включить последовательно обмотки двух реле не представляется возможным и т.д. Так вот, что если по аналогии с АСУ ТП разработать универсальный язык программирования для создания ПО МПЦ? Если в свое время для программирования ПЛК был изобретен язык релейно-контактной логики, понятный технологам-электрикам, то почему бы не взять за основу релейные схемы СЦБ с их принципами отображения и построения схем, понятийным аппаратом и наиболее часто применяемыми типами реле и т.д. Таким образом, процесс создания ПО МПЦ будет во многом напоминать процесс создания (рисования) проекта ЭЦ. Конечно, не надо забывать, что понадобится еще одна программа, некий движок, который будет исполнять получившуюся при проектировании схему. В нашем случае есть обязательное требование к движку, без учета которого все остальное не имеет смысла - схема должна исполняться так же, как аппаратная, по тем же принципам. Описанный подход позволил бы создать предпосылки к стандартизации и унификации алгоритмов, позволил бы студентам и инженерам изучать принципы построения современных систем, работать с ними без необходимости получения квалификации программиста. Исходный код движка, выполняющего релейную схему, можно сделать открытым и доступным для изучения, его смогут использовать производители систем МПЦ для реализации базовых функций системы, заключающихся в управлении стрелками и светофорами. Как-то так.

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

tyubik добавил 10.09.2019 в 21:14
Забудьте про контактную аппаратуру в логических цепях!
Да: в цепях управления и увязки с подобными без неё не обойтись.

В постановке вопроса ...
Сами начали ?

Отнюдь:

Почти сто страниц уже - может, новую ветку начнем?