Вероятность обнаружения неисправности в различных сетях

[Novice12]

Здравствуйте.

Интересный есть вопрос.

Наличие выделенного монитора в сети или, н-р, ноут со специализированным ПО и т.п. позволят определить обрыв в сети или всякие другие неполадки с вероятностью = 1?

Или для каждого вида неисправности существует своя вероятность выявления?
И зависит ли от вида сети?

Спасибо за ответы.

[Parliament74]

Наличие выделенного монитора в сети или, н-р, ноут со специализированным ПО и т.п. позволят определить обрыв в сети или всякие другие неполадки с вероятностью = 1?

Какой сети-то? В сети Profibus-DP, например, и без выделенного монитора (и даже без ноута со специализированным ПО и т.п.) обрыв сети с вероятностью = 1 выявляется ведущим устройством сети.

Или для каждого вида неисправности существует своя вероятность выявления?
И зависит ли от вида сети?

А что подразумевается под "каждым видом неисправности"? Огласите весь список, пожалуйста.
И от сети конечно зависит. Например у рыбаков, в их рыболовных сетях, при возникновении неисправности ("дырок"), вероятность их выявления обратно пропорциональна количеству принятых горячительных напитков перед забросом этих самых сетей. С другими сетями всё несколько иначе, но с примером с рыбаками можно будет найти некоторые аналогии при желании...

[Novice12]

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

значит, встроенными средствами ведущего устройства обрывы и отказы ведомых, наверное, в любой современной сети с р=1 определяются?

[Looker]

даже тогда не знаю, какие ещё могут быть "интересные" неисправности.

Например, контроллер переведен в режим PROGRAM, т.е. на связи, но полезное не выполняет. Применительно к Allen Bradley (PLC-5, SLC, Logix) - решаемо в любой сети и без каких либо

доп.датчиков и т.п.

[Novice12]

Looker, хм...

Тогда ещё один вопрос.
Есть находящаяся на некотором удалении от всей заводской инфраструктуры рабочая область.
Там устанавливают дробилку.
Из негативных факторов, в зависимости от режима функционирования:
- вибрация + пыль
- влага+высокая температура
Никаких особых требований к быстродействию и т.д.
Главное, высокая надёжность и самовосстановление в случае нештатной ситуации.
На что ориентироваться при выборе соответствующего оборудования и сети?
(цена вопроса важна, но не стоит на первом месте)
Возможно, есть какие-то ГОСТы и т.п.

Спасибо.

Отправлено спустя 48 минут 48 секунд:
Что-то аналогично этим, только для пром.сетей существует?
ГОСТ Р 53246-2008
ГОСТ Р 53111-2008

[Parliament74]

Есть находящаяся на некотором удалении от всей заводской инфраструктуры рабочая область.

"некоторое удаление" - это сколько метров?

- вибрация + пыль
- влага+высокая температура

это всё решаемо, например у Siemens есть оборудование исполнения Siplus для тяжёлых условий эксплуатации (как правило от -25 до +60 градусов, 100% влажность)

Никаких особых требований к быстродействию и т.д.
Главное, высокая надёжность и самовосстановление в случае нештатной ситуации.

если кабель вам бульдозером порвут, то никакая сеть сама не восстановится "в случае нештатной ситуации"

На что ориентироваться при выборе соответствующего оборудования и сети?
(цена вопроса важна, но не стоит на первом месте)

на то, какую информацию надо с этой дробилки забирать/отправлять, на каком оборудовании это всё физически реализовано (доступные протоколы/интерфейсы) и с каким быстродействием + учитывать местную инфраструктуру - если например физически нет возможности кабель связи пробросить, то надо смотреть варианты с беспроводным соединением.

У Siemens, например, для того же Profibus-DP, есть оптические модули OLM, которые позволяют обеспечить соединение длиной до 15 км (если только по меди передача - то до 1 км расстояние можно обеспечить, а по беспроводному интерфейсу - до 3 км, но это уже от Dataeagle будут устройства экстремальной серии).

[Novice12]

"некоторое удаление" - это сколько метров?

Может быть 75-100 метров.

если кабель вам бульдозером порвут, то никакая сеть сама не восстановится "в случае нештатной ситуации"

Нужно подразумевать резервирование или, действительно, дополнительно обеспечить беспроводное соединение ...?

какую информацию надо с этой дробилки забирать/отправлять

Я изучу этот вопрос поподробнее и сообщу.

[petr2off]

Нужно подразумевать резервирование или, действительно, дополнительно обеспечить беспроводное соединение ...?

