Это, конечно, моё личное мнение, но мировая практика показала, что успешнее всего разработка устройств централизации и интервального регулирования "в довесок" реализуется компаниями, производящими и поставляющими подвижной состав: ALSTOM, Thales, Hyundai ROTEM. Вот, наверное, путь поиска потенциального разработчика АТ на ЖД.

Это, конечно, моё личное мнение, но мировая практика показала, что успешнее всего разработка устройств централизации и интервального регулирования удаётся компаниям "в довесок" к производимому и поставляемому подвижному составу: ALSTOM, Thales, Hyundai ROTEM. Вот, наверное, путь поиска потенциального разработчика АТ для ЖД.

И самое главное, имеющие выход, на международный рынок сбыта.

нЭт, я нЭмножко другое хотел выразить слогом сим, но Ваша мыслЯ мне ндравица.

tyubik добавил 18.09.2019 в 18:10
Так что, сдаётся мне, не в поле действия ЦШ лежит эта задача. Вернее, не только в этом поле. Вернее, не столько ЦШ.

Да, я знаю, что там так все запутано и что кому-то это нравится, что делать приходится без вариантов...

Николай Николаевич добавил 18.09.2019 в 18:20
Не берусь комментировать мысль о связке разработчиков подвижного состава с разработкой средств ЖАТ, возможно что-то в этом и есть.
А вот про "путь поиска потенциального разработчика АТ" - насколько я понимаю, проблема не в поиске и задачи такой не стоит...

Я, если честно, не понял, что Вы хотели этим сказать и что Вам нравится,

но под слоганом международный рынок сбыта я имел ввиду, что у компании разработчика МПЦ рынок одной какой-либо страны не является определяющим фактором существования компании.

На российском рынке, точнее не так - российские компании, представляющие рынок СЦБ в России (хрень какая-то ))) ), не имеют выхода на международный рынок, и поэтому их продукция акромя 5000 станций в ОАО РЖД не нужна никому (Причем можно подлить масла в огонь - в процентном исчислении, на 80% станций на сети РЖД, МПЦ вообще "не уперлось" от слова СОВСЕМ).
А то, что предлагает Николай Николаевич - сделать одну МПЦ, которую потом силами шанцевого инструмента (да простят меня сотрудники РЖД) адаптировать на 4999 других станций, что в итоге приведет к разорению компании разработчика МПЦ.
Кому оно это надо :net: ?

У РЖД позиция какая-то "дикая" - она хочет ездить, но в разработки не хочет потратиться. Где так бывает?

Подозреваю, что если в РЖД появится "такая" МПЦ - то у неё будет и зарубежный рыночный потенциал...

А вот интересно, есть такой термин "Техничеcкое задание" - которое (не, который) всегда разрабатывал РАЗРАБОТЧИК системы, а не ЗАКАЗЧИК, которое утверждал ЗАКАЗЧИК.

А РЖД слабо написать грамотное ТЗ на систему МПЦ, которое он хочет видеть у себя на объектах инфраструктуры и выложить сей документ в public.

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

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

Прошу несколько часов для краткой и ёмкой формулировки.

Без обид - у кого "содран"?

bsabsa добавил 18.09.2019 в 19:08
Ок! :raD:

Коллеги! Еще немножко и перейдем на следующий уровень - 100 страница!!!!!

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

Стоп! В конец очереди.

tyubik добавил 18.09.2019 в 19:42
А вот это, дорогой мой, уже повод для разбирательства, ибо осведомлён был ОЧЕНЬ скромный круг специалистов.
От кого информация?!

Сименс, наверное, помог под себя написал?