Программные методы борьбы со сбоями
Для повышения надежности связи обязательно нужно предусмотреть программные методы борьбы со сбоями. Их можно условно разделить на две группы: защита от рассинхронизации и контроль достоверности.
1). Защита от рассинхронизации. Несмотря на защитное смещение, сильная помеха может пробиться в линию без активных передатчиков и нарушить правильную последовательность приема посылок. Тогда возникает необходимость первой же нормальной посылкой вразумить принимающие устройства и не дать им принять помеху за посылку. Делается это с помощью синхронизации кадров (активная пауза) и синхронизации посылок (преамбула).
Защита от рассинхронизации кадров. Обязательная мера! Все последующие меры синхронизации посылок имеют смысл только совместно с этой. Помеха ложным старт-битом может сбить правильный прием кадров последующей посылки. Чтобы вернуться к верной последовательности, нужно сделать паузу между включением приемопередатчика на передачу и посылкой данных. Все это время передатчик удерживает в линии высокий уровень, через который помехе трудно пробиться (активная пауза). Паузы длительностью в 1 кадр на данной скорости связи (10-11 бит) будет достаточно для того, чтобы любое устройство, принимавшее помехи приняло стоп-бит. Тогда следующий кадр будет приниматься с нормального старт-бита.
Того же эффекта можно добиться передачей символа FFh перед первым байтом посылки, так как кроме старт-бита, все его биты - "1". (Если старт-бит символа FFh попадет на стоп-бит ложного кадра, будет просто засчитана ошибка кадра).
Защита от рассинхронизации посылок. Применяется совместно с предыдущей защитой! Особо подлая помеха может замаскироваться под управляющий символ и сбить принимаемую затем посылку. Кроме того предыдущая посылка может быть прервана. Из-за этого крайне желательно в подпрограмме приема и сохранения данных предусмотреть меры по опознанию настоящего начала посылки и сбросу приемного буфера посылки (области памяти, куда сохраняются принимаемые байты).
Для этого служит преамбула - предварительный признак начала посылки.
Стартовый символ. В ASCII протоколе роль преамбулы играет специальный управляющий символ начала посылки. По каждому приему такого символа нужно сбрасывать буфер: обнулять число принятых байт, перемещать указатель на начало буфера и т.п. То же самое нужно делать при переполнении буфера. Это позволит настоящему управляющему символу сбросить предыдущую "посылку", начатую ложным символом.
Пример. Последний управляющий символ ":" сбросит предыдущую ложную посылку:
____ : ) ____ : 1 2 R S 4 8 5 /ПС/ ____
Стартовая пауза. В двоичном протоколе, где не предусмотрен уникальный управляющий символ, и синхронизация посылок идет по заданной паузе между байтами, достаточно увеличить активную паузу, описанную в синхронизации кадров, до длительности паузы между байтами, по которой начинается прием новой посылки. То есть, между включением приемопередатчика на передачу и отправкой первых байтов посылки нужно сделать паузу длительностью в 1.5 - 3.5 кадра UART. При активном передатчике во время такой преамбулы помехе трудно будет прорваться к приемникам, они зафиксируют нужную паузу, сбросят буфер посылки и настроятся на прием новой посылки. Этот метод применяется, в частности, для протокола MODBUS RTU.
Стартовая последовательность. Если в двоичном протоколе синхронизация осуществляется лишь по корректному началу посылки, то отфильтровать ложную посылку можно только по логике ее структуры. Преамбула в данном случае - некоторая стартовая последовательность символов, которая не может встретиться в данных посылки, и которую вряд ли сформирует помеха. Преамбула отсылается перед основной посылкой. Принимающее устройство отслеживает в поступающих данных эту стартовую последовательность. Где бы она не состоялась, принимающее устройство сбрасывает буфер посылки и начинает принимать новую.
Вариант 1. Посылка начинает заново приниматься после приема "go!" (вместо символов могут быть любые 8-битные данные):
____ : - Ь ___ g o ! 1 2 R S 4 8 5 ____
Вариант 2. Посылка начинает заново приниматься после приема не менее трех "E" подряд и стартового байта ":" (вместо символов могут быть любые 8-битные данные):
____ > : - E ___ E E E : 1 2 R S 4 8 5 ____
Даже если до стартовой последовательности было два таких символа подряд, посылка начнет сохраняться только за последовательностью из не менее чем трех подряд (лишние игнорируются) и стартового символа. Если вместо "Е" использовать байт FFh - можно совместить синхронизацию кадров и посылок. Для этого посылаются четыре FFh, а принимающее устройство ожидает не менее трех, с учетом того, что первый байт FFh может уйти на синхронизацию кадров.
2). Контроль достоверности. Особо сильная помеха может вклиниться в посылку, исказить управляющие символы или данные в ней, а то и вовсе уничтожить ее. Кроме того, одно из подключенных к линии устройств (абонент) может выйти из строя и перестать отвечать на запросы. На случай такой беды существуют контрольная сумма, тайм-ауты и квитирование.
Контрольная сумма - в общем случае 1-2 байта кода, полученного некоторым преобразованием из данных посылки. Самое простое - "исключающее или" всем байтам данных. Контрольная сумма рассчитывается и включается в посылку перед отправкой. Принимающее устройство производит ту же операцию над принятыми данными и сверяет рассчитанную контрольную сумму с полученной. Если посылка была повреждена, то, скорее всего, они не совпадут. В случае применения ASCII протокола - код контрольной суммы также передается ASCII-символами.
Тайм-аут - максимальное время ожидания ответа от запрашиваемого устройства. Если посылка была повреждена или запрашиваемое устройство вышло из строя, то ведущее устройство не повиснет в ожидании ответа, а по истечении определенного времени признает наличие сбоя. После чего можно еще пару раз повторить запрос и, если сбой повторяется, перейти на отработку аварийной ситуации. Тайм-аут отсчитывается с момента завершения передачи запроса.
Его длительность должна с небольшим запасом превышать максимальное время ответной передачи плюс время, необходимое на обработку запроса и формирование ответа. Ведомому устройству тоже не помешает отработка тайм-аутов. Особенно в ситуациях, когда отсутствие регулярного обновления данных или новых команд от ведущего устройства критично для работы устройств системы. Самая простая реализация для ведомого - сброс сторожевого таймера по приему посылки. Если по какой-либо причине данные перестали поступать - устройство сбросится по переполнению сторожевого таймера. После сброса устанавливается безопасный режим до приема первой команды.
Квитирование - подтверждение доставки (квитанция). Когда важно, чтобы ведомый обязательно получил данные или команду, возникает необходимость проконтролировать получение им посылки. Ведущее устройство, отправив ведомому данные, ждет ответа с подтверждением. Ведомое устройство, получив данные, в случае их корректности посылает ответ, подтверждающий доставку. Если по истечении тайм-аута ведущее устройство не получает подтверждение, делается вывод о сбое в связи или в ведомом устройстве. Дальше обычные меры - повтор посылки. Но тут есть нюанс: повреждена и не получена может быть сама квитанция. Ведущее устройство, не получив квитанцию, повторяет посылку, и ведомое отрабатывает ее повторно. Не всегда это существенно, но если перепосылалась команда типа "увеличить параметр на 1" это может привести к незапланированному двойному увеличению параметра. В таком случае надо предусмотреть что-нибудь типа циклической нумерации посылок, чтобы ведомое устройство отличало повторные посылки от новых и не отрабатывало их.
