КОНЦЕПЦИЯ СЕТИ КОНТРОЛЛЕРОВ И ПРОТОКОЛА CANOPEN

Во многих случаях при проектировании сетей у сетевых инженеров возникают проблемы, такие как: сетевая маршрутизация, эффективный дизайн сети, качество обслуживания и незнакомые настройки. В результате, инженеры начали разрабатывать несколько сетевых шин, чтобы быстро и эффективно передавать, и принимать данные. Сегодня на рынке доступны многие протоколы сетевой шины, такие как Profibus, Modbus, HART, Ethernet и т. д. В зависимости от требований и приложений, которые пользуется спросом, можно использовать любой из этих открытых протоколов. CAN и CANopen  как раз являются такими открытыми протоколами. CAN и CANopen управляются некоммерческой организацией, известной как сеть контроллеров в атоматизации (CiA), основанной в Нюрнберге (Германия). Сегодня CiA - это группа, включающая более 500 международных компаний.

1. История CAN и CAN Open

Сеть контроллеров (CAN) была первоначально разработана в феврале 1986 года Робертом Бошем и была представлена как «Автомобильная сеть с последовательным контроллером» на Международном конгрессе и выставке общества автомобильных инженеров (SAE) в Детройте, как новая система шин. Инженеры Боша Уве Киенке, Зигфрид Дайс и Мартин Личел были новаторами в создании этого сетевого протокола. Он был основан на неразрушающем арбитражном механизме, который обеспечивает доступ к шине сообщения с наивысшим приоритетом без каких-либо задержек [20, с. 2]. Этот автомобильный серийный CAN-протокол был введен в связи с тем, что автомобили требовали дополнительных затрат на проводку для увеличенного количества распределенной системы управления, а также что ни один из существующих протоколов не мог удовлетворительно работать для инженеров-автомобилестроителей [1, с. 10] [2, c. 22]. Одним из первых применений CAN были антиблокировочная система (ABS) и управление заносом ускорения (ASC). Например, в ASC требуется синхронизация двигателя и управление карбюратором при проскальзывании, и наоборот [19, c. 5]. Он был впервые разработан для автомобильной промышленности, кроме того, он широко разрабатывался и для других секторов автоматизации и сегодня используется в других самых разнообразных приложениях встраиваемых систем [1, с. 20] [2, с. 3]. Первая аппаратная реализация CAN-протокола была разработана корпорацией Intel в середине 1987 года в виде микросхемы контроллера 82526, который выступает за концепцию FullCan по сравнению с реализацией BasicCAN, выбранной Philips 82C200. Поставщики полупроводников, которые внедрили CAN-модули в свои устройства, были в основном сконцентрированы на автомобильной промышленности, и с середины 1990-х годов компании, подобные технологии Infineon и Motorola, изготовили и поставили большое количество чипов CAN-контроллеров для европейских производителей легковых автомобилей и их поставщиков [20, с. 44].

В 1993 году, в рамках проекта ASPIC Esprit, европейский консорциум во главе с Bosch разработал прототип того, чем должен стать CANopen. Это был профиль на основе контроллера прикладного уровня (CAL) для внутренней организации производственных ячеек. В одном из самых успешных мероприятий Esprit, когда-либо существовавших, академики доктор Герхард Грухлер из Университета прикладных наук в Ройтлингене (Германия) и доктор Мохаммед Фарси из Университета Ньюкасла (Великобритания) приняли участие в этом проекте Espirit. После завершения проекта спецификация CANopen была передана CiA для дальнейшей разработки и обслуживания [20, с. 60]. В 1995 году был полностью переработан профиль связи CANopen, и к 2002 году он был признан, как CENELEC EN 50325-4. После его выпуска он нашел широкое признание, особенно в европейских странах, где CANopen считается ведущим стандартом для CAN-приложений и решений для отраслей промышленности. Протокол CANopen – это, с одной стороны, стандартизованный протокол, но с другой стороны этот протокол по-прежнему открыт для неограниченных областей приложений. Он разработан как протокол более высокого уровня. Протокол CANopen, который в основном базируется на CAN-технологии, установил связь между устройствами разных производителей с гарантией взаимозаменяемости устройств. Этот протокол определил стандартные наборы приложений для всех видов распределенных систем, которые основаны на базовом CAN-протоколе [12, с. 32] [3, с. 23].

