Часто при покупці або установці фаркопа Вам пропонують придбати "блок узгодження". Розбираємося - для чого він потрібен і чому не можна обмежиться звичайним універсальним комплектом електрики для подлюченія фаркопа на ту чи іншу авто.

Smart Connec t - з англійської мови можна перекласти, як "розумне підключення". Саме так і відбувається підключення електрики у сучасних автомобілів, оснащених складними електронними схемами і бортовими комп'ютерами.

У сучасних автомобілях застосовується так звана can-bus (кан-шина) або інші різновиди аналогових і цифрових шин. Шина can-bus необхідна для управління складними системами безпеки і системами поліпшення комфорту водія (ABS, ESP, TSP і ін). Ці системи в свою чергу використовують безліч датчиків, від кожного датчика проходить як мінімум один провід, тому кан-шина має на увазі підключення величезної кількості всіляких проводів.

Кан-шиною керує бортовий комп'ютер, коли всі сигнали йдуть лише по двох проводах. Коли необхідно прийняти певний сигнал в потрібному місці, там же встановлюється приймальний блок дешифрування, який з'єднується зі споживачем сигналу (датчиком, моторчиком і ін. Механізмом).

У випадку з використанням фаркопа в легковому автомобіліситуація виглядає наступним чином. До дешифратор блоків задніх світлових ліхтарів автомобіля (стопи, габарити, противотуманки, поворотники, задній хід і ін.) Приходять два дроти а виходять вісім або десять. Теоретично можна спробувати підключитися до проводів вже після дешифратора і не ставити блок узгодження Smart Connect. Але не все так просто на жаль, при такій спробі підключення автомобіль відреагує спрацьовуванням системи Check Control (CC). Подвійне збільшення навантаження через світлотехніки причепа призводить до зміни опору кола. У свою чергу бортовий комп'ютер автомобіля відреагує на незрозуміле зміна сили струму. Реакція може бути різною, від спроби відключення ланцюга, визначення задніх ліхтарів як несправних, до різних "глюків" світлотехніки і виходу з ладу окремих вузлів автомобіля. Ось від таких неприємностей і рятує блок узгодження Smart connect.

Як відбувається підключення через Smart Connect?

Електрика з блоком can-bus підключається також, як і звичайна універсальна енергія - обтискними кліпсами паралельним підключенням. Але підключення проводиться до блоку узгодження а не до розетки фаркопа. Сам блок узгодження підключається додатково до акумулятора або проводу живлення. В такому випадку з підключеним причепом ви отримуєте тільки керуючий сигнал на включення того чи іншого електроприладу, а харчування на розетку фаркопа йде вже через виходи блоку смарт коннект, які запитані від бортового акумуляторабезпосередньо. Тому виключені втрати енергії в електросистемі машини, яку контролює бортовий комп'ютер, Він просто не реєструє невпізнаних зовнішніх підключень. Універсальний блок узгодження встановлюється на більшість сучасних авто.

можна в магазині причепів.

Важливо!

Якщо Ваш авто оснащений режимом буксирування причепа, при використанні smart connect режим працювати не буде. Для активації таких і деяких інших режимів потрібно використовувати оригінальні блоки узгодження для конкретного авто.

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

Нові технічні розробки з'являються все швидше, цілі розробників стають все більш амбітними. Це і є прогрес, і це добре. Прогресу ми вдячні за такі винаходи як, наприклад, ABS, подушка безпеки, повністю автоматична установкаштучного клімату; це тільки мала частка прикладів з величезної кількості технічних новинок, які за останнє десятиліттябули впроваджені в конструкцію автомобіля.

Завдяки цьому розвитку зростає також частка електронних систем. У сучасних автомобілях, в залежності від класу і оснащення автомобіля, застосовується від 25 до 60 електронних систем, які повинні бути всі пов'язані між собою проводовим зв'язком.

У звичайних видах дротових з'єднань провідники, кабелі роз'єми і запобіжні колодки мали величезні розміри, наслідком чого були дуже затратні виробничі процеси. Не кажучи вже про ті проблеми, які могли виникнути при проведенні діагностики для пошуку несправностей в таких автомобілях. Для механіків починався виснажливий і довгий пошук несправності, за який платив клієнт і платив дорого. Обмін даними між різними керуючими пристроями при такій технології також стикався з межами можливого.

