Мережі промислових контролерів

1. CAN і семиуровневая модель
2. Логіка роботи CAN
3. дволикий ідентифікатор
4. CSMA / BA і інші способи розподілу каналів
5. працездатності
6. Базовий и повний
7. Інтеграція мереж CAN
8. література

CAN (controller area network) - мережу промислових контролерів (іноді її називають послідовною комунікаційної шиною) служить засобом для об'єднання окремих контролерів в єдину систему управління, що працює в реальному часі. В основі ідеології CAN лежить семиуровневая модель OSI / ISO. Специфікою CAN є те, що для реалізації функцій управління ця мережа повинна забезпечувати надійний і високошвидкісний (до 1 Мбіт / с) внутрішньосистемний обмін даними між контролерами, з урахуванням несприятливих умов технологічного оточення. CAN за своїм визначенням об'єднує обмежена кількість контролерів, за своєю природою вона локальна і не виходить за рамки технологічного об'єкта.

В архітектурі цієї мережі є певний чарівність, властиве будь-мініатюрі. При знайомстві з нею виникає приблизно таке ж відчуття, як при вигляді вузькоколійної залізниці або діючих моделей, хоча насправді тут все «по-справжньому», але в іншому масштабі, ніж в більш відомих мережах WAN, LAN або SAN. Знайомство з її пристроєм може бути корисним не тільки фахівцям.

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

В даний час CAN успішно використовується. Досягнення в цій області, особливо на престижному «мерседесі» класу S (по-російськи - «крутий» шестисотий), стимулювали просування ідеї в інші галузі. Зараз CAN можна знайти в системах морської навігації, управлінні ліфтами, сільськогосподарських машинах, робототехніці, наукової та медичної апаратури, офісній техніці й навіть в складних іграшках. Загальна кількість мереж CAN у 2000 році перевищило 100 млн., А сфери застосування перекривають діапазон від побутової техніки до космічних апаратів. Це зовсім не дивно: заміна кабельних монстрів мережами (в найпростішому випадку телефонної «локшиною», кручений екранованої або неекранованої парою або навіть оптоволокном) представляється дуже привабливою.

CAN і семиуровневая модель

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

Стандарти на CAN сформульовані в двох документах: ISO 11898 та ISO 11519. Відповідне обладнання випускається цілим рядом найбільших виробників; в їх числі Bosch, NEC, Intel, Philips і цілий ряд інших компаній. Діючі стандарти поки поширюються тільки на два нижніх рівні моделі OSI / ISO - фізичний і канальний. Для фізичного рівня визначена середовище передачі, рекомендовані типи з'єднань і роз'ємів, швидкості передачі даних (10, 20, 50, 100, 250, 500, 800 кбіт / с і 1 Мбіт / с). На канальному рівні прийняті стандарти Standard CAN і Extended CAN, які визначають формати повідомлень (Message Frame). Логічно вони ідентичні, але різняться числом розрядів в ідентифікатор повідомлення. У першому випадку їх тільки 11, у другому - 11 або 29. Забезпечується сумісність зверху вниз. Про ідентифікатори, родзинку CAN, ми поговоримо трохи пізніше.

Протоколи верхніх рівнів моделі, звані HLP (High Level Protocol), стали активно розвиватися тільки в останні роки, в зв'язку з масовим поширенням CAN, тепер уже поза традиційними автомобільних додатків. Як зазвичай буває в таких випадках, ці протоколи пропонуються і розвиваються компаніями-конкурентами. Крім того, з метою стандартизації створюються картельні комерційні і некомерційні організації. Можна нарахувати кілька десятків протоколів CAN HLP. Серед них найбільшого поширення набули CAL / CANopen, CAN Kingdom, DeviceNet і SDS (Smart Distributed System). Ці протоколи з вичерпною повнотою описані в [1]. Загальним для всіх протоколів HLP є стиснення всіх верхніх рівнів в один: для додатків CAN цього цілком достатньо.

