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

Рис. 23. Поле конца кадра



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

4.2.3 Структура кадра запроса

Рис. 24. Структура кадра запроса

Для получения информационных данных, узел посылает в шину кадр запроса. Этот кадр запроса содержит идентификатор требуемых данных. В ответ на это, узел, который обладает запрашиваемыми данными, посылает в шину соответствующий кадр данных.

Кадр запроса имеет структуру, аналогичную кадру данных, за исключением двух различий. Во-первых, бит RTR кадра запроса имеет не преобладающий уровень, а в кадре данных - преобладающий уровень. Во-вторых, в кадре запроса нет поля данных.

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



4.2.4 Обнаружение и обработка ошибок

Рис. 25. Возникновение локальных ошибок

Локальные ошибки могут возникать по разным причинам, таким как несоответствие положения точки считывания (sample point), различие между уровнями переключения сигнала (преобладающего/не преобладающего) или дисперсия во время распространения сигнала в линии. Чтобы гарантировать правильные прием и передачу данных по сети, необходимо локальные ошибки, возникающие в одном узле, стали известны всем узлам сети - так называемая глобализация локальной ошибки.

В протоколе CAN для глобализации локальной ошибки используется правило вставки синхробита (см. CAN физический уровень). Таким образом, в случае возникновения ошибки, узел передает кадр ошибки, который включает 6 одинаковых по значению битов. В результате этого все остальные узлы обнаружат ошибку вставки синхробита и, таким образом будут информированы о локальной ошибке.



Рис. 26. Глобализация локальной ошибки

Глобализация локальной ошибки показана на рис. 26. Приемник 2 обнаруживает локальную ошибку и передает флаг ошибки, состоящий из 6 преобладающих битов. На шестом бите все остальные узлы, подключенные к сети, обнаруживают ошибку вставки синхробита и в свою очередь передают еще один флаг ошибки. После этого следует 8 бит делимиторов и 3 бита межкадрового поля. Затем Передатчик повторяет переданное сообщение (после того, как получит доступ к шине).

Последовательность обработки ошибок

Обнаруживается локальная или глобальная ошибка

Передается флаг ошибки (глобализация ошибки)

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

Переданное сообщение отвергается узлом-приемником

Счетчики ошибок увеличиваются для каждого узла сети

Сообщение передается повторно автоматически.

Данная последовательность гарантирует правильную доставку сообщений в сети в случае, если в сети нет узлов в состоянии пассивной ошибки и в состоянии отключения от сети. В случае возникновения локальной ошибки происходит процесс глобализации локальной ошибки путем передачи флага ошибки, состоящего из 6 одинаковых по значению битов. После прохождения кадра ошибки, узел пытается заново передать отвергнутое сообщение. Если в шине не будет передаваться более высокоприоритетное сообщение, то отвергнутый кадр данных (запроса) будет передан через 23 промежутка прохождения 1 бита. В случае если узел-передатчик находился в состоянии пассивной ошибки, отвергнутое сообщение будет передано через 31 промежуток прохождения 1 бита, так как передается еще поле дополнительной задержки, состоящее из 8 бит.

Рис. 27. Активный кадр ошибки

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



Рис. 28. Область вставки синхробита

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

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

Рис. 29. Область прослушивания шины

Все узлы в сети осуществляют прослушивание шины, то есть узлы сравнивают переданный бит с битом, отразившимся в шине. Ошибка бита возникает в случае несовпадения переданного и отразившегося в шине бита. Сразу же после ошибочного бита передается кадр ошибки. Ошибка бита может возникать только для битов из области прослушивания шины (см. рис. 29).



Рис. 30. Область для подсчитывания контрольной суммы

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

Контрольная последовательность используется только для обнаружения ошибки. Расстояние по Хэммингу для кода, используемого в данном случае, равно 6. Это значит, что возможно обнаружить 5 одиночных ошибок и пакетные ошибки длинной до 15 бит.

Рис. 31. Возникновение двух необнаруженных ошибок

Теоретически, код с расстоянием 6 по Хэммингу, примененный в CAN протоколе гарантирует обнаружение 5 одиночных ошибок. Но в редких случаях 2 ошибки не могут быть обнаружены (см. рис. 31). Эта проблема решается путем исключения кадров с идентификаторами, для которых необходима вставка синхробитов.

Рис. 32. Возникновение ошибки подтверждения

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

Рис. 33. Возникновение ошибки формы кадра

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

Вероятность необнаруженных ошибок в CAN сети обсуждалась на многих международных CAN конференциях. Эта вероятность зависит от различных параметров, например средней скорости искажения сообщений. Для стандартных кабелей эта скорость равна 10^-3. По устоявшимся данным, вероятность необнаруженных ошибок в CAN сети составляет 4,7*10^-11*скорость возникновения ошибки. Например, если узлы сети работают 8 часов в день, обнаруживается 1 ошибка каждые 0,7 секунд, скорость в сети 500 Кбит/с, то одна необнаруженная ошибка будет проходить через каждые 1000 лет.