Історія шини CAN

Тому в 1983 році автомобільної промисловість заявила про свою потребу мати таку комунікаційну систему, яка була в стані зв'язати вузли знаходяться між собою в єдину мережу, і забезпечити необхідний обмін даними. Система повинна була відповідати таким вимогам:

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

Найпоширеніша система обміну даними - CAN-bus

• 1983 Початок розробки CAN (Бош)
• 1985 Початок кооперації з Інтел по розробці чіпа
• Тисячу дев'ятсот вісімдесят вісім Перший серійний тип CAN від компанії Intel починає впровадження CAN для вантажних автомобілів
• 1991 Перше застосування CAN в серійному автомобілі(S-клас)
• +1994 Вводиться міжнародний стандарт для CAN (ISO 11898)
• 1997 Перше використання CAN в салоні (С-клас)
• 2001 Використання CAN в малолітражних автомобілях (Опель Корса) в приводі і кузові

Що означає CAN?

CAN означає Controller Area Network

Переваги передачі даних CAN-BUS

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

Що таке CAN-BUS?

Систему передачі даних CAN-бус можна представити у вигляді автобуса. Так само, як і автобус призначений для перевезення безлічі пасажирів, так і
система CAN-бус передає безліч інформації. Без системи CAN-бус всю інформацію треба було б передавати до керуючих пристроїв по величезній кількості дротових з'єднань. Це означає, що для кожної інформації повинен бути один провідний канал.

допомоги передачі даних CAN-бус число керуючих пристроями помітно зменшується. Весь обмін інформацією між керуючими пристроями відбувається максимум через два провідника. У галузі автомобілебудування існують різні технології з'єднань (мереж). Коротко розглянемо особливості деяких з них.

Схема «зірка»

• за схемою «зірка» всі елементи обміну даними замикаються на один центр (блок керування)
• якщо блок управління виходить з ладу, то з'єднання порушується

Схема «кільце»

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

лінійна схема

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

Пристрій системи обміну даними

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

• Мережевий вузол: У нього входять мікроконтролер, CAN-контролер і бусдрайвер
• мікроконтролерПризначений для безперервного управління CAN-контролером і обробки надісланих та отриманих даних.
• CAN-контролерПризначений для забезпечення режимів передачі і прийому.
• БусдрайверЗабезпечує рівень передачі, а також прийому.
• Канал зв'язку: Являє собою двожильний провідник (для обох видів сигналів: CAN-High і CAN-Low). Для зменшення електромагнітних перешкод провідники екрановані.
• перемичка бус: Навантажувальний резистор в 120 В запобігає появі луна-сигналу на кінцях провідника і усувають спотворення сигналу.

Як працює бус?

Передача даних за допомогою CAN-бус відбувається за принципом телефонної конференції. Учасник (блок керування) «висловлює» свою інформацію (дані) в лінію передачі, в той час, як інші учасники «слухають» цю інформацію. Деякі учасники знаходять цю інформацію цікавою і використовують її. Інші просто ігнорують її.

Автомобіль починає рух, але двері з боку водія закрита нещільно. Щоб попередити водія про це, модулю чек-контролю необхідні дві інформації:

• автомобіль рухається.
• двері з боку водія відкрита.

Інформацію сприймають сенсорного датчик дверного контакту /, і вона перетворюється в електричні сигнали. Ці електричні сигнали знову перетворюються, тепер в цифрову інформацію, і у вигляді двійкового коду пересилаються по каналу передачі даних, поки не надійдуть на приймальний пристрій. Що ж стосується сигналу про обертання коліс, то цей сигнал необхідний також і іншим керуючим пристроям, наприклад, керуючому пристрою. Стосується це також і до деяких інших автомобілів, які оснащені системою активного управління ходовою частиною. Залежно від швидкості руху в цьому випадку змінюється кліренс для того, щоб оптимізувати положення автомобіля на дорозі. Вся інформація проходить через бус даних, і може бути проаналізована кожним учасником.

Система передачі даних CAN-бус являє собою систему Мультімастер - систему множинного доступу, що означає наступне:

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

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

