Узник Абакана

Николай Николаевич это в принцине невозможно. Вы попаданте в ловушку противоречий. Хотите чтобы никакой "индивидуальной разработки ПО и/или "отладки ПО на месте" и в то же время чтобы было просто "как в ЭЦМ КБ ЦШ",

__________________
Разделение ШЧ на ПЧ и НГЧ

Legon

в ветке выделяется много энергии и происходит нагрев ...может быть пошел ядерный синтез?

Николай Николаевич

Ну а в чем противоречие?
В ЭЦМ КБ ЦШ сразу спаян некий монтаж, которые реализует маршрутизацию всех возможных маршрутов независимо от топологии путевого развития, при этом настройка на конкретное путевое развитие станции производится на месте без изменения или доработки проекта, путем заранее предусмотренных манипуляций.
Почему этого нельзя сделать в ПО?
Думаю, что это вполне возможно: "если ЭТО можно спаять - то ЭТО можно запрограммировать"!

бабулер 44

Всё в ваших руках! Формулируете техническое задание, объявляйте НИОКР, изыскивайте средства, пользуйтесь продуктом на здоровье.
Или вы считаете, что производители МПЦ будут за свой счет ваши "хотелки" реализовывать, и преподнесут вам готовый продукт?

Николай Николаевич

Не просто считаю, а убежден, что именно так и случится!

бабулер 44

Еще лет 5-7 санкций и ржд вернется к электромагнитным реле и ...ЭЦМ КБ ЦШ. Денег и времени сколько сэкономите! Кибербезопасность будет наивысшая, Элтеза будет процветать, все остальные разработчики систем ЖАТ устроятся работать таксистами.

Николай Николаевич

Да не переживайте Вы так за нас, как показывает время, в реальности санкции нам только на пользу...

bsabsa

Не тот у РЖД рынок, не та в России экономика, да и нет таких "игроков", чтобы кто-то вкладывал такие суммы.
И то что, "сами знаете кто" только меняет шильдик - лишнее тому подтверждение.

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

Николай Николаевич

Вот чего я своим СЦБиным (а не "компьютерным") умом не понимаю - так это почему софт должен быть "офигеть каким тяжелым", если алгоритмы в ЭЦ простейшие, количественно ограниченные, не супербыстродействующие и т.п.?

Александр

Насчёт тяжёлого ПО:
Уже больше 25 лет игрушке shortline.
Думаю, всем знакома, у кого был доступ к компу в конце 90-х.
Можно построить станцию на 6 подходов (правда, все однопутные). Недостаток - нет маневровых передвижений. Ну и "размах" строительства финансами ограничен.
Достоинство - работает под DOSом.
Интегрирована система "автомашинист".

Думаю, на её основе и надо строить новую МПЦ (чтобы не с нуля начинать, так быстрее и дешевле выйдет).

__________________
"Не думай. Думаешь - не говори. Думаешь и говоришь - не пиши. Думаешь, говоришь и пишешь - не подписывай. Думаешь, говоришь, пишешь и подписываешь - не удивляйся."
Ф.Э. Дзержинский.

Rustelo

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

Николай Николаевич

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

Omega

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

Николай Николаевич

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

bsabsa

Для того, чтобы перестать быть интеллектуальной и любой другой собственностью разработчика - НИОКР, КНП Вас ждет.
P.S. Все что сейчас внедряется из МПЦ, по НИОКР-у не шло - так что, придется "договариваться" с собственниками.

РЖД никогда не искала легких путей.