У того же сименса есть платы, называемые коммуникациооными процессорами. У них два вход RJ45 и софт специальный есть, обеспечивающий работу по 2-м линиям. Стоит такая платка правда 1500 евро....

[Parliament74]

Да там у дробилки, наверное, шкаф управления свой должен быть. А дробилки до сих пор бывает делают с такими шкафами управления, что там и контроллера-то может не быть, две ТРМки и тру-олд-скульная релейная схема, а для обмена сигналами - только сухие контакты )

Нужно подразумевать резервирование или, действительно, дополнительно обеспечить беспроводное соединение ...?

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

[keysansa]

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

А так, как и везде, для высокой доступности применяют резервирование.

[Novice12]

коммуникациооными процессорами

Кстати, про коммуникационные процессоры.
У нас лежит от предыдущих работничков вот такая штука:
https://www.pr-av.ru/doc/VIPA/300s/dat/342-1CA70_en.pdf
Судя по даташиту со встроенными средствами диагностики не особо хорошо?

Код: Выделить всё

Diagnostic interrupt
no
Diagnostic functions
no
Diagnostics information read-out
possible

Отправлено спустя 7 минут 22 секунды:
Parliament74, keysansa, я знаю только одно, что она всякие отходы производства дробит

Отправлено спустя 8 минут 14 секунд:

Наличие выделенного монитора

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

[keysansa]

Часто ли вы используете в своей работе такой?

У нас всегда использовался мониторинг сети. Управляемые коммутаторы + zabbix snmp. Часто проблемы устранялись не по "Аварийное отключение", а по "Плановое ТО".

[Novice12]

тру-олд-скульная

Там не только схема такая, но и сама дробилка. К 380В подключена и реле с двумя кнопочками.
Хотят всё автоматизировать, всякие датчики установить в помещении. Камеру, чтобы наблюдать за процессом и т.д.
Пока рожают желания.
Отходы по конвейерной ленте подавать в неё, короче говоря, организовать безопасное производство.
Ранее ситуация произошла нехорошая


Отправлено спустя 3 минуты 2 секунды:

"Аварийное отключение", а по "Плановое ТО".

Вот-вот, обычно после "Аварийного отключения" полмашины в утиль

Отправлено спустя 2 минуты 9 секунд:

мониторинг сети

А существует какой-то документ, где обозначены вероятности выявления того или иного рода неисправностей.
Ранее мы уже пришли к выводу, что обрыв выявляется с P=1... а остальное?

Отправлено спустя 1 минуту 2 секунды:
Или это в ТЗ задаётся? Выявление того-то - 0.65, того-то - 0.8?

[keysansa]

Документами не пользовались, но думаю, они есть.
По практике, обмен СКАДА-Контроллер это почти константа. Если вдруг падает или возрастает объем передаваемой информации - повод разобраться. Плюс ошибки начинают появляться. Тоже повод, хотя система еще работает.
Плюс, контроллер следит за собой и за удаленным вводом-выводом. Однако есть еще другие устройства. Например, принтеры. Которые могут отдавать остаток бумаги и картриджа по SNMP. Или внешние устройства, вроде SQL сервера, расположенного на другом сервере, да и в другом сегменте сети.
Ну и бонус, что можно сегментировать ошибки по разным службам. Нехватка картрижда - в ИТ (например), ошибки фреймов Ethernet - в КИП.

ЗЫ. Еще бывают, остаются забытые (не отключенные) порты на свичах, которые задумывались для наладки с помощью ноута. Операторы быстро их просекают, и приносят свои ноуты. По смене MAC адреса можно либо заблокировать порт, либо выслать трап, либо все вместе.

Отправлено спустя 31 минуту 20 секунд:

Или это в ТЗ задаётся? Выявление того-то - 0.65, того-то - 0.8?

Время выявления - это внутренний документ, который подгоняется под наружный. Снаружи задается время доступности системы.

[Valerich]

ЗЫ. Еще бывают, остаются забытые (не отключенные) порты на свичах, которые задумывались для наладки с помощью ноута. Операторы быстро их просекают, и приносят свои ноуты.

И что они потом делают? Хачат систему или рубятся в контру?

[keysansa]

По всякому было. могут например WiFI маршрутизатор внутренним портом воткнуть, и организовать второй DHCP сервер )

[Jackson]

Например, контроллер переведен в режим PROGRAM, т.е. на связи, но полезное не выполняет.

Это ведь не неисправность сети, а неисправность компонента АСУ (связь работает).