Це могло б призвести до «зіткнення» даних. Отже, потрібно стежити за порядком. Тому в системі CAN-бус існує чітка ієрархія - хто повинен послати свою інформацію найпершим, а хто повинен почекати. При програмуванні мережних вузлів була визначена черговість, в залежності від важливості тих чи інших даних. Згідно черговості, дані з більш високим пріоритетним правом першенствують по відношенню до даних з більш низьким пріоритетним правом. Якщо йде відправка даних з мережевого вузла з високим пріоритетом, то інші мережеві вузли автоматично.

Як діє ієрархія (логіка передачі) в системі CAN-бус?

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

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

На цьому прикладі можна ще раз пояснити доступ до передачі даних. В даному випадку три мережеві вузла хочуть передати по системі свої дані. Під час процесу арбітражної оцінки - вибору черговості - блок управління S1 перерве свою спробу передачі в пункті А, так його рецесивний рівень долається домінантними рівнями інших керуючих пристроїв S2 і S3.

Керуючий пристрій S2 перерве свою спробу передачі в пункті В по тій же самій причині, що була вказана раніше. Таким чином верх бере керуючий пристрій S3, воно може тепер передати своє повідомлення.

Що таке протокол даних?

Передача даних відбувається по протоколу даних в дуже короткі проміжки часу. Протокол складається з величезної кількості біт інформації, розташованих в певному порядку. Число біт залежить від величини поля даних. Біт є найменшою одиницею інформації, вісім біт утворюють байт = послання. Це послання має цифрову форму, і може виражатися значеннями 0 або 1.

Передача даних CAN-бус в легковому Автомобиле

У наші дні в сучасних автомобілях знаходять застосування 2 системи CAN-бус:
Високошвидкісна передача даних - High = Speed-Bus (ISO 11898)

• SAE CAN Class C.
• передача даних 125 Кбіт / сек - 1 Мбіт / сек.
• протяжність передачі до 40 метрів при 1 Мбіт / сек.
• вихідний струм передачі> 25 мА.
• низьке споживання струму.
• до 30 мережевих вузлів.

Завдяки своїй високій швидкості передачі даних (передача критичної інформації в режимі реального часу за мілісекунди), ця бус-система
знайшла застосування в агрегатах приводу, де пов'язані між собою в єдину мережу блоки управління двигуном, трансмісією, ходовою частиною і гальмами.

Повільна передача даних - Low-Speed-Bus (ISO 11519-2)

• SAE CAN Class В.
• передача даних 10 Кбіт / сек - 125 Кбіт / сек.
• максимальна довжина передачі залежить від обсягу передачі.
• вихідний струм передачі< 1 мА.
• система стійка до короткого замикання.
• низьке споживання струму.
• до 32 мережевих вузлів.

Ця система знаходить своє застосування в салоні, де пов'язані між собою в єдину мережу компоненти електронних вузлів кузова бортової електроніки,
відповідає за комфорт.

Діагностика системи CAN-BUS

Можливі несправності системи CAN-бус:

• обрив провідників.
• замикання на масу.
• замикання на батарею
• замикання CAN-High / CAN-Low ..
• Занадто низька напруга живлення / розряджений акумулятор.
• відсутність резисторних перемичок.
• напруги перешкод, наприклад, несправна котушка запалювання, що викликає спотворення сигналу.

Пошук несправності:

• перевірити роботу системи.
• запросити банк несправностей.
• ознайомитися з переліком виміряних характеристик.
• вивести сигнал на екран осцилоскопа.
• перевірити порогове напруга.
• виміряти опір провідників.
• виміряти опір резисторних перемичок.

Пошук причин несіправності

Перед початком пошуку причини несправності необхідно чи немає в даному автомобілі додаткових пристроїв, які мають

в системі передачі доступ до інформації системи передачі даних. Може трапитися, що в результаті проникнення в систему вона була порушена. Можливості пошуку несправностей в системі передачі даних залежать від багатьох факторів. Вирішальним є те, які можливості надав виробник. Це може бути пошук несправності за допомогою приладу для діагностики, якщо в Вашому розпорядженні знаходиться відповідний прилад, або Ви маєте в своєму розпорядженні «тільки» тестером і осцилоскопом. Також дуже важливо мати в своєму розпорядженні спеціальні дані по автомобілю (електричні схеми, докладний описсистеми передачі даних і т.д.), щоб уникнути розриву мережевого єдності автомобіля.

