Надежность PLC + УСО

Сообщение **petr2off** » 18 авг 2018, 05:56

Добрый день. Тут намедни у меня с боссом дискуссия возникла. Он большой любитель решений ТОРНАДО. (в основном в энергетике применяется). Ссылается при этом на исключительную надежность, которая обеспечивается дублированием.
У ТОРНАДО своя архитектура. Их модули УСО имеют по 2 IP интерфейса. А PLC по сути стоечный безвентиляторный PC с твердотельным диском. У которого до 5 IP Интерфейсов. Схема сборки у них следующая: Ставятся в стойку 2 PLC + 3 свича. У PLC 2 IP порта занято прямыми патчкордами - смотрят друг на друга. Плюс еще 2 соединяются со свичами. Т.е. в нормальной схеме PLC требуется 4 порта. Модули УСО соеденяются с 2 свичами. Вот такая схема дублирования. Схема компоновки - всегда распределенная.
Вопрос о реальной надежности такой схемы. Если рассматривать вариант без дублирования, то он получается менее надежен, чем тот же Simens например (я сейчас не рассматриваю распределенную схему), у которого модули УСО по внутренней шине общаются - которая просто набор проводов, залитых в пластиковый корпус.
А у ТОРНАДО получается 2 элемента соединенных последовательно и выход любого из них - это отказ. Т.е. грубо говоря, надежность не дублированного ТОРНАДО в 2 раза ниже недублированого Simens. Фактически получается (поправите, если не прав), дублирование ТОРНАДО всего лишь обеспечивает сопоставимый уровень надежности с тем же Simens ?
Т.е. в общем случае, шинная схема компоновки надежнее распределенной ?
PS. Simens я взял для примера, как вариант PLC имеющего схемы компоновки с использование шинной архитектуры.

Сообщение **Ryzhij** » 18 авг 2018, 07:39

Не согласен с Вами по ряду пунктов.
Во-первых по терминологии.
Вы описывете не "ПЛК+УСО", а "CPU+I/O" (это и есть "ПЛК"). Фактически Вы пытаетесь сравнить надёжность систем с удалённой (Remote I/O) и локальной (Local I/O) периферией.

petr2off писал(а): ↑18 авг 2018, 05:56 Т.е. в общем случае, шинная схема компоновки надежнее распределенной ?
PS. Simens я взял для примера, как вариант PLC имеющего схемы компоновки с использование шинной архитектуры.

Во-вторых, разместить всю периферию на локальной шине, это вовсе не значит обеспечить надёжность системы управления в целом. Помимо длинных проводов от "local I/O + УСО" до ОУ, есть ещё один нюанс - неисправность любого из модулей на локальной шине в состоянии "повесить" всю шину.
В-третьих, пример с Сименсом действительно неудачный. Там бэкплейн состоит из целого набора П-образных перемычек между модулями.

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

Сообщение **petr2off** » 18 авг 2018, 10:50

Добрый день. Я пытаюсь оценить реальную надежность архитектуры ТОРНАДО. Проблема проводов до объекта там никуда не денется, модули ТОРНАДО по факту не являются удаленными, все они находятся в одном шкафу. Теоретически их наверно можно было бы вынести, метров на 80, но к нему тогда нужно было бы протащить 2 кабеля для IP портов и плюс еще вопрос питания решить. Не заморачиваются они такой экзотикой.

Насчет неисправности модуля - я думаю далеко не всякая неисправность сможет подвесить шину, на моей практике таких неисправностей не было, а вот свичи накрывались - это было и не однократно. Не нравится Simens - ну давайте IPC DAS возьмем - там классическая шина (причем даже 2 в одном, последовательная и параллельная).

Так же, я как то слабо верю в отказ П образной перемычки.

Сообщение **Ryzhij** » 18 авг 2018, 12:19

Remote I/O - это не всегда физическая удаленность периферии, это способ ее подключения к ЦПУ в системно-топологическом смысле. Это раз.
Если кто-то ещё не сталкивался с каким-либо видом отказов, это ещё не значит, что этих отказов нет у других. Это два.

Итак, давайте рассмотрим конкретные цифры по интенсивности отказов конкретных вариантов архитектуры системы. Ибо иное - не более чем "гипотетический трёп",

Поймите правильно, я не за ТОРНАДО агитирую, я ратую за верную и честную методику сравнения.

Сообщение **petr2off** » 19 авг 2018, 03:21

