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

а есть человек, который может выслушать и принять правильное решение (о внедрении МПЦ) ?

Чтобы "выслушать" и "принять правильное решение" - один и тот же человек?
Хотелось бы надеяться!

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

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

Николай Николаевич добавил 17.03.2017 в 09:35
Вне контекста разговора о будущей МПЦ, отдельного обсуждения заслуживает тема с примерным названием "ЭЦ и ДЦ - где граница?".
Я имею в виду следующее: раньше для работы "под ДЦ" были специально разработанные альбомы ЭЦ, которые существенно отличались от ЭЦ "без ДЦ". Потом - с появлением микропроцессорных систем ДЦ - кто-то когда-то решил, что теперь в ДЦ можно включить любую ЭЦ. И произошла путаница на уровне алгоритмов - что делает ДЦ и что делает ЭЦ. И, мне думается, там огромный пласт, который тоже нужно разгребать и наводить порядок. Начиная - с идеологии! Которая, в свою очередь, должна быть учтена в МПЦ.

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

СЦБистам надо в свой клуб нормального АСУшника затащить, а потом уже с ним вместе думать над МПЦ. А то все одно получается, то попильный эбилок, которому ржд даже сама не хозяйка, то франкенштейны типа "Диалог-Ц".

Собственно, и дело-то, на мой взгляд, даже не аппаратных тонкостях (достойных вариантов очень много, как своих, так и зарубежных), а, скорее, в организации эксплуатационного хозяйства в РЖД. Пока нет своих программистов, и т.н. "интеллектуальная собственность" левых людей на прошивки, ничего не изменится. Никто так АСУ не эксплуатирует.

А можете в точно таком же ракурсе прокомментировать существующее у нас положение дел не с МПЦ, а с ДЦ? Их же тоже 6 систем уже в эксплуатации, причем достаточно давно.

У нас нет ДЦ, Николай Николаевич, не сталкивался. Да и современные МПЦ все функции ДЦ уже изначально в себе содержат.

Спасибо. Я же почти никого не знаю - кто где и кем.
Про то, что МПЦ должно в перспективе забрать в себя все функции ДЦ - я знаю.
Меня в Ваших словах про МПЦ больше заинтересовала оценка работы над созданием МПЦ в части участия СЦБистов и АСУшников. Эту тему, похоже, нужно "копать" глубже...

Builder - для меня как некий простой и достойный инструмент. В ряде случаев для создания ПО контроллера делаю следующим образом. Пишу исходник с условной компиляцией для возможности компилирования в среде Builder и в среде AVR. Под Builder достаточно простой и хороший отладчик, основную отладку делаю в Builder, а затем уже дорихтововаю на реальном железе, получается значительно быстрее!

Не так давно (год так 2012) мне пришлось проверять работу софта для 580 процессора с целью заменить систему собранную на КТС-ЛИУС (реальную), не только морально, но полностью физически устаревшую на туже самую систему работающую на современном промышленном компьютере (исходных текстов ПО не было даже у разработчиков). Написал симулятор 580 процессора и симуляцию блоков получилось классно, правда были заморочки с обработкой прерываний, загрузил ПО 580 процессора в свою программу и оп древний софт заработал. Хорошая была работа, но реально не потребовалась, просто удавили на объекте автоматизацию, ну это другая история и мне неинтересная.

Просто инженер АиТ добавил 17.03.2017 в 10:35
У меня есть ПО АРМов АСДК (в основном отображение сигналов ТС), который мы в свою очередь разрабатывали, есть версия ПО с созданием маршрутов и индивидуальным управлением устройствами ЖАТ (стрелки, сигналы) делали для макетов. Т.е. практически АРМ МПЦ. Этот АРМ формирует команды для макетов, я эти команды перенаправлю в будущий мой софт МПЦ (софт МПЦ делаю для модульного исполнения контроллерами, но этот же софт можно закрутить на компе). И можно отлаживаться.
Так же есть версия АРМа где можно задавать движение составов это делалось для макета отладки ЭЦ на станции при пуско-наладке.

А теперь давайте переместимся в будущее... лет на 10-15, как раз к тому периоду времени, когда Супер-пупер МПЦ-НН начнет широко тиражироваться на сети.

Как Вы считаете, кто будет производителем данной МПЦ-НН?

В конце 90х нам потребовался свой АРМ АСДК для возможности отладки АСДК станций. Заморачиваться не стали нашли простой выход. В среде Builder создали компоненты ЖАТ станции, нарисовали станцию из этих компонент, немного покрутили код и нет проблем АРМ готов!
Вот примерно также на первом этапе поступлю!

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

На втором этапе куплю у Китайцев штук 10 Ардуинов (200 рублей * 10 = 2000 рублей), на основе их с имитирую контроллеры ЖАТ для МПЦ.

Кстати, самый оптимальный вариант ))) Если действительно сподобитесь, то напишите тип и количество - периодически возникает возможность бесплатной доставки (с оказией).

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