Під час пошуку несправності, все одно, за допомогою тестера або осцилоскопа, необхідно діяти за операціями, використовувати структурний підхід. Це означає, що несправність можна локалізувати простим «промацування», тобто випробувати в роботі, щоб обмежитися надалі тільки найнеобхіднішими вимірами. Для того, що Ви могли собі це уявити наочніше, візьмемо в якості прикладу пошуку несправності конкретний автомобіль. У нашому випадку це буде (кузов W210).

Було заявлено про наступну несправності:

Стеклопод'емник з боку пасажира не працює.

Перевірка працездатності:

1. Чи можна впливати на стеклопод'емник з місця водія?

В цьому випадку обидва пристрої управління дверима, провідники системи CAN- бус і електродвигун стеклопод'емника знаходяться в робочому стані. Несправність полягає, ймовірно, в поломці вимикача стеклопод'емника з боку пасажира.

Чи можна скористатися іншими функціями (наприклад, змінити положення дзеркала)?

Якщо можна скористатися іншими функціями, то потрібно виходити з того, що пристрій управліннями дверима і система CAN-бус знаходяться в робочому стані. можливою причиноюнесправності є поломка вимикача стеклопод'емника з боку водія або електродвигуна стеклопод'емника з боку пасажира. Це можна з'ясувати, якщо перевірити цю функцію з місця пасажира. Якщо стеклопод'емник працює, то електродвигун можна виключити. Для пошуку несправності потрібно зосередитися на вимикачі з боку водія.

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

Порівняння правильного і неправильного зображень осцилоскопа

Для підключення осцилоскопа до системи CAN-бус потрібно знайти підходяще місце для підключення. Як правило, воно знаходиться на роз'ємних з'єднаннях між керуючим пристроєм і провідником даних CAN-бус. У нашому прикладі з боку пасажира, в кабельному каналі під швелерної планкою (дивись малюнок), знаходиться розподільник потенціалів.

Тут окремі провідники CAN-бус від керуючих пристроїв сходяться разом. До розподільника потенціалів можна підключити осцилоскоп безовсякіх труднощів.

Якщо на підключеному осциллоскопе не спостерігається ніякого сигналу, то в наявності порушення передачі даних CAN-бус. Для того, щоб визначити, в якому саме місці знаходиться несправність, тепер потрібно від'єднати окремі роз'єми. При цьому спостерігати за показаннями осцилоскопа. Якщо після відключення роз'єму на екрані осцилоскопа з'являється сигнал, то система CAN-бус знову працює. Несправність знаходиться в системі, пов'язаної з штепсельних роз'ємом. Всі відключені раніше роз'єми потрібно поставити на місце. Наступне завдання полягає в тому, щоб визначити, яким саме керуючому пристрою належить роз'єм, який відноситься до несправній системі. Тут виробник ніяких даних не призводить.

Для того, щоб спростити пошук і зробити його більш ефективним, потрібно знову методом проб з'ясувати, які саме системи не працюють. При наявності характеристик та інших даних автомобіля, про електричному з'єднанні і розміщенні окремих блоків управління, несправну систему можна визначити без жодних зусиль. Відключаючи роз'єм CAN-бус на керуючому пристрої, і підключаючи роз'єм на розподільнику потенціалів, можна визначити, чи знаходиться причина несправності в кабельному з'єднанні або в керуючому пристрої. Якщо на осциллоскопе можна розпізнати сигнали, то система CAN-бус знаходиться в робочому стані і кабельне з'єднання також знаходиться в робочому стані. Якщо після підключення керуючого пристрою сигнали на осциллоскопе розпізнати неможливо, то причина несправності полягає в несправності самого керуючого пристрою. Якщо встановлено факт несправності кабельного з'єднання, то, вимірюючи опір і напруга, можна визначити замикання на масу або на плюс, або замикання між проводами.

В автомобілях, які не мають розподільника потенціалів, пошук несправності вимагатиме значно більших зусиль. Осцилоскоп доведеться підключати до проводів CAN-бус в потрібному для цього місці (наприклад, на роз'ємних з'єднаннях блоку управління). Потім потрібно по черзі знімати все вузли знаходяться, і роз'ємні з'єднання CAN-бус від'єднувати безпосередньо від блоків управління. У цьому випадку також необхідно мати технічну документацію з даними про автомобілі, щоб визначити, які вузли знаходяться і де розташовані. Перед відключенням роз'ємів і після відключення роз'ємів необхідно спостерігати за зображенням на екрані осцилоскопа. Наступні дії нічим не відрізняються від тих, які ми здійснювали на прикладі нашого автомобіля.

