Протокол високого рівня canopen

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

У наш час налічується велика кількість інтерфейсів послідовної передачі даних. Деякі з них, наприклад, RS-232. USB. SPI. придбали величезну популярність завдяки своїм характеристикам або простоті використання. Інші ж не знайшли такого широкого поширення в електронних системах. До них можна віднести IEEE 1394. RS-449. Х.21. Деякі стандарти послідовних інтерфейсів і зовсім швидко забувалися після їх розробки, чого не можна сказати про стандарт CAN (Controller Area Network), розробленому в 1987 році німецькою компанією Robert Bosch GmbH і став, мабуть, найпопулярнішим інтерфейсом послідовної передачі даних в автомобільній галузі та промисловому обладнанні . Завдяки високій надійності, досить високій швидкості передачі даних (до 1 МБ / с) і гнучкості настройки і застосування, цей інтерфейс підтримується безліччю електронних пристроїв (промислові контролери, мікроконтролери, спеціалізовані мікросхеми, датчики). На сьогоднішній день останньою версією протоколу є CAN 2.0b.

Стандарт CAN описує поведінку сигналів на низькому рівні, причому у відриві від фізичного рівня, тобто для передачі даних можуть використовуватися різні середовища (мідний кабель, оптоволокно і т.п.). Для прискорення проектування мереж на основі CAN і стандартизації роботи таких мереж був розроблений протокол високого рівня CANopen. Він набув широкого поширення в промисловому обладнанні, транспортних засобах, медичному обладнанні, системах «розумний будинок». Цей протокол є відкритим, і документація по його використанню доступна кожному. DS.301 є основним документом, в якому описані основні положення і принципи роботи CANopen. У зв'язку з тим, що протокол орієнтований на використання в складі різних класів пристроїв, в документах CiA DS-4xx регламентується робота CANopen в кожному з них. Так, наприклад, CiA 412 відноситься до медичного обладнання, а CiA 417 - до систем управління ліфтами.

Топологія мережі CAN, принципи її роботи і формати кадрів докладно описані в [1] і [2], тому не має сенсу повторюватися, а варто перейти безпосередньо до розгляду протоколу високого рівня CANopen на базі даної мережі. На рисунку 1 показана функціональна схема зв'язку двох вузлів за допомогою шини CAN і протоколу CANopen.

# 65279; Комунікаційні рівні при з'єднанні двох вузлів.

Основною функціональною одиницею протоколу є об'єкт. Під об'єктом можна розуміти набір даних, що несуть інформацію про параметрах (наприклад, показання датчика температури), конфігурації вузла або мережі, що виникли помилки і т.п. Тому для пристрою (вузла) необхідною умовою роботи в мережі є наявність словника, що представляє собою групу доступних в певному порядку об'єктів. За своєю суттю, словник об'єктів - це сполучна ланка між додатком і переданої на фізичному рівні інформацією (Малюнок 2). З кожним пристроєм, що використовують інтерфейс CANopen, виробник повинен надати файл з розширенням * .eds (Electronic DataSheet), що містить словник об'єктів і додаткову інформацію.

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

Кожен об'єкт в словнику має 16-розрядний індекс і 8-розрядний підіндекс. За допомогою них можна посилатися на даний об'єкт. В Таблиці 1 показаний приклад опису ідентифікаційного об'єкта, що містить основну інформацію про пристрій.

Протокол CANopen передбачає існування таких типів об'єктів:

Сервісні об'єкти даних (SDO);
Об'єкти даних процесу (PDO);
Спеціальні функціональні об'єкти: об'єкт синхронізації (SYNC), тимчасова мітка, термінове повідомлення (EMCY);
Об'єкти управління мережею (NMT): NMT-повідомлення, повідомлення завантаження (boot-up), об'єкт контролю помилок.

Індекс параметра зв'язку SSDO = 1200h + № SSDO - 1;
Індекс параметра зв'язку CSDO = 1280h + № CSDO - 1.
Сервіси, що реалізують SDO-передачу, можуть бути наступними:
Завантаження на SDO-сервер (download), що складається з етапу ініціалізації завантаження і безпосередньо завантаження сегментів;
Вивантаження з SDO-сервера (upload), що складається з етапу ініціалізації вивантаження і безпосередньо вивантаження сегментів;
Аварійне завершення передачі SDO.

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

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

Індекс параметра зв'язку RPDO = 1400h + № RPDO - 1;
Індекс параметра зв'язку TPDO = 1800h + № TPDO - 1;
Індекс структурного параметра RPDO = 1600h + № RPDO - 1;
Індекс структурного параметра TPDO = 1A00h + № TPDO - 1.

За допомогою одного PDO можна передати від 1 до 8 байт даних. В одній мережі CANopen може бути присутнім до 512 TPDO і до 512 RPDO.

