Судьба ЭП10

[Oleg Izmerov]

Сообщение от SVP

А вот если комплекс входных сигналов попал в непредусмотренное в программном обеспечении состояние - тогда, конечно, "на знают, что делать" обе системы, и основная, и резервная.

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

[Ромыч РЖДУЗ]

Михаил Юрьевич а это не давно у вас было?

[SVP]

Сообщение от Oleg Izmerov

По крайней мере, так считалось четверть века назад.

Сейчас тоже так считается
Но источником информации о статических и динамических свойствах сопряженных систем является техдокументация на эти системы, стандарты и т.п. И все то, что особенного осталось вне этих документов - и является потенциальной причиной проблемы, с которой можно столкнуться в реальной жизни.
Самые простые примеры.
Ни в одном российском документе вы не прочитаете, что напряжение в к.с. переменного тока длительно может быть более 29 кВ. А реально в некоторых местах бывает и 30, а то и еще побольше.
Ни в одном российском документе вы не найдете информации о том, что наведенное напряжение на изолированном участве контактной сети на станции стыкования может достигать 15-18 кВ.
Или какой-нибудь ранее неизвестный разработчикам системы и ПО контактор на электровозе замыкается с дребезжанием контрольной блокрировки с 5 кратным разрывом.
И таких нюансов очень много. И обо всех них можно узнать только, когда электровоз начал работать.
Когда все компоненты на электровозе свои, и особенности инфраструктуры уже хорошо знакомы - проблем нет. Все едет с первого раза.
А если полигон эксплуатации новый, да еще в электровозе полно устройств, с которыми раньше не работали, да еще которые ведут себя весьма нестабильно - тут уже сложнее.
Все это вещи, как правило, элементарные и решаются в ПО достаточно просто. Но одна сложность неизбежна. На зачистку всех таких вещей нужно время.
Может кто не знает, но на ЭП10-001 практически все сопряженное с ситемой управления оборудование (релюшки, контакторы и т.п.) были импортные, пободранные специалистами Бомбардье. И ПО делалось под эти компоненты. А с 002 большая часть этих элементов была заменена на российские. Нельзя сказать, что они все хуже. Нет. Они просто другие. По другому работают. Хотя по документации такие же. Вот вам и целый ворох проблем сразу. И нужно было повозиться, чтобы сделать единое ПО, которое может работать и на 001, и на всех остальных электровозах.

[fasttrain]

Скажите, а единое ПО может быть причиной сбоя, так как является в некотором роде компромисом? Не было бы надежнее оставить специальное ПО под первичное сопряженное оборудование, а для машин с российским делать отдельное ПО? Или проблем быть не должно?

[Oleg Izmerov]

Сообщение от SVP

Сейчас тоже так считается
Но источником информации о статических и динамических свойствах сопряженных систем является техдокументация на эти системы, стандарты и т.п. И все то, что особенного осталось вне этих документов - и является потенциальной причиной проблемы, с которой можно столкнуться в реальной жизни.

Вообще-то ОСРВ должна иметь по умолчанию алгоритмы действий при произвольном нештатном сочетании внешних параметров, выполнение которых не нарушает функционирование системы. Если в документах прописано, что напряжение не более 29 кВ, должна быть определена процедура для случая, если напряжение 30 кВ, и т.п. Если замыкается контакт - определяется процедура для произвольной частоты замыкания/размыкания, и т.п. Более того, обязательным этапом работы должно быть исследование возможностей вывести эту систему из строя внешними воздействиями. Если, к примеру, речь идет о системе связи, исследуется, какими факторами можно ее специально нарушить, и, соответственно, какие меры защиты можно предусмотреть. В этом плане ОСРВ для локомотива ничем не отличается. Просто предполагается, что угроза носит стихийный характер, и не более того.

[SVP]

Это все именно так, и в этом, как раз, особой сложности нет.

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

Я говорил о сложностях другого характера.
В обработке каждой обратной связи или задания в программе всегда существует задача выбора типа - все нормально, продолжаем работу, или - ситуация ненормальна, активизируем защитный процесс и обесточиваем электровоз.

Вот именно поиск разумных критериев "браковки" ситуации с активацией защиты с точки зрения реальной опасности последующих процессов - в этом и есть тонкость накопления опыта и приспосабливания системы к особенностям работы сопряженного оборудования и систем.

Чтобы неопасные мелочи пропускать и не обращать на них внимания, а реально опасные вещи ни в коем случае не пропустить.

Система управления на ЭП10 агрегатно и в основных программных модулях была разработана еще раньше. И реальных зависаний у этих систем нет. Надежное железо, выверенное ПО уровня операционной системы, отработанное согласование взаимодействия общей шины со всеми объектами и т.п.

И ситуаций, что нужно переустанавливать ПО системы тоже не было.

А вот с отладкой функцинальной надстройки ПО, индивидуальной для каждого проекта - работы всегда много.


Единое ПО для 001 и остальных также не может быть причиной сбоев, потому что оно построено не на принципе компромиссов, а на принципе "поглощения" более простых задач более сложными.

Но с годами эксплуатации число сбоев в виде более частого срабатывания защит и отключения оборудования может происходить, если нарушается стабильность характера работы компонетов.

К примеру блокировка контктора обычно отскакивала при замыкании 5 раз. Это в ПО предусмотрели и еще дали запас на 10 раз. А через 5 лет работы из-за механических износов в приводе блокировок число отскоков стало выше 10. Сразу проблема.

[Oleg Izmerov]

Сообщение от SVP

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

Ну, для этого, собственно, есть (или должен быть) этап работы, на котором ищут способы нарушить функционирование системы. Надеюсь, что это есть.

Во-вторых, снижение неопределенности при выборе процессов браковки также достигается увеличением степени избыточности входной информации, в первую очередь такой, которая бы подтверждала или не подверждала наличие опасной ситуации. Без такой перекрестной проверки автоматическая идентификация события на основе параметров резко затрудняется.

Но с годами эксплуатации число сбоев в виде более частого срабатывания защит и отключения оборудования может происходить, если нарушается стабильность характера работы компонетов.

Хорошо, но ведь у нас есть априорная информация об изменении стабильности работы компонентов, тех же контактных групп. И мы можем прогнозировать как необходимость их планового ремонта, так и необходимость обработки ситуации их отказа (как и идентифицировать отказ). Кроме того, если срабатывание контактных групп имеет только информационную функцию, то можно повысить избыточность информации.