postmitya

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

tyubik

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

Бабулер 14

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

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

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

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

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

NikoS

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

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

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

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

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

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

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

postmitya

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

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

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

NikoS

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

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

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

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

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

Абрамов..ИЧ

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

Просто инженер АиТ

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

__________________
Не важна реальность, важно как мы к ней относимся!

Абрамов..ИЧ

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

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

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

Бабулер 14

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




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