Хотелось бы отметить несколько фактов. Цифры это безусловно хорошо. Но мнет тут вспомнился старый советский фильм - самогонщики (Вы его должны помнить). Там есть такой момент, Бывалый вываливает мешок сахара в аппарат. А Балбес, после манипуляций с логарифмической линейкой добавляет туда кусочек. Это я к вопросу учета вероятности отказа П образной перемычки, Далее, очень интересный вопрос - а насколько можно верить цифрам по часам наработки, приводимых производителем - там часто приводятся значения, превышающие время существования фирмы. Тот же грайдекс Торнадовский, из 3-х штук что у меня были - один отказал, после 3-х часов работы. Лично возил на ремонт.
Поэтому меня больше интересует методика расчета. Т.е. если я имею PLC с наработкой на отказ 1000 часов, свич с наработкой на отказ 1000 часов ну и модуль 1000 часов, то какая наработка на отказ получится при схеме дублирования применяемая в Торнадо.

Отправлено спустя 2 часа 20 минут 39 секунд:
В догонку, общую надежность оборудования Торнадо я сомнениям не подвергаю, особенно в варианте с Адвантеками. К Грайдексам у меня есть претензии. И модули у них весьма надежные, там на вход вставится вставка, которая определяет вариант интерфейса, и при проблемах на входе (а это наиболее реальный и частый вариант, особенно при наладке) выгорает вставка. Сам торнадо дает гарантию на 5 лет. И если щкаф на обслуживании, то через 5 лет они потроха меняют на 100%. Если уж совсем теоретически говорить, то проблема в том, что дублирование такого рода приводит к появлению дополнительных активных компонент (свичи, IP интерфейсы), которые тоже имеют конечную надежность, причем существенно ниже - чем у той же П перемычки.
Я по базовому образованию теплотехник, в свое время меня удивил тот факт (в молодости я был способен удивляться), что возможно увеличение теплопотерь с увеличением толщины изоляции. Не может ли в данном случае возникнуть аналогичный эффект ?
Иначе говоря, что бы факт дублирования кратно увеличивал надежность, необходим опережающий рост надежности коммуникационного оборудования.

Сообщение **Ryzhij** » 19 авг 2018, 06:04

По методике:
Выделяют критические рабочие контуры, в нашем случае это каналы связи.
Рассчитывают интенсивности потоков отказов для каждого из каналов (критических контуров).
Определяют группы взаимно резервируемых каналов, и по законам теории вероятности считают вероятность отказа всей группы.
Если критических резервируемых групп несколько, то дальше расчитывают вероятность отказа хотя бы одной из групп.
При независимых потоках отказов расчет несложен, а при коррелирующих между собой событиях отказов подключают теорию цепей Маркова.
Вообще, для расчётов сложных систем используется специализированные программные пакеты.

Сообщение **petr2off** » 19 авг 2018, 06:49

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

Сообщение **Ryzhij** » 19 авг 2018, 08:38

Производители при получении сертификата уровня функциональной безопасности SIL публикуют данные по своим модулями и сетевым решениям.

Сообщение **petr2off** » 19 авг 2018, 13:29

Это понятно. Но все это хорошо при создании проекта. Там есть соответствующий раздел, где все эти мантры пишутся. А есть практика. Как говорил товарищ Гете - суха теория мой друг, а древо жизни пышно зеленеет. Сменил Торнадо в своей архитектуре Адвантек на Грайдекс, обнаружил, что Window XP на новую плоту не встает, поставил WIndows 8 Embeded. Все мантры остались, все типа ОК. А сеть не заработала. Ладно - свозил на ремонт. А протокол Modbus TCP - стал работать хреново, потому как раньше сетка /23 под windows XP в общем то работала быстро, потому как XP не обладает функция автоматического роутинга, а 8-ка периодически пробует обновить табличку на 64 тысячи адресов.
При этом с сертификатами все в порядке. Я им даже верю....

Сообщение **Ryzhij** » 20 авг 2018, 01:25

petr2off писал(а): ↑19 авг 2018, 13:29 При этом с сертификатами все в порядке. Я им даже верю....

Ай-я-яй!
Вы тролите или просто опять пытаетесь сравнить зелёное с квадратным?
ЦПУ ПЛК под RTOS и Софт-ПЛК под офисной ОС...

Нет, если Вам кроме визуализации ничего от компьютера не надо, то и Windows вполне себе подойдёт.

Только сравнивать работу такой системы с работой ЦПУ на RTOS не стоит.
Это будет несколько нечестно.
Давайте, опять-таки, не будем валить в одну кучу вероятности аппаратных отказов и вероятности программных сбоев.
Начинали мы именно с аппаратуры.
Кстати, мне не попадались системы с Windows с сертификатом SIL, а в тех бумагах, что видел, четко расписано под какой версией среды исполнения работает сертифицируемый ЦПУ.

Сообщение **petr2off** » 20 авг 2018, 02:32