Резюме:

• 1983: Bosch начинает внутренний проект по созданию автомобильной сети.
• 1986: Введение протокола CAN.
• 1987: Первый чип CAN-контроллера от Intel и Phillips Semiconductors.
• 1991: Опубликована спецификация Bosch CAN 2.0.
• 1991: Протокол CAN высокого уровня
• 1992: Создана группа пользователей и производителей CAN в области автоматизации (CiA).
• 1992: Протокол CAN Application layer (CAL), опубликованный CiA.
• 1992: Первые автомобили использовали сеть CAN.
• 1993: Опубликован стандарт ISO11898.
• 1994: 1-я Международная конференция CAN (ICC), организованная CiA.
• 1995: Опубликована поправка ISO11898 (расширенный формат кадра).
• 1995: Протокол CANopen, опубликованный CiA.
• 2000: Разработка протокола связи для CAN (TTCAN) [20]

2. CAN и CANopen протокол

CAN протокол

CAN - это система последовательной шины, которая особенно подходит для организации сети нескольких интеллектуальных устройств. Это последовательная шина с возможностями нескольких ведущих элементов, то есть в любой момент времени несколько CAN-узлов или устройств пытаются передать данные [18, с. 5].

CAN протокол может интерпретироваться как двухуровневый протокол с точки зрения эталонной семиуровневой модели OSI / ISO. Другими словами, CAN работает на физическом уровне и канальном уровне стандартной модели OSI [18, с. 13]. Физический уровень определяет способ передачи сигнала. Международная организация по стандартизации (ISO) определила стандарт ISO11898, который включает спецификации CAN для удовлетворения некоторых требований [19, с. 42], а именно физической сигнализации, которая включает в себя кодирование и декодирование битов (Non-Return-to-Zero, NRZ) так же как битовая синхронизация и обычная синхронизация [20, с. 17]. Используя сетевые механизмы последовательной шины, существующие CAN-приложения отправляют сообщения по сети [4, с. 33]. В системах CAN нет необходимости в центральном контроллере, поскольку каждый узел подключен к каждому другому узлу в сети.

Возможности протокола CAN, в основном, включают в себя функции мультимастера и возможность широковещательных/многоадресных телеграмм [21]. Возможность многосвязной коммуникации с несколькими ведущими устройствами CAN заключается в том, чтобы каждый узел в равной степени обменивался информацией с любым другим узлом в системе и, следовательно, любой узел мог отправлять сообщения на каждый другой узел в системе [5, с. 23]. В случае сбоя какого-либо узла/устройства другие узлы/устройства в сети берут на себя ответственность за завершение связи, чтобы поддерживать работу системы. Если шина занята, узел, желающий отправить сообщение, ждет, пока шина не станет доступна [7, с. 12]. Каждое сообщение имеет свой уникальный идентификационный номер, который доступен для всех других узлов в системе. Узел выбирает только сообщения, относящиеся к системе, и игнорирует остальные. Первоначально протокол CAN был разработан для коротких сообщений, длина которых всего 8 байт, а выше – было недопустимо [5, с. 19]. Определенный протокол не нарушает текущую связь, а только присваивает приоритеты всем сообщениям, которые должны быть доставлены, чтобы сообщения, которые являются срочными, доставлялись в первую очередь во избежание конфликтов. Протокол CAN включает в себя надежные механизмы обнаружения ошибок и механизм ограничения отказов, что делает систему очень надежной. В сети шины, когда какой-либо узел выходит из строя, он удаляется из системы, не затрагивая остальную сеть, в результате чего система обеспечивает большую надежность. [8, с. 20]. Сеть CAN-систем работает по-разному по сравнению с другими сетями, такими как USB или Ethernet, так как в CAN нет центрального ведущего устройства шины; Здесь каждый узел имеет те же полномочия и функциональность. Интерфейс между последовательной шиной CAN и CAN-приложением обеспечивается CAN-контроллером, который преобразует данные, предоставленные приложением, в CAN-кадр, который затем передается по последовательной шине CAN [7, с. 21] [8, с. 24]. Физическое соединение CAN-контроллера с CAN-шиной выполняется с помощью CAN-трансивера, который соответствует ISO11898, например Phillips 82C250, который широко используется для реализации CAN [19, с. 15]. Контроллер передает последовательный входной поток в трансивер, который преобразует его в различные дифференциальные сигналы [3, с. 31] [5, с. 26]. На физическом уровне приведенные дифференциальные сигналы передаются по последовательной шине CAN с помощью двухпроводной шины высокой линии (CAN-High) и низкой (CAN-Low) с общим возвратом, чтобы преодолевать проблемы прерывания шума путем переноса сигналов с противоположной полярностью [18, с. 19]. Приоритет доступа к шине определяется 11-битным идентификатором, используя метод бит-арбитража, используемый в сети CAN. Все сообщения в сети принимаются контроллером CAN, которые передаются по шине [9, с. 21]. Контроллер использует механизм фильтрации, чтобы решить и выбрать соответствующую информацию для взаимодействия с интерфейсом, чтобы перейти к дополнительной информации [9, с. 17]. Перспектива CAN, таким образом, безопасна из-за низкой стоимости его компонентов, высокой надежности данных и короткого времени реакции вместе с огромной пользовательской базой [21, с. 28].

