etherCUT

[petr2off]

Добрый день. Была тут у меня жаркая дискуссия с начальником. Суть вопроса, допустим есть 2 рабочих места, с которых возможно управление исполнительными механизмами(ИМ). Например АРМ оператора в диспетчерском центре и панель на месте. Естественно возникает проблема арбитража, нельзя допускать что бы одновременно одним устройством управляли из 2-х мест, возможны конфликты.

Я традиционно тяготел к программу решению этого вопроса. Т.е. в контроллере хранится флаг - местное/дистанционное управление. Который можно выставлять и читать с обеих точек доступа (разумеется в рамках прав доступа). Боссу сильно не понравилась идея, что арбитраж идет на уровне контроллера. Базовая его идея - с помощью реле переключать кабель TCP. Идея сама по себе достаточно бредовая, хотя бы потому что кроме команд управления есть еще и данные о состоянии ИМ. Но меня просто заинтересовала сама фактическая возможность этого процесса.
Посмотрел в Интернете и - о чудо - увидел забавный девайс - etherCUT называется. Правда езернет он не переключает, а отключает. Причем может это делать как механически (поворотный выключатель) так и электронным образом, у него есть пара двоичных сигналов DI и DO соответственно. Но тем не менее с помощью 2 - устройств вполне можно сделать аппаратный арбитр. Правда для данной задачи он все равно не годится.
Штука забавная, чисто наша, как я понял. Единственно не понял, для чего то он нужен ? Ссылки на информационную безопасность в рекламе, мне показались несколько за уши притянутые.

[Jackson]

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

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

А когда вот эта самодеятельность начинается - будут и конфликты и жаркие дискуссии. Зачем каждый раз ими заниматься когда всё уже придумано давно - я не могу понять. Видимо очень много свободного времени и делать нечего.

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

[alex45]

Если делать всё по правилам

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

[Jackson]

Правда для данной задачи он все равно не годится.
Штука забавная, чисто наша, как я понял. Единственно не понял, для чего то он нужен

Вот это вот ключевое. :)

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

Вот я тоже таких правил не встречал.

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

[Ryzhij]

Вот это вот ключевое. :)

Как вариант - отключение сегмента сети на время проведения регламентных работ на роутерах.

[Михайло]

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

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

[Jackson]

Это может быть недостаточно универсальным требованием, хотя смысл имеется в подавляющем большинстве случаев.

Так ведь

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

[ava]

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

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

[keysansa]

Вот это вот ключевое. :)

Как вариант - отключение сегмента сети на время проведения регламентных работ на роутерах.

Согласен. Только не отключение сегмента, а переключение VLAN. Причем это можно выполнить просто SSH/SNMP командой на большинстве управляемых коммутаторов.

[Ryzhij]

Причем это можно выполнить просто SSH/SNMP командой на большинстве управляемых коммутаторов.

На исправных. Это ключевое.

[keysansa]

На исправных. Это ключевое.

Наличие SSH/SNMP позволяет очень быстро и, что самое главное, автоматически диагностировать исправность коммутатора.

[Ryzhij]

На исправных. Это ключевое.

Наличие SSH/SNMP позволяет очень быстро и, что самое главное, автоматически диагностировать исправность коммутатора.

Ок. Диагностировали - неисправен.
Наши дальнейшие действия? Речь о практической пошаговой методике в условиях непрерывного производства.
А в новых реалиях нас и без всяких коммутаторов заставляют составлять список портов и кабелей связи "по периметру АСУТП", маркировать их, чтобы в случае угрозы изолировать средний уровень от верхнего и продолжать работу.
"- Чуешь, хрень творится - перво-наперво отключи нахлебников, и потом разбирайся. Звони IT-шникам и прочим." - такая установка дана операторам технологии. Для них вот эти вот абревиатуры SSH/SNMP звучат как ругательства, а тут переключатель повернул и всё.
Теория суха, мой друг, а древо жизни буйно зеленеет... /Гёте, Фауст/

[petr2off]

"- Чуешь, хрень творится - перво-наперво отключи нахлебников, и потом разбирайся. Звони IT-шникам и прочим." - такая установка дана операторам технологии. Для них вот эти вот абревиатуры SSH/SNMP звучат как ругательства, а тут переключатель повернул и всё.

Меня убедил. Когда делали КНС для зимней универсиады - там на входе поставили управляемую задвижку. Я блин целую программу написал, которая контролировала уровень говна, что бы в нужный момент ее перекрыть (на закрывалась 60 секунд) и в нужный момент открыть. Уровень контролировался по аналоговым и дискретным датчикам - анализировалась достоверность.
Мастер сказал - круто, а где все это можно отключить. Очень обрадовался, что на шкафу управления задвижкой есть тумблер - отключить управление. И отключил.....

[keysansa]

Ок. Диагностировали - неисправен.

Немного не так... Диагностировали ухудшение параметров, для начала. Далее, пляшем "от печки". Это может быть не неисправность самого коммутатора, а генерация излишнего трафика подключенного к нему устройства. Или перегрев.

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

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

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

Когда делали КНС для зимней универсиады - там на входе поставили управляемую задвижку. Я блин целую программу написал, которая контролировала уровень говна, что бы в нужный момент ее перекрыть (на закрывалась 60 секунд) и в нужный момент открыть. Уровень контролировался по аналоговым и дискретным датчикам - анализировалась достоверность.

Тут немного другое.
Вот мой пример. Машина (3 штуки simotion, два десятка приводов, пяток ET, 4 панели и 400й). Плюс, сканнер штрихкодов, два принтера и комп оператора с 1С.
1. Ставить два коммутатора (для машины и для оператора), разводить по разным физическим сетям.
2. Коммутатор c VLAN/SNMP (та же cisco 2950) на 24 порта.

Во втором случае - проще физика, контроль над каждым портом коммутатора вплоть до того, что можно считать сырые данные с любого порта (mirroring). При этом, "бухгалтерия" отделена от машины и никоим образом не сможет на нее повлиять.
Пропускной способности коммутационной матрицы 2950 в данном случае хватает (занята на 25-30%).