Эта вероятность подсчитана для кадров стандартного формата. Для кадров расширенного формата она будет больше.

Рис. 34. Режимы работы узла

Чтобы различить случайные и постоянные ошибки у каждого CAN узла есть счетчики ошибок: счетчик ошибок приема (REC) и счетчик ошибок передачи (TEC). Счетчики увеличивают свое значение в случае возникновения ошибки и уменьшают свое значение в случае правильного приема или передачи сообщения. В зависимости от значения этих счетчиков выбирается режим работы узла. Сразу после включения питания, узел находится в режиме активной ошибки. Это значит, что при возникновении ошибки, он передает кадр активной ошибки. Если значение счетчика ошибок (REC или TEC) станет больше или равно 127, то узел переходит в режим пассивной ошибки, то есть при возникновении ошибки он будет передавать кадр пассивной ошибки.

В случае если значение счетчика TEC станет больше, чем 255, узел перейдет в режим отключения от шины, то есть выводы CAN_H и CAN_L перейдут в состояние высокого сопротивления. Вывести из этого состояния можно теплым сбросом. После этого сброса узел ждет прохождения 128x11 не преобладающих битов, и только после этого он готов к обмену информацией. В данном случае не рекомендуется осуществлять холодный сброс, так как при этом не будет цикла ожидания.

Рис. 35. Кадр Пассивной ошибки

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

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

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

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

Рис. 36. Поле дополнительной задержки

Для того чтобы шина не была блокирована некорректно работающими узлами при передаче высокоприоритетных сообщений, в протоколе CAN введена задержка для узлов, находящихся в состоянии пассивной ошибки. После передачи кадра данных (запроса) узел в состоянии пассивной ошибки должен ждать прохождения 3+8 не преобладающих битов перед тем, как снова начать передачу.

Рис. 37. Счетчик ошибок передачи

Для счетчика ошибок, возникающих при передачи сообщения, введены следующие критерии:

0-96: Узел находится в состоянии активной ошибки до предупреждающего предела. Если значение счетчика превысит 96, то CAN контроллер выдаст предупреждающее сообщение микроконтроллеру (сгенерирует прерывание с соответствующим флагом ошибки).

97-127: Узел продолжает оставаться в состоянии активной ошибки. Если счетчик ошибок продолжает увеличиваться в этом промежутке, то вероятнее всего, что узел работает некорректно.

128-255: Узел переходит в состояние пассивной ошибки. Некоторые CAN контроллеры не сообщают об этом микроконтроллеру.

>255: в этом случае происходит отключение узла от шины. Микроконтроллер об этом информируется с помощью прерывания с соответствующим флагом ошибки.

Рис. 38. Счетчик ошибок приема

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

Правила изменения значений счетчиков ошибок

Когда приемник обнаруживает ошибку, значение счетчика REC увеличивается на 1, кроме случаев, когда обнаруживается ошибка бита во время передачи активного флага ошибки или флага переполнения.

Когда приемник обнаруживает преобладающий бит, как первый после передачи флага ошибки, величина счетчика REC увеличивается на 8.

Когда передатчик посылает флаг ошибки, значение счетчика TEC увеличивается на 8.

Случай 1: Если передатчик находится в состоянии пассивной ошибки и обнаруживает ошибку подтверждения (не было преобладающего бита в слоте поля подтверждения), а также не обнаруживает преобладающий бит как первый, после передачи пассивного флага ошибки.

Случай 2: Если передатчик посылает флаг ошибки вследствие возникновения ошибки вставки синхробита во время арбитража. Данная ошибка возникает, если синхробит должен быть не преобладающим, и он посылается как не преобладающий, а в шине отражается преобладающий бит.

Если передатчик обнаруживает ошибку бита во время передачи активного флага ошибки или флага переполнения, то значение счетчика TEC увеличивается на 8.

Если приемник обнаруживает ошибку бита во время передачи активного флага ошибки или флага переполнения, то значение счетчика REC увеличивается на 8.

Каждый узел способен нормально принять последовательность, состоящую из одинаковых по значению битов, длиной до 7 бит, и если эта последовательность передается после активного флага ошибки, пассивного флага ошибки и флага переполнения. После приема последовательности из четырнадцати преобладающих битов (вследствие суперпозиции активных флагов ошибки или суперпозиции флагов переполнения) или после приема восьми преобладающих битов, следующих за пассивным флагом ошибки, каждый передатчик увеличивает значение счетчика TEC на 8, а каждый приемник увеличивает значение счетчика REC на 8.

После правильной передачи кадра (получения подтверждения и отсутствия ошибок, кроме последнего бита поля EOF), значение счетчика TEC уменьшается на 1, если оно уже не равно 0.

После правильного приема кадра (прием без ошибок до поля подтверждения и правильного послания подтверждающего бита), значение счетчика REC уменьшается на 1, если оно находится между 1 и 127. Если оно равно 0, то оно и остается нулем, и если значение счетчика больше, чем 127, то устанавливается значением от 119 до 127.

