Практические соображения - цифровая коммуникация

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

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

Способность сети гарантировать «пропускную способность» данных называется детерминизмом. Детерминированная сеть имеет гарантированную максимальную временную задержку для передачи данных от узла к узлу, а недетерминированная сеть - нет. Ярким примером недетерминированной сети является Ethernet, где узлы полагаются на схемы со случайной временной задержкой для сброса и повторной попытки передачи после конфликта.

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

Еще одним важным фактором, особенно для промышленных сетей управления, является отказоустойчивость сети:то есть насколько уязвима сигнализация, топология и / или протокол конкретной сети к сбоям? Мы уже вкратце обсудили некоторые вопросы, связанные с топологией, но протокол влияет на надежность не меньше. Например, сеть Master / Slave, будучи чрезвычайно детерминированной (что хорошо для критических элементов управления), полностью зависит от главного узла, чтобы поддерживать все в рабочем состоянии (обычно это плохо для критических элементов управления). Если главный узел выйдет из строя по какой-либо причине, ни один из других узлов не сможет передавать какие-либо данные вообще, потому что они никогда не получат свои права на выделенные временные интервалы для этого, и вся система выйдет из строя.

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

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

Однако проблема возникает, если это кабельное соединение снова подключается:эти две сегментированные сети снова объединяются в одну, и теперь по одной сети передаются два токена, что приводит к конфликту передач узлов!

Не существует «идеальной сети» для всех приложений. Задача инженера и техника - знать приложение и работу доступных сетей. Только тогда эффективное проектирование и обслуживание систем станут реальностью.