AN228 — рассмотрение физического уровня CAN. CAN-шина в промышленных сетях

Впервые идея CAN была предложена в середине 80-х немецкой компанией Robert Bosch, которая задумывала ее в качестве экономичного средства для объединения контроллеров, расположенных внутри автомобиля. Традиционный способ связи распределенных по объекту контроллеров жгутами проводов по своей технической сложности, по ценовым и по весовым параметрам для столь массового изделия, коим является автомобиль, оказался непригоден. Требовалось альтернативное решение, сокращающее количество проводов, поэтому был предложен протокол CAN, для которого достаточно любой проводной пары.

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

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

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

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

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

Топология сети CAN.

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

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

CAN контроллеры соединяются с помощью шины, которая имеет как минимум два провода CAN_H и CAN_L , по которым передаются сигналы при помощи специализированных ИМС приемо-передатчиков. Кроме того, ИМС приемо-передатчиков реализуют дополнительные сервисные функции:

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

Наиболее широкое распространение получили два типа приемоперадатчиков (трансиверов):

• «High Speed» приемопередатчики (ISO 11898-2),
• «Fault Tolerant» приемопередатчики

Трансиверы, выполненные в соответствии со стандартом «High-Speed» (ISO11898-2), наиболее просты, дешевы и дают возможность передавать данные со скоростью до 1 Мбит/c. «Fault-Tolerant» приемопередатчики (не чувствительные к повреждениям на шине) позволяют построить высоконадежную малопотребляющую сеть со скоростями передачи данных не выше 125 кбит/c.

Физический уровень канала CAN.

Физический уровень (Physical Layer) протокола CAN определяет сопротивление кабеля, уровень электрических сигналов в сети и т.п. Существует несколько физических уровней протокола CAN (ISO 11898, ISO 11519, SAE J2411). В подавляющем большинстве случаев используется физический уровень CAN определенный в стандарте ISO 11898.

