Любопытные идеи звучат касаемо написания своего ПО под чьё-то существующее железо, корректировку ПО силами чуть ли не механика и т.д.
Такое ощущение, что вопрошающие находятся в ином мире и, мягко говоря, не в курсе. Не спорю, что технически это возможно, хоть и крайне сложно, долго и дорого. Не говорю уж о необходимом уровне квалификации работников, которые смогут такое делать. Кроме того, кто будет нести ответственность за качество и безопасность таких разработок или изменений? Как сертифицировать такую поделку? Если сейчас фирма-разработчик делает все этапы сама и несёт ответственность по широчайшему спектру вопросов, то чем предлагается это заменить? Или предполагается, что кто-то из разработчиков МПЦ согласится на таких условиях недорого клепать железо и гарантировать безопасность чужих трудов?
Или я неверно интерпретирую посыл?

))) Да не относись ты так серьезно, уж скоро 20 лет этим разговорам )))

конечно можно... лет через 8-10, только железо к тому веремени "устареет".

После "последних указаний" предчувствую скачок проектирования релейных ЭЦ :oiE:.

Посыл - отделить ПО от "железа".
Алгоритмы в СЦБ - простенькие, медленные, одинаковые "для всех и вся". Интерфейс - тоже.
Поэтому представляется логичным делать ПО "в одном окне" и силами этого же "окна" сопровождать ПО в течение всего срока эксплуатации объекта.
Принципиально - не ставя перед кем-либо задачу сделать из этого процесса "великий бизнес"!

Николай Николаевич добавил 15.08.2017 в 09:52
Думаю, что до большого "скачка" внедрения вчерашних релейных систем дело не дойдет, хотя некоторый откат наверное возможен.
Хотя, если объективно, нынешние "МПЦ" - тоже не айс, и внедрять их становится также стремно, как и релейные системы.
Очень бы не хотелось продолжать внедрять РПЦ - это вообще было бы безумием.
Вывод: нужен четко структурированный переходный период продолжительностью два-три года.

Совершенно то же самое говорит любой посторонний человек (не СЦБист), глядя на ряды релейных стативов. Как же так, кто несет ответственность, кто гарантирует и т.п.
Для специалистов в этом нет совершенно ничего особенного. То же самое и с программированием.

Просто СЦБисты застряли в 60х и не хотят соглашаться с тем, как эксплуатируются современные АСУ ТП. Но это не проблемы АСУ ТП.
Технические ньюансы в конструкции блоков МПЦ есть, и они не простые. В программировании нет никаких ньюансов - это полностью надуманная проблема.

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

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

Что там может устареть в свете поставленных задач? Сильно устарел протокол RS-485 за 25 лет? А i8051? А работающие и поныне ТР-47?

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

Гм... С вашей точки зрения, МПЦ столь же просты, как и релейка? Если, условно говоря, МРЦ-13 очевидно доступна для понимания (почти) любому технарю и может быть поконтактно выверена, то как быть с ПО?
Внедрение "современных АСУ ТП" без адекватной проработки безопасности, в т.ч. "кибер..." может привести к очень печальным событиям в масштабах сотен станций по всей стране. Как вы хотите доказать безопасность наработок "дядиваси"? И таки да, прошу ознакомиться со словом Stuxnet например.

То, о чем Вы пишете - это ведь не эксплуатация...
И, на мой взгляд, это один из ключевых моментов!

Ну вы же (условно) наняли технаря, чтобы он провел поконтактную сверку? Наймите еще АСУшника, чтобы он проверил/подкорректировал ПО в вашей АСУ. Именно так и поступают люди их эксплуатирующие.

Мне не нужно доказывать, это РЖД нужно. Они, грубо говоря, создали себе проблему - пусть сами и решают. Другие люди так не работают, в т.ч. и на опасных производствах.
Со стакснетом знаком. На протяжении уже очень долгих лет эта проблема решается: 1) физической изоляцией сетей АСУ от "внешки"; 2) не установкой windows на ответственных машинах, тем более на тех, где 24/7 крутится одна и та же мнемосхема.
Много вот, например, вы можете назвать аварий на МНЛЗ или коксохимпроизводстве из-за "неправильного ПО"? Я все это лично видел, и даже доводилось косвенно принимать участие.
ПО - это просто один из техпроцессов, нужно его правильно организовать и контролировать, но никак не делать из него священной коровы.

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

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

Менять железо не обязательно, за исключением нескольких НО:
1. Чтобы разрабатывать ПО нужна КД, как минимум тех узлов, для которых Вы собираетесь писать софт. От кого-то её нужно получить.
2. Написать и править ПО неспециалисту - это утопия. Кроме всего прочего, нужно ещё и ясно понимать - как происходит обмен данными с верхним и нижним уровнем, по каким протоколам и т.д.
Люди годами пишут софт, оттачивают, испытывают, проходят разные экспертизы, в конце концов получают сертификаты. В Вашем случае кто этим будет заниматься - не ШН же) Я вот сейчас по работе столкнулся с информационной и кибербезопасностью ПО, извините - пипец-пипец (без стакана не разобрать - ШНы сопьются))) "Пользуясь случаем" - привет НИИАСу!
3. Как бы там ни было, но есть ещё авторское право. Здесь тоже камни могут быть, надо думать..

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

Там написано "проверки производятся", но не понятно кем?
Исправлено: И опять-таки речь про изменения ПО, а не про проверки.

Почему не понятно - очень даже понятно: тем, для кого эта инструкция написана, т.е. эксплуатационным штатом ШЧ, который выполняет проверку зависимостей.
И по смыслу этого пункта понятно, что никаких манипуляций с ПО - установка, замена, или, не дай бог, изменение ПО -
эксплуатационным штатом не производится!

Издеваетесь?

http://www.picshare.ru/uploads/170815/6M6PoPDJKy.jpg


Как Вы без Разработчика ПО собираетесь проводить проверки?