Судьба ЭП10

[fasttrain]

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

[Oleg Izmerov]

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

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

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

[SVP]

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

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

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

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

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

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

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

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


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

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

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

[Oleg Izmerov]

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

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

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

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

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

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

[Combine]

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

А раньше парой релюх обходились...

[SVP]

Избыточность контроля - опасная вещь.
Больше консольных устройтсв - больше каналов связи и ввода.
Автоматом поток отказов лезет вверх.
Ну и про цену забывать нельзя.

По поводу проверок - это отдельный вопрос.
На это есть стандарты и сертификаты.
У серьезных фирм это поставлено на серьезную ногу.

А если говорить про ЭП10, то его ПО еще проходило сертификацию в России. Делали это специалисты ВНИИАС. Они мало что понимают в электровозе, но зато как раз очень хорошо понимают в формальностях построения ПО и приемах программирования. Вот они то и посмотрели весьма пристально на ПО и на электровозе, и на всех отладочных стендах в Швейцарии, и им во ВНИИАС Бомбардье на полгода передавала отладочный стенд системы верхнего уровня, на котором они самые разные эксперименты ставили. Плюс они 4 раза по неделе сидели с программистами Бомбардье в Швейцарии у компьютеров и просматривали тексты исходных кодов ПО и задавали всякие вопросы. Плюс в Бомбардье для них подготовили серьезный пакет документации на ПО общим объемем несколько сотен страниц на русском языке и по требования российских ГОСТов .

Закончилось все это формированием эталонного комплекта исходников и его компиляции в устанавливаемое ПО в присутствии комиссии ВНИИАС.
И вот это проверенное ПО с фиксацией конрольной суммы по каждому программному модулю и установлено на электровозах. Вся работа продолжалась 10 месяцев. Было очень интересно.

По стабильность работы устройств.
Если устройства соотвествуют техдокументации новые и потом, то проблем было бы гораздо меньше. Проблемы возникают тогда, когда в документации одно, а в жизни другое.

[Colonel_Abel]

Господа. продолжайте, очень интересно читать. Как вспомню глюк после очередного обновления ПО, когда машина, после прохода нейтральной вставки, запускаться отказывалась. До появления следующей версии ПО, сначала "лечили" перезапуском СУЭ, потом проходом вставки с опущенным токоприемником. Весело было.

[Oleg Izmerov]

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

Избыточность контроля - опасная вещь.
Больше консольных устройтсв - больше каналов связи и ввода.
Автоматом поток отказов лезет вверх.
Ну и про цену забывать нельзя.

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

То-есть, противоречия в показаниях датчиков не вызывают отказа, как в простых САУ 50-60 гг.

По стабильность работы устройств.
Если устройства соотвествуют техдокументации новые и потом, то проблем было бы гораздо меньше. Проблемы возникают тогда, когда в документации одно, а в жизни другое.

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

[SVP]

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

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

Возвращаясь к тому случаю, когда ребята 4 раза перезапускали систему, чтобы распознавалка рода тока нормально сработала.
Первое, что приходит на ум, что ребята не очень утруждали себя попытками понять, что происходит. Хотя может быть и не так.

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

А можно всю эту систему и двумя тумблерами заменить

[Oleg Izmerov]

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

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

Возможно, в разных ведомствах была разная устоявшася терминология.

Но целесообразность применения комплексного алгоритма идентификации неисправности не всегда нужна.

Естественно.

Про рост числа отказов от избыточности я имел в виду, что если мы увеличиваем объем соответствующего оборудования на электровозе, то общий поток отказов в любом случае возрастет.

Так ведь нам важен не теоретический поток отказов, а нарушение функционирования изделия. Though there`s one motor gone We can still carry on...
Конечно, можно представить себе такую ситуацию, когда отказы дублирующих датчиков настолько часты, что снижают общую надежность системы, но это уже грубый просчет в проектировании датчиков. Вероятность отказа дублирующих датчиков должна быть в худшем случае одного порядка с дублируемыми.

Возвращаясь к тому случаю, когда ребята 4 раза перезапускали систему, чтобы распознавалка рода тока нормально сработала.
Первое, что приходит на ум, что ребята не очень утруждали себя попытками понять, что происходит. Хотя может быть и не так.

Ну, так нужен еще и алгоритм обработки ситуации для оператора, сетественно.

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

Им надо было обратиться в какое-нибудь КБ в составе МРП - там такой подход считался нормой.

[Combine]

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

А можно всю эту систему и двумя тумблерами заменить

Вот я не пойму смысла в более дорогих и сложных системах, которые работают хуже, чем мешок дореволюционных РП-280.

[SVP]

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

Вот я не пойму смысла в более дорогих и сложных системах, которые работают хуже, чем мешок дореволюционных РП-280.

А и не надо понимать!
Его (смысла) в таком случае нету!

Функциональное усложнение имеет смысл только когда приводит к улучшению эксплуатационных показателей системы.

Добавлено через 1 минуту

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

Господа. продолжайте, очень интересно читать.

Спасибо!

[Combine]

Функциональное усложнение имеет смысл только когда приводит к улучшению эксплуатационных показателей системы.

То есть из ЭП10 выкидываем все, кроме САУ ТПр-ов, ставим потенциометры на пульт, УРТ от ВЛ82 и получаем идеально-надежный электровоз с асинхронным приводом? Стоило ли тогда огород городить с кучей компов?

[SVP]

Коллега, сделать так в принципе можно, если перенести функции автоматического регулирования силы тяги и скорости из верхнего уровня в системы управления ТПр.

Но Вы, почему-то, опять-таки сводите все проблемы к наличию на ЭП10 "компов".
Не в "компах" проблема ЭП10.
А в нескольких не особо удачно разработанных и не особо качественно изготовленых аппаратах.
Сами "компы" никого не мучают (с последней зачищенной версией ПО).
И именно аппаратная часть компьютерной системы не является серьезным источником отказов.

[SVP]

Вообще в системе управления ЭП10 верхнего уровня ничего сложного нет.
Она состоит из двух идентичных комплектов модулей (100% резервирования).
Каждый комплект - это два контролера и 25 модулей ввода-вывода 3 модификаций.
И все это соединено между собой оптволоконным последовательным интерфейсом для связи.
Один контролер - собственно управляющий.
Второй контролер - администратор интерфейса связи.
Вот и все.
Контролеры стоят в кабинах управления.
А модули ввода-вывода распределены по 5 ящикам: 2 также в кабинах и 3 в разных местах кузова - чтобы сократить длину проводов к объектам управления и контрольным устройствам.

Да, забыл еще 2 дисплея к функциональными кнопками в кабинах.

Надежность этих контролеров и модулей ввода вывода довольно высокая.
Расчетная средняя наработка на отказ контролера - примерно 100 тыс. часов.
Реальная из практики - в несколько раз выше.
Для модуля ввода-вывода расчетная в среднем - примерно 300 тыс. часов.

А 100 тыс. часов наработки на отказ - это примерно 14 лет эксплуатации, если считать, что электровоз находится в рабочем состоянии (с включенной системой управления) 20 часов в сутки и 350 суток в году.
Так что бояться этих вещей не нужно.

Есть, конечно, машинисты, которым нет ничего лучше и милее старого доброго ЧС2 или еще чего-нибудь из классики.
Но это уже вопрос совсем другого характера.