ISO 11898 в качестве среды передачи определяет двухпроводную дифференциальную линию с импедансом (терминаторы) 120 Ом (допускается колебание импеданса в пределах от 108 Ом до 132 Ом.

Максимальная скорость сети CAN в соответствие с протоколом равна 1 Mbit/s. При скорости в 1 Mbit/sec максимальная длина кабеля равна примерно 40 метрам. Ограничение на длину кабеля связано с конечной скоростью распространения сигнала и механизмом побитового арбитража (во время арбитража все узлы сети должны получать текущий бит передачи одновременно, те сигнал должен успеть распространится по всему кабелю за единичный отсчет времени в сети.

Соотношение между скоростью передачи и максимальной длиной кабеля приведено в таблице: скорость передачи максимальная длина сети 1000 Кбит/сек 40 метров 500 Кбит/сек 100 метров 250 Кбит/сек 200 метров 125 Кбит/сек 500 метров 10 Кбит/сек 6 километров.

Разъемы для сети CAN до сих пор НЕ СТАНДАРТИЗОВАНЫ. Каждый протокол высокого уровня обычно определяет свой тип разъемов для CAN-сети.

Логический ноль регистрируется, когда на линии CAN_H сигнал выше, чем на линии CAN_L.
Логическая единица — в случае когда сигналы CAN_HI и CAN_LO одинаковы (отличаются менее чем на 0.5 В).
Использование такой дифференциальной схемы передачи делает возможным работу CAN сети в очень сложных внешних условиях.
Логический ноль — называется доминантным битом, а логическая единица — рецессивным. Эти названия отражают приоритет логической единицы и нуля на шине CAN.

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

Арбитраж шины CAN.

Быстродействие CAN сети (до 1 Mbit/s) достигается благодаря механизму недеструктивного арбитража шины посредством сравнения бит конкурирующих сообщений. Т.е. если случится так что одновременно начнут передачу несколько контроллеров, то каждый из них сравнивает бит, который собирается передать на шину с битом, который пытается передать на шину конкурирующий контроллер. Если значения этих битов равны оба контроллера пытаются передать следующий бит. И так происходит до тех пор пока значения передаваемых битов не окажутся различными. Теперь контроллер, который передавал логический ноль (более приоритетный сигнал) будет продолжать передачу, а другой(другие) контроллер прервёт свою передачу до того времени пока шина вновь не освободится. Конечно,если шина в данный момент занята,то контроллер не начнет передачу до момента её освобождения.

Эта спецификация CAN исходит из предположения, что все CAN контроллеры принимают сигналы с шины одновременно. Т.е. в одно и то же время один и тот же бит принимается всеми контроллерами в сети. С одной стороны такое положение вещей делает возможным побитовый арбитраж, а с другой стороны ограничивает длину CAN bus. Сигнал распространяется по CAN bus с огромной, но конечной, скоростью и для правильной работы CAN нужно, чтобы все контроллеры «услышали» его почти одновременно. Почти, потому что каждый контроллер принимает бит в течении определённого промежутка времени, отсчитываемого системным часам. Таким образом, чем выше скорость передачи данных, тем меньшая длинна CAN bus возможна.

Структура формата передачи данных.

Данные по CAN сети пересылаются в виде отдельных кадров стандартного формата. Наиболее важными полями являются поле идентификатора (identifier) и собственно данные (data).

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

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

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

Форматы кадра.

Данные в CAN передаются короткими сообщениями-кадрами стандартного формата. В CAN существуют четыре типа сообщений:

• Data Frame
• Remote Frame
• Error Frame
• Overload Frame

Data Frame — это наиболее часто используемый тип сообщения. Он состоит из следующих основных частей: поле арбитража (arbitration field) определяет приоритет сообщения в случае, когда два или более узлов одновременно пытаются передать данные в сеть.

Поле арбитража состоит в свою очередь из:

• для стандарта CAN-2.0A, 11-битного идентификатора + 1 бит RTR (retransmit)
• для стандарта CAN-2.0B, 29-битного идентификатора + 1 бит RTR (retransmit)

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

Для Data кадра бит RTR всегда выставлен в логический ноль (доминантный сигнал). Поле данных (data field) содержит от 0 до 8 байт данных поле CRC (CRC field) содержит 15-битную контрольную сумму сообщения, которая используется для обнаружения ошибок слот подтверждения (Acknowledgement Slot) (1 бит), каждый CAN-контроллер, который правильно принял сообщение посылает бит подтверждения в сеть. Узел, который послал сообщение слушает этот бит, и в случае если подтверждение не пришло, повторяет передачу. В случае приема слота подтверждения передающий узел может быть уверен лишь в том, что хотя бы один из узлов в сети правльно принял его сообщение.

Remote Frame — это Data Frame без поля данных и с выставленным битом RTR (1 — рецессивные бит). Основное предназначение Remote кадра — это инициация одним из узлов сети передачи в сеть данных другим узлом. Такая схема позволяет уменьшить суммарный трафик сети. Однако, на практике Remote Frame сейчас используется редко (например, в DeviceNet Remote Frame вовсе не используется).

Error Frame — это сообщение которое явно нарушает формат сообщения CAN. Передача такого сообщения приводит к тому, что все узлы сети регистрируют ошибку формата CAN-кадра, и в свою очередь автоматически передают в сеть Error Frame. Результатом этого процесса является автоматическая повторная передача данных в сеть передающим узлом. Error Frame состоит из поля Error Flag, которое состоит из 6 бит одинакового значения (и таким образом Error frame нарушает проверку Bit Stuffing, см. ниже), и поля Error Delimiter, состоящее из 8 рецессивных битов. Error Delimiter дает возможность другим узлам сети обнаружив Error Frame послать в сеть свой Error Flag.

Overload Frame — повторяет структуру и логику работы Error кадра, с той разницей, что он используется перегруженным узлом, который в данный момент не может обработать поступающее сообщение, и поэтому просит при помощи Overload-кадра о повторной передаче данных. В настоящее время Overload-кадр практически не используется.

Мехнизм обработки ошибок.

Надежность CAN сети определяется также механизмами обнаружения ошибок. Стандарт CAN определяет следующие методы обнаружения ошибок в сети CAN:

• Check Bit monitoring
• Bit stuffing
• Frame check
• ACKnowledgementCheck
• Check CRC

Check Bit monitoring — каждый узел во время передачи битов в сеть сравнивает значение передаваемого им бита со значением бита которое появляется на шине. Если эти значения не совпадают, то узел генерирует ошибку Bit Error. Естественно, что во время арбитража на шине (передача поля арбитража в шину) этот механизм проверки ошибок отключается.

Bit stuffing — когда узел передает последовательно в шину 5 бит с одинаковым значением, то он добавляет шестой бит с противоположным значением. Принимающие узлы этот дополнительный бит удаляют. Если узел обнаруживает на шине больше 5 последовательных бит с одинаковым значением, то он генерирует ошибку Stuff Error.

Frame Check — некоторые части CAN-сообщения имеют одинаковое значение во всех типах сообщений. Т.е. протокол CAN точно определяет какие уровни напряжения и когда должны появляться на шине. Если формат сообщений нарушается, то узлы генерируют ошибку Form Error.

ACKnowledgement Check — каждый узел получив правильное сообщение по сети посылает в сеть доминантный (0) бит. Если же этого не происходит, то передающий узел регистрирует ошибку Acknowledgement Error.

CRC Check — каждое сообщение CAN содержит CRC сумму, и каждый принимающий узел подсчитывает значение CRC для каждого полученного сообщения. Если подсчитанное значение CRC суммы, не совпадает со значением CRC в теле сообщения, принимающий узел генерирует ошибку CRC Error.

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

Кроме того, каждый узел ведет два счетчика ошибок:

• Transmit Error Counter (счетчик ошибок передачи) и
• Receive Error Counter (счетчик ошибок приема).

Эти счетчики увеличиваются или уменьшаются в соответствие с несколькими правилами. Сами правила управления счетчиками ошибок достаточно сложны, но сводятся к простому принципу, ошибка передачи приводит к увеличению Transmit Error счетчика на 8, ошибка приема увеличивает счетчик Receive Error на 1, любая корректная передача/прием сообщения уменшают соответствующий счетчик на 1. Эти правила приводят к тому, что счетчик ошибок передачи передающего узла увеличивается быстрее, чем счетчик ошибок приема принимающих узлов. Это правило соответствует предположению о большой вероятности того, что источником ошибок является передающий узел.

Каждый узел CAN сети может находится в одном из трех состояний. Когда узел стартует он находится в состоянии Error Active. Когда, значение хотя бы одного из двух счетчиков ошибок превышает предел 127, узел переходит в состояние Error Passive. Когда значение хотя бы одного из двух счетчиков превышает предел 255, узел переходит в состояние Bus Off.

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

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

Узел в состоянии Bus Off ничего не передает в сеть (не только Error кадры, но вообще никакие другие).

Адресация и протоколы высокого уровня

Однако сетевых сервисов спецификации Robert Bosch CAN Specification 2.0A/B и международного стандарта ISO 11898 зачастую явно недостаточно для эффективной разработки CAN-сетей. Дело в том, что упомянутые документы описывают лишь два самых нижних уровня эталонной (семиуровневой) модели взаимосвязи открытых систем OSI/ISO физический и канальный. Определены форматы сообщений, процессы передачи данных длиной до 8 байт, механизмы обнаружения ошибок, некоторые физические параметры среды передачи данных (только в ISO 11898) и др.
Но «за кадром» остаются такие важные на этапе разработки моменты, как адресация узлов, распределение между ними CAN-идентификаторов, интерпретация содержимого фрейма данных, передача данных длиной более 8 байт и др.

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

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

Точно также протокол не запрещает использовать поле арбитража для передачи данных.

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

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

Утилизация поля арбитража и поля данных, и распределение адресов узлов, идентификаторов сообщений и приоритетов в сети является предметом рассмотрений так называемых протоколов высокого уровня (HLP — Higher Layer Protocols).

Название HLP отражает тот факт, что протокол CAN описывает только два нижних уровня эталонной сетевой модели ISO/OSI, а остальные уровни описываются протоколами HLP.

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

• CAL/ CANopen,
• CAN Kingdom,
• DeviceNet и

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

Сетевые CAN приложения, основанные на прикладном уровне CAL, в настоящее время успешно работают в медицинской электронике, системах контроля дорожного движения, на транспорте, в промышленном оборудовании. Результатом дополнения CAL (точнее, некоторого его подмножества) системой профилей (устройств, интерфейсов, приложений и т. д.) и спецификациями физического уровня (типы соединителей, правила битового квантования и т. д.) явилось появление более «конкретного» стандарта протокола CANopen. По существу CANopen является приложением прикладного уровня CAL. Первоначально CANopen предназначался для сетей управления движущимися механизмами в системах промышленной автоматики.
Однако впоследствии протокол нашел применение в медицине, морской электронике, на транспорте и в системах автоматизации зданий. CANopen базируется на двух уровнях стандарта CAN (ISO 11898, Bosch CAN Specification 2.0 A/B). В дополнение к спецификациям физического уровня ISO 11898 (среда передачи данных двухпроводная дифференциальная линия), CANopen содержит собственные правила битового квантования, а также определяет три рекомендуемых типа соединителей. Разводкой контактов для всех типов соединителей предусмотрена возможность подачи питания на трансиверы узлов, имеющих гальваническую развязку. В сети CANopen определены восемь градаций скоростей передачи данных: 1 Мбит/с, 800 кбит/с, 500, 250, 125, 50, 20 и 10 кбит/с. Поддержка скорости 20 кбит/с является обязательной для всех модулей.

CAN Kingdom

Протокол шведской компании KVASER-AB (www.kvaser.se) занимает особое место среди CAN HLP благодаря оригинальной концепции сетевого взаимодействия и эффективности CAN-приложений на его основе.

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

CAN Kingdom является также основой американского военного стандарта CDA 101 и широко используется в военной технике от надувных лодок и систем наведения на цели до сверхзвуковых истребителей и ракет. Основной целью создания протокола было предоставление системному разработчику максимальной свободы в реализации своих идей при построении сети, сохранив при этом возможность использования стандартных модулей от независимых производителей. CAN Kingdom не является «готовым» протоколом в том смысле, в каком это справедливо, например, по отношению к стандартам типа CANopen или DeviceNet. Это скорее набор примитивов метапротокол, с помощью которых можно «собрать» протокол под конкретную сеть модулей. Этим достигается уникальное сочетание простоты интеграции готовых модулей с высокой степенью «закрытости» оригинального протокола. Краеугольным камнем концепции сетевого взаимодействия CAN Kingdom является принцип: «Модули обслуживают сеть» (MSN Modules Serves the Network) в отличие от принципа «Сеть обслуживает пользователей» (NSM Network Serves the Modules), свойственного компьютерным сетям.

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

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 кбит/с.

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

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

Максимальное число узлов в сети DeviceNet 64.

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, предусмотрено подведение питающего напряжения к узлам.

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

Шина CAN – Введение

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

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

Протокол CAN

Протокол CAN описан в стандарте ISO 11898–1 и может быть кратко охарактеризован следующим образом:

Физический уровень использует дифференциальную передачу данных по витой паре;

Для управления доступом к шине используется неразрушающее bit–wise разрешение конфликтов;

Сообщения имеют малые размеры (по большей части 8 байт данных) и защищены контрольной суммой;

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

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

Протоколы более высоких уровней

Сам по себе протокол CAN определяет всего лишь, как малые пакеты данных можно безопасно переместить из точки A в точку B посредством коммуникационной среды. Он, как и следовало ожидать, ничего не говорит о том, как управлять потоком; передавать большое количество данных, нежели помещается в 8–байтное сообщение; ни об адресах узлов; установлении соединения и т.п. Эти пункты определяются протоколом более высокого уровня (Higher Layer Protocol, HLP). Термин HLP происходит из модели OSI и её семи уровней.

Протоколы более высокого уровня используются для:

Стандартизации процедуры запуска, включая выбор скорости передачи данных;

Распределения адресов среди взаимодействующих узлов или типов сообщений;

Определения разметки сообщений;
обеспечения порядка обработки ошибок на уровне системы.

Пользовательские группы и т.п.

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

Продукты CAN

На низком уровне принципиально различают два типа продуктов CAN, доступных на открытом рынке – микросхемы CAN и инструменты разработки CAN. На более высоком уровне – другие два типа продуктов: модули CAN и инструменты проектирования CAN. Широкий спектр данных продуктов доступен на открытом рынке в настоящее время.

Патенты в области CAN

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

Системы распределённого управления

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

Систему распределённого управления можно описать как систему, вычислительная мощность которой распределена между всеми узлами системы. Противоположный вариант – система с центральным процессором и локальными точками ввода–вывода.

Сообщения CAN

Шина CAN относится к широковещательным шинам. Это означает, что все узлы могут «слушать» все передачи. Не существует возможности послать сообщение конкретному узлу, все без исключения узлы будут принимать все сообщения. Оборудование CAN, однако, обеспечивает возможность локальной фильтрации, так что каждый модуль может реагировать только на интересующее его сообщение.

Адресация сообщений CAN

CAN использует относительно короткие сообщения – максимальная длина информационного поля составляет 94 бита. В сообщениях отсутствует явный адрес, их можно назвать контентно–адрессованными: содержимое сообщения имплицитно (неявным образом) определяет адресата.

Типы сообщений

Существует 4 типа сообщений (или кадров), передающихся по шине CAN:

Кадр данных (Data Frame);

Удаленный кадр (Remote Frame);

Кадр ошибки (Error Frame);

Кадр перегрузки (Overload Frame).

Кадр данных

Кратко: «Всем привет, есть данные с маркировкой X, надеюсь вам понравятся!»
Кадр данных – самый распространенный тип сообщения. Он содержит в себе следующие основные части (некоторые детали не рассматриваются для краткости):

Поле арбитража (Arbitration Field), которое определяет очередность сообщения в том случае, когда за шину борятся два или более узла. Поле арбитража содержит:

В случае CAN 2.0A, 11–битный идентификатор и один бит, бит RTR который является определяющим для кадров данных.

В случае CAN 2.0B, 29–битный идентификатор (который также содержит два рецессивных бита: SRR и IDE) и бит RTR.

Поле данных (Data Field), которое содержит от 0 до 8 байт данных.

Поле CRC (CRC Field), содержащее 15–битную контрольную сумму, посчитанную для большинства частей сообщения. Эта контрольная сумма используется для обнаружения ошибок.

Слот распознавания (Acknowledgement Slot). Каждый контроллер CAN, способный корректно получить сообщение, посылает бит распознавания (Acknowledgement bit) в конце каждого сообщения. Приемопередатчик проверяет наличие бита распознавания и, если таковой не обнаруживается, высылает сообщение повторно.

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

Примечание 2: Идентификатор в поле арбитража, несмотря на свое название, необязательно идентифицирует содержимое сообщения.

Кадр данных CAN 2.0B («cтандартный CAN»).

Кадр данных CAN 2.0B («расширенный CAN»).

Удаленный кадр

Кратко: «Всем привет, кто–нибудь может произвести данные с маркировкой X?»
Удаленный кадр очень похож на кадр данных, но с двумя важными отличиями:

Он явно помечен как удаленный кадр (бит RTR в поле арбитража является рецессивным), и

Отсутствует поле данных.

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

Удаленные кадры можно использовать для реализации управления трафиком шины типа «запрос–ответ». На практике, однако, удаленный кадр используется мало. Это не так важно, поскольку стандарт CAN не предписывает действовать именно так, как здесь обозначено. Большинство контроллеров CAN можно запрограммировать так, что они будут автоматически отвечать на удаленный кадр, или же вместо этого извещать локальный процессор.

Есть одна уловка, связанная с удаленным кадром: код длины данных (Data Length Code) должен быть установлен длине ожидаемого ответного сообщения. В противном случае разрешение конфликтов работать не будет.

Иногда требуется чтобы узел, отвечающий на удаленный кадр, начинал свою передачу как только распознавал идентификатор, таким образом «заполняя» пустой удаленный кадр. Это другой случай.

Кадр ошибки (Error Frame)

Кратко (все вместе, громко): «О, ДОРОГОЙ, ДАВАЙ ПОПРОБУЕМ ЕЩЁ РАЗОК»
Кадр ошибки (Error Frame) – это специальное сообщение, нарушающее правила формирования кадров сообщения CAN. Он посылается, когда узел обнаруживает сбой и помогает остальным узлам обнаружить сбой – и они тоже будут отправлять кадры ошибок. Передатчик автоматически попробует послать сообщение повторно. Наличествует продуманная схема счетчиков ошибок, гарантирующая, что узел не сможет нарушить передачу данных по шине путём повторяющейся отсылки кадров ошибки.

Кадр ошибки содержит флаг ошибки (Error Flag), который состоит из 6 бит одинакового значения (таким образом нарушая правило вставки битов) и разграничителя ошибки (Error Delimiter), состоящего из 8 рецессивных бит. Разраничитель ошибки предоставляет некоторое пространство, в котором другие узлы шины могут отправлять свои флаги ошибки после того, как сами обнаружат первый флаг ошибки.

Кадр перегрузки (Overload Frame)

Кратко: «Я очень занятой 82526 маленький, не могли бы вы подождать минуточку?»
Кадр перегрузки упоминается здесь лишь для полноты картины. По формату он очень похож на кадр ошибки и передается занятым узлом. Кадр перегрузки используется нечасто, т.к. современные контроллеры CAN достаточно производительны, чтобы его не использовать. Фактически, единственный контроллер, который будет генерировать кадры перегрузки – это ныне устаревший 82526.

Стандартный и расширенный CAN

Изначально стандарт CAN установил длину идентификатора в поле арбитража равной 11 битам. Позже, по требованию покупателей стандарт был расширен. Новый формат часто называют расширенным CAN (Extended CAN), он позволяет использовать не менее 29 бит в идентификаторе. Для различения двух типов кадров используется зарезервированный бит в поле управления Control Field.

Формально стандарты именуются следующим образом –

2.0A – только с 11–битными идентификаторами;
2.0B – расширенная версия с 29–битными или 11–битными идентификаторами (их можно смешивать). Узел 2.0B может быть

2.0B active (активным), т.е. способным передавать и получать расширенные кадры, или

2.0B passive (пассивным), т.е. он будет молча сбрасывать полученные расширенные кадры (но, смотрите ниже).

1.x – относится к оргинальной спецификации и её ревизиям.

В настоящее время новые контроллеры CAN обычно относятся к типу 2.0B. Контроллер типа 1.x или 2.0A прибудет в замешательство, получив сообщения с 29 битами арбитража. Контроллер 2.0B пассивного типа примет их, опознает, если они верны и, затем – сбросит; a контроллер 2.0B активного типа сможет и передавать, и получать такие сообщения.

Контроллеры 2.0B и 2.0A (равно, как и 1.x) совместимы. Можно использовать их все на одной шине до тех пор, пока контроллеры 2.0B будут воздерживаться от рассылки расширенных кадров.

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

Основной CAN (Basic CAN) и полный CAN (Full CAN)

Термины Basic CAN и Full CAN берут начало в «детстве» CAN. Когда–то существовал CAN–контроллер Intel 82526, предоставлявший программисту интерфейс в стиле DPRAM. Потом появился Philips с моделью 82C200, в котором применялась FIFO–ориентированная модель программирования и ограниченные возможности фильтрации. Для обозначения различия между двумя моделями программирования, люди стали называть способ Intel – Full CAN, а способ Philips – Basic CAN. Сегодня большинство контроллеров CAN поддерживают обе модели программирования, поэтому нет смысла в использовании терминов Full CAN и Basic CAN – фактически, эти термины могут вызвать неразбериху и стоит воздержаться от их употребления.

В действительности, контроллер Full CAN может взаимодействовать с контроллером Basic CAN и наоборот. Проблемы с совместимостью отсутствуют.

Разрешение конфликтов на шине и приоритет сообщения

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

Любой контроллер CAN может начать передачу, когда обнаружит, что шина простаивает. Это может привести к тому, что два или более контроллеров начнут передачу сообщения (почти) одновременно. Конфликт решается следующим образом. Передающие узлы осуществляют мониторинг шины в процессе отправки сообщения. Если узел обнаруживает доминантный уровень в то время, как сам он отправляет рецессивный уровень, он незамедлительно устранится от процесса разрешения конфликта и станет приемником. Разрешение конфликтов осуществляется по всему полю арбитража, и после того, как это поле отсылается, на шине остается только один передатчик. Данный узел продолжит передачу, если ничего не случится. Остальные потенциальные передатчики попытаются передать свои сообщения позже, когда шина освободится. В процессе разрешения конфликта время не теряется.

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

Поскольку, CAN–шина является шиной с подсоединением устройств по типу «монтажное И» (wired–AND) и доминантный бит (Dominant bit) является логическим 0, следовательно сообщение с самым низким в численном выражении полем арбитража выиграет в разрешении конфликта.

Вопрос: Что произойдет в случае, если единственный узел шины попытается отослать сообщение?

Ответ: Узел, разумеется, выиграет в разрешении конфликта и успешно проведет передачу сообщения. Но когда наступит время распознавания… ни один узел не отправит доминантный бит области распознавания, поэтому передатчик определит ошибку распознавания, пошлет флаг ошибки, повысит значение своего счетчика ошибок передачи на 8 и начнет повторную передачу. Этот цикл повторится 16 раз, затем передатчик перейдет в статус пассивной ошибки. В соответствии со специальным правилом в алгоритме ограничения ошибок, значение счетчика ошибок передачи не будет более повышаться, если узел имеет статус пассивной ошибки и ошибка является ошибкой распознавания. Поэтому узел будет осуществлять передачу вечно, до тех пор, пока кто–нибудь не распознает сообщение.

Адресация и идентификация сообщения

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

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

Определённый адрес работает так: «Это сообщение для узла X». Контентно–адресованное сообщение можно описать так: «Это сообщение содержит данные с маркировкой X». Разница между этими двумя концепциями мала, но существенна.

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

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

Примечание о значениях идентификатора

Мы говорили, что идентификатору доступны 11 (CAN 2.0A) или 29 (CAN 2.0B) бит. Это не совсем верно. Для совместимости с определенным старым контроллером CAN (угадайте каким?), идентификаторы не должны иметь 7 старших бит установленных в логическую единицу, поэтому 11–битным идентификаторам доступны значения 0..2031, а пользователи 29–битных идентификаторов могут использовать 532676608 различных значений.

Заметьте, что все остальные контроллеры CAN принимают «неправильные» идентификаторы, поэтому в современных системах CAN идентификаторы 2032..2047 могут использоваться без ограничений.

Физические уровни CAN

Шина CAN использует код без возвращения к нулю (NRZ) с вставкой битов. Существуют два разных состояния сигнала: доминантное (логический 0) и рецессивное (логическая 1). Они соответствуют определенным электрическим уровням, зависящим от используемого физического уровня (их несколько). Модули подключены к шине по схеме «монтажное И» (wired–AND): если хотя бы один узел переводит шину в доминантное состояние, то вся шина находится в этом состоянии, вне зависмости от того, сколько узлов передают рецессивное состояние.

Различные физические уровни

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

Существует несколько различных версий физических уровней: Наиболее распространенным является вариант, определенный стандартом CAN, часть ISO 11898–2, и представляющий собой двухпроводную сбалансированную сигнальную схему. Он также иногда называется high–speed CAN.

Другая часть того же стандарта ISO 11898–3 описывает другую двухпроводную сбалансированную сигнальную схему – для менее скоростной шины. Она устойчива к сбоям, поэтому передача сигналов может продолжаться даже в том случае, когда один из проводов будет перерезан, замкнут на «землю» или в состоянии Vbat. Иногда такая схема называется low–speed CAN.

SAE J2411 описывает однопроводной (плюс «земля», разумеется) физический уровень. Он используется в основном в автомобилях – например GM–LAN.

Существуют несколько проприетарных физических уровней.

В былые времена, когда драйверов CAN не существовало, использовались модификации RS485.

Различные физические уровни как правило не могут взаимодействовать между собой. Некоторые комбинации могут работать (или будет казаться, что они работают) в хороших условиях. Например, приемопередатчики high–speed и low–speed могут работать на одной шине лишь иногда.

Абсолютное большинство микросхем приемопередатчиков CAN произведено компанией Philips; в число других производителей входят Bosch, Infineon, Siliconix и Unitrode.

Наиболее распространен приемопередатчик 82C250, в котором реализован физический уровень, описываемый стандартом ISO 11898. Усовершенствованная версия – 82C251.

Распространенный приемопередатчик для «low–speed CAN» – Philips TJA1054.

Максимальная скорость передачи данных по шине

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

Low–speed CAN (ISO 11898–3, см. выше) работает на скоростях до 125 кбит/с.

Однопроводная шина CAN в стандартном режиме может передавать данные со скоростью порядка 50 кбит/с, а в специальном высокоскоростном режиме, например для программирования ЭБУ (ECU), около 100 кбит/с.

Минимальная скорость передачи данных по шине

Имейте в виду, что некоторые приемопередатчики не позволят вам выбрать скорость ниже определенного значения. Например, при использовании 82C250 или 82C251 вы можете без проблем установить скорость 10 кбит/с, но если вы используете TJA1050, то не сможете установить скорость ниже 50 кбит/с. Сверяйтесь со спецификацией.

Максимальная длина кабеля

При скорости передачи данных 1 Мбит/с, максимальная длина используемого кабеля может составлять порядка 40 метров. Это связано с требованием схемы разрешения конфликтов, согласно которому фронт волны сигнала должен иметь возможность дойти до самого дальнего узла и вернуться назад прежде чем бит будет считан. Иными словами, длина кабеля ограничена скоростью света. Предложения по увеличению скорости света рассматривались, но были отвергнуты в связи с межгалактическими проблемами.

Другие максимальные длины кабеля (значения приблизительные):

100 метров при 500 кбит/с;

200 метров при 250 кбит/с;

500 метров при 125 кбит/с;
6 километров при 10 кбит/с.

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

Оконечное прерывание шины

Шина CAN стандарта ISO 11898 должна заканчиваться терминатором. Это достигается путем установки резистора сопротивлением 120 Ом на каждом конце шины. Терминирование служит двум целям:

1. Убрать отражения сигнала на конце шины.

2. Убедиться, что получает корректные уровни постоянного тока (DC).

Шина CAN стандарта ISO 11898 обязательно должна терминироваться вне зависимости от её скорости. Я повторю: шина CAN стандарта ISO 11898 обязательно должна терминироваться вне зависимости от её скорости. Для лабораторной работы может хватить и одного терминатора. Если ваша шина CAN работает даже при отсутствии терминаторов – вы просто счастливчик.

Заметьте, что другие физические уровни , такие как low–speed CAN, однопроводная шина CAN и другие, могут требовать, а могут и не требовать наличия оконечного терминатора шины. Но ваша высокоскоростная шина CAN стандарта ISO 11898 всегда будет требовать наличия хотя бы одного терминатора.

Стандарт ISO 11898 предписывает, что волновое сопротивление кабеля номинально должно равнятся 120 Ом, однако допускается интервал значений сопротивления Ом.

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

ISO 11898 описывает витую пару, экранированную или неэкранированную. Идёт работа над стандартом однопроводного кабеля SAE J2411.

Валюта магазина рубли у.е.

CAN шина. Часть 1.

1. Локальная сеть контроллеров (CAN)

Области применения.

Электронные распределители, Автомобили, Морские суда, Гидравлическое оборудование, Текстильная Промышленность, Перерабатывающая промышленность, Медицинское оборудование, Железная дорога, Строительная автоматизация, Авиационная радиоэлектроника, Бытовые приборы, Вооруженные силы, Обработка материалов, Сельское хозяйство, Телекоммуникация, Грузовики, Строительные Машины и Транспортные средства, Индустриальная автоматизация.

Общие сведения

Локальная сеть контроллеров CAN это стандарт серийной шины, разработанный в 80-х годах Robert Bosch GmbH, для соединения электронных блоков управления. CAN был специально разработан для устойчивой работы в насыщенной помехами окружающей среде с применением разносторонне сбалансированной линии, такой как RS-485. Соединение может быть более устойчивым к помехам при использовании витой пары. Первоначально создавалась для автомобильного назначения, но в настоящее время используется в разнообразных системах управления, в т.ч. индустриальных, работающих в насыщенной помехами окружающей среде.
Скорость обмена данными до 1Mbit/s возможна в сетях протяженностью не более 40м. Снижение скорости обмена позволяет увеличить протяженность сети, например — 250 Kbit/s при 250м.
CAN протокол связи стандартизирован согласно ISO 11898-1 (2003). Этот стандарт главным образом описывает слой обмена данными состоящий из подраздела логического контроля (LLC) и подраздела контроля доступа (MAC), и некоторых аспектов физического слоя ISO/OSI модели. Остальные слои протокола оставлены на усмотрение разработчика сети.

CAN сети и их разновидности

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

Общая характеристика

Интегрированная серийная коммуникационная шина для приложений работающих в режиме реального времени.
. Сеть работоспособна при скорости обмена данными до 1Mbit/s.
. Обладает превосходными возможностями обнаружения и проверки ошибок и неисправностей.
. Изначально CAN шина разработана для применения в автомобилях
. Используется в различных автоматических системах и системах управления.
. Международный стандарт: ISO 11898

Определение CAN

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

Свойства CAN

CAN система на серийной шине с мультифункциональными возможностями, все CAN узлы способны передавать данные и некоторые CAN узлы могут запрашивать шину одновременно. Передатчик передает сообщение всем CAN узлам. Каждый узел, на основании полученного идентификатора, определяет, следует ли ему обрабатывать сообщение или нет. Идентификатор так же определяет приоритет, который имеет сообщение при доступе к шине. Простота определяет стоимость оборудования и затраты на обучение персонала. CAN микросхемы могут быть относительно просто запрограммированы. Вводные курсы, функциональные библиотеки, наборы для начинающих, различные интерфейсы, I/O модули и инструменты в широком разнообразии представлены в открытой продаже по доступным ценам. С 1989 года CAN микросхемы могут быть свободно и просто соединены с микроконтроллерами. В настоящее время в наличии около 50 CAN микросхем для микроконтроллеров более чем 15 производителей.
CAN применяется в большинстве Европейских легковых автомобилях, а так же решение производителей грузовиков и внедорожников в дальнейшем применять CAN, определили развитие более чем на 10 лет. В других областях применения, таких как, бытовая сфера и индустриальный сектор наблюдается рост продаж CAN оборудования, и будет продолжаться в будущем. К весне 1997 года уже насчитывалось более чем 50 миллионов установленных CAN узлов. Одна из выдающихся особенностей CAN протокола высокая надежность обмена данными. CAN контроллер регистрирует ошибки и обрабатывает их статистически для проведения соответствующих измерений, CAN узел, являющийся источником неисправности, в результате будет отстранен от соединения.
Каждое CAN сообщение может содержать от 0 до 8 бит пользовательской информации. Конечно, возможна передача более продолжительных данных с применением фрагментации. Максимальная специфицированная скорость обмена 1 Mbit/s. Это возможно при протяженности сети не более 40м. Для более длинной коммуникации скорость обмена должна быть снижена. Для дистанции до 500 м скорость 125Kbit/s, и для передачи более чем на 1 км допускается скорость 50 Kbit/s.

CAN приложения

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

Лицензия CAN

CAN протокол разработан Robert Bosch GmbH и защищен патентами.

Основные стандарты CAN

Далее перечислены некоторые международные CAN стандарты
. CAN стандарты:
o ISO 11898-1 — CAN протокол
o ISO 11898-2 — CAN высокоскоростная физическая структура
o ISO 11898-3 — CAN низкоскоростная физическая структура совместимая с ошибками
o ISO 11898-4 — CAN запуск
o ISO 11898-5 — Высокоскоростное низковольтное устройство (в разработке).
o ISO 11519-2 — заменен на 11898-3.
. ISO 14230 — «Keyword Protocol 2000» — диагностический протокол использующий серийную линию, не CAN
. ISO 15765 — Диагностический протокол по CAN bus — Keyword 2000 на CAN bus.
. J1939 — Основной CAN протокол для грузовиков и автобусов определенный SAE
. ISO 11783 — J1939 и дополнение для сельхоз машин
. ISO 11992 — определяет интерфейс тягачей и прицепов
. NMEA 2000 — Протокол основанный на J1939 для судов, определен NMEA.

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

Преимущества CAN:

— Доступность для потребителя.
CAN протокол успешно применяется на протяжении более 15 лет, с 1986 года. Существует богатый выбор CAN продуктов и устройств в открытой продаже.

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

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

— Превосходная способность обнаружения ошибок и сбоев и локализация неисправностей.
Способность обнаруживать ошибки и сбои является существенным преимуществом CAN протокола. Механизм определения ошибок построен на экстенсивном принципе, так же надежна и хорошо разработана система проверки и подтверждения ошибок и сбоев.
Система определения неисправностей и повторная передача данных выполняется автоматически на аппаратном уровне.

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

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

CAN протокол

CAN определен стандартом ISO 11898-1 и включает следующие основные сведения.
. На физическом уровне, сигнал передается, используя витую пару.
. Для контроля к доступу шины применяются правила арбитража.
. Блоки данных небольшие по размеру (в большинстве случаев 8 байт) и защищены чексуммой.
. Блоки данных не имеют адресации, вместо того каждый блок содержит числовое значение, которое определяет приоритет передачи по шине, так же может нести идентификатор содержания блока данных.
. сложная схема обработки ошибок, которая приводит к повторной передаче данных, которые должным образом не получены.
. Эффективные действия по изоляции неисправностей и отключение источника неисправности от шины.

Протоколы высшего порядка (HLP)

CAN протокол определяет безопасную передачу небольших пакетов данных из пункта А в пункт Б используя общую линию коммуникации. Протокол не содержит средств контроля потока, адресацию, не предоставляет передачу сообщений более чем 8 бит, не осуществляет установку соединения и т.д. Перечисленные свойства определяются HLP(Higher layer protocol) или Протокол Высшего Порядка. Условия HLP получены и состоят из семи порядков OSI модели.

Назначение HLP
. Стандартизация процедур запуска и установка скорости передачи
. Распределение адресации устройств и разновидности сообщений.
. Определение порядка сообщений
. обеспечивает механизм определения неисправностей системного уровня

CAN продукты

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

Патенты в области CAN

Патенты в отношении CAN приложений могут быть различных видов и направлений. Далее несколько видов:
. Синхронизация и реализация частоты передачи
. Передача больших блоков данных (CAN протокол использует фреймы длинной не более 8 бит)
Системы контроля распределения
CAN протокол продуктивная база для создания систем контроля распределения. Метод арбитража обеспечивает возможность каждого CAN устройства взаимодействовать с сообщениями относительно этого устройства.
Система контроля распределения может быть заявлена как система, в которой возможности процессора распределены среди устройств системы, или же наоборот, как система с центральным процессором и локальными I/O устройствами.
При разработке CAN сети могут быть применены различные совместимые аппаратные устройства, обладающие необходимыми свойствами и удовлетворяющие заданным или расчетным параметрам сети такие как, частота процессора, скорость передачи данных и т.д.

Действующие протоколы высшего порядка (HLP)

CAN протокол определяет безопасную передачу небольших пакетов данных из пункта А в пункт Б используя общую линию коммуникации. Протокол не содержит средств контроля потока, адресацию, не предоставляет передачу сообщений более чем 8 бит, не осуществляет установку соединения и т.д. Перечисленные свойства определяются HLP, higher layer protocol (Протоколами Высшего Порядка). Условия HLP получены и состоят из семи порядков

OSI модели (Open Systems Interconnect Model)
CanKingdom
CANopen/CAL
DeviceNet
J1939
OSEK
SDS
HLP обычно определяет
. Параметры запуска
. Распределение идентификатора сообщения среди различных устройств в системе
. Интерпретация содержимого блоков данных
. Статус взаимодействия в системе

Характеристика SDS, DeviceNet and CAN Kingdom.

И различия между CAN Kingdom and CANopen. В настоящее время насчитывается более 50 HLP. Применение HLP обязательно, в противном случае придется изобрести свой, собственный HLP.

CanKingdom поддерживается организацией CanKingdom International полная спецификация доступна на сайте организации.
CanKingdom обычно упоминается как CAN (Controller Area Network) протокол высшего порядка. В реальности наиболее упорядоченный протокол. Модули в системе соединены сетью, в которой один из модулей является главным (King). Например: для организации plug & play системы, главный модуль определяет какое устройство и при каких обстоятельствах может быть добавлено, разрешено добавление только специфицированных устройств. CanKingdom обеспечивает простую уникальную идентификацию устройств в системе, для этого используется стандарт идентификации EAN/UPC, индивидуальный идентификатор устройства определяется серийным номером устройства.
CanKingdom предоставляет разработчику все потенциальные возможности CAN.
Дизайнер не ограничен мультимастер протоколом CSMA/AMP и может создавать виртуальные системы управления шинами всевозможных разновидностей и топологии. Предоставляет возможность создания общих модулей без учета обстоятельств таких как, зависимость от HLP и свойств системы. Дизайнер может определить использование только специфических модулей, совмещая тем самым ценности открытой системы с преимуществами системы с ограниченным и безопасным доступом.

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

CAL and CANopen

CAL сокращенно от «CAN Application Layer» Порядок или слой CAN приложений, протокол поддерживается CiA. CAL разделен на несколько составных частей:
. CMS (CAN-based Message Specification) определяет протоколы передачи данных между CAN устройствами
. NMT (Network Management Service) определяет протоколы запуска и выключения, определения неисправностей, и т.д.
. DBT (Distributor Service) определяет протокол распределения идентификаторов различных устройств в системе
— CAL протокол отличный от OSI модели (Open Systems Interconnect (OSI) Model)
— CANopen является подразделом CAL, и скомпонован как набор профилей, которые не завершены окончательно.
— CAL/CANopen один из HLP действующих протоколов, поддерживаемых CiA.
— CAL и CANopen спецификации в полном объеме доступны и поддеживаются CiA

Протокол развивается “Rockwell Automation nowadays”, определен организацией ODVA (Open DeviceNet Vendor Association). DeviceNet один из четырех протоколов, которые поддерживает CiA.

J 1939 высокоскоростная сетевая коммуникация класса С разработанная для поддержки функций управления в режиме реальногго времени между контроллерами, которые физически расположены в различных местах автомобиля.
Jl708/Jl587 предыдущий, широко распространенный тип сети класса B с возможность обмена простой информацией, включая диагностические данные, между контроллерами. J1939 обладает всеми свойствами J1708/J1587.
J1939 использует CAN протокол с позволяет любому устройству передавать сообщение по сети в момент когда шина не загружена. Каждое сообщение включат в себя идентификатор, который определяет приоритет сообщения, информацию об отправителе данных, об информации, заключенной в сообщении. Конфликты избегаются благодаря механизму арбитража, который активизируется с передачей идентификатора (используется безопасная схема арбитража). Это позволяет сообщениям с наивысшим приоритетом передаваться с наименьшими задержками, по причине равного доступа к шине любым из устройств сети.
J1939 организован из нескольких частей основанных на (Open Systems Interconnect (OSI) Model). OSI модель определяет семь коммуникационных порядков (слоев), каждый представляет различные функции. В то время как есть документ J1939, ассигнованный каждому слою, не все они явно определены в пределах J1939. Другие слои выполняют вторичные функции, описанные в другом месте. Физический Слой описывает электрический интерфейс коммуникаций (витая экранированная пара проводов, который может также быть упомянут как шина). Слой Канала связи описывает протокол или управляет структурой сообщения, получая доступ к шине, и обнаруживая ошибки передачи. Слой приложения определяет специфические данные, содержащиеся в каждом сообщении, посылаемом по сети.
Полный комплект спецификации можно приобрести в SAE, ниже приведен перечень документов
J1939 дополняется следующими документами:
J1939 Практические рекомендации по Контролю серийной передачи и коммуникационная сеть транспортного средства
J1939/11 Физический порядок (слой) — 250k bits/s, экранированная витая пара
J1939/13 Диагностические разъемы
J1939/21 Данные слоя связи
J1939/31 Слой сети
J1939/71 Слой приложений
J1939/73 Диагностика
J1939/81 Управление сетью

OSEK/VDX является совместным проектом в автомобильной индустрии. Создан как промышленный стандарт открытой оконечной архитектуры для распределенных контроллеров транспортных средств. Операционная система в режиме реального времени, интерфейсы программных средств и задачи управления сетью специфицированы совместно. OSEK» (Open systems and the corresponding interfaces for automotive electronics.) Открытые системы и информационные интерфейсы для автомобильной электроники. VDX “Whicule Distributed eXecutive» Распределенные исполнители транспортного средства.
Компании совместно участвующие в разработке: Opel, BMW, DaimlerChrysler, IIIT — University of Karlsruhe, PSA, Renault, Bosch, Siemens, Volkswagen.
Официальный сайт: www.osek-vdx.org

Smart Distributed System (SDS)

SDS система, на основе шины для интеллектуальных датчиков и исполнительных устройств, с упрощенным процессом установки, предоставляет широкие возможности управления вводом — выводом. Посредством одного четырехпроводного кабеля SDS система может быть оборудована до 126 приборами с индивидуальным адресом. Дополнительная информация и спецификация по SDS доступна на сайте разработчика Honeywell. SDS один из действующих четырех протоколов поддерживаемых CiA.

Сравнительная характеристика основных HLP протоколов
Общие сведения

DeviceNet, SDS и CAN Kingdom основаны на ISO 11898 CAN коммуникационном протоколе и функционируют согласно требований CAN спецификации. Каждый CAN модуль, следующий определенному протоколу может быть подключен к CAN шине следующей тому же протоколу. В любом случае при подключении модулей, которые действуют по различными протоколам, в большинстве случаев проблемы возникают по причине конфликта интерпретации сообщений на уровне приложений. CAN Kingdom отличается от SDS и DeviceNet основным принципом: CAN Kingdom организуется главным узлом коммуникации (“King”) при запуске, в отличии от SDS и DeviceNet. Такая организация позволяет упростить разработку комплекса систем реального времени и сокращает необходимое количество модулей координирующих спецификации, часто обозначаемые как профили.
SDS эффективен при подключении I/O устройств, различных выключателей и датчиков к PLC , фактически представляет собой соединение между основным модулем и удаленными I/O устройствами.
DeviceNet открытая система, в которой все модули имеют равные права по пользованию шиной, и порядок пользования шиной определяется небольшим набором инструкций. Разработчик модулей системы может передать полномочия по управлению коммуникацией другим модулям, например основному модулю в предопределенном режиме Главный/подчиненный, но DeviceNet не имеет возможности передать полномочия другим модулям. Характеристики SDS с использованием I/O устройств и DeviceNet в режиме Главный/подчиненный сходны.
Can Kingdom протокол ориентированный на системы продуцирования, соединения и контроля и не поддерживает профили для цифровых и аналоговых устройств. Основная особенность протокола заключается в том что модуль, подключенный к системе только ожидает инструкции от главного устройства. Все CAN приоритеты и идентификаторы принадлежат и предоставляются главным устройством. Во время запуска каждый модуль конфигурируется основным устройством, определяются приоритеты и идентификаторы объектов продуцирующих и потребляющих. Основное устройство является главным, но только в период конфигурирования системы. Главное устройство не может быть внедрено в период коммуникационной сессии между работающими приложениями различных модулей. Основное устройство может быть удалено после конфигурирования и проверки комплектности, при том каждый модуль запоминает полученные инструкции в памяти.

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

* Что такое CAN?

* Взаимосвязь открытых систем (Open System Interconnection (OSI))

* Controller Area Network (CAN)

* Основные принципы CAN

* Как выглядит CAN шина на примере автомобилей произведённых в Японии

Парк автомобилей на наших улицах стремительно омолаживается и вместе с этим приходится осваивать и решать новые задачи связанные с диагностикой и ремонтом. Всё чаще и чаще сталкиваешься в своей повседневной работе с проблемами коммуникации между различными бортовыми системами автомобиля. Если ещё несколько лет назад приезжающие на диагностику автомобили с ошибками по CAN шине (первый символ в классификации диагностического кода неисправности — U ) были редкими гостями, то сейчас это практически повседневная практика. Информация на эту тему в принципе доступна и её достаточно много, даже очень много — что с одной стороны хорошо, а с другой представляет собой определённую сложность в поиске необходимой информации. Этой статьёй хотелось бы в первую очередь дать общее представление о системе CAN ( ) тем, кто только начинает с ней знакомство, и тем, кто желает в этом поглубже разобраться.

Что такое CAN ?

Controller Area Network — это понятие вошло в обиход после того, как в начале 1980-х годов в Robert Bosch GmbH разработали стандарт промышленной сети, ориентированный прежде всего на объединение в единую сеть различных исполнительных устройств и датчиков. Одно их первых внедрений в автомобильной промышленности было осуществлено на нескольких моделях автомобилей Mercedes-Benz в 1992 году. До этого момента электронное управление исполнительными функциями строилось по системе — один блок управления принимал электронные сигналы с различных датчиков и после их обработки посылал соответствующие команды на исполнительные устройства (такие как бензонасос, форсунки, катушки зажигания и прочие. ). Увеличение объёма функций управления автомобилем, передаваемое электронике, привело к появлению таких дополнительных систем как ABS, SRS, AT, Immobilaser и других. Совмещение этих функций в одном ЭБУ привело бы к его громоздкости и чрезмерной сложности, а так же к потере надёжности, когда выход из строя одной системы мог бы привести к потере управляемости всего автомобиля. Поэтому автопроизводители пошли по пути разделения функций управления и выделения всех систем в отдельные блоки. А для того, чтобы увязать все системы в единое целое для решения общих задач управления автомобилем, на помощь пришёл коммуникационный стандарт CAN от Robert Bosch GmbH и это всё шире и шире стало применяться в автомобилестроении. На сегодняшний день практически каждый новый автомобиль оснащён этой системой.

Всё в принципе просто и понятно, но как устроена CAN шина и на чём основывается принцип её работы? Вот один из примеров взаимосвязи электронных блоков управления и устройств завязанных в единую бортовую коммуникационную сеть автомобиля,- рис. 1

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

Немного предыстории — Взаимосвязь открытых систем (Open System Interconnection (OSI)).

Это очевидно, что если два или более микропроцессора взаимосвязаны в одну систему, то должен использоваться стандартный протокол который определяет, каким образом данные должны быть переданы между сетевыми блоками. Наиболее распространенным примером такого протокола является TCP/IP ( Transmission Control Protocol / Internet Protocol ), который используется для подключения хостингов в сети Интернет. Предшественником TCP/IP был протокол — Open System Interconnection (OSI ). Этот протокол был разработан в 1982 году Международным бюро по стандартизации International Organization for Standardization (ISO 7498-1:1994 (E )). OSI протокол иногда называют как «семиуровневая» модель, поскольку он состоит из семи независимых элементов, которые определяют требования к взаимосвязи на различных уровнях взаимодействия.

Вот эти семь уровней:

1) Уровень приложений ( Application Layer ) — этот уровень определяет какие приложения (программы) имеют доступ к сети. Например — электронная почта, передача файлов, терминалы удалённого доступа и веб-браузеры.

2) Уровень представления данных ( Presentation Layer ) — этот уровень определяет такие моменты, как стандарты сжатия данных и их шифрования.

