Не знаю, о чем мечтают в ПКТБ (и вообще, мечтают ли), но ПКТБ даже к разговору на данную тему не готов. К сожалению.
А в части собственников - собственником должен быть только балансодержатель.

РЖД лучше занимался скворечниками/синичниками.
Место разработчика ПО и МП электроники занято навсегда.

етить колотить, какая каша у многих комментаторов в голове о программировании и ОС )))

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

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

к 2097 успеем? РЖД постоянно плачется что у них денег нет..

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

Есть некоторые нюансы..
есть организации в которых есть люди которые могут сесть и написать ПО, а есть другие организации и люди, которые могут написать ПО и потом сесть.

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

Я в этом же ключе как то высказывался. Пришло время объединить разработчиков и производителей МПЦ под одной крышей, определить 1 -2 системы и их тиражировать, а привлеченным к этой "сборной" определить каждой группе свой кусок пирога. Не очень по рыночному? Зажим конкуренции? Таки для оборудования РЖД почти по всем направлениям так. На старых ЭЦ долго не проживем, жизнь заставит резко увеличить объёмы МПЦ и сейчас нужно готовить такую модель организации разработки(доработки), производства, системы сервисного обслуживания МПЦ.

Уверен, что разработчики МПЦ выполнят любые работы связанные с МПЦ гораздо быстрее и дешевле чем "Завистьимые".

Legon добавил 26.01.2017 в 11:21
Предлагаю отказаться от Ebilock, оставшихся объединить и распределить подряды. Убрать "РЖД составляющую" стоимости системы.

Так как система будет полностью открытой для тиражирования, разместить исходные программные разработки в свободный доступ, например на www.scbist.com с подробным описанием.

Если будет общая концепция построения МП систем разработчики сами по себе объединяться (некоторые разработчики между собой уже объединены, например, на уровне общих форматов сообщений (СДУМ передача информации в центры мониторинга))!

Что такое единая/общая концепция создания систем ?

Только набор функций и алгоритмов реализации этих функций?

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

Просто инженер АиТ добавил 26.01.2017 в 13:31
Ещё несколько принципов.
- совместимость. Изготовители аппаратных средств могут быть различные, но их изделия в системе должны быть совместимы;
- преемственность. Ничто не стоит на месте, всё должно развиваться, но более новые изделия должны поддерживать работу более старых разработок;
- масштабируемость. Наращивание, изменения конфигурации, топологии должны осуществляться на уровне файлов настройки, при этом не должен изменяться программный код системы (элементов системы).

Необходимо единое ПО(САПР) - Конструктор станции/перегонов.
Во главе всего - схематический/путевой план созданный в конструкторе, логика проверок на основе релейных схем ЭЦ-12/АБТЦ.
Внутренний мир системы - объектный.

Да, необходим, но пока не возможно это сделать!

Просто инженер АиТ добавил 26.01.2017 в 14:10
Еще пара принципов.
- универсальность. Возможность применения однотипных изделий для различных по назначению системах. Например, элемент ввода дискретных сигналов может быть одинаковым для систем ДЦ, ДК, ЭЦ, ГАЦ, СТДМ;
- внутренняя самодиагностика каждого изделия применяемого в системе.

Для меня, эксплуататора, вопрос единого ПО вторичен, на уровне ШЧ им всё равно никто не будет заниматься, править.
Для эксплуатации принципиально "железо"!
1. Минимизация применения реле.
2. Стандартизация системы электропитания ЛЮБЫХ МПЦ на основе наиболее удачных элементов системы, уже созданных в различных МПЦ.
3. Стандартизация применяемых контроллеров на основе наиболее удачных вариантов
4. Стандартизация систем управления напольными устройствами.
Извиняюсь за "кривую" терминологию, всё же мы эксплуататоры пока в основном "релейщики".