Электроника:Цифровая электроника/Цифровая связь/Практические аспекты цифровой связи

Материал из Онлайн справочника
Перейти к навигацииПерейти к поиску

Перевод: Макаров В. (valemak) Контакты:</br>* Habr: @vakemak</br>* Сайт: www.valemak.com</br>Перевёл статей: 648.
Проверка/Оформление/Редактирование: Мякишев Е.А.


Практические аспекты цифровой связи[1]

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

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

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

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

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

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

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

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

См.также

Внешние ссылки