3) Уровень передачи данных ( Transport Layer ) — этот уровень обеспечивает стандарты передачи данных между адресатами, осуществляет контроль ошибок и безопасности.

4) Сетевой уровень ( Network Layer ) — этот уровень отвечает за вопросы маршрутизации сетевого трафика данных.

5) Уровень каналов связи ( Data Link Laye r ) — этот уровень обеспечивает синхронизацию передачи данных и контроль ошибок.

6) Уровень контроля за сеансами связи ( Session Layer ) — этот уровень обеспечивает стандартизацию начала и завершения сеансов связи между различными приложениями и сетевыми блоками.

7) Физический уровень ( Physical Layer ) — этот уровень определяет стандарты физических характеристик устройств в сети, в том числе типы соединений и разъёмов, электрические характеристики кабелей, уровня напряжения, силы тока и тд.

Но задачи, решаемые протоколом OSI не в полной мере отвечали нуждам автомобильной электроники, и как следствие этого, инженерами Robert Bosch GmbH был разработан, в развитие протокола OSI , специальный протокол CAN , который определял стандарты физического и канального уровней модели OSI в кремнии для осуществления последовательной передачи информации между двумя или более устройствами.

Controller Area Network (CAN)

CAN был разработан Robert Bosch GmbH для автомобильной промышленности в начале 1980-х годов и официально публично выпущен в пользование в 1986 году. Эта разработка CAN от Bosch была принята в качестве стандарта ISO (ISO 11898 ), в 1993 переименована в CAN 2.0A , и расширена в 1995 году, чтобы позволить идентифицировать большее количество сетевых устройств в CAN 2.0B . Как правило, CAN шина соединяет в сеть модули (или узлы), используя два провода, витая пара. Многие компании и не только автомобильные, внедряют CAN протокол в свои разработки для взаимосвязи различных электронно-управляемых устройств. В неофициальной классификации устройства связанные протоколом CAN и имеющие процессоры серии MPC 5xx , называются TouCAN модули; имеющие процессоры серии MPC 55xx называются FlexCAN модули. CAN — последовательный, мульти-отправляющий, многоадресный протокол, это означает, что, когда шина свободна, любой узел, может отправить сообщение (мульти-отправляющее устройство), и все узлы могут получить и отреагировать на сообщение (многоадресно передано). Узел, который инициирует сообщение, называют передатчиком, любой узел не отправляющий сообщение называют получателем. Всем сообщениям присвоены статические приоритеты, передающий узел остаётся передатчиком до тех пор пока шина не станет неактивной или пока в сети не появилось сообщение от другого узла с более высоким приоритетом, процесс который определяет приоритет сообщений и называется — арбитраж. Сообщение по CAN шине может содержать до 8 байтов данных. Идентификатор сообщения описывает контент данных и используется получающими узлами для определения места назначения в сети (другими словами — адресата, узел которому это сообщение адресовано). В коротких сетях (≤ 40 м), скорость передачи сообщений может достигать до 1 Мбит/с. Более длинные сетевые расстояния уменьшают доступную скорость передачи, например до 125 Кбит/с в сети длиной до 500м. Высокоскоростной CAN ( “ High speed” CAN ) сетью, считается сеть со скоростью передачи данных более 500 Кбит/с.