Узел переходит в состояние пассивной ошибки, если значение счетчика TEC или REC станет больше, чем 127. Притом, последняя ошибка, из-за которой узел перешел в состояние пассивной ошибки, передается с активным флагом ошибки.

Узел отключается от шины, если значение счетчика TEC станет больше, чем 255.

Узел переходит в состояние активной ошибки из состояния пассивной ошибки, когда значение счетчиков TEC и REC станут меньше, чем 128.

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



Рис. 39. Кадр переполнения

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

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



Рис. 40. Локальные ошибки в поле EOF

Если хотя бы один из шести первых битов поля конца кадра (EOF) имеет преобладающее значение, то узел передает кадр ошибки, чтобы глобализовать эту ошибку.

Ошибка в последнем 7 бите поля EOF обрабатывается по-разному для передатчика и приемника сообщения:

Передатчик: В случае возникновения ошибки в 7 бите поля EOF передается кадр ошибки, с соответствующим потом повтором передаваемого сообщения.

Приемник: На ошибку в 7 бите поля EOF приемник посылает кадр переполнения, однако само сообщение считается принятым правильно.

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

Не использовать повторяющиеся сообщения

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

Использовать защищенный протокол или последовательность чисел для адресации данных или программы.

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

1. Приемник передает сообщение о возникшей локальной ошибке в предпоследнем бите поля EOF.

2. Ошибка при передаче последнего бита.

Во втором случае приемник примет сообщение, а передатчик начнет передавать тоже самое сообщение снова.

4.2.5 Дополнительные режимы

В CAN протоколе существуют два дополнительных режима работы:

Режим прослушивания шины. В этом режиме CAN узел способен принять правильные кадры данных или запроса, но в этом режиме узел посылает в шину только не преобладающие биты, и также он не может начать передавать сообщение.

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

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

При использовании обмена информацией по расписанию CAN узел работает в пошаговом режиме. В этом режиме узел не передает флаги ошибки и переполнения. Также, в этом режиме отключен автоматический повтор сообщения в случае возникновения ошибки.

Рис. 41. Режим Обмена информацией по расписанию

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

Каждый узел, поддерживающий режим обмена информацией по расписанию имеет циклический счетчик размером в 16 бит, увеличивающий свое значение по внутренним или внешним часам. Значение счетчика может быть задано микроконтроллером. Каждое сообщение передается или принимается в момент времени, когда значение счетчика соответствует по времени нахождению в шине поля SOF требуемого сообщения или точки считывания (sample point) последнего бита поля EOF предшествующего сообщения. После правильного приема сообщения значение счетчика говорит микроконтроллеру, что еще одно сообщение принято и его можно считать, пока принимается следующее сообщение.

Рис. 42. Соотношение времени всей сети и относительных времен отдельных узлов.



Уравнения времен передачи информации с одного узла на другой

5. Обзор существующих уровней приложений для CAN протокола

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

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

К настоящему времени известно уже более четырех десятков CAN приложений. Среди подобного многообразия CAN приложений наибольшее распространение, в особенности в системах промышленной автоматизации, получили четыре, поддерживаемых ассоциацией CiA и рассмотренных ниже. Это CAL/CANopen, CAN Kingdom, DeviceNet и SDS (Smart Distributed System).



5.1 CAL/CANopen

Разработка и поддержка открытого протокола прикладного уровня для сетей промышленной автоматизации были одними из приоритетных целей создания организации CiA в 1992 году. Основой такого протокола послужил прикладной уровень, разработанный фирмой Philips, после доработки и усовершенствования которого рабочей группой CiA, в 1993 году была опубликована спецификация CAL -- CAN Application Level (CiA DS 20x). Фундаментом CAL служит канальный уровень CAN. CAL не является ориентированным на конкретные приложения стандартом протокола, не содержит каких-либо профилей, привязанных к конкретным устройствам, и не определяет содержание передаваемых данных, но предлагает стандартизованные элементы сетевого сервиса прикладного уровня. CAL включает в себя четыре составные части:

Спецификация CAN сообщений (CMS -- CAN Message Specification);

Сетевое управление (NMT -- Network Management);

Распределение идентификаторов (DBT -- Identifier Distributor);

Управление уровнем (LMT -- Layer Management).

CMS определяет типы объектов взаимодействия в рамках объектно- ориентированного подхода, правила и механизмы передачи данных разных типов посредством CAN фреймов, включая передачу пакетов длиной более 8 байт. Сетевое управление построено на взаимодействии типа мастер-слуга. Один модуль сети является NMT-мастером, все остальные -- NMT-ведомые. NMT-мастер инициализирует, управляет NMT-слугами, которые желают принять участие во взаимодействии, и позволяет им общаться между собой посредством CMS-сервисов. Также в задачи сетевого управления входят контроль ошибок и конфигурирования устройств. Благодаря DBT-сервисам происходит бесконфликтное распределение идентификаторов среди модулей под контролем DBT-мастера. Посредством LMT-сервисов возможны запрос и изменение текущих параметров (значений идентификаторов, скорости передачи, битового квантования и т. п.) в модулях непосредственно из CAN-сети.