Итак, протокол CAN имеет следующие свойства:

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

повторная передача поврежденных сообщений автоматически, как только шина снова простаивает;

• различие между временными ошибками в узлах и постоянными отказами узлов и автоматическим отключением дефектных узлов [1, с. 29].

Стандарт CANopen и модель OSI

Сетевые системы CANOpen используют три уровня модели OSI, то есть: физический уровень, канальный уровень передачи данных и уровень приложения по сравнению с CAN, который использует только первый и второй уровни модели OSI. Для этой промышленной шины остальные уровни не нужны. [15, с. 25]. В сетевых стандартах CANopen нам нужен самый верхний уровень, то есть прикладной уровень в сетевой модели OSI, чтобы использовать протоколы более высокого уровня, которые необходимы для определения того, как CAN-сообщение получает 11-битный идентификатор кадра и использование 8 байт данных [15, с. 22].

Приложения автоматизации на основе CANOpen требуют протоколы уровня приложения и профили, стандартизацию системы связи, администрирование системы и функциональность устройств [16, с. 31].

1. Прикладной уровень: этот уровень предоставляет набор сервисов и протоколов, которые полезны для каждого устройства в существующем сетевом приложении.

2. Профиль связи: этот профиль предоставляет информацию для настройки устройств и данных связи, а также определяет, как данные фактически передаются между устройствами.

3. Профили устройств: добавляют поведение устройства (например, цифровой ввод-вывод, аналоговый ввод-вывод, контроллеры движения, кодеры и т. д.).

Для решения этих проблем изначально был разработан и реализован другой стандарт, известный как CAN контроллер прикладного уровня (CAL) [16, с. 27].

CAL (CAN контроллер прикладного уровня)

Philips разработала протоколы связи более высокого уровня для медицинских систем, которые уже существуют для сетей CAN, называемых CAL (CAN Application Layer). CAN в автоматизации (CiA) принял CAL для дальнейшего развития и опубликования в серии стандартов [14, с. 24] [17, с. 28].

CAL имеет следующие четыре службы прикладного уровня:

1. Спецификация сообщений на основе CAN (CMS): CMS основана на спецификации производственных сообщений (MMS), и она предлагает объекты для проектирования и определения того, как осуществляется доступ к функциям любого узла в сети с использованием существующего интерфейса CAN. [17, с. 41].

2. Управление сетью (NMT): он предлагает услуги, которые используются для управления сетью, такие как инициализация узлов, остановка узлов, запуск узлов, обнаружение сбоев узлов и т. д. [17, с. 25] [10, с. 32].