PDO можуть передаватися як синхронно, так і асинхронно щодо об'єкта синхронізації SYNC, видатного на шину з певною періодичністю. Це проілюстровано Малюнком 5. Синхронні PDO передаються в рамках встановленого інтервалу часу після появи на шині SYNC-об'єкта.

# 65279; Принцип передачі синхронних і асинхронних PDO.

Асинхронні PDO передаються без будь-якого зв'язку з об'єктом синхронізації. Розрізняють також три режими виклику PDO (Малюнок 6):

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

Передача синхронних PDO може виконуватися як в циклічному режимі, так і ациклічності. При виборі циклічного режиму PDO передаються з певною періодичністю, яка встановлюється числом від 1 до 240, т. Е. 5 означатиме передачу PDO після кожного п'ятого появи SYNC-об'єкта на шині. У ациклічності режимі момент видачі PDO на шину визначається внутрішнім подією пристрою, але вона обов'язково повинна виконуватися у вікні SYNC-об'єкта.

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

Іншими об'єктами, без яких неможливе існування CANopen-мережі, є NMT-об'єкти, що дозволяють управляти роботою цієї мережі. Спочатку варто відзначити, що в конкретний момент часу потрібно перебувати в одному з чотирьох станів: ініціалізація (Initialization), готовність (Pre-operational), робота (Operational) або зупинка (Stopped). При включенні пристрій проходить етап внутрішньої ініціалізації, і після її успішного завершення переходить в стан готовності. У цьому стані вже можливо здійснити настройку CANopen-вузла за допомогою SDO. Потім вузол може перейти в робочий стан. Для цього необхідно, щоб Master мережі (передача NMT повідомлень відбувається відповідно до моделі Master-Slave) передав широковещательное повідомлення Start_remote_node. ID NMT-повідомлень дорівнює 0, оскільки вони повинні мати найвищий пріоритет у мережі. У Таблиці 2 представлено опис NMT-повідомлень.

Для підвищення надійності функціонування мережі є об'єкти термінових повідомлень (Emergency Object або EMCY). Їх передача здійснюється при виникненні внутрішніх помилок будь-якого вузла. Термінове повідомлення передається в мережу лише один раз після виникнення певної помилки, і, як би довго стан активної помилки не було присутнє, нового відповідного їй EMCY передано не буде. Тільки при виникненні нових помилок можуть бути передані відповідні їм EMCY. Механізм передачі термінових повідомлень не є обов'язковим для мережі CANopen, але при грамотному його застосуванні він дозволить вчасно визначити і усунути несправність вузла.

Все Slave-пристрої в складі мережі CANopen можуть посилати спеціальне повідомлення про свою готовність функціонування в мережі. Це повідомлення початкового завантаження (boot-up message) дає зрозуміти Master-пристрою, що внутрішній мережевий статус Slave-вузла перейшов з режиму ініціалізації в режим готовності до роботи. Передача boot-up-повідомлення є також необов'язковою, але бажаної процедурою, оскільки Master знатиме, що конкретне Slave-пристрій вже можна налаштовувати за допомогою SDO або переводити його в режим роботи.

Інтерфейсом CANopen передбачені два протоколи контролю функціонування мережі: протокол варти вузлів (Node guarding protocol) і протокол контрольного тактирования (Heartbeat protocol). У першому випадку виділений NMT-майстер опитує Slave-пристрої через однакові проміжки часу, звані guard time. У відповідь кожне Slave-пристрій посилає повідомлення, що містить його мережевий статус. Час очікування подібного повідомлення може бути налаштоване індивідуально для кожного вузла. Якщо вузол автоматично через певний час не отримав запит від Master-пристрої, на його стороні за допомогою сервісу Life Guarding Event виникне помилка, яка свідчить про відсутність сторожового запиту. Якщо віддалений запит передачі не була підтверджена за час сторожового очікування, або вказаний у відповідному повідомленні статус Slave-пристрої не відповідає очікуваному, з боку Master-пристрої виникне помилка варти вузла, що повідомляється за допомогою сервісу Node guarding event.

Heartbeat-протокол дозволяє контролювати функціонування мережі без необхідності посилки Slave-пристроями віддалених відповідей. В даному випадку вузол, сконфігурованих на трансляцію передачу Heartbeat-повідомлення, є виробником контрольних тактів. Решта пристрої, налаштовані на прийом Heartbeat-повідомлення, є споживачами контрольних тактів, і в разі якщо за час очікування контрольного такту (Heartbeat Consumer Time) Heartbeat-повідомлення не прийшло, генерується помилка контрольного тактирования. Обидва розглянутих протоколу контролю функціонування мережі є взаємовиключними, тобто в мережі можна використовувати лише один з них. Heartbeat-протокол має більш високий пріоритет, і за замовчуванням передбачається використання саме його.

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