Для перевірки резисторних перемичок потрібно, щоб CAN-бус знаходився в стані спокою (Sleepmode). Вузли знаходяться при проведенні вимірювань повинні бути підключені. Загальний опір, яке складається паралельно включених однакових резисторів по 120 Ом, становить 60 Ом. Це опір вимірюється між провідниками CAN- High і CAN-Low.

Установка додаткових пристроїв

Установка додаткових пристроїв, наприклад, систем навігації, для роботи яких необхідне отримання сигналів з системи CAN-бус, є складною проблемою. Вона полягає, в першу чергу, в тому, щоб знайти зручне місце для доступу, наприклад, до отримання сигналу швидкості автомобіля, а зробити це, не маючи під рукою технічної документації автомобіля, дуже складно.

У всесвітній мережі існують сайти, де можна знайти інформацію про способи і місцях підключення і установки різних пристроїв. Ці відомості, зрозуміло, не дають ніяких гарантій, тому в будь-якому випадку весь ризик на себе бере автотранспортна майстерня, якщо вирішиться використовувати такі дані. Однак в будь-якому випадку найнадійніший спосіб - це ознайомитися з технічною документацією виробника автомобіля. Для того, щоб познайомитися з усіма можливими системами CAN-бус, вивчити передачу даних, пристрій, роботу і пошук несправностей, далі - як можна встановлювати додаткові пристрої - ми в будь-якому випадку радимо пройти спеціальне навчання.