3. Дистрибьютор (DBT): он используется для динамического распространения CAN-идентификаторов на существующие сетевые узлы. Эта услуга реализуется путем рассмотрения механизма «ведущий-ведомый» (Master-slave) [17, с. 34] [10, с. 29].

4. Уровень управления (LMT): предоставляет возможность изменять параметры прикладного уровня, такие как изменение NMT-адреса узла, или изменение битовой синхронизации и скорости передачи данных интерфейса CAN [17, с. 28] [10, с. 33].

Все службы управления сетью, протоколы сообщений предоставляются стандартом CAL, но ему не удается получить содержимое объектов CMS, определить какие объекты переданы, и какие типы объектов переданы. Эти проблемы были решены с введением CANopen [17, с. 45].

Обзор CANopen

CANopen - это протокол более высокого уровня, построенный на основе CAL-механизма, а также на CAN-протоколе [19, с. 25]. Он работает таким образом, что доступные узлы могут варьироваться от симплексной функциональности до сложной функциональности, не затрагивая проблем взаимодействия между узлами в сеть. Словарь объектов устройств (OD) является основным механизмом, который рассматривается в случае CANopen [12, с. 34]. В любом открытом CAN-устройстве весь трафик шины концептуально разделяется на два класса, т.е. объект служебных данных (SDO) и объект данных процесса (PDO). Коммуникация в SDO включает в себя конфигурационную информацию всех устройств, например, выбор полярности выходного сигнала для модуля цифрового вывода, тогда как связь в PDO включает в себя всю информацию, касающуюся работы устройств во время выполнения, например, фактическое положение приводного устройства [22, с. 41]. Это понятие словаря объекта устройств не включено в систему CAL; он является одним из аспектов реализации стандарта CANopen [12, с. 37]. CANopen обеспечивает механизм, при котором устройства разных типов объединяются вместе и обмениваются данными в стандартном формате, благодаря чему различные CAN-устройства взаимодействуют друг с другом [18, с. 32].

Опишем различные взаимодействия уровней и связь между ними. На прикладном уровне CANopen устройства обмениваются объектами связи и конкретным приложением. Эти объекты затем доступны для обработки с помощью 16-битного индекса и 18-битного субиндекса [12, с. 41] [13, с. 37]. Используя сконфигурированные и заранее определенные идентификаторы, такие объекты связи приложений затем отображаются на один или несколько кадров CAN. Здесь физический уровень определяет значение битового уровня с битовой синхронизацией [13, с. 55].

ВЫВОД

Таким образом CANopen должен быть определен как протокол более высокого уровня, который не только имеет все определенные свойства CAN, но также имеет дополнительное преимущество в использовании прикладного уровня эталонной модели OSI. CANopen не включает в себя использование шины для обмена данными между узлами в сети. Он предоставляет стандартный и настраиваемый метод для передачи данных между несколькими узлами CAN. Некоторые функции CANopen включают в себя легкий доступ ко всем параметрам устройства, высокую скорость передачи, механизм спасения, циклическую передачу данных и событий, скорость передачи до 1 Мбит /с и т. д. По итогу этого обзора литературы, мы предлагаем разработать CAN-карту, которая связывает через последовательную шину CAN-протокола, а также управляет мастер-контроллером, чтобы можно было передавать данные, а также получать данные с любого узла, который подключен по шине. Карта должна быть размещена на задней панели ПК с D-разъемом для подключения к шине. Карта включает микросхему с поддержкой CANopen в виде Siemens C167CR-16F, которая представляет собой 16-битный микроконтроллер, трансивер, например, Phillips 82C250, который формирует интерфейс между контроллером CAN и последовательной шиной. Микроконтроллер имеет встроенную 128-битную память с функцией очистки банка и защиты чтения. EEPROM запрограммирован объектно-ориентированным программированием, таким как C, JAVA. Для вызова любого адреса узла, который затем подается в банк регистров, данные адреса обрабатываются микроконтроллером, который отправляет данные через приемопередатчик на последовательную шину для адресации узла. Узел с этим конкретным адресом принимает вызов, и он возвращает обратно на ту же шину обратно к контроллеру. Таким образом, CAN-карта может в любой момент контролировать весь набор узлов, и представлять на шине. Это косвенно можно назвать прототипом или симуляцией небольшой автоматизации.