Основные принципы CAN

Детали спецификации CAN протокола полностью описаны в Robert Bosch GmbH , “ CAN Specification 2.0,” 1991 . Ознакомиться с документом в формате PDF можно последующему адресу http://esd.cs.ucr.edu/webres/can20.pdf . Далее я дам максимально возможно краткое описание того как данные передаются по CAN, как структурированы сообщения CAN и как обрабатываются ошибки передачи сообщений.

Есть четыре типа сообщений CAN , или фреймы (frames ): фрейм данных (Data Frame ), удаленный фрейм ( Remote Frame ), ошибочный фрейм ( Error Frame ) и фрейм перегрузки ( Overload Frame ).

Data Frame — стандартное сообщение CAN, широковещательно передаваемые данные от передатчика на другие узлы сети.

Remote Frame -широковещательно передаваемое передатчиком сообщение, на запрос данных от конкретного узла сети.

Error Frame -может быть передан любым узлом, который обнаруживает ошибку в сети.

Overload Frame -используются как запрос на предоставление дополнительной паузы между получаемыми данными ( Data Frame ) или запросами на получение данных ( Remote Frame ).

Ниже проиллюстрированы различия между Data Frames для стандартов CAN 2.0A и CAN 2.0B,- рис. 2

Различие между форматами CAN 2.0 А и CAN 2.0B заключаются в том что фрейм данных для CAN 2.0B поддерживает как стандартный идентификатор фрейма данных — 11 бит, так и расширенный идентификатор фрейма данных — о 29 бит. Фреймы стандартного и расширенного формата могут без проблем передаваться по одной на той же шине, и даже иметь в цифровой форме эквивалентный идентификатор.