Шина 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 ( «Стандартний 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

Шина 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-busбула створена в кінці 80-х років фірмою Robert Bosch GmbH (Німеччина) як рішення для розподілених систем, що працюють в режимі реального часу. Відмінною особливістю шини є її висока перешкодозахищеність. Додатковою перевагою шини CAN виступає її стійкість до механічних пошкоджень - замикання провідників шини на загальний провід, харчування або між собою не призводить до виходу з ладу пристроїв. Більш того, деякі модифікації шини здатні функціонувати при обриві одного з провідників.

CAN-шина в промислових мережах

Польова шина CAN (Controller Area Network) характеризується високими швидкістю передачі даних і помехоустойчивостью, а також здатністю виявляти будь-які виникаючі помилки. Завдяки цьому CAN сьогодні широко використовується в таких областях, як автомобільний і залізничний транспорт, Промислова автоматика, авіація, системи доступу та контролю. За даними асоціації CiA (CAN in Automation, www.can-cia.de), в даний час в експлуатації знаходиться близько 300 млн CAN-вузлів по всьому світу. У Німеччині CAN-шина займає перше місце за популярністю серед інших польових шин.

Характеристики протоколу CAN Переваги CAN

Загальна тенденція в області автоматизації полягає в заміні традиційної централізованої системи управління на розподілене управління шляхом розміщення інтелектуальних датчиків і виконавчих механізмів поруч з керованим процесом. Це викликано зростанням числа проводів зв'язку, збільшенням кількості з'єднань, складністю діагностики помилок і проблемами з надійністю. Зв'язок між вузлами такої системи здійснюється за допомогою польової шини. CAN - це система зв'язку для багатоконтролерні систем. Розглянемо більш докладно переваги CAN і причини, за якими CAN набуває все більшого поширення.

Випробуваний стандарт. Протокол CAN активно використовується вже більше 20 років, що дуже важливо для таких консервативних областей як залізничний транспорт або суднобудування. CAN був розроблений в 1980 р фірмою Robert Bosch для автомобільної промисловості. CAN-інтерфейс регламентований міжнародними стандартами ISO 11898 для високошвидкісних і ISO 11519-1 для низькошвидкісних додатків. Низька вартість визначається хорошим співвідношенням ціна / продуктивність, також широкою доступністю CAN-контролерів на ринку. Надійність визначається лінійною структурою шини і рівноправних її вузлів, так званої мультімастерностью (Multi Master Bus), при якій кожен вузол CAN може отримати доступ до шини. Будь-яке повідомлення може бути надіслано одному або декільком вузлам. Всі вузли одночасно зчитують з шини одну і ту ж інформацію, і кожен з них вирішує, прийняти дане повідомлення або ігнорувати його. Одночасний прийом дуже важливий для синхронізації в системах управління. Відмовили вузли відключаються від обміну по шині.

Висока стійкість досягається завдяки придушення синфазних перешкод диференціальним приемопередатчиком, роботі вбудованих механізмів виявлення помилок (одна невиявлення помилка за 1000 років при щоденній 8-годинний роботі мережі на швидкості 500 Кбіт / с), повтору помилкових повідомлень, відключення несправних вузлів від обміну по шині і стійкості до електромагнітних завад.

Гнучкість досягається за рахунок простого підключення до шини і відключення від шини CAN-вузлів, причому загальне число вузлів не лімітовано протоколом нижнього рівня. Адресна інформація міститься в повідомленні і поєднана з його пріоритетом, за яким здійснюється арбітраж. У процесі роботи можлива зміна пріоритету переданого повідомлення. Слід також відзначити можливість програмування частоти і фази сигналу, що передається і арбітраж, що не руйнує структуру повідомлень при конфліктах. На фізичному рівні є можливість вибору різнотипних ліній передачі даних: від дешевої кручений пари до оптоволоконної лінії зв'язку.

Робота в реальному часі стає можливою завдяки механізмам мережевої взаємодії (мультімастерность, широкомовлення, побітовий арбітраж) в поєднанні з високою швидкістю передачі даних (до 1 Мбіт / с), швидкою реакцією на запит передачі і змінною довжиною повідомлення від 0 до 8 байт.

додатки CAN

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

Широке застосування CAN знайшов в промисловій автоматиці, де є велика кількість пристроїв управління, датчиків, механізмів, електроприводів та інших об'єктів, які пов'язані єдиним технологічним циклом (системи опалення та кондиціонування, насоси, конвеєри, ліфти, ескалатори, транспортери і т. Д.) . Важливою особливістю таких систем є можливість діагностики та управління об'єктами, розташованими на великій території, по адаптивним алгоритмам. В результаті досягається істотне зменшення споживаної потужності, шуму, зносу устаткування. Подібна картина спостерігається і в залізничних бортових системах, Де вирішальну роль відіграє обмін даними між підсистемами при наборі швидкості, гальмуванні, управлінні дверима і діагностиці.

фізичний рівень

Фізичний рівень CAN-шини являє собою з'єднання «монтажне И» між усіма пристроями, підключеними до неї. Диференціальні сигнальні лінії називаються CAN_H і CAN_L і в статичному стані знаходяться під потенціалом 2,5 В. Лог. 1 (рецесивний біт) позначає стан шини, при якому рівень на лінії CAN_H вище, ніж рівень CAN_L. При лог. 0 (домінантний біт) рівень на лінії CAN_H нижче, ніж рівень CAN_L. Прийнято наступну угоду про стан шини: пасивний стан шини відповідає рівню лог. 1, а активне - рівню лог. 0. Коли повідомлення не передаються по шині, вона знаходиться в пасивному стані. Передача повідомлення завжди починається з домінантного біта. Логіка роботи шини відповідає «провідного І»: домінантний біт «0» пригнічує рецесивний біт «1» (рис. 12.1).

Мал. 12.1. Логіка роботи CAN шини

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

Максимальна швидкість передачі даних становить 1 Мбіт / с при довжині шини 40 м і близько 40 Кбіт / с при довжині шини 1000 м.

різновиди CAN

В даний час доступні різні пристрої з CAN-інтерфейсом, сформованими незалежно від передачі даних з однієї точки в іншу дозволяють реалізувати синхронізацію процесів і обслуговування за пріоритетами. Більш ранні реалізації CAN-контролерів використовують кадри з 11-розрядних ідентифікатором і можливістю адресації до 2048 повідомлень і відповідають специфікації CAN V. 2.0A. Такі контролери звуться Basic CAN і характеризуються сильною завантаженістю центрального процесора (ЦП), так як кожне вхідне повідомлення запам'ятовується в пам'яті і ЦПУ вирішує, потрібні йому дані повідомлення чи ні (рис. 12.2). Контролери Basic CAN містять один передавальний буфер і один або два прийомних буфера повідомлень. Щоб послати або отримати повідомлення, потрібно задіяти ЦПУ через переривання «сообщеніе_послано» і «сообщеніе_получено». В результаті перевірки кожного вхідного повідомлення завантаження ЦПУ дуже велика, що обмежує реальну швидкість обміну по мережі. З цієї причини такі контролери використовуються в мережах CAN з низькою швидкістю обміну і / або малою кількістю повідомлень.

Мал. 12.2. Структура контролера Basic CAN

Більшість що випускаються сьогодні CAN-контролерів використовують розширені кадри повідомлень з ідентифікатором довжиною 29 розрядів, що дозволяє адресувати до 536 млн повідомлень. Такі контролери відповідають специфікації CAN V. 2.0B (active) і називаються контролери Full-CAN. У них передбачено буфер для декількох повідомлень, причому кожне повідомлення має свою маску, і фільтрація здійснюється по відповідності ідентифікатора масці.

У разі Full-CAN ЦПУ максимально розвантажено, оскільки не виконує жодних непотрібні повідомлення (рис. 12.3). Після отримання повідомлення з ідентифікатором, відповідним масці, воно запам'ятовується в спеціальній зоні двухпортового ОЗУ, і робота ЦПУ переривається. Full-CAN має також спеціальний тип повідомлення, яке означає: «у кого б не перебувала ця інформація, будь ласка, надішліть її зараз же». Контролер Full-CAN автоматично прослуховує всі повідомлення і посилає запитану інформацію.

Мал. 12.3. Структура контролера Full-CAN

До недавнього часу в промисловості був широко поширений Basic CAN з 11-розрядних ідентифікатором. Цей протокол допускає просту зв'язок між мікроконтролерами і периферійними пристроями при швидкості обміну аж до 250 Кбіт / с. Однак при стрімкому здешевленні CAN-контролерів використання Full-CAN стало виправданим і для зв'язку з повільними пристроями. Якщо в промислових додатках потрібно високошвидкісний (до 1 Мбіт / с) обмін даними, то неодмінно слід використовувати Full-CAN.

Арбітраж вузлів CAN-шини

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

В результаті, вузол приймає і обробляє тільки ті повідомлення, які призначені саме для нього.

Кожне повідомлення має свій пріоритет, значення якого міститься в ідентифікаторі повідомлення. Крім того, ідентифікатори використовуються для позначення типу повідомлення. Повідомленням з молодшим номером ідентифікатора відповідає вищий пріоритет; найвищим пріоритетом має повідомлення з ідентифікатором, що складається повністю з нулів. Передача повідомлення починається з відправки на шину ідентифікатора. Якщо доступ до шини вимагають кілька повідомлень, то спочатку буде передано повідомлення з найбільш високим пріоритетом, тобто з меншим значенням ідентифікатора, незалежно від інших повідомлень і поточного стану шини. Кожен вузол перш ніж надсилати повідомлення перевіряє, чи працює вузол з більш високим пріоритетом. Якщо так, то він повертається в стан приймача і намагається передати повідомлення в інший час. Це властивість має особливе значення при використанні в системах управління реального часу, оскільки значення пріоритету жорстко визначає час очікування.

Якщо передача вузла А призупиняється вузлом B, відповісти тому, хто повідомлення з більш високим пріоритетом, то, як тільки шина звільниться, буде здійснена спроба передачі повідомлення від вузла A. Цей принцип отримав назву CSMA / CA: Carrier Sense Multiple Access / Collision Avoidance (загальний доступ з опитуванням / запобігання конфліктів). Такий режим на відміну від Ethernet не дозволяє сторонам конфлікту вузлів в шині з'ясовувати стосунки, а відразу виявляє переможця і скорочує час обміну.

Отже, завдяки арбітражу шини повідомлення з вищим пріоритетом передається першим, забезпечуючи функціонування системи в реальному масштабі часу і швидку передачу інформації. Розподіл пріоритетів між різними типами повідомлень задається розробником при проектуванні мережі.

формат повідомлень

Якщо не враховувати процедуру повтору повідомлення, прийнятого з помилкою, існує два види зв'язку між вузлами: один вузол передає інформацію, а інший отримує, або вузол A запитує вузол B про дані і отримує відповідь.

Мал. 12.4. Кадр даних (Data Frame)

Для передачі даних служить кадр даних - Data Frame(Рис. 12.4), який містить:

• ідентифікатор, який вказує на тип повідомлення ( «скорость_двігателя», «температура_масла») і на пріоритет доступу до шини. Поле ідентифікатора містить різну кількість біт в залежності від різновиду протоколу: в стандартному форматі CAN V2.0A передбачений 11-розрядний ідентифікатор, а в розширеному CAN V2.0B - 29-розрядний;
• поле даних, що містить відповідне повідомлення ( «скорость_двігателя» = 6000 об / хв, «температура_масла» = 110 ° C) довжиною до восьми байт;
• два байта контрольної суми - Cyclic Redundancy Check (CRC)для виявлення і корекції помилок передачі.

Для запиту інформації вузол CAN використовує кадр запиту даних Remote Frame (рис. 12.5), який містить:

• ідентифікатор, що визначає тип інформації, яка запитується ( «скорость_ двигуна», «температура_масла») і пріоритет повідомлення;
• два байта контрольної суми CRC.

Мал. 12.5. Кадр запиту даних Remote Frame

У цьому випадку за ідентифікатором не дотримуються дані і код довжини даних не має прямого відношення до кількості байт даних. Вузол, якому запропоновано передати інформацію (датчик температури масла), передає кадр даних, що містить необхідну інформацію. Таким чином, якщо вузол А направляє вузлу У кадр запиту з ідентифікатором «температура_масла», то вузол В опитує датчик температури і направляє вузлу А кадр даних, що містить ідентифікатор «температура_масла» і необхідну інформацію.

Додаткова інформація, що міститься в кадрі, дозволяє визначити формат і синхронізацію протоколу передачі повідомлення і тип посилки:

• яке повідомлення надіслано - запит про дані або власне дані визначають біт віддаленого запиту передачі (RTR для 11-розрядної ідентифікатора і SRR для 29-розрядної);
• код довжини даних, що повідомляє, скільки байтів даних містить повідомлення; всі вузли приймають кадр даних, але ті з них, яким ця інформація не потрібна, її незберігають;
• для забезпечення синхронізації і контролю кадр містить поля початку кадру Start of Frame, кінця кадру End of Frame і підтвердження Acknowledgement Field;
• вхід в режим синхронізації на шині здійснюється першим бітом поля Start of Frame, далі синхронізація підтримується фронтом при зміні рівня посилаються бітів;
• використовується механізм бітстаффінг - вставка додаткового біта при наступних поспіль п'яти нулях або одиницях.

виявлення помилок

Сигналізація про помилки відбувається шляхом передачі кадру помилки Error Frame. Він ініціюється будь-яким вузлом, який виявив помилку. CAN-контролери використовують метод статистичної обробки помилок. Кожен вузол містить лічильники помилок при передачі і прийомі Transmit Error Counter і Receive Error Counter. Якщо передавач або приймач виявляють помилку, значення відповідного лічильника збільшується. Коли значення лічильника перевищує певний межа, поточна передача переривається. Вузол видає сигнал про помилку в вигляді Error Frame, де виставляє активний домінантний прапор помилки довжиною 6 біт. Після цього вузол, передача якого була перервана, повторює повідомлення. Ненадійним або частково пошкодженим вузлів дозволено посилати лише пасивний рецесивний прапор помилки.

У CAN існує кілька різновидів помилок. З них три типи на рівні повідомлень:

• CRC Error - помилка контрольної суми (при розбіжності прийнятої в поле CRC і обчисленої контрольних сум).
• Form Error - помилка формату кадру при невідповідність прийнятого повідомлення формату CAN.
• Acknowledgement Error - помилка підтвердження прийому повідомлення, якщо жоден з вузлів не підтвердив правильного отримання повідомлення.

Крім того, існує два типи помилок на битовом рівні:

• Bit Error - виявлення активним вузлом розбіжності між посланим в шину рівнем і фактичним значенням за рахунок реалізації вузлом механізму самоконтролю.
• Stuff Error - наявність в поле повідомлення шести наступних поспіль біт 0 або 1 (помилка бітстаффінг).

Завдяки цим механізмам виявлення і корекції помилок ймовірність пропуску помилки вкрай мала. Наприклад, при швидкості 500 Кбіт / с, завантаженості шини 25% і використанні протягом 2000 годин на рік виникає лише одна невиявлення помилка за 1000 років. Крім того, в шині неможлива ситуація блокування несправним вузлом роботи всієї мережі. Такі вузли виявляються і відключаються від обміну по шині.