Ну Windows 8 Embeded Это точно не офисная ОС. Хотя мне она категорически не нравится. В свое время Торнадо перешел от QNX на Windiws XP. А в качестве протокола связи с Интачем, стали использовать DDE. И системы их отнюдь не визуализацией занимаются, а управление энергоблоками.
Мне же как последнему в цепочке, не очень существенно в итоге, по какой причине меня дернут ночью на объект. И какое количество сертификатов при этом будет лежать на полочке. По моему мнению, (для АСУ ТП это особенно характерно) - ПО и железо связаны в один комплекс, не зря существует такое понятие ПТК (программно-технический комплекс). У того же сименса есть решения и на компьютерах с Windows (я в офисе такой в стойку воткнул, он у меня роль контроллера домена играет).
Т.е. ПО вполне может вносить свою лепту в общую надежность. И объяснение что железо то в общем то хорошее, а все сбои из за ПО - никого особенно не убедят.

Сообщение **Ryzhij** » 20 авг 2018, 05:20

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

Сообщение **petr2off** » 20 авг 2018, 10:01

А объекты автоматизации одинаковые. Одна насосная сделана на сименсе, S7 - 315, не дублированный вариант. Другая на ТОРНАДО. Дублированный вариант. Обе отработали по 5 лет. На сименовскую даже реже пришлось ездить. Хотя справедливости ради надо заметить, что конкретно торнадо здесь было ни причем. И как раз в Торндовском варианте, были проблемы связанные с отказом свича. Да дублирование сработало, часа 4 все работало через другую сетку, ПОКА СВИЧ НЕ ЗАМЕНИЛИ. Но на сименовском варианте вообще ничего не ломалось. Хотя ребята с Торнадо грамотные, они в Новосибирском Академгородке сидят, математиков так много и расчеты у них очень хорошие, и по ним следует - что они всяко надежней дублированного сименса.
А внутри меня где то убеждение сидит, чем меньше частей в системе связанных активными компонентами, тем она надежней.

Сообщение **Ryzhij** » 20 авг 2018, 13:16

petr2off писал(а): ↑20 авг 2018, 10:01 А внутри меня где то убеждение сидит, чем меньше частей в системе связанных активными компонентами, тем она надежней.

Как верующий человек я вас понимаю.
Понимаю я также и тщетность любых доводов против "внутреннего убеждения" ))

Сообщение **ASUTP_PLC** » 20 авг 2018, 15:54

Да че тут думать, гадать. Пример простой. У меня была авто, на которой я должен был ездить, и физически ее обслуживать даже эквивалентно поездкам не можешь. То есть больше нужно ездить, а времени не выкраивается ни разу.
Можно машину которая не ломается, а можно две машины. И пускай даже они ломаются, и меннее надежные, крути не крути - машина каждый день есть чтоб ехать. Сломалась одна, едешь на другой. Пока решается вопрос с ремонтом, запчастями, вырабатываешь ресурс
другой авто. Здесь все аналогично. Все горит, ну не можешь из-за даже 1 часа простоя - ну все рушится... груз приходит на таможню...
там монтаж горит... там срочно материалы нужны... В итоге имея две даже средней надежности авто, легко все решается. Можно не прям сегодня умри но поставь на прикол авто, а так, - нужно, да. Лучше сейчас, но не критично.

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

Сообщение **alex45** » 20 авг 2018, 17:06

Универсал писал(а): ↑20 авг 2018, 16:43 А если встанет без резерва

Это всё ерунда. Вот если котёл какой-нибудь взорвётся и люди погибнут... В первую очередь смотреть надо с точки зрения безопасности.

Котельная там, к счастью, без постоянного присутствия персонала. Да и не взорвётся она без насоса, просто встанут котлы. Взорвать котёл можно только умышленно, отключив все блокировки, привязав сбросные клапана.

Сообщение **alex45** » 21 авг 2018, 09:07

Универсал писал(а): ↑20 авг 2018, 17:10 Да и не взорвётся она без насоса, просто встанут котлы.

Откуда такая уверенность? А если защиты не отработают и котлы не встанут?
Безопасность людей здесь на первом месте. Для того и дублируют АСУ ТП, чтобы в аварийной ситуации все защиты гарантированно отработали и оборудование было переведено в безопасное состояние. На крупных энергетических объектах, например, кроме дублирования АСУ ТП делают ещё аварийный пульт, органы управления которого воздействуют непосредственно на механизмы, в обход АСУ ТП.

Отправлено спустя 5 минут 41 секунду:
Вот к примеру читаем СО 153-34.1-30.106-00:

5.1 Требования БЕЗОПАСНОСТИ должны быть ПРИОРИТЕТНЫМИ при создании АСУТП по отношению к другим требованиям.