Есть шина RS-485 (мастер и несколько слэйвов). Если завести еще одну такую же шину - получится резервирование обмен сначала в одной шине, потом во второй.
Нужно парировать зависший на передаче слэйв или пробитый опять же на передачу 485-й драйвер. Если две шины вроде получается?
Также надо при зависании или умирании мастера одному из слэйвов стать мастером. Вроде бы можно сделать передачу полномочий по обычному тайм-ауту? Или кроме этого еще получить подтверждение зависания/умирания старого мастера от большинства слэйвов?
Или может лучше одну шину пустить штатно мастер-слэйвы, а вторую только между слэйвами?
Что посоветутете?

Была такая задачка. Реализовали резервный канал, протокол Modbus. В слэйве реализовали поочередный опрос каналов так: считали команду, выполнили, перешли на другой канал, там считали и при необходимости выполнили. Вроде всё нормально, но только в том случае, если оба канал подключены к одному мастеру :P . Возможны случаи, когда по ошибке или в целях отладки каналы разводишь на разные мастера, тогда в слэейве поочереди могут возникнуть две взаимоисключающие команды. После подчистки и отладки кода, удалось исключить возможный конфликт. Эту ситуацию рассмотрели по-подробнее и даже стали иногда использовать, например, когда нужно временно дублировать мастера.

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

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

А еще есть такая замечательная штука, как Token Ring...
Можно взять за основу...

В смысле взять и token и ring.. Хорошо получится и без Token Ring ™

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

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

[/quote=По-правде, вся эта бодяга так и не понадобилось, заказчик тему схлопнул.]


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

Мы работали так:
Когда станция выходит на передачу, то передает одинаковые данные одновременно в оба канала RS485.
Принимающая станция принимает и обрабатывает запросы только из одного канала. Текущий "рабочий" канал определяется фоновой задачей, которая попеременно "прослушивает" оба канала, составляя список доступных станций на каждом канале. Это про дублирование.
Что касается многомастерности - работали по протоколу Profibus.

Делали подобную задачу (не 485). В итоге слали по обоим каналам. Контроллер по приёму отрабатывал первую пришедшую команду. Копию игнорирует (тайм аут) на выполнение, но шлет подтверждение на все команды и по тому же каналу, какому получил. Мастер один - РС.

Знаю, что неправильно, но на одном объекте провели две линии (основную и резервную), а инфу гоняли только по одной. мастер сам принимал решение о переходе на другую линию, только если на первой была проблема. Что это дало? Дополнительный канал связи с удаленными объектами на период наладочных и ремонтных работ. Зная алгоритм мастера и то, что мала вероятность выхода из строя текущего канала именно тогда, когда приехал на объект, суешь в свободный канал то, что нужно для профилактических и ремонтных работ. Заказчик об этом знает, не ругается, сам иногда пользуется, хотя не положено.
Не делайте так, это не совет. Но если Заказчик берет ответственность на себя, то осторожно можно