Сетевые CAN приложения, основанные на прикладном уровне CAL, в настоящее время успешно работают в медицинской электронике, системах контроля дорожного движения, на транспорте, в промышленном оборудовании. Результатом дополнения CAL (точнее, некоторого его подмножества) системой профилей (устройств, интерфейсов, приложений и т. д.) и спецификациями физического уровня (типы соединителей, правила битового квантования и т. д.) явилось появление более “конкретного” стандарта протокола CANopen. По существу CANopen является приложением прикладного уровня CAL. Первоначально CANopen предназначался для сетей управления движущимися механизмами в системах промышленной автоматики. Однако впоследствии протокол нашел применение в медицине, морской электронике, на транспорте и в системах автоматизации зданий.

CANopen базируется на двух уровнях стандарта CAN (ISO 11898, Bosch CAN Specification 2.0 A/B). В дополнение к спецификациям физического уровня ISO 11898 (среда передачи данных -- двухпроводная дифференциальная линия), CANopen содержит собственные правила битового квантования, а также определяет три рекомендуемых типа соединителей:

9-контактный D-Sub (DIN 41652);

5-контактный круглый Mini (ANSI/B93.55M-1981);

5-контактное открытое клеммное соединение.

Разводкой контактов для всех типов соединителей предусмотрена возможность подачи питания на трансиверы узлов, имеющих гальваническую развязку. В сети CANopen определены восемь градаций скоростей передачи данных: 1 Мбит/с, 800 Кбит/с, 500, 250, 125, 50, 20 и 10 Кбит/с. Поддержка скорости 20 Кбит/с является обязательной для всех модулей. Прикладной уровень представляет собой подмножество CAL и основано на 4-х его сервисных элементах -- CMS, NMT, DBT и LMT, дополненных профилем соединения (CiA DS 301), определяющим базовые правила обмена данными и структуру словаря объектов. Более развитые механизмы сетевого взаимодействия для интеллектуальных устройств (человеко-машинные интерфейсы -- HMI, PC-контроллеры, PLC, инструментальные средства и т. п.) описаны в дополнении к коммуникационному профилю (CiA DS 302). В сети CANopen на прикладном уровне модули обмениваются между собой объектами- сообщениями -- COB (Communication Object), включающими в себя один или более CAN фреймов. Всего существует четыре типа таких объектов:

данных процесса -- Process Data Objects (PDO);

сервисных данных -- Service Data Object (SDO);

специальных функций -- Special Function Objects;

сетевого управления -- Network Management Objects.

SDO-объекты позволяют модулям обмениваться данными любого объема (при последовательностях более 8 байт -- благодаря использованию нескольких CAN фреймов) в ацикличном низкоприоритетном режиме. Как правило, этот тип обмена (обязательный к поддержке всеми модулями) используется для конфигурирования устройств или настройки формата PDO объектов. В противоположность SDO типу, обмен на основе PDO объектов используется для синхронной (цикличной или ацикличной) или асинхронной (инициируемый внешними прерываниями) скоростной передачи не более 8 байт (длина поля данных фрейма CAN), имеет более высокий приоритет, чем SDO и применяется для пересылок данных в режиме реального времени. Объекты специальных функций служат для выполнения ряда специальных задач: запуска синхронных процессов, передачи значения абсолютного времени и кодов ошибок. Объекты сетевого управления включают сообщения NMT, LMT и DBT сервисов. Администрированием сети занимается NMT-мастер, который инициализирует устройства, обеспечивает контроль ошибок, а также производит их периодическую “перекличку” (Life Guarding) с помощью PDO сообщений (Node Guarding Object) для выявления узлов, находящихся в нерабочем состоянии ввиду физического отсутствия или отключения от шины (bus off) по счетчику ошибок.

Для максимального упрощения процесса интеграции модулей независимых производителей в единую сеть в CANopen используется концепция профилей. К настоящему времени завершено формирование следующих профилей устройств:

Модули ввода/вывода (аналоговые и цифровые) (DSP-401);

Приводы и модули управления перемещением (DSP-402);

Элементы человеко-машинного интерфейса (DSP-403);

Измерительные устройства и регуляторы (WD-404);

Кодеры (DSP-406).

Разрабатываются профили для модулей управления гидравлическими механизмами, дизельными двигателями и железнодорожным транспортом.
Первым профилем приложения стал WD-407 (IBIS-CAN) для электронных систем управления на общественном транспорте Европы (билетный контроль, подсчет пассажиров и т. п.), где CAN-сети применяются достаточно широко.

5.2 CAN Kingdom