[Jackson]

Наличие выделенного монитора в сети или, н-р, ноут со специализированным ПО и т.п. позволят определить обрыв в сети или всякие другие неполадки с вероятностью = 1?

Вероятности = 1 в реальной жизни не существует, только в теории.

Или для каждого вида неисправности существует своя вероятность выявления?

Наверное существует, однако такой характеристики нигде нет - никто этим не заморачивается. Так что на практике это совсем неинтересный вопрос.

И зависит ли от вида сети?

Это зависит в 1ю очередь от применённых мер диагностики, от применённых аппаратных средств (везде свои возможности), от типа интерфейса, от оператора (иные и не распознают что что-то не так). Короче, нет такой оценочной величины, она бессмысленна. Например, в SCADA можно просто отключить контроль таймаутов (отключить на этапе ПНР и забыть включить по убытии после ПНР) - и всё, БД будет забита некорректными данными (последними или нулями). Какова вероятность того что случится именно это? Невысокая, но и не = 0 (вероятностей = 0 в реальной жизни тоже не бывает).
При любом обмене данных по любому интерфейсу, когда разработчик всей системы всё сделал штатно и не поленился, вероятность обнаружения стремится к 1.

даже тогда не знаю, какие ещё могут быть "интересные" неисправности.

Сразу видно, Вы теоретизируете о том, чего не видели практически. У нормальной техники есть всего два состояния: "работает штатно" и "неисправно, работает нештатно, не работает". Неисправность - это всё что не относится к первому. И давайте уж говорить нормально: правильный термин не "неисправность" а "отказ". Отказ либо есть, либо нет, а конкретных неисправностей, вызвавших отказ, может быть миллион (от выхода из строя по старости до падения метеорита).

Воздействия всяких субстанций на оборудование (температуры, влаги) определяются только с помощью доп.датчиков и т.п.?

Иногда да, иногда нет. От оборудования зависит. В некоторых устройствах есть встроенный датчик внутренней температуры. Но эти вещи используются в основном для превентивной сигнализации, чтобы персонал начал принимать меры во избежание отказа. Сам факт же воздействия определяется непосредственно на месте: приходят люди смотреть почему контроллер не работает, и говорят "ох, <идиоматическое выражение по месту>, не работает, <идиоматическое выражение по месту>". Короче, теорию надёжности поизучайте, для начала, а то говорить не о чем.

значит, встроенными средствами ведущего устройства обрывы и отказы ведомых, наверное, в любой современной сети с р=1 определяются?

И даже в ведомых есть диагностика (нет входящих запросов в течение таймаута = что-то не так с обменом данных), только транслировать этот сигнал удалённо не получится, его должны запросить. Если только сухими контактами.

Главное, высокая надёжность и самовосстановление в случае нештатной ситуации.
На что ориентироваться при выборе соответствующего оборудования и сети?
(цена вопроса важна, но не стоит на первом месте)
Возможно, есть какие-то ГОСТы и т.п.

Ориентироваться на технические решения, обеспечивающие:

1. выход установки из строя в безопасную сторону
2. отказоустойчивость к единичным отказам
3. работоспособность средств самодиагностики (WatchDog-таймеры, алармы сухими контактами, включенные таймауты и их обработка)

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

Нужно подразумевать резервирование или, действительно, дополнительно обеспечить беспроводное соединение ...?

Это ещё вопрос, что надёжнее. Решение принимается на месте

Судя по даташиту со встроенными средствами диагностики не особо хорошо?

Это неважно. Важно чтобы самодиагностика работала. Нет встроенных средств - придумайте внешние, на то и инженер.

Пока рожают желания.

Вот пусть сначала ТЗ родят, а там и видно будет.

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

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

Или это в ТЗ задаётся? Выявление того-то - 0.65, того-то - 0.8?

Нет. В специальных ТЗ задаётся ВБР всей установки, средняя наработка на отказ и среднее время устранения. В обычных ТЗ это бессмысленно указывать потому что любой отказ и простой - это ущерб от простоя и ремонта, иногда такой что весь завод будет дешевле закрыть и работников уволить, чем ремонтировать. Установка делается для того чтобы работала в пределах нормативного срока службы, к этому и стремятся.

Отправлено спустя 4 минуты 49 секунд:
Раз у Вас конкретная установка, то не надо теоретизировать "вообще". Прикиньте топологию Вашей будущей АСУ, нарисуйте её, с интерфейсами, устройствами связи, расстояниями, запульните сюда получившийся эскиз - тогда будет о чём поговорить. А иначе это сферическиконновакуумный разговор ни о чём. Вам нужна надёжность Конкретно Вашей системы (а не мир во всём мире) - так давайте с ней и разбираться. Конкретный вопрос - конкретный ответ.