Логіка роботи CAN

Принцип передачі даних в CAN часто, але не завжди, називають CSMA / BA (Collision Sense Multiple Access / Bitwise Arbitration). З першої частини назви випливає, що він відноситься до категорії CSMA (Carrier Sense, Multiple Access), де передбачається поділ доступу до носія шляхом його прослуховування. Успіх Ethernet зробив популярним інший варіант CSMA - з виявленням колізій CSMA / CD (Collision Detect). Другу ж частину назви CSMA / BA можна перевести як «побітно арбітраж»; в цьому красивому способі розв'язання колізій і полягає специфіка CAN.

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

Для поділу доступу до носія в CAN розроблений простий і разом з тим дуже надійний механізм доставки повідомлень. Слід виділити кілька основних ідей цього механізму.

• Дані віддаються квантовими повідомленнями стандартного формату (телеграмами), тому виключаються всі звичайні складності, властиві пакетної передачі з змінною довжиною пакетів. Кожне повідомлення містить тільки одне значення деякого фізичного параметра, наприклад, швидкість обертання валу або температуру рідини, назвемо це типом повідомлення, і ідентифікатор типу.
• Апріорно передбачається, що кількість станцій і кількість різних типів повідомлень відносно невеликі; в кінцевому рахунку, вони обмежені технологічною складністю об'єкта управління. При такому допущенні можна побудувати безадресну і абсолютно децентралізована систему, де жоден передавач не пов'язаний у своїй роботі з іншими. Іншими словами, має місце, на перший погляд, повна анархія, кожен котроллер намагається передати дані тоді, коли вважає це за необхідне, піклуючись зовсім не про те, хто буде наступником. Його завдання - передати. Тому всі приймачі змушені приймати всі повідомлення і відбирати за ідентифікатором тільки ті, які відповідають їх функціональної задачі. Скажімо, система управління запалюванням приймає повідомлення про швидкість обертання двигуна і ігнорує дані про роботу кондиціонера.

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

Data Frame - фрейм передачі даних: «Привіт усім, ось дані з ідентифікатором Х, отримаєте».

Remote Transmission Request Frame або просто Remote Frame - фрейм запиту даних: «Привіт усім, а чи може хто-небудь вислати дані з ідентифікатором Х?»

Error Frame - службовий фрейм помилки: «Стоп, почнемо все з початку».

Overload Frame - службовий фрейм перевантаження контролера: «Я дуже зайнятий, зачекайте трохи».

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

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

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

Але передавач і сам повинен бути якось повідомлений про успіх чи неуспіх своєї спроби, отримавши повідомлення від контрагентів. Для цієї мети в Data Frame є слот ACK (від англійського acknowledgment - «підтвердження»), куди будь-який з контролерів, прийнявши даний фрейм як адресований йому, може занести запис про прийом. Передавач відстежує стан цього слоту і, якщо він не заповнений, повторюватиме передачу до переможного кінця, поки підтвердження про прийомі не буде отримано.

дволикий ідентифікатор

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

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

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

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

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

CSMA / BA і інші способи розподілу каналів

Для того щоб порівняти CSMA / BA з іншими способами розділеного доступу до каналу, введемо дві дихотомії.

Перша з них - ставлення до ресурсу. Свого часу аналогічним чином вирішувалося завдання поділу доступу до центрального процесора. Будь-ресурс (процесора або носія) можна якимось чином квантовать за часом, виділяючи кожному учаснику обміну фіксований фрагмент (token slot, token passing). З іншого боку його можна виділяти в міру необхідності (за запитами) тому учаснику обміну, кому в даний момент він потрібен (CSMA / CD, Bitwise Arbitration, циклічні перестановки).