Протокол шведской компании KVASER-AB (www.kvaser.se) занимает особое место среди CAN HLP не только из-за своего необычного названия (CAN королевство), но и в значительной степени благодаря оригинальной концепции сетевого взаимодействия и эффективности CAN-приложений на его основе. Началу работ над первой версией (текущая -- третья) протокола CAN Kingdom в 1990 году предшествовал многолетний опыт компании в области создания систем распределенного управления. Протокол был специально разработан для управления движущимися машинами и механизмами -- промышленными роботами, текстильными станками, мобильными гидравлическими устройствами, -- и позволяет достичь высокой производительности в режиме реального времени при удовлетворении жестких требований безопасности. CAN Kingdom является также основой американского военного стандарта CDA 101 и широко используется в военной технике -- от надувных лодок и систем наведения на цели до сверхзвуковых истребителей и ракет.

Основной целью создания протокола было предоставление системному разработчику максимальной свободы в реализации своих идей при построении сети, сохранив при этом возможность использования стандартных модулей от независимых производителей. CAN Kingdom не является “готовым” протоколом в том смысле, в каком это справедливо, например, по отношению к стандартам типа CANopen или DeviceNet. Это скорее набор примитивов -- метапротокол, -- с помощью которых можно “собрать” протокол под конкретную сеть модулей. Этим достигается уникальное сочетание простоты интеграции готовых модулей с высокой степенью “закрытости” оригинального протокола.

При разработке спецификации CAN Kingdom авторы отказались от принятого в подобных случаях и широко распространенного следования правилам взаимосвязи открытых систем OSI/ISO, поскольку семиуровневая модель OSI/ISO создавалась изначально для описания традиционных компьютерных сетей, от которых не требуется работа в реальном масштабе времени, и предназначены они для обслуживания пользователей, требования которых априори (на этапе построения такой сети) неизвестны и непредсказуемы. В системах же управления реального времени ситуация прямо противоположная -- на стадии разработки все коммуникационные потребности модулей должны быть известны.

Краеугольным камнем концепции сетевого взаимодействия CAN Kingdom является принцип: “Модули обслуживают сеть” (MSN -- Modules Serves the Network) в отличие от принципа “Сеть обслуживает пользователей” (NSM -- Network Serves the Modules), свойственного компьютерным сетям.

В CAN Kingdom сеть CAN -- это страна (королевство) со своей столицей (центральный контролирующий узел) и провинциальными городами (остальные узлы). Король (управляющая программа-супервизор) управляет всем королевством и отвечает за соблюдение закона и порядка в нем, а за местное управление (в пределах своего узла) отвечают мэры городов (управляющие программы узлов). Каждый город экспортирует или импортирует продукцию -- информацию -- посредством почты, которая циркулирует по почтовому тракту (CAN-шина) и проходит через почтмейстеров (CAN контроллеры). Типы почтовой корреспонденции (информация, передаваемая по сети) и ее соответствие CAN-терминам таковы:

Письмо	CAN-фрейм(данных или удаленного запроса)
Конверт	CAN-идентификатор
Страница	Поле данных CAN-фрейма
Строка	Байт данных
Элемент строки	Бит данных

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

Распределение CAN идентификаторов находится под полным контролем разработчика.

Максимальное время прохождения любого сообщения в сети предсказуемо.

Во время начальной инициализации системы происходит обязательный этап настройки (setup) протокола, включая построение форматов данных, начиная с битового уровня, методов управления шиной, распределение идентификаторов и т. д.

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

Перед инициализацией сети каждый модуль (город) должен иметь свой номер (CAN Kingdom не описывает конкретный способ установки номера модуля -- это может быть DIP-переключатель, энергонезависимая память или конфигурация соединителя) и “знать” идентификатор сообщения инициализации (королевское письмо) и скорость передачи данных в сети.

В сеть CAN Kingdom возможна интеграция любых CAN-модулей, включая разработанных для других протоколов, например, DeviceNet или SDS.

Не существует каких-либо рекомендуемых скоростей передачи данных. Но за первые 200 мс после подачи питания узел обязан настроиться на прослушивание шины на скорости 125 Кбит/с. Допустимы отличающиеся от ISO 11898 спецификации физического уровня.

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

Правила идентификации модулей основаны на использовании международного кода EAN/UPC, включающего код производителя и продукта. Среди других особенностей CAN Kingdom можно отметить гибкость режимов передачи и упаковки данных (включая использование поля арбитража для передачи данных), объединение узлов в группы, поддержка часов реального времени, различных режимов доступа к шине.

5.3 DeviceNet

DeviceNet -- протокол, разработанный и опубликованный в 1994 году компанией Allen-Bradley (www.ab.com) корпорации Rockwell и впоследствии переданный в ведение специально организованной для его поддержки ассоциации ODVA (Open DeviceNet Vendor Association Inc., www.odva.org). DeviceNet -- недорогое, простое и эффективное решение для объединения разнообразных устройств промышленной автоматизации независимых производителей в единую систему: фото-, термодатчики, стартеры, считыватели штриховых кодов, элементы человеко-машинного интерфейса -- клавиатуры, дисплейные панели, -- наряду с управляющими устройствами -- PLC, компьютерами и т. д. . При разработке протокола помимо снижения стоимости также стояла задача упрощения и унификации диагностики подобных устройств. Первые устройства, удовлетворяющие спецификации DeviceNet, появились на рынке в начале 1995 года. DeviceNet также построен на двух нижних уровнях стандарта CAN, дополненных более детальными, чем в других HLP, спецификациями физической среды.

