Это все именно так, и в этом, как раз, особой сложности нет.
К примеру, если в программу не включать циклы ожидания какого-то условия, то ее "залетание" в "функциональный тупик" вообще невозможно.
В разработке ПО управляющих систем есть комплекс правил, какие программыные конструкции категорически недопустимо использовать.
Я говорил о сложностях другого характера.
В обработке каждой обратной связи или задания в программе всегда существует задача выбора типа - все нормально, продолжаем работу, или - ситуация ненормальна, активизируем защитный процесс и обесточиваем электровоз.
Вот именно поиск разумных критериев "браковки" ситуации с активацией защиты с точки зрения реальной опасности последующих процессов - в этом и есть тонкость накопления опыта и приспосабливания системы к особенностям работы сопряженного оборудования и систем.
Чтобы неопасные мелочи пропускать и не обращать на них внимания, а реально опасные вещи ни в коем случае не пропустить.
Система управления на ЭП10 агрегатно и в основных программных модулях была разработана еще раньше. И реальных зависаний у этих систем нет. Надежное железо, выверенное ПО уровня операционной системы, отработанное согласование взаимодействия общей шины со всеми объектами и т.п.
И ситуаций, что нужно переустанавливать ПО системы тоже не было.
А вот с отладкой функцинальной надстройки ПО, индивидуальной для каждого проекта - работы всегда много.
Единое ПО для 001 и остальных также не может быть причиной сбоев, потому что оно построено не на принципе компромиссов, а на принципе "поглощения" более простых задач более сложными.
Но с годами эксплуатации число сбоев в виде более частого срабатывания защит и отключения оборудования может происходить, если нарушается стабильность характера работы компонетов.
К примеру блокировка контктора обычно отскакивала при замыкании 5 раз. Это в ПО предусмотрели и еще дали запас на 10 раз. А через 5 лет работы из-за механических износов в приводе блокировок число отскоков стало выше 10. Сразу проблема.
|