Список литературы:

1. CAN Specification Version 2.0,Part A, Robert Bosch GmbH, Stuttgart, Germany, 1991.
2. Wolfhard Lawrenz, CAN System Engineering: From Theory to Practical Applications, Springer-Verlag, 1997, ISBN 0-387-94939-9.
3. Daniel Mannisto, Mark Dawson, An Overview of Controller Area Network (CAN) Technology, mBus, 2003.
4. Steve Corrigan, Introduction to the Controller Area Network (CAN) - Texas Instruments Application Report, SLOA101, 2002.
5. ISO. International Standard ISO 11898: Road Vehicles - Interchange of digital information -Controller Area Network (CAN) for high speed communication, ISO 11898:1993[E], 1993.
6. Karl Henrik Johansson, Martin Torngren, Lars Nielsen, Vehicle Applications of Controller Area Network, 2005.
7. Stuart Robb, CAN Bit Timing Requirements - Motorola Semiconductor Application Note, AN1798, 1999.
8. Lars-Berno Fredriksson, Controller Area Networks and the protocol CAN for machine control systems, Kvaser AB, P.O. Box 4076, S-511 04 Kinnahult, Sweden.
9. Blagomir Donchev, Marin Hristov, Implementation of CAN Controller With Universidade Técnica de Lisboa, Avenida Rovisco Pais - 1096 Lisboa Codex - Portugal.
10. Michael John Sebastian Smith, Application-Specific Integrated Circuits, Addison-Wesley Longman Publishing Co., Inc., 1997, ISBN 0-201-50022-1. FPGA Structures, 7th International Conference, CADSM, 2003.
11. CAN-in-Automation, CAL, CAN Application Layer for Industrial Applications, CiA Draft Standard DS-201 to DS-207, Version 1.1, Feb 1996.
12. CAN-in-Automation, CANopen, CAL-based Communication Profile for Industrial Systems, CiA DS-301, Version 4.0, June 16 1999.
13. CAN-in-Automation, CANopen Device Profile for I/O Modules, CiA DSP-401, Version 1.4, Dec 1996.
14. CAN-in-Automation, Framework for Programmable CANopen Devices, CiA DSP-302, Version 2.0, Nov 27 1998.
15. CS5525/CS5526 16-bit / 20-bit multi-range ADC with 4-bit latch, data sheet, Crystal Semiconductor Corporation, Sep 1996.
16. H.Boterenbrood, SPICAN CANopen I/O-system (for analog inputs), user documentation, Version 2.1, NIKHEF internal documentation, Jan 14 2000.
17. CAN-in-Automation, CANopen Device Profile for Measuring Devices and Closed-Loop Controllers, CiA DSP-404, Revision 1.11, Nov 27 1997.
18. Dr Mohammad Farsi and Mr Karl Ratcliff, CANopen: The Open Communications Solution, Department of Electrical and Electronic Engineering, The University of Newcastle Upon Tyne.
19. M.Farsi and M.Barbosa,"CANopen Implementation:Application to industrial networks",ISBN 0863802478, January 2000 ,Research Studio Press ltd.
20. CAN history, CAN in Automation e.V., Kontumazgarten 3,DE-90429 Nuremberg Website: http://www.can-cia.org/index.php?id=522
21. Farsi.M ,Ratcliff.K,"An Introduction to CANopen and CANopen communication issues"CANopen Implementation (Digest No. 1997/384), IEE Colloquium on Volume , Issue , 6 Oct 1997 Page(s):2/1 - 2/6
22. M.Farsi, K.Ratcliff,"CANopen:CONFIGURE AND DEVICE TESTING", Department of Electrical and Electronic Engineering, The University of Newcastle Upon Tyne.