Сеть DeviceNet имеет шинную топологию с отводами. Физической средой передачи является 4-проводной кабель (CAN_H, CAN_L, Vcc, Ground), причем возможны две его разновидности: толстый (внешний диаметр 12,2 мм) и тонкий (6,9 мм). Определены лишь три значения скорости передачи данных -- 125, 250 и 500 Кбит/с. Максимальные длины центральной магистрали и отводов в зависимости от скорости передачи и типа кабеля приведены в таблице 11.



Таблица 11. Ограничения на протяженность сети DeviceNet

Скорость передачи, Кбит/с	Длина магистрали, м	Длина отводов, м
	Толстый кабель	Тонкий кабель	Одиночных	Суммар-ная
125	500	100	6	156
250	250	100	6	78
500	100	100	6	39

Важной особенностью сети DeviceNet является возможность питания модулей непосредственно от сетевого кабеля (24 В, до 8 А на толстом кабеле), а также допускается применение нескольких источников питания в любой точке шины. Все это дает возможность построения автономной сети, не зависящей от наличия или качества внешнего питания, а при необходимости позволит легко демонтировать и снова развернуть систему на новом месте. Сеть DeviceNet допускает “горячее” (без обесточивания сети) подключение и отключение модулей.

Стандарт DeviceNet содержит также подробное описание многочисленных типов переходников, разветвителей (одиночных и многопортовых), соединителей (Mini, Micro), сетевых отводов и т. п. При описании организации типов данных, сетевого поведения модулей в DeviceNet используется объектно-ориентированная модель. Обязательные классы объектов включают в себя следующие:

объект удостоверения (Identity object). Содержит информацию о модуле (код производителя, продукта, версия и т. п.);

объект соединения (Connection object). Логический порт ввода/вывода устройства;

объект DeviceNet. Включает MAC ID (идентификатор модуля), скорость передачи, состояние модуля и т. п.;

объект роутера сообщения (Message router object). Перенаправляет явное сообщение получателю.

Сообщения в сети DeviceNet могут быть двух типов:

сообщения ввода/вывода (I/O messages) -- предназначены для целей управления устройствами и передачи данных в реальном времени между узлами в широковещательном или в режиме точка-точка. Используют идентификаторы с высоким приоритетом, которые и определяют содержание сообщения;

явные сообщения (Explicit messages) -- для многоцелевого обмена данными в режиме точка- точка. Обеспечивают типичный сервис запрос/ответ. Используют идентификаторы с низким приоритетом и применяются обычно для конфигурирования устройств и целей диагностики. Значение сообщения содержится в поле данных.

При необходимости передачи данных длиной более 8 байт применяется механизм фрагментации. В зависимости от потребностей обмена и возможностей модулей, возможны мастер-слуга (master-slave), мультимастерный (multi-master), или равноправный (peer to peer) способы взаимодействия устройств. Пересылки данных могут инициироваться путем опроса, циклически или по изменении их значения (change of state). Максимальное число узлов в сети DeviceNet -- 64. Модули в сети могут быть как UMCC-типа (UnConnected Message Manager), способные выставлять равноправные (peer to peer) соединения с другими модулями, так и Predefined Master/Slave- типа, требующие меньшей длины кода и производительности управляющего микроконтроллера, но которые не могут произвольно выбирать путь соединения, и их объекты соединения конфигурируются при включении устройства.

Для обеспечения “стыкуемости” устройств разных производителей и их взаимодействия в рамках единой сети стандарт DeviceNet, подобно многим HLP, определяет ряд профилей устройств. Формированием библиотек профилей занимаются специальные группы (Special Interest Groups) ассоциации ODVA.



5.4 SDS (Smart Distributed System)

SDS -- разработка компании Honeywell Inc. (Micro Switch Division, www.honeywell.sensing.com). Наряду со стандартом DeviceNet, SDS представляет собой еще одно недорогое и законченное решение для сетевого управления интеллектуальными датчиками и приводами от центрального контроллера (PLC, компьютера) в системах промышленной автоматизации. По степени завершенности -- от спецификаций физической среды до прикладного уровня, -- ориентировке на снижение стоимости, SDS-стандарт напоминает DeviceNet.

Шинная топология представляет собой линейную шину (магистраль или транк) с короткими отводами. Определены два базовых типа кабельной разводки: Mini (применяемый при сборке транка сети) -- 4-проводной кабель с максимальной токовой нагрузкой 8 А, 5-контактный разъем -- и Micro (для подключения физических устройств к сети) -- 4-проводной кабель, 3 А, 4-контактный разъем без отдельного контакта для экрана кабеля.

