ТЕХНОЛОГІЯ ДІАГНОСТУВАННЯ НА БАЗІ CAN

ТЕХНОЛОГІЯ ДІАГНОСТУВАННЯ НА БАЗІ CAN-МЕРЕЖІ

CAN протоколи високого рівня та їх різновиди

CAN протокол отримав всесвітнє визнання як дуже універсальна, ефективна, надійна і економічно прийнятна платформа для майже будь-якого типу зв'язку даних у пересувних системах, машинах, технічному обладнанні і індустріальної автоматизації. Заснована на базі протоколів високого рівня CAN-технологія успішно конкурує на ринку розподілених систем автоматизації. Під термінами «CAN стандарт» або «CAN протокол» розуміються функціональні можливості, які стандартизовані в ISO 11898. Цей стандарт об'єднує фізичний рівень (Physical Layer) і рівень каналу даних (Data Link Layer) відповідно до 7-ми рівневої OSI моделлю. Таким чином, «CAN стандарт» відповідає рівню мережевого інтерфейсу в 4-х рівневої моделі TCP/IP. Проте, практична реалізація навіть дуже простих розподілених систем на базі CAN показує, що крім сервісів, що надаються рівня каналу даних потрібні більш широкі функціональні можливості: передача блоків даних довжиною більше ніж 8 байтів, підтвердження пересилання даних, розподіл ідентифікаторів, запуск мережі і функції супервізора вузлів. Так як ці додаткові функціональні можливості безпосередньо використовуються прикладним процесом, вводиться поняття рівня додатків (Application Layer) і протоколів високого рівня [7]. Протокол діагностування CAN приведений на рисунку1.