В этом случае у стандартного фрейма будет более высокий приоритет,- рис. 3

Описание фрейма сообщения стандарта CAN 2.0А

Начало сообщения ( Start of Frame (SOF)

Идентификатор (Identifier ) — 11 бит, уникальный идентификатор, указывает приоритет.

Удаленный запрос на передачу ( ) — 1 бит, доминантный в сообщении и рецессивный в запросе на передачу сообщения.

Резерв (Reserved ) — 2 бита, должны быть доминантными.

Длина кода данных ( Data Length Code (DLC)

Поле передаваемых данных ( Data Field DLC .

Cyclic Redundancy Check (CRC) ) — 15 бит.

Разделитель CRC

Подтверждение (Acknowledge (ACK)

Разделитель ACK — 1 бит, должен быть рецессивным.

Завершение сообщения ( End of Frame (EOF) ) — 7 бит, должны быть рецессивными,- рис. 4

Описание фрейма сообщения стандарта CAN 2.0В

Начало сообщения ( Start of Frame (SOF) ) — 1 бит, должен быть доминантным.

Идентификатор стандартного и расширенного форматов ( Identifier ) — 11 бит, уникальный идентификатор, соответствует базовому ID в расширенном формате.

Идентификатор расширенного формата ( Identifier – Extended Format ) — 29 бит, состоит из 11 бит базового ID и 18 бит расширенного ID .

Удаленный запрос на передачу ( Remote Transmission Request (RTR) ) стандартный и расширенный форматы — 1 бит, доминантный в сообщении и рецессивный в запросе на передачу сообщения. В стандартном формате 11 бит идентификатора следуют за битом RTR .

Замещение удалённого запроса ( Substitute Remote Request ( SRR ) ). Для расширенного формата — 1 бит, должен быть рецессивный. SRR передаются в расширенных форматах сообщений на позиции бита RTR в стандартном сообщении. В арбитраже между стандартными и расширенными сообщениями, рецессивные SRR обеспечивает приоритет стандартным сообщениям.

Поле IDE – для стандартного и расширенного форматов — 1 бит, должен быть рецессивным для расширенного формата и доминантным для стандартного.

Резерв (Reserved r0 ) для стандартного формата — 1 бит, должен быть доминантным.

Резерв (Reserved r1, r0 ) для расширенного формата — 2 бита, должны быть рецессивными.

Длина кода данных ( Data Length Code (DLC ) ) — 4 бита, количество байтов данных (0-8).

Поле передаваемых данных ( Data Field ) — от 0 до 8 байт, размер определен в поле DLC .

Контрольный циклический избыточный код ( Cyclic Redundancy Check (CRC ) ) — 15 бит.

Разделитель CRC — 1 бит, должен быть рецессивный.

Подтверждение (Acknowledge (ACK ) ) — 1 бит, передатчик отправляет рецессивный; получатель подтверждает доминантным.

Разделитель ACK — 1 бит, должен быть рецессивным.

Завершение сообщения ( End of Frame (EOF ) ) — 7 бит, должны быть рецессивными.

Фрейм данных CAN

Фрейм данных CAN состоит из семи полей: Начало фрейма ( SOF ), арбитраж, управление, данные, цикличные, проверка по избыточности (CRC) , подтверждение (ACK ) и конец фрейма (EOF ). Биты сообщения CAN обозначены как «доминирующие» (0) или «рецессивные» (1). Поле SOF состоит из одного доминирующего бита. Все сетевые узлы синхронно ожидают команды разрешения на передачу сообщений и начинают передавать одновременно. Арбитражная схема определяет, какой из узлов, пытающихся передавать сообщения имеет главный приоритет и фактически будет управлять шиной.

А рбитраж (Arbitration)

Арбитражное поле сообщения CAN состоит из 11-или 29-разрядного идентификатора и бита удаленной передачи ( RTR ). Арбитражную схему CAN называют “ носителем контроля с множественным доступом и обнаружением коллизий ” или CSMA/CD , которая гарантирует, что самое важное сообщение с наивысшим приоритетом будет передано по всей сети в первую очередь . Приоритет сообщения определен численным значением идентификатора в арбитражном поле, поле с самым низким численным значением имеет самый высокий приоритет. Неразрушающий, интеллектуальный арбитраж разрешает конфликты среди конкурирующих передатчиков. Это означает, что шина может считаться действующей как логический элемент И ( AND gate ). Если какой-либо узел пишет по сети доминантный признак (0), то каждый узел читает доминирующий бит независимо от его назначения, заданного передающим узлом. Каждый передающий узел всегда читает ответ на каждый переданный бит. Если узел передает рецессивный бит запроса на отправку сообщения и получает доминирующий бит для прочтения сообщения, он сразу же прекращает передавать.

Ниже проиллюстрирован приоритет сетевого арбитража где третий узел имеет высший приоритет и первый низший,- рис. 5

Бит RTR включён для того чтобы различать сообщения для передачи и удаленные запросы на приём сообщений. В стандартных сообщениях для передачи ( Data Frame ) бит RTR должен быть доминантным, а в удаленных запросах на приём сообщений ( Remote Frame ) должен быть быть рецессивным.

Контрольное поле и поле данных в сообщении (Control and Data Fields)

Поле управляющее длиной кода данных ( DLC ) состоит из 6 бит (из которых используются только 4 младших бита), они показывают количество данных в сообщении. Поскольку только до 8 байт данных может быть отправлено в одном сообщение, поле DLC может принимать значения в диапазоне от 000000 до 000111. Данные которые должны быть переданы содержатся только в поле данных. В первую очередь передается наиболее значимый байт ( M ost significant byte (MSB) ) из байтов данных.

Обработка ошибок (Error Handling)

В протоколе CAN реализовано пять уровней обнаружения ошибок. На уровне сообщений, выполняется циклическая проверка избыточности ( Cyclic Redundancy Check (CRC) ), проверки сообщения и обязательное подтверждение проверок ( Acknowledge (ACK) ). Бит проверки уровней состоит из монитора и наполнения.

Циклические ошибки избыточности обнаруживаются, используя код CRC размером 15 битов, вычисленный передатчиком из контента сообщения. Каждый получатель, принимающий сообщение, повторно вычисляет код CRC и сравнивает его с переданным значением. Несоответствие между этими двумя вычислениями заставляет установить флаг ( flag ) ошибки. Проверяемые сообщения, в которых будет установлен флаг ошибки, это обнаружение получателем недопустимого бита в разделителе CRC , разделителе ACK , в завершении сообщения EOF или в 3-х битном разделяющим сообщения пространстве. В конечном итоге каждый принимающий узел записывает доминантный бит в ячейку разделителя ACK , которая затем читается отправившим это сообщение узлом. И если приём сообщения получателем не подтверждён (возможно потому что получающий узел перестал работать) то устанавливается флаг ошибки подтверждения ( ACK ).

На уровне битов мы уже отметили, что каждый переданный бит считывается снова передатчиком этого сообщения при контроле подтверждения о получении сообщения, присланного получателем. Если контролируемое значение отличается от отправленного, значит на уровне битов обнаружена ошибка. Дополнительно, ошибки на уровне битов обнаруживаются при помощи «вставок»: После пяти последовательных идентичных битов, которые передаются в сообщении следует «вставка», бит противоположной полярности вставляется передатчиком в поток передаваемых битов (биты «вставки» вставляются в сообщение от поля SOF до поля CRC ). Получатели автоматически проверяют сообщение на наличие «вставок». Если любой из принимающих узлов сети обнаруживает в полученном сообщении шесть последовательных идентичных битов, то фиксируется ошибка (отсутствия «вставки»). В дополнение для обнаружения ошибок, «вставки» гарантируют, что есть достаточно не нулевых окончаний в потоке битов ( non-return to zero (NRZ) ), чтобы поддержать синхронизацию.

Сообщение об ошибке (The CAN Error Frame)

Если передающий или принимающий узел обнаруживает ошибку, он немедленно прерывает приём или передачу текущего сообщения. Сообщение об ошибке называемое «флаг» ошибки, составляется из шести доминантных битов и разделителя сообщения об ошибке состоящего из восьми рецессивных битов. Так как эта строка битов нарушает правило «вставок», все другие узлы также передают сообщение об ошибке. После критичного количества обнаруженных ошибок, узел в конце концов само-отключается. Надежность, особенно в производстве и автомобильной электронике, где применяется технология CAN, требует, чтобы сеть могла отделять случайные ошибки (из-за скачков напряжения, шумов или других временных причин) от постоянных, являющихся причиной неисправности узла из-за дефектов в оборудовании. Следовательно, узлы хранят и отслеживают число обнаруженных ошибок. Узел может быть в одном из трех режимов в зависимости от количества зафиксированных ошибок:

Если количество зафиксированных ошибок в каждом буфере передачи или приёма соответствующего узла, больше чем нуль и меньше чем 128, узел считается «активным с ошибкой» ( “ error active ” ), указывая на то, что несмотря что узел остается полностью функциональным, по крайней мере одна ошибка была обнаружена.

Если количество зафиксированных ошибок между 128 и 255, то узел переходит в «пассивный с ошибками» ( “error passive” ) режим. В «пассивном с ошибками» режиме узел будет передавать на более медленном уровне, отправляя 8 рецессивных битов прежде чем снова отправить сообщение, распознав что шина свободна.

Если количество зафиксированных ошибок более 255, то узел переходит в режим «отключен от сети» ( “ bus off ” ), отключив себя самостоятельно.

Ошибка при получении добавляет в общее количество учтённых ошибок 1, ошибка при передаче добавляет в общее количество учтённых ошибок 8. Последующие безошибочные сообщения постепенно уменьшают количество учтённых ошибок на 1, за каждое безошибочное сообщение. Если общее количество учтённых ошибок возвращается к нулю, узел возвращается в нормальный режим функционирования. Узел в находящийся режиме “ bus off ” может перейти в режим “ error active ” после 128 входов в сеть из 11 последовательных рецессивных битов, которые были проконтролированы. Сообщение считается безошибочным, если передающий узел не нашёл в нём ошибок вплоть до поля EOF . Повреждённые сообщения отсылаются повторно сразу как только шина становится свободной.

Запрос данных от конкретного узла сети (The CAN Remote Frame)

Узел, которому необходимы данные от другого узла сети, может запросить передачу таких данных, отправив соответствующий запрос на получение данных ( Remote Frame ). Например, микропроцессору управления центральным замком на вашем автомобиле необходимо знать положение селектора коробки передач от ЭБУ трансмиссии (является ли он в положении «паркинг»). Структура запроса на получение данных аналогична структуре стандартного сообщения только без поля данных ( data field ) и с рецессивным RTR битом.

Запрос на предоставление дополнительной паузы между получаемыми данными и свободное пространство между сообщениями (Overload Frames and Interframe Space)

Если какой-либо узел сети будет получать сообщения быстрее, чем он может их обработать, то будет сгенерирован запрос на предоставление дополнительной паузы между получаемыми данными ( Overload Frames )чтобы обеспечить дополнительное время между принимаемыми данными или запросами на получение сообщений ( Remote Frame ). Подобно сообщению об ошибке, Overload Frame имеет два поля с битами: flag перегрузки состоящий из шести доминирующих битов и разделитель перегрузки, состоящий из восьми рецессивных битов. В отличие от сообщений об ошибке, суммарный подсчёт Overload Frames не ведётся.

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

CAN обеспечивает устойчивое, простое и гибкое сетевое решение для производственных, автомобильных и многих других приложений. Главный недостаток протокола CAN — что задержка сообщения не является определённой (из-за существования Error Frame s , Overload Frame s и повторных передач), и увеличения задержки ведёт к увеличению сетевого трафика. В целом использование шины не должно превышать 30% от максимальной мощности шины и гарантировать, что низкоприоритетные сообщения не испытывают недопустимую задержку. Использование шины определено как деление двух величин — общее количество использованных для передачи битов поделённое на общее максимально доступное количество для передачи битов , и вычисляется следующим образом:

Шаг 1 — Выбирается единица времени ≥ самого медленное зафиксированного периодического сообщение в сети (обычно 1 секунда).

Шаг 2 — Определяются все периодические сообщения.

Шаг 3 — К каждому из этих сообщений приблизительно одинакового размера, добавляются 47 служебных бит (размер служебных полей данных — SOF + Arbitration + RTR + Control + CRC + Acknowledgment + EOF +

Interframe Space = 1 + 11 + 1 + 6 + 16 + 2 + 7 + 3 = 47 bits).

Шаг 4 — Рассчитывается количество бит используемых в сообщениях путем умножения размера сообщения в битах на количество передач выполняемых в единицу времени.

Шаг 5 — Суммирование всех битов используемых в переданных сообщениях для оценки общего объёма сетевого трафика. Умножение этой величины на страховочный коэффициент 1.1 для получения наихудшего прогноза сетевого трафика.

Шаг 6 — В завершении, поделите общее количество использованных для передачи битов на общее максимально доступное количество для передачи битов (например, 125 Кбит/с или 500 Кбит/с умножаются на единицу времени) для получения предполагаемого процента загрузки шины,- рис. 6

Протоколы синхронизированные по времени (Time-triggered Protocols)

Для контроля над сетью в реальном времени было бы желательно реализовать такой протокол связи, который гарантирует, что для сообщений выбираются крайние временные параметры независимо от нагрузки на шину. Пример такого протокола, который контролирует временной уровень связи CAN данных, это “ time-triggered CAN ,” или TTCAN (ISO 11898-4 ). TTCAN сообщения имеют два специальных типа, называемые «окна времени» ( time windows ): привилегированные окна времени ( exclusive time windows ), и арбитражные окна времени ( arbitrating time windows ). Еxclusive time windows прикреплены к специальным сообщениям, которые передаются периодически. Таким образом, Еxclusive time windows не конкурируют за доступ к шине. Аrbitrating time windows используются для сообщений не имеющих строгих ограничений по времени.

Аrbitrating time windows , как нормальные сообщения CAN , конкурируют за доступ к шине на основе приоритета через арбитраж. Тime-triggered CAN протокол, требует наличия в сети «главного узла» ( master node ), который периодически широковещательно передает сигнал времени сети (называемый глобальным временем ( global time )) в специальном информационном сообщении. Для повышения отказоустойчивости в сети должны быть несколько потенциальных главных узлов. Если главный узел перестал работать (обнаружено отсутствие специального информационного сообщения), другие потенциальные главные узлы конкурируют за статус «главного узла» при помощи арбитража и новым «главным узлом» становится узел с самым высоким приоритетом. После этого новый главный узел начинает широковещательно передавать специальные информационные сообщения — global time . Тime-triggered CAN протокол не ретранслирует повреждённые сообщения, и при этом это не вызывает Error Frames.

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

Ну вот, в принципе, вся основная информация о протоколе CAN , а теперь немного о том, как выглядит CAN шина на примере автомобилей произведённых в Японии . Сразу хочу отметить, что без надлежащего диагностического оборудования проводить диагностику и ремонт неисправностей CAN шины можно в очень ограниченном диапазоне. Всё сведётся к проверке физической целостности проводов, проверки состояния соединительных разъёмов, проверки сопротивления проводки и Terminal resistor , проверки соответствующего уровня напряжения на CAN low и CAN high линиях. Применение в диагностике дилерского оборудования тоже лишь облегчит проверку и сузит круг поиска неисправности, с очень большой неохотой автопроизводители допускают контакт с программным обеспечением, своей интеллектуальной собственностью. В случае проблем на программном уровне возможно только перепрограммирование или замена соответствующего ЭБУ.

Пример CAN шины автомобиля Nissan 2007г.в. — Рис. 7

Сегодня я хочу познакомить вас с интересной микроконтроллерной платформой CANNY . Это обзорная статья в которой вы узнаете о технологии, а в последующих статьях я расскажу вам о работе с сообщениями CAN, интеграции CANNY c Arduino Mega Server и о тех возможностях, которые предоставляет эта связка.

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

Шина CAN

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

Контроллеры CANNY

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

Кроме CANNY 7 в линейке контроллеров присутствует ещё несколько моделей, мы будем проводить свои эксперименты с более простой встраиваемой моделью CANNY 5 Nano. Она также поддерживает работу с CAN шиной, но при этом похожа на уже знакомую нам Arduino Nano.

Визуальное программирование

Развитая поддержка шины CAN это не единственная особенность этих контроллеров, кроме этого CANNY имеют свою собственную среду программирования, CannyLab, но не «обычную», а визуальную, где весь процесс написания программ сводится к манипулированию готовыми структурными блоками, заданию их параметров и соединению входов и выходов этих блоков в определённой последовательности, в соответствии с алгоритмом решаемой задачи.

Ни одной строчки кода!

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

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

CannyLab является бесплатной средой разработки и вы можете свободно скачать её с сайта разработчиков, она также не требует специальной процедуры инсталляции — достаточно распаковать файл с архивом — и вы можете начинать работу.

Подключение

Практические примеры

В контроллере CANNY 5 на выводе С4 (Channel 4) присутствует тестовый светодиод (аналог светодиода, находящегося на 13 выводе в Arduino). И его тоже можно использовать для индикации и экспериментов, чем мы и воспользуемся.

Что же нужно, чтобы помигать светодиодом в контроллере CANNY? Нужно сделать всего две вещи — сконфигурировать пин четвертого канала как выход и подать на этот выход сигнал с ШИМ генератора. Все эти действия мы уже не раз проделывали в Arduino IDE, посмотрим как это выглядит в CannyLab.

Итак, конфигурируем пин четвертого канала как выход

Настраиваем генератор ШИМ. Задаём период 500 миллисекунд, заполнение — 250 миллисекунд (то есть 50 %) и 1 (true) на входе генератора «Старт» и… всё! Больше ничего делать не нужно — программа готова, осталось только залить её в контроллер.

Режим симуляции

Среда разработки CannyLab позволяет запускать и отлаживать программу, не записывая её в память контроллера. В режиме симуляции вы можете видеть результат работы программы прямо в реальном времени и даже вмешиваться в её работу.

Заливка в контроллер

После того, как программа написана и отлажена, её можно загрузить в ваш контроллер. Это делается просто — в меню выбираете пункт «Устройство/Диаграмма/Записать» и через несколько секунд программа оказывается записанной в контроллер.

Аналоговые входы

Мы будем отслеживать уровень напряжения на 10 пине контроллера и если он находится в диапазоне 2,5 В ± 20%, будем зажигать встроенный в плату светодиод.

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

Включаем АЦП на 10-м канале.

Блок «Логическое И» довершает работу и со своего выхода управляет работой светодиода на плате.

Вот и всё. То, что мы привычно делали на Arduino, мы легко сделали в CannyLab. Осталось только освоиться в этой среде программирования и вы сможете легко и непринуждённо создавать свои проекты на этой платформе.

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

Использование стандарта CAN в Arduino – полное руководство

Современные автомобили включают в себя несколько десятков разнообразных датчиков. И все эти датчики регулярно обмениваются информацией с другими датчиками/устройствами автомобиля. Причем автомобили с каждым годом становятся все «умнее» и поэтому количество датчиков в них все больше увеличивается. В автомобилях сегодняшнего дня находят широкое применение системы автономного вождения, системы безопасности с автоматически срабатывающими подушками безопасности, системы контроля давления в шинах, круиз-контроль и т.д. В большинстве случаев информация, поступающая от этих датчиков, является критически важной. Например, если сработает датчик столкновения, которому срочно нужно передать сигнал на раскрытие подушек безопасности, а ему это помешают сделать какие-либо сигналы/процессы в электронной системе автомобиля. В этом случае жизнь людей в автомобиле может оказаться под угрозой. Поэтому в автомобилях не используют такие широко распространенные в обычной электронике протоколы передачи данных как UART, SPI или I2C. Вместо них конструкторы автомобилей отдают предпочтение значительно более надежным протоколам передачи данных, таким как LIN, CAN, FlexRay и т.д.

Наибольшее распространение среди этих «надежных» протоколов получил стандарт (протокол) CAN. Этот стандарт широко применяется не только в электронных системах современных автомобилей, но и во многих других промышленных устройства, в которых критически важна надежная передача данных. Достаточно подробную информацию о стандарте CAN можно прочитать в соответствующей статье Википедии. Мы же в данной статье рассмотрим обмен данными между двумя платами Arduino с помощью протокола CAN.

Краткие сведения о протоколе CAN

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

CAN-сеть состоит из двух проводников (CAN High и CAN Low) и обеспечивает двунаправленную передачу данных. На практике под CAN-сетью обычно подразумевается сеть топологии «шина» с физическим уровнем в виде дифференциальной пары. Передача ведется кадрами, которые могут принимать все узлы сети. Для доступа к такой шине выпускаются специализированные микросхемы (модули) – драйверы CAN-шины.

Обычно скорость передачи по CAN-шине варьируется от 50 Кбит/с до 1 Мбит/с, а дальность связи лежит в диапазоне от 40 метров (на скорости 1 Мбит/с) до 1000 метров (на скорости 50 Кбит/с).

Формат CAN сообщений

В CAN-сети данные передаются в виде сообщений определенного формата. Этот формат состоит из большого числа сегментов, но двумя основными сегментами является идентификатор (identifier) и данные (data), которые и позволяют передавать и принимать сообщения по CAN-шине.

Идентификатор (Identifier) – также известен под именами CAN ID и PGN (Parameter Group Number). Он используется для идентификации CAN устройств в CAN-сети. Длина идентификатора составляет 11 или 29 бит в зависимости от того какой тип протокола CAN используется:

• Standard (стандартный) CAN: 0-2047 (11-bit);
• Extended (расширенный) CAN: 0-2 29 -1 (29-bit).

Data – это данные, которые необходимо передать от одного устройства другому. Длина данных может составлять от 0 до 8 байт.

Data Length Code (DLC) (длина поля данных): может принимать значения от 0 до 8 в зависимости от количества байт для передачи.

Проводники, используемые в CAN

CAN протокол работает по двум проводникам, именуемыми CAN_H и CAN_L, для передачи и приема информации. Оба проводника работают как дифференциальная линия, что означает что CAN сигнал (0 или 1) представляет собой разность потенциалов между CAN_L и CAN_H. Если эта разность положительна и больше определенного минимального уровня напряжения, то это 1, а если эта разность отрицательна – то это 0.

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

Сравнение CAN с SPI и I2C

На нашем сайте мы ранее уже рассматривали использование в платах Arduino протоколов SPI и I2C, поэтому давайте сравним данные протоколы с протоколом CAN.

быстрый: 400 Кбит/с;

По скорости стандарт CAN не в лидерах, но его главным «козырем» является высокая надежность связи.

Применения CAN протокола

1. В связи с чрезвычайно высокой надежностью и устойчивостью CAN протокола он широко применяется в автомобилях, промышленных механизмах, сельском хозяйстве, медицинском оборудовании и т.д.
2. В связи с небольшим количеством используемых проводников CAN протокол исключительно удобен для применения в автомобилях.
3. Устройства на основе CAN протокола отличаются низкой стоимостью.
4. В CAN-сеть (шину) легко добавлять и удалять новые устройства.

Использование протокола CAN в Arduino

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

CAN модуль (контроллер шины CAN) MCP2515

Модуль MCP2515 включает в себя CAN контроллер MCP2515, который представляет собой высокоскоростной CAN приемопередатчик. Соединение модуля MCP2515 с микроконтроллером осуществляется с помощью интерфейса SPI, поэтому его легко подключить ко всем микроконтроллерам с данным интерфейсом.

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

Основные технические характеристики модуля MCP2515:

• включает в себя высокоскоростной CAN приемопередатчик TJA1050;
• размеры модуля: 40×28mm;
• управление по интерфейсу SPI с возможностью подключения к CAN-шине нескольких устройств;
• кварцевый генератор на 8 МГц;
• сопротивление на концах 120 Ом;
• включает независимый ключ, светодиодный индикатор, индикатор мощности;
• поддерживает скорости передачи данных до 1 Мбит/с;
• низкий потребляемый ток в режиме ожидания;
• возможность подключения до 112 устройств (узлов).

Назначение контактов (распиновка) CAN модуля MCP2515 представлено в следующей таблице.

Наименование контакта	Назначение контакта
VCC	контакт питания 5 В
GND	общий провод (земля)
CS	SPI SLAVE select pin (Active low) (выбор ведомого)
SO	SPI master input slave output lead
SI	SPI master output slave input lead
SCLK	контакт синхронизации SPI
INT	контакт прерывания MCP2515

В данном проекте мы будем передавать данные, считываемые с датчика температуры и влажности DHT11 платой Arduino Nano, плате Arduino Uno с помощью CAN модуля MCP2515.

Необходимые компоненты

1. Плата Arduino Uno (купить на AliExpress).
2. Плата Arduino Nano (купить на AliExpress).
3. Датчик температуры и влажности DHT11 (купить на AliExpress).
4. ЖК дисплей 16х2 (купить на AliExpress).
5. MCP2515 CAN Module (контроллер шины CAN MCP2515) – 2 шт. (купить на AliExpress).
6. Потенциометр 10 кОм (купить на AliExpress).
7. Макетная плата.
8. Соединительные провода.

Схема проекта

Схема проекта для связи между двумя платами Arduino с помощью протокола CAN и модулей MCP2515 представлена на следующем рисунке.

Соединения на передающей стороне:

Компонент — контакт	Arduino Nano
MPC2515 — VCC	+5V
MPC2515 — GND	GND
MPC2515 — CS	D10 (SPI_SS)
MPC2515 — SO	D12 (SPI_MISO)
MPC2515 — S I	D11 (SPI_MOSI)
MPC2515­ — SCK	D13 (SPI_SCK)
MPC2515 — INT	D2
DHT11 — VCC	+5V
DHT11 — GND	GND
DHT11­ — OUT	A0

Соединения на приемной стороне:

Компонент — контакт	Arduino Uno
MPC2515 — VCC	+5V
MPC2515 — GND	GND
MPC2515 — CS	10 (SPI_SS)
MPC2515 — SO	12 (SPI_MISO)
MPC2515 — SI	11 (SPI_MOSI)
MPC2515 — SCK	13 (SPI_SCK)
MPC2515 — INT	2
LCD (ЖК дисплей) — VSS	GND
LCD — VDD	+5V
LCD — V0	к среднему контакту потенциометра 10 кОм
LCD — RS	3
LCD — RW	GND
LCD — E	4
LCD — D4	5
LCD — D5	6
LCD — D6	7
LCD — D7	8
LCD — A	+5V
LCD — K	GND

Соединения между двумя CAN модулями MCP2515:

H – CAN High
L – CAN Low

MCP2515 (Arduino Nano)	MCP2515 (Arduino UNO)
H	H
L	L

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

Объяснение программы для Arduino

Первым делом нам необходимо установить библиотеку для работы с протоколом CAN в Arduino IDE. Сначала скачайте ZIP файл библиотеки по следующей ссылке — Arduino CAN MCP2515 Library. Затем установите ее в Arduino IDE с помощью пункта меню Sketch -> Include Library -> Add .ZIP Library.

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

Инициализация CAN модуля MCP2515

Для установления соединения платы Arduino с модулем MCP2515 выполните следующую последовательность шагов. Но перед этим убедитесь в том, что указанная выше библиотека CAN MCP2515 установлена в вашу Arduino IDE.

Шаг 1. Установите номер контакта, к которому подключена линия CS интерфейса SPI (10 по умолчанию).

Industrial Internet of Things — IIoT
Промышленный интернет вещей

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

Статья входит в обзор TAdviser «Интернет вещей»

Содержание

Интернет вещей Internet of Things

Что такое Industrial Internet of Things

Общепринятая терминология

Интернет Вещей (IoT, Internet of Things) – система объединенных компьютерных сетей и подключенных физических объектов (вещей) со встроенными датчиками и ПО для сбора и обмена данными, с возможностью удаленного контроля и управления в автоматизированном режиме, без участия человека.

Индустриальный (часто Промышленный) Интернет Вещей (Industrial Internet of Things, IIoT) – интернет вещей для корпоративного / отраслевого применения — система объединенных компьютерных сетей и подключенных промышленных (производственных) объектов со встроенными датчиками и ПО для сбора и обмена данными, с возможностью удаленного контроля и управления в автоматизированном режиме, без участия человека.

В промышленном применении используется термин «Промышленный интернет». Далее по тексту для упрощения восприятия вместо написания «индустриальный интернет вещей» используется термин «интернет вещей» в данном контексте.

Как работает промышленный интернет вещей

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

Помимо этого, компании могут заменить быстро устаревающую бумажную документацию, а также аккумулировать экспертные знания специалистов [1] .

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

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

Согласно исследованию консалтинговой компании IDC, в 2011 году человечеством было сгенерировано 1,8 зеттабайт информации. В 2012 году объем ценных данных увеличился почти в два раза и составил 2,8 зеттабайт. К 2020 году эта цифра достигнет 40 зеттабайт. Такие большие объемы данных требуют обработки для того, чтобы быть использованными в процессе принятия решений.

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

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

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

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

Как промышленный интернет вещей трансформирует экономику

Новые подходы и модели

Индустриальный интернет вещей кардинально изменяет всю экономическую модель взаимодействия «поставщик – потребитель». Это позволяет:

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

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

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

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

Проведенный консультантами J`son & Partners Consulting анализ опыта внедрения интернета вещей в мире показывает, что переход на концепцию IIoT происходит за счет формирования кросс-индустриальных открытых (по горизонтали и вертикали) производственно-сервисных экосистем, объединяющих множество различных информационных систем управления разных предприятий и задействующих множество различных устройств.

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

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

Таким образом, можно сказать, что индустриальный интернет вещей представляет собой организационно-технологическую трансформацию производства, базирующуюся на принципах «цифровой экономики», позволяющую на уровне управления объединять реальные производственные, транспортные, человеческие, инженерные и иные ресурсы в практически неограниченно масштабируемые программно-управляемые виртуальные пулы ресурсов (shared economy) и предоставлять пользователю не сами устройста, а результаты их использования (функции устройств) за счет реализации сквозных производственных и бизнес-процессов (сквозного инжиниринга).

Отличием экосистемы IoT от традиционных рынков является трансформация предприятий из изолированных самодостаточных систем, внутри которых реализованы все необходимые для производства товара или услуги производственные и бизнес-процессы, в открытые системы интегрированных высокоавтоматизированных процессов. Такие открытые системы реализованы по модели облачных сервисов, в которых различные участники рынка объединены в единую платформу предоставления услуг конечному потребителю, для создания которой основными средствами производства выступает не персонал, а облачные сервисы, автоматически управляющие объединенными в пулы программно-определяемыми устройствами (Рис. 4).

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

Внедрение интернета вещей требует изменения подходов к созданию и использованию автоматизированных информационных систем управления (АСУ) и общих подходов к управлению предприятиями и организациями. Устаревшие производственные линии, которые по разным причинам не могут быть автоматизированы с помощью IoT, могут быть заменены на новое автоматизированное и роботизированное оборудование в будущем. Другим препятствием, ограничивающим развитие IoT, является отсутствие или недостаточно высокое развитие традиционных корпоративных информационных систем управления (ERP), тогда решения IoT будут локальными и решать нишевые функции и задачи.

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

В части технологий управления и обработки информации эти изменения состоят в следующем:

• реализация программной логики АСУ как взаимодействующих между собой облачных сервисов («облако управления», «платформа IoT»);
• переход от жестко иерархически выстроенных информационно изолированных АСУ на непосредственное, без участия человека и промежуточных АСУ, подключение объектов управления в «облако управления».

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

За счет использования механизма открытых прикладных интерфейсов программирования (Application Programming Interface, API) реализуется возможность подключения к «облаку управления» любых устройств и любых АСУ без необходимости внесения изменений в подключаемые устройства и системы, и возможность реализации логики обработки поставляемых в «облако управления» данных с использованием готовых шаблонов и, при их отсутствии, с использованием встроенных средств разработки программных приложений.

Эффект «Больших данных», накапливаемых в таких платформах IoT, и применение технологий машинного обучения позволяет автоматизировать процессы совершенствования программно исполняемых «облаком управления» алгоритмов, то есть оптимизировать алгоритмы управления по мере накопления исторических данных, поступающих от широкой номенклатуры устройств и АСУ, что в принципе невозможно в информационно изолированных АСУ.

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

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

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

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

С точки зрения макроэкономики рост эффективности процессов в цепочке «поставщик-потребитель» означает переход от инфляционного развития, состоящего в перекладывании растущих издержек (рост выручки поставщика – это рост издержек потребителя) на «следующего в цепочке», а от конечного потребителя — назад к производителям (работодателям) через требования о росте зарплат, — к дефляционному. Дефляционное развитие базируется на росте эффективности всех участников экосистемы IoT, включая конечных потребителей, что является беспрецедентным для истории развития мировой экономики.

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

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

Преимущества промышленного интернета вещей для экономики

По мнению J’son & Partners Consulting, за количественным ростом интернета вещей и организационно-технологической трансформацией производства стоят важные качественные изменения в экономике:

• данные, которые раньше были не доступны, с ростом проникновения встроенных устройств представляют собой ценную информацию о характере использования продукта и оборудования для всех участников производственного цикла, являются основной формирования новых бизнес-моделей и обеспечивают дополнительный доход от предложения новых услуг, таких как, например: контракт жизненного цикла на промышленное оборудование, контрактное производство как сервис, транспорт как сервис, безопасность как сервис и другие;

• виртуализация производственных функций сопровождается формированием «экономики совместного использования» (shared economy), характеризующейся существенно более высокой эффективностью и производительностью за счет повышения использования имеющихся ресурсов, изменения функционала устройств без внесения изменений в физические объекты, путем изменения технологий управления ими;

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

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

• анализ данных о пользователе, его производственных объектах (машинах, зданиях, оборудовании) и характере потребления открывают возможности для поставщика услуги по улучшению клиентского опыта, созданию большего удобства пользования, лучшего решения и сокращению затрат клиента, что ведет к повышению удовлетворенности и лояльности от работы с данным поставщиком;

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

Оценка эффективности использования

В конечном счете, внедрение любых средств автоматизации, в том числе и согласно концепции интернета вещей, будет оправдано, если это дает экономический эффект по сравнению с принятыми формами производства и бизнес-процессов. В связи с этим, консультанты J’son & Partners Consulting провели анализ кейсов по применению интернета вещей в различных отраслях в мире и проанализировали численные значения показателей эффективности.

Перечень некоторых показателей эффективности по рассмотренным кейсам в разрезе основных отраслей

Применение IIoT в различных отраслях

IIoT на производстве

Условия для внедрения IIoT

Анализ лучших мировых практик внедрения IIoT в исследовании J’son & Partners Consulting показывает, что основными сферами применения решений в сфере промышленного интернета являются производства, характеризующиеся наличием одного либо нескольких следующих важных условий:

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

Типовые результаты внедрения IIoT в промышленности

Исследование J`son & Partners Consulting показало, что, во-первых, применение датчиков контроля работы оборудования с выходом в сеть позволяет производителю оборудования удаленно контролировать его работу, своевременно проводить регламентные работы, предсказывать аварии и проводить планово-предупредительный ремонт или заранее подготовить необходимые детали на замену и т. п. Таким образом, мы говорим о том, что Интернет вещей является эффективным инструментом управления жизненным циклом продукции.

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

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

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

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

• крупнейший поставщик промышленных компрессоров Kaeser – оплата компрессорного оборудования происходит по объему произведенного им сжатого воздуха;
• производитель сельскохозяйственной техники John Deere – оплата фактического времени использования сельскохозяйственной техники (тракторов);
• многие другие ведущие производители промышленного оборудования и потребительской техники, описанные в отчете.

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

Следствием такого типового результата проектов IoT является рост конкурентоспособности участников экосистем IoT в глобальной системе разделения труда и рост их акционерной стоимости, когда претерпевающая IoT-трансформацию «традиционная» компания, достигая сравнимой с «технологическими» компаниями эффективности, начинает оцениваться инвесторами по коэффициентам облачных/технологических компаний, таких как Google, Amazon и других аналогичных.

IIoT в системах энергоснабжения

В электроэнергетике под определение «интернета вещей» обычно попадают «умные» или «интеллектуальные» сети (smart grids) и счетчики (smart meters). Новые технологии особенно актуальны для России, обладающей исторически сложившейся масштабной централизованной системой энергоснабжения, а это свыше 2,5 млн км линий электропередач, около 500 тыс. подстанций, 700 электростанций мощностью более 5 МВт. Однако на сегодняшний день проникновение «интернета вещей» в российскую энергетику находится на начальном уровне.

На уровне управления системой, балансами и режимами в электроэнергетике шаг в направлении цифровой обвязки активов может дать возможность более оптимально планировать загрузку генерирующих мощностей и, главное, их объем. Так как российская энергосистема построена на резервировании, создание интеллектуальной модели распределения позволило бы вывести часть неэффективной генерации из эксплуатации и частично решить вопрос перепроизводства генерирующих мощностей (рост с 215 ГВт в 2008 г. до 235 ГВт в 2016 г. при отсутствии коррелирующего роста потребления). Одновременно это позволило бы более широко внедрить современные стимулы снижения потребления электроэнергии: например, управление спросом (demand response).

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

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

С передачей информации также не должно возникнуть проблем, так как сетевой комплекс, по сути, является крупнейшим оператором связи в России: например, на всех подстанциях (ПС) 110 кВт есть каналы связи (в подавляющем большинстве оптоволоконные), все новые ПС 35 кВт имеют выход в интернет. Интеллектуальная электрическая сеть также позволит интегрировать различные объекты производства электроэнергии, в том числе на основе возобновляемых источников энергии (ВИЭ – солнце, ветер и др.), распределенную генерацию.

Пока объемы ВИЭ в России незначительны, а объем распределенной генерации составляет около 5,5% установленной мощности (чуть менее 13 ГВт), однако опыт других стран показывает, что эти показатели будут расти.

В Северной Америке и Западной Европе «интеллектуальные сети» также позволяют организовать движение электроэнергии в двух направлениях, делая возможной продажу излишков электричества, произведенного домохозяйствами (в основном солнечными панелями на крышах домов).

В генерации элементы «интернета вещей» также используются – это системы управления активами класса АСУТП (автоматизированные системы управления технологическими процессами). Они установлены в различных комбинациях на всех электростанциях нашей страны и позволяют дистанционно управлять и получать информацию о работе ключевых систем. При этом доля отечественного оборудования, что отрадно, достаточно велика. С целью развития IoT в генерации Минэнерго совместно с РОСНАНО и Ростелекомом формирует национальный проект по «Индустриальному интернету» на основе пилотного проекта развития системы удаленного мониторинга и диагностики парогазовых установок.

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

Безусловно, более интеллектуальная энергетика принесла бы очевидные выгоды как потребителям и производителям электроэнергии, так и отечественной экономике в целом. Соответствующие цели обозначены в ряде программных документов (утвержденная энергетическая стратегия России на период до 2030 г., проект новой стратегии до 2035 г., в документах Energy.net (которая является частью Национальной технологической инициативы)). Однако, по нашему мнению, необходима более четкая, предметная стратегия государства в развитии интеллектуальной энергетики.

ЕС, например, ставит целью обеспечение 80% потребителей «умными счетчиками» к 2020 г. (200 млн электрических и 45 млн газовых счетчиков). В США каждый штат самостоятельно определяет политику по их внедрению, однако число «умных счетчиков» в целом по стране уже приближается к 50% от общего числа (в шести штатах доля «умных счетчиков» составила более 80%).

IIoT в транспортной отрасли

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

Наибольшее развитие IoT получил в автомобильном транспорте благодаря распространению тех же смартфонов, которые водители берут с собой в дорогу и доля которых приблизилась к 50 % сотовых устройств в России. Благодаря им построены системы мониторинга загруженности дорог на картах Яндекс, Google и др. Вокруг смартфонов в автомобиле – целые экосистемы программных решений (например, Uber, Яндекс Такси, [GetTaxi]] и др.).

Данные решения полностью изменили рынок такси в крупных городах. Такие сервисы уже не ограничиваются только сферой такси и проникают в сферу логистики: подобно UberCargo и Trucker path в России появились стартапы GoCargo и iCanDrive, в основе которых лежит как раз использование IoT.

Более серьезные системы интеллектуального мониторинга транспорта внедряются благодаря установке в автомобили систем удаленного мониторинга передвижения на базе датчиков ГЛОНАСС/GPS и систем контроля за расходом топлива. Такие устройства позволяют существенно сократить затраты и контролировать целевое использование транспорта, анализировать и оптимизировать маршруты движения, что крайне важно для логистики. Без таких устройств не обходится, наверное, ни одно более или менее крупное транспортное предприятие. При этом они используются не только для внешних перевозок, но и внутри предприятий: «Северсталь», например, таким образом отслеживает массу и передвижение грузов, маршруты погрузчиков на своих заводах. В России появилось уже довольно много производителей устройств дистанционного мониторинга транспорта – Omnicom, «АвтоГРАФ Система спутникового мониторинга и контроля транспорта», ГалилеоСкай, «Форт», Naviset, «Инкотекс», «Штрих-ТахоRUS», «Гранит Навигатор», M2M Cyber и др. На рынке также много программных продуктов, позволяющих анализировать получаемые данные и оптимизировать затраты и процессы.

Безопасность IIoT

2019: ТК26 утвердил протокол защищенного обмена для индустриальных систем CRISP в качестве методических рекомендаций

Решением протокола №23.1 Технического комитета по стандартизации «Криптографическая защита информации» (ТК26) от 27-30 мая 2019 г. утверждены методические рекомендации МР 26.4.001-2019 «Протокол защищенного обмена для индустриальных систем (CRISP 1.0)». Об этом 27 июня 2019 года сообщил Infotecs. Подробнее здесь.

Разработан стандарт по обеспечению безопасности промышленного IoT-оборудования

11 февраля 2019 года появилась информация о том, что Международная организация по стандартизации (ИСО/ISO) разработала стандарт ISO/TR 22100-4:2018 «Безопасность производственного оборудования — Связь с ISO 12100 — Часть 4: Руководство для производителей оборудования по рассмотрению соответствующих аспектов информационной безопасности (кибербезопасности)» (ISO/TR 22100-4:2018 Safety of machinery — Relationship with ISO 12100 — Part 4: Guidance to machinery manufacturers for consideration of related IT-security (cyber security) aspects). Документ был опубликован в декабре 2018 года. Подробнее здесь.

Рост IIoT приводит к увеличению потенциальных кибератак

Высокое проникновение промышленного интернета вещей в критически важную инфраструктуру и производственный сектор привело к увеличению числа потенциальных кибератак. Об этом свидетельствуют данные исследования, проведенного аналитиками компании Frost & Sullivan, о чем стало известно 13 декабря 2018 года.

Согласно их мнению, кибератаки только в энергетической и коммунальной отраслях обходятся в среднем в $13,2 млн ежегодно. Эксперты Frost & Sullivan отмечают, что повышение рисков приводит к выработке общих подходов к обеспечению кибербезопасности. Свою роль играют усиление регулятивной роли правительств стран мира в области ИБ и увеличение осведомленности о проблеме и на зрелых рынках, и на молодых.

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

Промышленный интернет вещей приносит не только хорошие прибыли, но и риски

В отчете Frost & Sullivan указываются несколько рекомендаций для компаний, которые хотят расти на рынке услуг обеспечения кибербезопасности. Среди них – разработка интегрированных платформ, обеспечивающих высокий уровень безопасности конечных пользователей, параллельное внедрение лучших практик обеспечения ИБ, использование автоматизированных сервисов управления и расширенной аналитики для разработки комплексного портфеля услуг, который может быть адаптирован для всех типов конечных пользователей. Кроме того, аналитики считают перспективными гибкие модели ценообразования и подход CSaaS (Cybersecurity-as-a-Service – «кибербезопасность как услуга») [2] .

2017: Рекомендации по защите IoT-устройств в рамках критической инфраструктуры

Агентство Европейского союза по сетям и информационной безопасности (ENISA) в конце ноября 2017 года опубликовало рекомендации по обеспечению безопасности IoT-устройств в контексте объектов критической инфраструктуры. Свой вклад в создание этого документа внесли и эксперты «Лаборатории Касперского».

Отчет консолидирует знания отрасли по промышленной кибербезопасности, показывает модель угроз промышленного интернета вещей, а также описывает доступные меры, которые могут защитить от этих угроз. Эксперты «Лаборатории Касперского», участвующие в группе IoTSEC (ENISA IoT Security Experts Group), добавили ряд рекомендаций для тех, кто занимается разработкой унифицированных политик безопасности.

Согласно результатам исследования «Лаборатории Касперского», инциденты с устройствами интернета вещей входят в тройку угроз с наибольшим финансовым ущербом для компаний. Это относится к компаниям любого размера: как малого и среднего бизнеса, так и больших корпораций.

По информации «Лаборатории Касперского», одной из главных проблем в сфере кибербезопасности индустриальных IoT-устройств до сих пор остается отсутствие единых стандартов. Рекомендации ENISA, как ожидается, станут важным шагом в сторону унификации практик и политик безопасности, причем они касаются как создателей и пользователей промышленных IoT-устройств, так и разнообразных агентств Евросоюза, разрабатывающих политики безопасности.

Среди основных рекомендаций, разработанных для регуляторов:

• Сфокусироваться на специфичных для конкретного сектора рекомендациях вместо общих;
• Стандартизировать рекомендации внутри ЕС, установить единую терминологию и классификацию;
• Сотрудничать с представителями индустрии и вовлекать частный сектор в разработку законов, используя действующие ассоциации и объединения, например, AIOTI.

Главные рекомендации для производителей устройств и разработчиков ПО:

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

Полный текст документа «Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures» можно найти на сайте ENISA. [3]

IIoT в России

IIoT в мире: аналитика и прогнозы

Магический квадрант Gartner

В начале июля 2019 года аналитическая компания Gartner представила результаты исследования мирового рынка платформ для промышленного Интернета вещей — Magic Quadrant For Industrial IoT. Решения лидирующих производителей, как отмечают эксперты, объединяют возможности для интеграции, аналитики, обеспечения безопасности, а также управления приложениями крупных промышленных комплексов.

Предполагается, что число промышленных предприятий с локальными платформами IoT вырастет на 30% к 2023 году. В отчете Gartner названы лидеры рассматриваемого рынка: в их число вошли Software AG, PTC, Hitachi, Accenture, Atos, GE Digital, IBM.

Платформа Cumulocity IoT от немецкого поставщика Software AG предлагает управление устройствами и предварительно сконфигурированными приложениями IIoT, а также аналитику в реальном времени, интеграцию с предприятиями и облачными системами. Из сильных сторон платформы специалисты отметили то, что клиенты Software AG обычно довольны опытом работы с Cumulocity. Из слабых – неудовлетворительное техническое обслуживание платформы.

Платформа ThingWorx от компании PTC фокусируется на оценке мониторинга, прогнозируемом обслуживании и использовании активов. ThingWorx можно запустить на облачном сервере, в локальной или гибридной среде. Платформа также может подключаться к существующим облачным средам и средам IIoT. Из сильных сторон следует отметить, что клиенты высоко оценили ThingWorx за возможность интеграции и управления приложениями. Из слабых — ThingWorx Enterprise Edition на 20-50% дороже, чем продукты конкурентов.

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

Решение Connected Platform as Service компании Accenture поставляется с готовыми и настраиваемыми приложениями для сферы транспорта и торговых операций. Платформа доступна для локальных и облачных сервисов. Из сильных сторон следует отметить, что Accenture имеет обширный опыт работы с заказчиками. Из слабых — компания не имеет ориентированной на рынок программы для разработчиков.

Платформа Bezons французской компании Atos сочетает ПО с открытым исходным кодом и ПО от сторонних независимых поставщиков. Используя такой подход, компания предоставляет конкурентоспособный продукт, который прост в использовании, развертывании и внедрении. Из сильных сторон в Gartner указывают, что компания готова работать и со старыми промышленными системами управления, из слабых — имеет ограниченную сферу применения, в основном фокусируясь на решениях Siemens.

Платформа Predix компании GE Digital поставляется с возможностями для подключения активов, агрегирования данных датчиков и анализа этих данных при бизнес-аналитике. Компания поддерживает облачные и локальные развертывания. Из сильных сторон следует отметить высокую удовлетворенность клиентов, из слабых – постоянные изменения в руководстве компании, ее структуре и стратегии выхода на рынок.

Платформа Watson IoT предоставляет полный комплекс услуг и может развертываться как управляемая облачная служба в инфраструктуре IBM Cloud или локально, причем клиенты могут создавать собственные сервисы поверх платформы. Из сильных сторон следует отметить, что большинство заказчиков высоко оценивают поддержку IBM IoT, из слабых – значительные затраты на развертывание платформы. [4]

Источник https://bitserv.ru/an228—rassmotrenie-fizicheskogo-urovnya-can-can-shina-v-promyshlennyh-setyah/

Источник https://microkontroller.ru/arduino-projects/ispolzovanie-standarta-can-v-arduino-polnoe-rukovodstvo/

Источник https://www.tadviser.ru/index.php/%D0%A1%D1%82%D0%B0%D1%82%D1%8C%D1%8F:IIoT_-_Industrial_Internet_of_Things_(%D0%9F%D1%80%D0%BE%D0%BC%D1%8B%D1%88%D0%BB%D0%B5%D0%BD%D0%BD%D1%8B%D0%B9_%D0%B8%D0%BD%D1%82%D0%B5%D1%80%D0%BD%D0%B5%D1%82_%D0%B2%D0%B5%D1%89%D0%B5%D0%B9)