В сети SDS допускается и обычная проводная разводка с использованием открытых клеммных соединителей. Всеми типами кабельной разводки и соединителей, также как и в сети DeviceNet, предусмотрено подведение питающего напряжения (диапазон 11-25 В на стороне устройства) к узлам. Предельные значения длин магистрали и отводов сети SDS в зависимости от скоростей (их четыре) передачи приведены в таблице 12.

Таблица 12. Предельные значения длин магистрали и отводов сети SDS

Макс. Длина магистрали, м	Скорость передачи, Кбит/с	Макс. длина отводов, м	Макс. количество узлов
22,8	1000	0,3	32
91,4	500	0,9	64
182,8	250	1,8	64
457,2	125	3,6	64

Сообщения, циркулирующие в сети SDS, носят название APDU (Application layer Protocol Data Unit) -- блоки данных протокола прикладного уровня. APDU представляет собой CAN фрейм стандартного формата (расширенный формат фрейма в SDS-сети не применяется), элементы которого имеют свое собственное назначение в SDS. APDU имеет две формы -- укороченную (не используется при передаче данных и содержит в поле DLC нули) и длинную. При необходимости передачи последовательностей данных более 6 байт используется фрагментированный формат (до 64 фрагментов по 4 байт) длинной формы APDU.

Укороченная форма APDU используется в следующих сервисах прикладного уровня:

Change of State (OFF, ON, OFF ACK, ON ACK) -- обнаружение изменения состояния логического устройства;

Write (ON State, OFF State, ON State ACK, OFF State ACK) -- управление состояниями логического устройства.

К сервисам, использующим длинную форму APDU, относятся:

Channel -- обеспечивает как широковещательный (multicast), так и равноправный (peer to peer) каналы соединения;

Connection -- открытие/закрытие индивидуальных типов соединения;

Write -- чтение атрибутов объектов устройства;

Read -- изменение атрибутов объектов устройства;

Action -- команда объекту устройства выполнить действие;

Event -- сигнализация о событии объектом устройства.

При инициализации взаимодействия модулей сети SDS используются 4 сервисных функции-примитива:

Запрос (Request) -- генерация APDU устройством-инициатором соединения;

Ответ (Response) -- ответный APDU устройства-ответчика;

Индикация (Indication) -- фиксация факта приема APDU устройством-ответчиком;

Подтверждение (Confirm) -- подтверждение приема APDU устройством-инициатором.

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



II. Практическая реализация ISA CAN сетевого адаптера

1. Структурная схема и назначение отдельных блоков

Структурная схема ISA CAN адаптера изображена на рис. 43. Как видно, адаптер функционально состоит из блока согласования, CAN микроконтроллера, схемы оптической развязки и приемопередатчика. Блок согласования, в свою очередь, состоит из шинного разветвителя и ПЛУ (программируемого логического устройства). Команды управления CAN адаптером, а также данные для приема/передачи поступают через ISA шину персонального или промышленного компьютера. Адаптер, в свою очередь, осуществляет прием, передачу, фильтрацию сообщений по CAN сети, а также проверку на ошибки в принятых сообщениях.

Рис. 43. Структурная схема ISA CAN адаптера

В основном, все сигналы ISA шины можно разделить на три группы - это шина адреса (ША), шина данных (ШД) и шина управления (ШУ). Сигналы ШД, ША и часть сигналов ШУ поступают на блок согласования, предназначение которого согласование протокола обмена данными CAN микроконтроллера и ISA шины. В блоке управления младшая часть сигналов ША и сигналы ШД поступают на шинный разветвитель, который в определенное время осуществляет подключение к CAN контроллеру сигналы ША либо ШД. Наличие шинного разветвителя необходимо, так как входная шина CAN микроконтроллера совмещает ША и ШД. Работа шинного разветвителя управляется логикой, “прошитой” в ПЛУ. Кроме того, ПЛУ выполняет функцию дешифратора адреса. Дешифратор адреса активизирует процесс обмена информацией с микроконтроллером по шине ISA при определенных уровнях сигнала на старшей части ША. Таким образом, за микроконтроллером закрепляется определенное адресное пространство из пространства ША.

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

2. Описание работы устройства

2.1 Общее описание

Принципиальная схема ISA CAN адаптера приведена в конструкторской документации на устройство (Приложение 3). Для начала рассмотрим назначение выводов ISA шины (разъемы XT1.A и XT1.B), которые используются устройством.

GND, +5V - напряжение питания CAN адаптера;

SA0-SA19 - выводы ША;

SD0-SD7 - выводы ШД;

SMEMR - вывод чтения из памяти. На этом выводе появляется логический ноль, когда происходит чтение данных микропроцессором из первого мегабайта памяти;

SMEMW - вывод записи в память. На этом выводе появляется логический ноль, когда происходит запись данных микропроцессором в первый мегабайт памяти;

