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

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

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

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

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

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

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

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

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

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


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

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

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

[QUOTE=SVP;296178]
Вот именно поиск разумных критериев "браковки" ситуации с активацией защиты с точки зрения реальной опасности последующих процессов - в этом и есть тонкость накопления опыта и приспосабливания системы к особенностям работы сопряженного оборудования и систем. Чтобы неопасные мелочи пропускать и не обращать на них внимания, а реально опасные вещи ни в коем случае не пропустить.
[/QUOTE]
Ну, для этого, собственно, есть (или должен быть) этап работы, на котором ищут способы нарушить функционирование системы. Надеюсь, что это есть.

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

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

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

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

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

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

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

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

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

[QUOTE=SVP;296364]Избыточность контроля - опасная вещь.
Больше консольных устройтсв - больше каналов связи и ввода.
Автоматом поток отказов лезет вверх.
Ну и про цену забывать нельзя.
[/QUOTE]
Простите, Вы, видимо, что-то перепутали.
Избыточность информации, наоборот, позволяет резко сократить число отказов. Разумеется, если есть алгоритмы обработки коллизий, что давно уже не новость.

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


[QUOTE]По стабильность работы устройств.
Если устройства соотвествуют техдокументации новые и потом, то проблем было бы гораздо меньше. Проблемы возникают тогда, когда в документации одно, а в жизни другое.[/QUOTE]
Опять-таки это сводится к обработчику ситуации, когда параметр выходит за нормативные пределы.

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

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

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

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

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

[QUOTE=SVP;296526]Понятно.
Я бы тогда применил более подходящий, по моему, термин.
Не избыточность, а комплексность информации.
В этом Вы правы. [/QUOTE]
Возможно, в разных ведомствах была разная устоявшася терминология.


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

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

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

[QUOTE]Не знаю, почему ВЭлНИИ в свое время не сообразили, но в таких устройствах как раз бы и пригодилась избыточность в виде трех параллельно работающих каналов. И если сигнал одного канала из трех отличается от двух других, значит этот канал неисправен, и его можно игнорировать. [/QUOTE]
Им надо было обратиться в какое-нибудь КБ в составе МРП - там такой подход считался нормой.

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

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

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

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

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

[size="1"][color="Silver"]Добавлено через 1 минуту[/color][/size]
[QUOTE=Colonel_Abel;296450]Господа. продолжайте, очень интересно читать. [/QUOTE]

Спасибо! :o

:drinks:

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

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

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

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

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

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

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

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