Друга дихотомія визначається ставленням до збереження переданих даних. Доступ до шини може бути неразрушающим, якщо шина виділяється по якимось принципом монопольно на інтервал часу одному з претендентів, і він доводить свою передачу до логічного кінця, зберігаючи дані (token slot, token passing, Bitwise Arbitration, циклічні перестановки). Навпаки, CSMA / CD і Ethernet відносяться до руйнуючих методів резервування каналів, при виявленні в них колізії перериваються всі беруть участь в ній передачі.

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

працездатності

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

Друга складова механізму контролю - «імплантація біта» (bit stuffing), захищає від зависань і інших «глюків». За умовами в ефір поспіль не може проходити більше п'яти бітів одного значення. Якщо їх набирається п'ять, то між ними вставляється додатковий, службовий шостий, який має протилежне значення, в подальшому він просто фільтрується приймачем. Але якщо його немає, то знову виробляється Error Frame.

Ще одна складова - моніторинг стану контролерів. Для контролера звичайним є активне по відношенню до помилок (error-active) стан, активне в тому сенсі, що воно передбачає здатність генерувати фрейм Error Frame. Але при цьому кількість породжених помилок постійно вважається самим контролером і, якщо воно досягає 96, то виробляється застережливий сигнал. Якщо ж значення лічильника помилок перевищить 127, то контролер переходить в пасивне (error-passive) стан, в якому він продовжує виконувати регулюючу функцію, підраховуючи і далі число помилок, але при цьому сигнал про помилки Error Frame видозмінюється і тепер складається з шести рецесивних біт і ні на що вплинути не в змозі. Якщо в процесі роботи кількість помилок скоротиться, впаде нижче 128, то контролер повертається в активний стан. Якщо ж число помилок ще більше зросте і досягне 256, то контролер відключається від мережі, переходячи в стан buss-OFF і чекаючи обслуговування.

Про ефективність цих механізмів можна судити за даними, які опубліковані в досить популярному і багаторазово передрукованому в Мережі документі [2]. У ньому оцінюється ймовірність виникнення помилок, не виявлених описаними методами; їх називають residual errors, тобто залишкові або непояснені помилки. Стверджується, що в середньої мережі, що складається з п'яти - десяти станцій, що працює по 8 годин 365 днів в році така помилка може виникнути один раз за тисячу років.

Базовий и повний

Існує два основні підході до архітектури інтерфейсу контролерів з Мережа. Перший - спрощений Basic CAN (BCAN), другий - більш складаний Full CAN (FCAN). Між ними є ще проміжне компромісне решение Direct storage CAN - DCAN. Два дерло розрізняються между собою механізмамі буферізації Повідомлень. Если врахуваті, что Кожна станція отрімує весь потік Повідомлень, что ціркулюють в мережі, то становится зрозуміло: значний частина процесорніх ресурсов контролера уходит на обробка Повідомлень. Можливі два виходи з цієї ситуації, перший - забезпечити контролер продуктивним процесором, який би справлявся з навантаженням, а другий - посилити логіку допоміжної частини контролера, що здійснює буферизацію і обробку повідомлень. Чим ефективніше механізм буферизації, тим менше навантаження на ЦП. Власне, ці дві полярні ідеї розвиваються в альтернативних рішеннях: BCAN - все навантаження на процесор, FCAN - мінімізація навантаження.

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

Інтеграція мереж CAN

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

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

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

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

Контролери з вбудованими функціями міжмережевого шлюзу сьогодні випускають дві компанії. З назви контролера TwinCAN виробництва Infineon Technologies (англійське twin означає «близнюк») слід, що він здатний підключатися до двох мереж одночасно. FCAN-контролер ELIZA виробництва компанії NEC включає 7 модулів підключення до мережі та шлюзування між ними.

література

1. А. Щербаков, Мережа CAN: популярні прикладні протоколи. ChipNews, 1999, № 5
2. Controller Area Network, A Serial Bus System. CAN in Automation.
3. Jens Eltze, Thomas Lee, Integrated Controller Area Network Applications. NEC Electronics.