[Novice12]

Вероятности = 1 в реальной жизни не существует, только в теории.

Конечно, только вероятность смерти = 1
Но от меня требуют теоретическое обоснование со всеми циферками перед закупкой оборудования.

Наверное существует, однако такой характеристики нигде нет - никто этим не заморачивается.

А можете поинтересоваться у Ваших товарищей, мб у них есть такие циферки?

когда разработчик всей системы всё сделал штатно и не поленился, вероятность обнаружения стремится к 1.

и

Это зависит в 1ю очередь от применённых мер диагностики, от применённых аппаратных средств (везде свои возможности),

Тогда получаем формулу:
Максимальное внимание при проектировке+достойное вложение денежных средств в апп. и прогр. средства диагностики + адекватный оператор P->1?

Сразу видно, Вы теоретизируете о том, чего не видели практически.

Да, Вы абсолютно правы...

Отказ либо есть, либо нет, а конкретных неисправностей, вызвавших отказ, может быть миллион (от выхода из строя по старости до падения метеорита).

Да. Должен ли я тогда сам сформировать что-то типа БД с такими неисправностями.
Например, наличие в отходах металлических компонентов > 5 см приведёт к отказу (P = 0,73) и т.д.
И потом провести все расчёты, схемы построить ... Ну чтоб отстали, так сказать)

Короче, теорию надёжности поизучайте, для начала, а то говорить не о чем.

У меня сохранилась пара книг ещё с универа.

И даже в ведомых есть диагностика (нет входящих запросов в течение таймаута = что-то не так с обменом данных), только транслировать этот сигнал удалённо не получится, его должны запросить. Если только сухими контактами.

Это строго так на всём ведомых? Новомодные компоненты с интерфейсами Profinet/Eternet/IP и пр. так же сами о "своей болезни" не сообщат?

Вот пусть сначала ТЗ родят, а там и видно будет.

Подождём ;)

[Jackson]

Но от меня требуют теоретическое обоснование со всеми циферками перед закупкой оборудования.

Когда составите сие обоснование, не забудьте включить в него затраты на его составление. 1 Ваш трудочас стОит примерно 2 т.р., плюс ресурсы.

А можете поинтересоваться у Ваших товарищей, мб у них есть такие циферки?

У каких товарищей? :)
Если честно, то с таким понятием как вероятность обнаружения отказа я столкнулся сейчас впервые - от Вас услышал.
Если отказ есть, но его никто не обнаружил и установка продолжает нормально работать - значит это не отказ. :)

Должен ли я тогда сам сформировать что-то типа БД с такими неисправностями.
апример, наличие в отходах металлических компонентов > 5 см приведёт к отказу (P = 0,73) и т.д.
И потом провести все расчёты, схемы построить ... Ну чтоб отстали, так сказать)

Я завидую Вашей фирме. Она настолько преуспевает что готова оплачивать даже такое бесполезное занятие своих сотрудников.

Прежде чем что-то делать, задайте сами себе вопрос "зачем?". И пока ответа не будет - можно не приступать.

Это строго так на всём ведомых?

Нет. Я же написал - от конкретной реализации зависит. В моих устройствах это стандарт (отключаемый аларм на слейвах и серверах), а в ТРМках к примеру такого не было, нет и не будет за ненадобностью.

Тогда получаем формулу:

Коллега, как художник художнику, Вы на какой должности трудитесь? Обычному инженеру не до этой ерунды.

Всё-таки, хвалю образование своего ВУЗа (хотя он считался средненьким отраслевым с проходным баллом 5 при двух экзаменах во времена моего поступления). У нас был замечательный предмет: "Основы тех.экслуатации и теория надёжности". От теории надёжности там были только основы, базирующиеся на опять же основах теории вероятности (преподавалась в программе общего курса высшей математики). Настоятельно рекомендую поискать методички по этому предмету, а не выдумывать свои бог невесть какие формулы. Можно например легко вывести формулу бороды (вообще элементарно), я когда-то вывел формулу скорости и качества реакции вахтенного оператора на единичное внешнее воздействие - преподаватели потом читали конспект, составляли вопросы к зачётам, и восклицали "да, всё верно выведено, но ведь мы этого не читали!" (от скуки вывел, на пару листов А4). Потом смеялись над этим вместе. :) Короче можно под что угодно подвести теоретическую базу. Но зачем? :)

