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

Насколько я понимаю, САПР - это только надстройка над Системой, которая облегчает создание Ресурса для Системы. Чтобы создать САПР под Систему надо знать как Система устроена!
Сам по себе САПР представляет интерес при тиражировании Системы.

Вы отгадаете код за 1-1,5 млн $, кто меньше?!

Что понимать под "железом"? Обьектные контроллеры? Т.е. к каком то приближении электронные реле? У первых МПЦ скорее всего такой период был, но сейчас же есть несколько типов (6?) отлаженных МПЦ и на основе изучения методов построения и элементной базы их контроллеров возможно сразу разработать новый унифицированный тип и период болезней сократить в рАзы?

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

Николай Николаевич добавил 30.01.2017 в 15:50
Я имею в виду отказы различного "железа" при эксплуатации в реальных условиях - гроза, плохое питание, помеховая обстановка от электротяги и т.д., и т.п.

А подносить "патроны" ( информацию от конечных устройств СЦБ дежурному в глаз) кто будет?

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

Николай Николаевич добавил 30.01.2017 в 15:55
Неужели отобразить и зажечь ячейки индикации на мониторе сложнее, чем сделать то же самое на железном табло с коммутаторными лампочками?

И поэтому быть ей "вечной под луной"?

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

Когда реальных объемов внедрения не хватает даже для более-менее рентабельного существования одной "вечной под луной" - это проблема, с которой рано или поздно придется что-то делать...

Где гарантия, что и он не сдуется?

Всё было бы именно так, но есть НО! Это условие выполнения условий Безопасности! Вот тут то выплывают различные нюансы построения ПО!!! Есть ещё определенные сложности, но это чисто программистские штучки (Например. Внутри программное связывание объектов после создания их по описанию Ресурса, созданного САПРом. Межобъектное взаимодействие.)!

В том-то и дело...

Как это не удивительно, но сложнее!!!

Как будто в БМРЦ не так! Всё то же самое, только в БМРЦ - все наглядно.
Все равно - все формализуется Булевой алгеброй, хоть в БМРЦ, хоть в МПЦ...
Может быть - все дело в не "наглядности" отображения алгоритмов в софте? И, как следствие, каждый программист каждый раз делает "по своему", и каждый раз - "не так, или не совсем так, как в предыдущий раз"?
А мы, потребители, все это спокойно "хаваем"?

Изюбленный всеми Ebilock имеет межобъектное взаимодествие по геогрфическому принципу. БМРЦ в чистом виде.
Это бу... алгебра, так как использование циклов приведет к снижению производительности. И придется применить 20 ядерный камень.