OSI модель протоколів високого рівня на базі CAN, протоколів TCP/IP. Для систем реального часу на базі CAN немає необхідності в реалізації повної 7-ми рівневої моделі OSI. (Це пов'язано з тим, що типова CAN система має в своїй основі єдиний канал даних для обміну повідомленнями між пристроями, всі пристрої орієнтовані на конкретний спосіб передачі даних по каналу, а додатки пишуться саме під цю архітектуру мережі і даний протокол (рисунок 2).

Рисунок 1 - Протокол діагностування CAN у легковому автомобілі

OSI модель протоколів високого рівня на базі CAN, протоколів TCP/IP. Для систем реального часу на базі CAN немає необхідності в реалізації повної 7-ми рівневої моделі OSI.

Рисунок 2 – Мережевий рівень

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

Через широкого використання CAN мереж з різними цілями і вимогами існують кілька головних стандартів CAN-протоколів високого рівня CAL (CAN Application Layer), OSEK/VDX, SAE J1939, CANopen, DeviceNet, SDS (Smart Distribution Systems), CAN-Kingdom. Далі більш докладно буде розглянуто стандарт DeviceNet для порівняння з TCP/IP.

Рисунок 3 - CAN моделі

1.1 Основні можливості протоколів високого рівня на базі CAN. Розглянемо основні можливості, які надають протоколи високого рівня:

• система призначення ідентифікатора для повідомлення;

• метод обміну даних процесу;

• пряма (peer-to-peer) зв'язок;

• метод встановлення зв'язків для обміну даних процесу;

• мережеве управління;

• ідентифікатори повідомлень.

Метод призначення ідентифікатора повідомлення є головним архітектурним елементом CAN систем, так як ідентифікатор CAN-повідомлення визначає відносний пріоритет повідомлення і отже час обробки повідомлення (latency time). Це також впливає на можливість застосування фільтрування повідомлення, на використання можливих комунікаційних структур та ефективність використання ідентифікатора. Що стосується призначення ідентифікаторів повідомлень, існують різні підходи для систем на базі CAN. Деякі (CANopen) не застосовують приречення ідентифікаторів для спільних структур системи, DeviceNet і SDS роблять це. Прилади (nodes) в DeviceNet отримують постійний ідентифікатор. Максимальна кількість вузлів становить 64. Кожен вузол має деяка безліч ідентифікаторів в одній з 3-х груп в залежності від пріоритету повідомлення (таблиця 1).

Таблиця 1 - Експлуатаційно-технічні характеристики STBD

0	Група 1 ідентифікатор повідомлень					Джерело MAC ID	група 1
1	0	MAC ID				Група 2 ідентифікатор повідомлень	група 2
1	1	Група 3 ідентифікатор повідомлень				Джерело MAC ID	група 3
1	1	1	1	1	Група 4 ідентифікатор повідомлень		група 4

Група 1 повідомлень забезпечує до 16 високо пріоритетних повідомлень на пристрій, група 3 повідомлень - до 7 низько пріоритетних повідомлень на пристрій. Група 2 повідомлень призначена для підтримки пристроїв з обмеженими здібностями фільтрування повідомлень. Тому для цієї групи ідентифікаторів було вибрано фільтрування згідно з номером вузла (MAC-ID). Це означає, що пріоритет повідомлень цієї групи прямо визначається номером вузла. MAC-ID групи 2 може бути адресою джерела або адресою призначення.

DeviceNet використовує також зумовлене Master/Slave безліч зв'язків для полегшення взаємодії в Master/Slave системної конфігурації (таблиця 2).

Таблиця 2 - Системна конфігурація зв'язків

Ідентифікатор байтів															Ідентифікатор використання
10	9	8	7	5		6	4	3	2		1		0
0	Група 1 ідентифікатор повідомлень								Джерело MAC ID						Група 1 повідомлення
0	1	1	0	1		Джерело MAC ID									Приймач зі зміни повідомлення
0	1	1	1	0		Джерело MAC ID									Видача відповіді на запит
0	1	1	1	1		Джерело MAC ID									Відповідь опитаних повідомлень
1	0	MAC ID			Група 1 ідентифікатор повідомлень										Група 2 повідомлення
1	0	Джерело MAC ID								0		0		0	Майстер команд вводу/виводу повідомлень
1	0	Джерело MAC ID								0		0		1	Зарезервовані для використання TBD
1	0	Призначення MAC ID								0		1		0	Зміна стану або циклічні повідомлення
1	0	Джерело MAC ID								0		1		1	Видача відповіді на запит
1	0	Призначення MAC ID								1		0		0	Запит повідомлень
1	0	Призначення MAC ID								1		0		1	Опитування/ зміна стану/циклічні повідомлення
1	0	Призначення MAC ID								1		1		0	Тільки група 2 (не пов’язаних з повідомленням запиту)
1	0	Призначення MAC ID								1		1		1	Дублікат MAC ID перевірити повідомлення

Явний канал повідомлень головним чином служить для конфігурації пристрою. Зі зміною Master статусу каналу Master може запитувати дані введення - виведення від пристрою і посилати дані на Slave пристрій. C зміною Slave статусу каналу Slave пристрій може передати дані Master-пристрою. За допомогою Bit Strobe команди Master-пристрій може запросити дані у будь-якого з 64 Slave пристроїв за допомогою одного повідомлення.

Підтримуються наступні функції каналу обміну I/O повідомленнями і явними (Explicit) повідомленнями між Master і Slave пристроями з визначеного безлічі зв'язків:

• явний канал повідомлень;

• зміна Master статусу каналу (Майстер команд введення/виведення

• повідомлень);

• зміна Slave статусу каналу (Зміна стану або циклічні повідомлення);

• Bit Strobe канал.

Oбмін даних процесу. Передача даних процесу між пристроями розподіленої системи - мета системи на основі CAN протоколу. Тому передача прикладних даних (дані процесу, дані введення - виведення) системи повинна бути виконана найбільш ефективним шляхом [8]. CANopen і DeviceNet забезпечують вельми схожі механізми зв'язку для передачі даних обслуговування/конфігурації процесу. У CANopen передача даних процесу відбувається за допомогою так званих «Об'єктів Даних Процесу (PDOs)», у DeviceNet допомогою «I/O-повідомлень».

Одним з головних відмінностей є забезпечення протоколами DeviceNet and SDS фрагментації пакетів без підтвердження, що робить можливим передачу даних довжиною більше 8 байт. Всі розглянуті протоколи підтримують різні способи виклику повідомлень. DeviceNet підтримує циклічний (Cyclic), за станом (Change-of-State) і програмний (Application) способи виклику. Циклічний виклик здійснюється по закінченню часу таймера і починається передача повідомлення. Передача станом починається, коли статус певного об'єкта змінюється. У цьому випадку повідомлення також передається, коли спливає визначений інтервал часу, в якому не здійснювалася передача повідомлення. Програмним способом сам об'єкт вирішує, коли почати передачу повідомлення. У цьому випадку повідомлення також передається, коли спливає визначений інтервал часу без передачі повідомлення. Встановлення відповідностей (mapping) для програмних об'єктів. Мережеві пристрої зазвичай містять більше одного програмного об'єкту і передача I/O повідомлення більш ніж одному програмному об'єкту всередині одного PDO є необхідною вимогою. У DeviceNet об'єднання прикладних даних здійснюється за допомогою трансляційних (assembly) об'єктів, які визначають формат переданих даних. Пристрій може містити більше одного I/O трансляційного об'єкта та вибір відповідного (consumed/produced_connection_path) може бути настроюваної опцією пристрою.

1.2 Прямі (peer-to-peer) комунікаційні канали. Для конфігурації пристроїв за допомогою конфігураційних засобів потрібні спеціальні функції у пристроїв або програми, що забезпечують багатоцільові канали зв'язку. Це не критичні за часом канали зв'язку. Передача даних в них здійснюється за допомогою протоколу з підтвердженнями і фрагментацією. Будь-який з протоколів високого рівня, які підтримують деяку конфігурацію пристроїв, повинні забезпечувати цей вид зв'язку. У запиті сервісу вказується номер класу, номер екзем (instance), номер атрибуту (в полі Service specific arguments). DeviceNet забезпечує багатоцільові пристрій орієнтовані канали і сервіси. Запис і читання атрибутів об'єктів, контролювання об'єктів (reset, start, stop etc.), Збереження/відновлення атрибутів об'єктів здійснюється за допомогою явних (Explicit) повідомлень. Намір використовувати дане повідомлення визначається в полі даних CAN.

Explicit (пряма) зв'язок встановлюється за допомогою менеджера повідомлень (Unconnected Message Manager (UCMM)). UCMM надає два сервіси для відкривання і закривання подібних сполук. Кожен пристрій, що підтримує UCMM, резервує у себе код повідомлення для запитів та відповідей для UCMM. Для пристроїв 2-ї групи, які не підтримують UCMM порт, master пристрій спершу має розмістити Explicit з'єднання в зумовленому безлічі сполук. Запит до пристрою групи 2 передається як Explicit запит без попереднього встановлення з'єднання (Unconnected Explicit Request) із зарезервованим ідентифікатором повідомлення.

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

У системі з наперед визначеним безліччю повідомлень "функції" і ідентифікатори повідомлень вже визначені. DeviceNet також використовує зумовлене безліч повідомлень для системи зі структурою 1: n. Master пристрій, попередньо розмістивши у себе безліч зв'язків зі Slave пристроями, «знає» ID повідомлень для передачі запиту та ID повідомлень для отримання відповіді, який включає Slave MAC-ID відповідно до визначеним безліччю зв'язків. Також можливо не визначати ідентифікатори повідомлень.

1.4 Мережеве управління. Так як в CAN-мережі ми маємо справу з розподіленими додатками, повинні відстежуватися певні події (відмови різних частин програми або відмову пристроїв). Тому головними завданнями мережевого управління стають виявлення та виведення помилок у мережі та надання сервісів, що дозволяють контролювати статуси пристроїв і вести координацію пристроїв. У залежності від системних рішень мережеве управління може вестися явним або непрямим шляхом. У DeviceNet кожне з'єднання контролюється. Тому кожна очікує повідомлення кінцева точка має «Inactivity/Watchdog» таймер, щоб контролювати прибуття повідомлення згідно зумовленого часу очікування. Якщо час закінчується, з'єднання виконує дію «Timeout». На рисунку 4 показано діаграма зміни станів у об'єкта I/O.

Рисунок 4 - Підключення стан об'єкта діаграми переходів

Після отримання виклику CREAT (Explicit повідомлення) з'єднання налаштовується за допомогою відповідної послідовності викликів явних повідомлень і після цього встановлюється. Перед отриманням доступу до мережі кожен пристрій має здійснити перевірку на дублікат свого MAC-ID. Певні алгоритми вибору гарантують унікальність MAC-ID.

Контроль може здійснюватися також за допомогою Heartbeat повідомлення, яке може надсилатися пристроїв за допомогою UCMM у формі повідомлення. У поле даних цього повідомлення передається стан пристрою. Heartbeat повідомлення викликається об'єктом Idendity.

1.5 Файли пристроїв. Крім опису функціональності пристроїв модель пристрою повинна також містити ряд важливих параметрів (статус, діагностичну інформацію, комунікаційні можливості, конфігураційні параметри і т.д.). На рисунку 5 показана модель устрою DeviceNet.

DeviceNet файл повинен містити наступну інформацію:

• модель об'єкта для пристрою;

• формат даних I/O для пристрою;

• конфігураційні дані і зовнішні інтерфейси для цих даних.

Рисунок 5 - Модель устрою DeviceNet.

Таблиця 2 - Мережевої об'єктної моделі

Об’єкт	Функції
Зв'язок	Примірник з’єднання (I/O або явний обмін повідомленнями)
Пристрій об’єкта	Підтримує конфігурацію і статус фізичного вкладення об’єкта
Маршрутизатор повідомлень	Маршрути отримали явні повідомлення до відповідного об’єкту
Збір даних	Групи атрибутів декількох об’єктів в одному блоку даних, які можуть бути відправленні й отримані через одне з’єднання
Параметри	Забезпечує стандартні засоби для налаштування пристрою і доступ до атрибутів
Тотожність	Надає загальну інформацію про пристрій
Додаток	Конкретний додаток поведінки і даних

Протокол CAN застосовується в real-time системах для вирішення різних завдань. На даний момент розвиваються кілька видів CAN протоколів високого рівня, таких як CAL, OSEK/VDX, SAE J1939, CANopen, DeviceNet, SDS, CAN-Kingdom, в основі яких лежить канальний протокол CAN2.0 (Bosch), і на основі цих протоколів можна вирішувати проблеми, що виникають у real-time системах, які неможливо вирішити за допомогою інших відомих протоколів, скажімо, TCP/IP.

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

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

CANopen є ідеальною мережевою системою для всіх типів автоматизованого устаткування. Одна з чудових характеристик CANopen - підтримка обміну даними на рівні управління пристроїв (PLC і ін) і підключення дуже маленьких датчиків (сенсорів) і виконавчих механізмів (актюаторів) до тієї ж самої фізичної мережі. Це дозволяє уникнути непотрібного витрати кабелю, що зв'язує шину системи сенсор/активатор з більш високою мережею зв'язку, що робить CANopen дуже привабливим для виробників специфічного устаткування. Структура CANopen відповідно до моделі ISO/OSI показана на рисунку 6.

Рисунок 6 - Базова архітектура додатка, розробленого на основі CANopen

CANopen, ґрунтуючись на ISO 11898, визначає стандартні механізми зв'язку та функціональні можливості пристроїв, що підтримують CAN. Таке сімейство розроблено, підтримується CiA і складається з профілю зв'язку CANopen (CiA DS-301) і різних профілів пристроїв (CiA DS-40x).

Протокол CANopen (профіль зв'язку) CANopen визначає кілька методів прийому та передачі повідомлень по шині CAN.

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

• адміністративні повідомлення мережі, такі як повідомлення управління мережею (NMT), повідомлення управління рівнями (LMT), повідомлення розподілу ідентифікаторів (DBT);

• повідомлення сервісних даних SDO (Service Data Object);

• повідомлення даних процесу PDO (Process Data Object);

• зумовлені повідомлення, такі як об'єкт синхронізації SYNC, об'єкт штампа часу TIME STAMP і об'єкт аварії EMERGENCY.

Адміністративні повідомлення дозволяють проводити ініціалізацію, конфігурування та управління у мережі, виконувати настанови специфічних параметрів різних рівнів. Сервіс та протоколи цих функцій базуються на протоколі CAN Application Layer (CAL). Профіль зв'язку CANopen визначає два механізми передачі даних - повідомлення типу SDO і типу PDO. Вони володіють різними характеристиками і призначені для покриття всього діапазону вимог, що використовуються в задачах автоматизації (дивись. таблицю 2).

CAN в автомобілебудуванні. Поточні роботи по стандартизації CAN-протоколу для автомобільних додатків виконуються, головним чином, трьома організаціями: ISO, американським Товариством інженерів автомобілебудування SAE (Society of Automotive Engineers) і міжнародною групою "Відкриті системи і відповідні інтерфейси для автомобільної електроніки" OSEK/VDX

1.7 Оперативні групи ISO. Вищезазначена робоча група ISO/TC22/SC3/WG1 в даний час продовжує працювати над шістьма різними стандартами для автомобільних додатків, заснованих на CAN-протоколи. Робота організована таким чином, що кожна оперативна група TF (Task Force) відпрацьовує кожну з тем. Завдання кожної TF - "видати на-гора" міжнародний стандарт для автомобілебудування.

Група TF1, іменована "Diagnostic services" (Діагностичний сервіс) - розробила стандарт: ISO 14230 Road vehicles - Diagnostic systems - Keyword protocol 2000 (Транспортні засоби. Системи діагностики. Протокол KWP 2000). Цей стандарт визначає діагностичний сервіс та протоколи зв'язку для транспорту, що використовує шину CAN.

1.8 Оперативні групи ISO. Група TF2 - "Diagnostics on CAN" (CAN-шина дігностікі) - займається стандартизацією CAN-протоколу для діагностичних автомобільних додатків.

Таблиця 3 порівняння SDO і PDO типу повідомлення.

Характеристика повідомлень	PDO	SDO
Призначення	Використовується для обміну даними в реальному часі	Використовується для обміну даними
Види повідомлень	Синхронні та асинхронні повідомлення	Асинхронні повідомлення
Види передачі	Циклічна та ациклічна передача
Ідентифікація	Високопріоритетні ідентифікатори	Низькопріорітетні ідентифікатори
Оптимізація	Оптимізовані для високошвидкісного обміну даними
Сервіси		Підтверджений сервіс
Максимальна довжина повідомлень	Максимальна довжина 8 байт	Можливість мультелеграмних повідомлень
Особливості повідомлень	Формат повинен бути узгоджений між партнерами зв’язку	Використовується індекс і субіндекс для посилання на поле даних у словнику об’єктів

Зокрема, група визначає протокол транспортного рівня (рівень 4 моделі ISO/OSI стандарту ISO/IS 7498), який дозволяє використовувати діагностичний сервіс на CAN-шину. Причому стандарт буде підтримувати як однопровідну середу передачі в рухомому транспорті, так і нормальну (двухпроводную) CAN-шину.

Група TF4 - "Truck and Trailer interfaces" (Інтерфейси вантажівок і причепів) - опублікувала стандарт ISO/DIS 11992 Road vehicles - Electrical connections between towing and towed vehicles - Interchange of digital information (Транспортні засоби. Електричні з'єднання між буксируються і буксируваним засобом. Обмін цифровою інформацією). Цей стандарт визначає безпечну зв'язок для вантажівок та причепів. Стандарт базується на ISO 11898 (високошвидкісний CAN-протокол), але визначає новий фізичний рівень, який більше відповідає жорстким вимогам до електромережі вантажівок і причепів. ISO 11992 також визначає прикладний рівень (рівень 7 моделі ISO/OSI стандарту ISO/IS 7498) для різного транспортного обладнання (наприклад, система гальмування). Мета цієї роботи - стандартизувати обладнання від різних виробників для використання у вантажівках і причепах на основі CAN-мережі.