[Novice12]

вероятность обнаружения отказа

Нововведение))) И я писал не про отказ, а про неисправность (подразумевал под ней: работает, но "криво" )
Давайте я приведу пример:

"Борю обидел начальник. Он знал, что в одном из цехов во время работы повышенная влажность/температура/наводки от приборов и т.п.
Ночью он туда проник и порубил топором броню кабеля. Пока значения показателей данных параметров не были критическими - всё работало штатно. Но в один из дней произошло их превышение, связь со станком была потеряна, он резко остановил свою работу, заготовка вылетела и убила цехового кота Леню...

Если сказать проще "выявить лёгкий косяк, чтобы не накрыло тяжёлым"

Коллега, как художник художнику, Вы на какой должности трудитесь? Обычному инженеру не до этой ерунды.

Я тоже инженер, только программист) И я думаю, что Вы в мои годы не меньше проявляли интерес к всяким-разным, может даже не совсем адекватным, затеям

Короче можно под что угодно подвести теоретическую базу. Но зачем? :)

Ну как, без теории не может быть практики, а без практики - теории)
Мб потом кому-то Ваша формула помогла, и Вас до сих пор вспоминают добрым словом последующие поколения студентов)
Зря Вы так

[keysansa]

Если сказать проще "выявить лёгкий косяк, чтобы не накрыло тяжёлым"

Для этого, почти во всех АСУТП предназначены не сообщения об ошибках (обычно выводятся красным, влияют на прерывание техпроцесса), а просто сообщения (выводятся синим, не влияют на техпроцесс). Но как показывает практика, если ситуация не влияет на процесс, она игнорируется (может не сразу, а через месяц после пуска).
Еще видел варианты, где все отклонения от техпроцесса (даже те, которые могут на него влиять косвенно) приводят к его останову, "синие" не сразу, а через какое-то время. Это, ИМХО, лучший вариант.

Но циферок все равно не будет - это зависит от проекта к проекту. Лучше всего это, опять же ИМХО, отрабатывается в системах с дорогим простоем/прерыванием, но там и алгоритмы четкие (металлургия/АЭС например).

Но от меня требуют теоретическое обоснование со всеми циферками перед закупкой оборудования.

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

Если закрытая дверь чревата подозрениями, то открытая — грозит неожиданностями.

Возьмите схему проекта и начинайте со списка неожиданностей. Потом переходите к подозрениям.
Дальше для каждой строки проставьте вероятность возникновения.
Потом - чистая статистика.

[Novice12]

а просто сообщения

Будем выводить сообщения-предупреждения.
Эврика Дзякуй)

что у вас за проект

Я же писал, где-то выше.
Отходы производства по конвейерной ленте подаются в дробилку (крупная фракция), далее она их выплёвывает на другой конвейер (мелкая фракция), по которому всё это сваливается в бункер (типовой, как для мусора).
Потом продаются населению, они чинят ими свои дороги в садах

Потом - чистая статистика.

Да, это хорошая идея. Можно даже что-то типа экспертной системы сделать.

[keysansa]

Будем выводить сообщения-предупреждения.
Эврика Дзякуй)

Вы все прочитали?

Я же писал, где-то выше.

Я прочитал, и в своем сообщении упомянул, что нашел.

Отходы производства по конвейерной ленте подаются в дробилку (крупная фракция), далее она их выплёвывает на другой конвейер (мелкая фракция), по которому всё это сваливается в бункер (типовой, как для мусора).

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

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

[Jackson]

Нововведение))) И я писал не про отказ, а про неисправность (подразумевал под ней: работает, но "криво" )
Давайте я приведу пример:

Советую Вам обратиться к диалектике. Именно она работает в полный рост в Вашем вопросе.
Так вот неисправность - это отказ. Всегда. Не изобретайте велосипед (или я вторично высказываю почтение благосостоянию Вашей фирмы). То, о чём Вы говорите, есть диагностика. Тоже советую ознакомиться, чтобы перестать изобретать велосипед.

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

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

Короче, стало скучно, разговор про сферического коня в вакууме бесполезен. Если Вы можете себе позволить тратить рабоче время и деньги своей фирмы на это всё (без результата, просто так), то уверяю Вас, это могут и хотят далеко не все.

Отличное уточнение. Сразу стало понятно, где тут сеть контроллировать,

Именно. Так что прошу заканчивать со словоблудием и переходить уже к конкретике вопроса, если она вообще есть. Давно пора.