1. Промислова мережа CANopen

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

Типові області застосування

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

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

Недолік: мала поширеність за межами Європи.

Структура стандартів

В основі протоколу прикладного рівня лежить документ DS.301, який у свою чергу є практичним розвитком ідей декларованих в документах CiA DS-201-207. Він визначає протоколи конфігурування та функціонування мережі.

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

Функціонування мережі - це обмін даними. Для розуміння функціонування мережі CANopen розділимо всі дані на функціональні та технологічні.

Функціональні дані - ті дані, які описують цільове функціонування системи (температура, величини керуючих впливів виконавчих механізмів), ті дані, які передавалися б між блоками, навіть якби як сполучної ланки використовувалася лінія звязку відмінна від CAN, наприклад, LIN або USB, або Ethernet, або I2C.

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

CMS - передача повідомлень. Сюди відносяться: обмін функціональними даними, обмін терміновими повідомленнями, обмін даними за запитом, управління обєктним словником;

NMT - управління мережею, контроль роботи пристроїв мережі;

DBT - динамічний розподіл ідентифікаторів;

LMT - управління конфігуруванням пристроїв;

1. Обмін функціональними даними в реальному часі ключове слово PDO, CMS (основна підсистема, в принципі необовязкова, але якщо не буде жодної з інших підсистем то дане порожня множина може називатися CANopen лише потенційно).

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

Асинхронний обмін даними. Включає обмін повідомленнями мережевого управління (керування вузлами мережі) Network Management, NMT Services, повідомленнями підсистеми контролю роботи мережі (варіант Виявлення помилок роботи мережі) Error Control, строковими повідомленнями - авральними обєктами (виявлення помилок роботи вузлів) Emergency Object, EMCY. Повідомлення цього класу можуть зявитися в будь-який момент часу, у тому числі і всередині вікна синхронного обміну даними. Дані повідомлення мають високий пріоритет (вище, ніж повідомлень, складових пакети даних), а колізії вирішуються на рівні фізичного рівня протоколу CAN. Для реалізації даних підсистем в мережі призначається (на етапі проектування мережі) пристрій відповідальна за роботу конкретної підсистеми. Крім цього є механізми динамічного призначення подібних пристроїв. Тепер докладно.

3. Управління вузлами мережі Network Management, NMT Services (необовязкова підсистема). Мережа може бути спроектована таким чином що після включення кожен прилад, завершивши ініціалізацію, перейде в стан готовності, але при цьому не буде брати участь в обміні функціональними даними до тих пір, поки майстер управління роботою мережі (NMT master) не дозволить його роботу. У стані готовності пристрій не приймає участь в обміні функціональними даними але може обмінюватися технологічними даними. У стані готовності пристрій може бути налаштоване (див далі Підсистема управління словником обєктів). За допомогою даної підсистеми майстер мережі може виконати скидання і перезапуск будь-якого з вузлів, для якого буде потрібно така процедура. Майстер отримує від приладу повідомлення, в яких вказано реальний стан приладу, якщо реальний стан не відповідає очікуваному, то це розцінюється як помилка. Реакції на помилки розглянуті нижче по тексту.

4. Контроль роботи мережі (виявлення помилок роботи мережі) NMT Error Control Protocols, Node Guarding, Heartbeat Protocol (необовязкова підсистема). Деякі системи (особливо повязані з безпекою) повинні контролювати наявність і справність всіх штатних датчиків.

Виявлення помилок роботи мережі проводиться двома подібними способами:

I. Караул вузлів Node Guarding. Майстер періодично опитує вузли, які відповідають. Як тільки вузол перестає відповідати, відзначається помилка для цього датчика, і майстер відповідно до логіки роботи може зупинити потенційно небезпечні процеси. Вузол, який не буде опитаний протягом певного часу (обірвалася лінія), також відзначає для себе помилку.

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

Для кожної конкретної мережі допускається використання тільки одного способу контролю або Node Guarding або Heartbeat Protocol.

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

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

Оскільки пристрої передають і приймають PDO повинні розуміти один одного, то може виникнути ситуація коли один пристрій буде працювати з новою структурою, а інше зі старою.

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

