На ответственные/крупные станции ставить ЭЦ-ЕМ, на менее ответственные - МПЦ-МПК, МПЦ-И. Остальных выгнать всех к едреней фене.

это наша корова и мы ее....
это противоречит демократическим ценностям и здоровой конкуренции.

...

Это как? Власть поменялась, красные(голубые, зеленые) пришли? Все EBILock на свалку истории, да ещё за два года? Весь документ можно выложить?

Этот документ под грифом ДСП.
Хай подняло ФСБ...

А что пить будем?!
Чуть по свободнее буду переведу тему обратно в техническое русло?
Кстати, попробовал в Visio поработать с VBA. Занятная штука, действительно может получится. Рисуем картинку станции из своих элементов, даже без разницы насколько они удовлетворяют стандартам. Затем обрабатываем софтом на VBA, генерируем ресурс для основной Программы МПЦ.

В этой ли или соседней теме обсуждали открытое ПО для МПЦ...Волею случая последние 2-е суток работал с Сервисниками, заменяя АРМы РПЦ по сроку службы на АРМы, уже настроенные на "макете". Во очую наблюдал работу в действующих устройствах достаточно грамотного программиста, по отладке программы. Это что то с чем то.....Гарантировать, что человек, выполняя такой объём работы не ошибется.... Если такая технология Сервиса по всем МПЦ, печально и Опасно, самое неприятное, что находишься рядом - дуб дубом и не можешь прогнозировать развитие ситуации, это ещё поездов у нас кот наплакал, а как на главном ходу??


ЗЫ;Завтра к ночи "добьем" этот проект и как советуют в соседней теме пойду-"начальника, давай отгул":sm496:
Шутка, не выставлять же себя на посмешище.....

Е.М., добрый день и спасибо за эту реплику!
Только я не очень понял Ваш акцент на будущее "открытое ПО" - что Вы имели в виду?

ПО АРМ это в аналогии с релейной ЭЦ наборная группа, ошибки в нем (ПО) к опасным отказам не приведут...

нет ничего невозможного, возможно всё, что можно себе вообразить!:raD:

Здесь на Форуме, чуть ли не по Вашей инициативе, мы обсуждали вопросы ПО не так давно, это я и имел ввиду.

Открытое ПО как средство избежать зависимости от конкретного разработчика - это один ракурс.
Открытое ПО как средство сделать это ПО доступным для корректировки силами эксплуатационного штата - это другой ракурс.
Наверное, есть и какие-то иные ракурсы.
Так в каком смысле Вы, описывая действия представителя сервисной организации, акцентировали "открытость" ПО? Или слово "открытое" в Вашей реплике лишнее?

В контексте обсуждаемой проблемы - да, лишнее.

Понял, спасибо!
Направленность осмысления того, о чем Вы написали, стала более конкретной!

Если систематизировать мои "очучения" от такой работы, то получается следующее:
1. Необходимо в процесс корректировки ПО на действующих объектах внести принцип предварительной проверки вновь создаваемой версии ПО на "макете", аналогично релейным системам, но "макет" уже на IP технических средствах.
2. Что получается сейчас: корректируем алгоритм (элемент) ПО и опробируем вариант на действующем СЦБином напольном железе - пойдет не пойдет, Опасно.
3. Структура ПО должна состоять из 2х разделов : "безопасного", корректировка которого не может привести к нежелательным результатам ("глюк" дает не ту информацию, блокирует часть команд, даже парализует систему - перешел на резервный АРМ и поехали как раньше) и "защищенный", при корректировке которого нужно максимально подстраховаться.("глюк" приводит к перекрытию сигналов в совсем другом районе станции, переводу не той стрелки (пусть даже не замкнутой в ином маршруте), и т.д.)
4. Напрашивается назначение принципа 2й проверки - новая версия ПО отработывается на действующих устройствах с выделением измененных команд, АРМы возвращаются на старую версию, все измененные команды дополнительно анализируются в спокойном режиме программистом(в идеале его коллегой) и только после этого "внедряются" в действующий АРМ.