IRQ3…IRQ7 - выводы запроса прерывания. Внешнее устройство может прервать основную работу микропроцессора и заставить его выполнить специальную подпрограмму - обработчик прерывания. Для этого на один из выводов IRQ3…IRQ7 внешнее устройство должно подать уровень логической единицы и держать его, пока микропроцессор не начнет выполнения подпрограммы обработки прерывания;

BALE - по фронту и спаду этого сигнала происходит запись адреса из ША во внешнее устройство.

Reset DRV - по фронту и спаду этого сигнала происходит сброс компьютера.

Далее рассмотрим реализацию блока согласования. Шинный разветвитель выполнен на двух двунаправленных буферных усилителях. На входа микросхемы DD1 приходят сигналы с адресных линий SA0-SA7, а на входа D2 - сигналы SD0-SD7 ШД. Выходные выводы B0…B7 D1 и D2 соединяются попарно (см. принципиальную схему) и поступают на входа AD0-AD7 CAN микроконтроллера. Входа AD0-AD7 представляют собой совмещенную ША и ШД. Уровень на выводах DIR у D1 и D2 управляет направлением передачи данных. Если на выводе DIR присутствует уровень логической единицы, то сигналы с выводов A0-A7 поступают на выводы B0-B7. При логическом нуле на выводе DIR направление сигналов обратное. На вывод DIR буфера D1 через резистор R1 поступает напряжение питания +5 вольт, поэтому направление передачи сигналов у него всегда от A0-A7 до B0-B7. В обратной передаче сигналов здесь нет необходимости, так как CAN микроконтроллер не осуществляет операции чтения/записи в память либо в устройство ввода/вывода. Вывод DIR у D2 подключен к выводу SMEMR ISA шины. Благодаря этому, учитывается направление передачи сигналов при операциях чтения/записи регистров CAN микроконтроллера. Уровень на выводах OE у D1 и D2 управляет подключением выходов буферов. Если на OE присутствует уровень логической единицы, то выхода буферов находятся в состоянии высокого сопротивления. При присутствии уровня логического нуля на OE сигналы на входах буфера отражаются на его выходах. Таким образом, с помощью сигналов на выводах OE у D1 и D2 можно управлять подключением к CAN контроллеру ШД и ША. Управление по этим выводам осуществляется логикой, “прошитой” в ПЛУ.

ПЛУ реализована на микросхеме D4. Функциональная схема ПЛУ изображена на рис. 44.



Рис. 44. Функциональная схема ПЛУ

Основная часть ПЛУ - это дешифратор адреса устройства и логика управления буферами D1 и D2.

К дешифратору относятся следующие выводы D4: BALE, SA11-SA19, SelA14-SelA16, CSel. Выводы SA11-SA19 подключены к ША ISA шины. К выводам SelA14-SelA16 подключены разъемы XT3-XT4, положением перемычек, на которых можно подключить эти выводы либо к общему, либо через резистор к напряжению питания. Таким образом, на эти выводы подается либо логический ноль, либо логическая единица. Выходной вывод дешифратора - CSel. Работа дешифратора описывается следующей логической формулой:

Из формулы видно, что на выходе дешифратора будет логический ноль, когда адрес на ША будет равен 110C.CC00.0ХХХ.XXXX.XXXX_B (здесь C - значения этих разрядов зависят от положения перемычек на XT3-XT5; X - значение этих разрядов безразлично). При остальных адресах на выходе дешифратора присутствует логическая единица. В таблице 13 приведены все возможные значения адресного пространства, занимаемого CAN адаптером и соответствующее им расположение перемычек.

Таблица 13. Адресные пространства и расположение перемычек

Диапазон адресов	XT3	XT4	XT5
C0000-C07FF	1-2	1-2	1-2
C4000-C47FF	2-3	1-2	1-2
C8000-C87FF	1-2	2-3	1-2
CC000-CC7FF	2-3	2-3	1-2
D0000-D07FF	1-2	1-2	2-3
D4000-D47FF	2-3	1-2	2-3
D8000-D87FF	1-2	2-3	2-3
DC000-DC7FF	2-3	2-3	2-3

Кроме дешифратора адреса, как сказано выше, в ПЛМ еще организована логика управления шинным разветвителем. В ее работе участвует дешифратор адреса, а также вывода ASel, DSel, SMRD и SMWR. Вывода SMRD и SMWR подключены к выводам SMEMR и SMEMW шины ISA. Вывода ASel и DSel являются выходами логики управления и подключаются к выводам OE буферов D1 и D2 соответственно. Логика управления описывается следующими выражениями:

Принцип работы логики управления шинным разветвителем объясняется при рассмотрении процессов чтения/записи информации из регистров CAN адаптера.

Далее рассмотрим схему включения CAN микроконтроллера D3. Выводы AD0-AD7 подключены к выходной шине адреса/данных шинного разветвителя. Сигналы SMEMR, SMEMW, BALE ISA шины и вывод CSel D4 подключены к выводам RD, WR, ALE и CS CAN микроконтроллера соответственно. Эти сигналы используются для организации процессов чтения/записи регистров CAN микроконтроллера.