6. Зміна даних за запитом. Крім зміни словника додаток одного пристрою може завантажити дані в інший пристрій. Відмінність PDO і SDO обміну даними з точки зору програми. При обміні PDO все відбувається автоматично за певними правилами і додаток не звертаючи до мережевим примітивам отримує дані з змінних, як нібито дані виходять всередині е того самого приладу. Для отримання даних за принципом SDO додаток повинен за допомогою мережевих сервісів запросити дані в іншого пристрою, і тільки потім отримавши відповідь використовувати дані для роботи. Тому основу-хребет обміну даними слід будувати на PDO-обміні. На жаль є обмеження на розмір даних (8 байт для PDO, але можна використовувати кілька таких штук). І тільки при особливої необхідності використовувати SDO. При SDO обміні даними, пристрій до якого звернулися із запитом на отримання або запис (dowload / upload) даних називається SDO сервером, а пристрій яке ініціювало обмін називається клієнтом. Залежно від обсягу переданих даних, обмін здійснюється за різними алгоритмами, і може бути не менш ефективний ніж PDO обмін. SDO обмін допускає виробляти контроль безпомилковості даних, що дозволяє навіть завантаження шматків виконуваного коду.

7. Авральні обєкти, термінові сообщенія. Emergency Object, EMCY. У процесі роботи прилад може виявити помилки в роботі своєї програми, або в роботі електроніки. У такому випадку чим скоріше про це будуть оповіщені всі інші частини системи, тим буде краще і робота такої системи буде безпечніше. Для цієї мети використовуються високо пріоритетні термінові повідомлення. Такі повідомлення надсилаються в момент виявлення несправності, і в момент зникнення цієї несправності. Стандарт описує класи помилок, такими параметрами можуть бути Струм, напруга, температура. Якщо в мережі задіяний механізм термінових повідомлень, то пристрої зобовязані розуміти по край мірі два повідомлення - Загальна помилка (без уточнення категорій), скидання помилки. Кожен тип помилки може бути уточнений ще цілим байтом, який може кодувати наприклад номер контрольованої ланцюжка.

Обробка помилок. Базовий стандарт описує тільки способи оповіщення про помилки і задає категорії помилок. Подальші уточнення, і реакція на помилку визначається розробником системи.

Наведені вище пункти описуються в документах CiA DS-201-207 і CiA DS-301 Розробник системи «з нуля» може самостійно визначити функціональні вимоги до сітки, контрольовані параметри і сценарії поведінки при появі несправностей. Але оскільки CANopen мережі використовує велику кількість виробників, які вже розробили системи, що охоплюють безліч сфер промисловості, то зявилися рекомендації того, якими параметрами, як мінімум, повинна оперувати та чи інша система, і які типи реакцій на ті чи інші конкретні помилки, які властиві конкретного класу пристроїв. Дані рекомендації оформлені у вигляді стандартів серій CiA DS-4. Це дозволяє проводити не системи в цілому, а частини систем, і ці нові прилади будуть прекрасно інтегруватися з системами розробленими іменитими виробниками. Частина цих стандартів вже відкриті (усталені), частина залишаються надбанням невеликих груп виробників (нові, схильні змінам). Основна причина того що існує так багато закритих документів та, що це не просто рекомендації, але стандарти при недотриманні яких порушується працездатність системи. При внесенні змін до документів, нові версії розсилаються всім учасникам даної групи «за інтересами». Групи за інтересами не є замкнутою кастою, всі бажаючі можуть вступити в ту чи іншу групу. Обовязковою умовою є грошовий внесок. Стягуються суми залежать від розміру фірми, і є демократичними за відношенню до малого бізнесу.

2. Моделювання системи у середовищі Twidosuite

Рисунок 1 - Схематичний вигляд мікропроцесора

Код програми:

Рисунок 2

Рисунок 3

Рисунок 4

Рисунок 5

Рисунок 6

Рисунок 7 - Вигляд програми у середовищі TwidoSuite, виконаний графічною мовою програмування Ladder Diagram (LD)

Рисунок 8

програмний управління текстильний мікроконтролер

Рисунок 9

Рисунок 10 - Вигляд програми у середовищі TwidoSuite, виконаний мовою програмування Instructional List (IL)

Рисунок 11 - Список використаних параметрів у програмі