Расширение возможностей «умной» автоматизации с помощью CANopen
Введение
Системы автоматизации включают огромное количество устройств, каждое из которых идет в комплекте с датчиками, двигателями, а также другими компонентами и микроконтроллерами, которые принимают и передают информацию по общей сети. При обеспечении необходимой координации между всеми этими устройствами, а также их эффективного мониторинга решающее значение имеет система коммуникации, которая часто бывает весьма сложной.
Шина CAN (Controller Area Network — местная контроллерная сеть, определение дано согласно ГОСТ Р ИСО 11898-2-2015) — это стандарт промышленной сети, ориентированный прежде всего на объединение в одну сеть различных исполнительных устройств и датчиков. Это протокол на основе сообщений, который стал предпочтительным стандартом для широкого спектра отраслей промышленности [2]. В этих отраслях существуют многочисленные протоколы разного уровня, каждый со своей специализацией и отраслевыми особенностями. В свою очередь, CANopen был создан как высокоуровневый сетевой протокол, работающий поверх физического CAN. Сейчас это один из самых популярных протоколов, а с развитием интеллектуальной, или «умной» автоматизации и «Интернета вещей» (Internet of Things, IoT) он становится все более и более востребованным [3].
Тем не менее реализация в существующих системах или оборудовании поддержки CANopen может быть сложной задачей, особенно если речь идет об интеллектуальной автоматизации.
Общие сведения
CAN-шина
Controller Area Network (шина CAN) — это внутренняя коммуникационная сеть, которая изначально была разработана для автомобилей. Использовать ее предложил Роберт Бош (Robert Bosch), владелец компании Robert Bosch GmbH, — для снижения стоимости производства автомобилей. Шина CAN стала альтернативой толстым многожильным кабелям, необходимым для подключения датчиков и узлов внутренней электроники автомобилей, которых становилось все больше, и позволила упростить прокладку кабелей благодаря использованию многоузловых шин. Когда шина CAN была впервые представлена в автомобиле BMW 850 в 1986 г., этот интерфейс позволил сэкономить более 2 км проводов! Кроме того, значительно уменьшилось количество разъемов, повысилась надежность, а оценочная экономия веса составила 50 кг [12]. В 1993 г. Международная организация по стандартизации приняла шину CAN в качестве международного стандарта [4].
Одним из основных преимуществ шины CAN является то, что она обеспечивает связь между устройствами и микроконтроллерами без необходимости использования главного компьютера. Устройства подключаются через один витой провод, а сигналы, передаваемые любым из них, принимаются всеми остальными устройствами, подключенными по шине CAN [5]. Для определения предполагаемых получателей сообщений, передаваемых по шине CAN, в каждом сообщении используются идентификаторы узла, а сами узлы определяются через так называемый словарь объектов (рис. 1).
Что же касается CANopen, он использует кадры CAN в качестве носителей данных. Кадры CAN доставляют данные от одного узла сети к другим, т. е. выполняют задачу канального уровня (data link layer) модели OSI. Таким образом, CANopen использует протокол CAN на канальном уровне. С помощью CAN-кадров можно обмениваться любыми данными (до 8 байт), вне зависимости от их предназначения. Используя CAN, пришлось бы придумывать свои правила обмена (свой протокол). Так, например, в центральных процессорах (CPU) программируемых логических контролеров (ПЛК) потребовалось бы записывать микропрограмму для формирования последовательности байтов данных в кадре, а в модуле — микропрограмму для их интерпретации. В реальных ПЛК обмен между CPU и модулями проходит неявно, то есть без участия программы пользователя. Подобного функционала не хватает CAN. Эти функции обеспечивают протоколы прикладного уровня CANopen, описанные в стандарте CiA DS 301 [13] (CiA — компания CAN in Automation [6]). Эта спецификация определяет прикладной уровень CANopen, в том числе типы данных, правила кодирования и объекты словаря объектов, коммуникационные сервисы и протоколы CANopen, а также сервисы и протоколы управления сетью CANopen.
Архитектура нижнего уровня CAN определяет только физическую структуру сети CANopen. По сути она ничем не отличается от других сетей CAN: используется линейная (шинная) топология, где все устройства параллельно подключены к одной двухпроводной линии связи. Чтобы избежать паразитных отражений сигнала, оба конца сети должны быть нагружены на терминирующую нагрузку (два резистора по 120 Ом, показанные на рис. 1). Кроме того, должны быть учтены максимально допустимые длины сегментов сети между отдельными сетевыми узлами — в зависимости от скорости передачи и параметров линии.
В результате получается эффективная система, требующая небольшого количества проводов, без центрального хост-компьютера и способная обрабатывать большое число подключенных устройств.
CAN-протоколы высшего уровня
Протоколы высшего уровня CAN — это, грубо говоря, языки, каждый из которых использует шину CAN в качестве общего алфавита. Однако, в отличие от человеческих языков, определяет, какой протокол более высокого уровня использовать, предполагаемое приложение с конкретными протоколами, более популярными или более полезными именно в этой области применения.
Существует широкий спектр высокоуровневых протоколов на основе CAN, многие из которых предназначены для конкретных отраслей или даже для использования одним производителем. Среди наиболее распространенных стандартизированных протоколов высокого уровня — CANopen, DeviceNet и SAE J1939. Примеры более специализированных протоколов — GMLAN (для General Motors), RV-C (для транспортных средств для отдыха) и космический протокол CubeSat (для CubeSats) [6].
CAN в автоматизации
Шина CAN изначально была стандартом для систем в автомобиле, но через некоторое время стала популярным стандартом и для автоматизации. В таких приложениях особую значимость приобрел открытый протокол более высокого уровня, CANopen. По сравнению с другими сетями на базе шины CAN сеть CANopen более пригодна для быстродействующих систем управления перемещением и контуров регулирования с обратной связью за счет высокой надежности, рационального использования пропускной способности, подачи питающего напряжения по сетевому кабелю. CANopen разрабатывается и поддерживается CAN in Automation (CiA) — международной некоммерческой организацией для пользователей и производителей CAN [7].
Этот протокол нашел применение в робототехнике, в управлении заводскими конвейерными лентами и в широком спектре промышленного оборудования. Однако CANopen не ограничивается автоматизацией, он также используется в таких секторах, как здравоохранение и автомобильная промышленность [8].
Устройства CANopen
Устройства CANopen, обычно называемые узлами, должны иметь словарь объектов (OD, OBD object dictionary) — стандартизированную таблицу, в которой хранятся данные, относящиеся к узлу и его работе. Через объектный словарь можно обратиться ко всем объектам CANopen-устройства. OD разделен на область с общей информацией об устройстве, такой как название производителя и т. д., область, содержащую параметры связи, и область, которая описывает специфичную для устройства функциональность. Через записи (объекты) OD прикладные объекты устройства, такие как входные и выходные сигналы, параметры устройства, сервисы устройства или сетевые переменные, становятся доступными по сети в стандартизированной форме. OD образует интерфейс между сетью и прикладным программным обеспечением.
Объектный словарь каждого узла CANopen содержит запись для его типа устройства, используемого в целях идентификации. Другие индексы объектного словаря могут содержать информацию, такую как показания датчика или состояния процесса — например, передается ли сигнал в данный момент или активна ли операция устройства [9].
Обмен данными в CANopen реализуется в соответствии с архитектурой Master/Slave: одно из устройств является ведущим (Master) и осуществляет управление сетью (Network Management, NMT). Все остальные имеют статус ведомых (Slaves). Кроме того, протокол CANopen позволяет применять коммуникационные модели Producer/Consumer (производитель/потребитель, иногда также называется поставщик/потребитель) и Client/Server (клиент/сервер).
В модели связи «ведущий — ведомый» один из узлов CANopen отправляет и запрашивает данные от «подчиненных» узлов, которые, по сути, просто следуют инструкциям своего «ведущего». В модели «клиент — сервер» «клиенты» читают или записывают данные с «серверов». Наконец, в модели связи «производитель — потребитель» «производители» передают данные всем другим узлам, то есть «потребителям».
Кроме того, узлы CANopen обмениваются данными через различные службы связи, причем каждая служба связи подходит для передачи определенных команд. Например, коммуникационная служба управления сетью используется для передачи желаемого состояния узлов CANopen (такого как выключение всех двигателей или запуск датчика).
Еще одна важная услуга связи — это периодические контрольные сообщения (heartbeat), посылаемые по линии связи, которую узлы регулярно передают друг другу, указывая тем самым, что они все еще активны [10].
Обычные сообщения, передаваемые узлами CANopen, следуют стандартному формату сообщений, который дает понять принимающим узлам, какой узел передает данные, какова длина сообщения, а также фактическая передача данных. Эта стандартизация применяется ко всем сообщениям CANopen, независимо от того, какие используются модели связи или коммуникационные услуги (рис. 2).
Первая часть сообщения CANopen содержит 11-битный длинный CAN-ID, идентифицирующий передающее устройство, за которым следует управляющий бит. Эта часть сообщения обычно называется идентификатором объекта связи, или COB-ID. Она создает коммуникационное соединение между передаваемым и принимаемыми коммуникационными объектами и в то же время определяет приоритет сообщения. Удаленный запрос передачи — RTR. Идентификатор 0 с наивысшим приоритетом зарезервирован для сервисов управления сетью. Следующие четыре бита сообщают приемным устройствам, какова длина сообщения, чтобы они могли определить, в какой точке передачи сообщение заканчивается. Последняя часть сообщения CANopen представляет собой фактические данные, длина которых может достигать 8 байт (или 64 бит). Фактическая длина сообщения зависит от типа передаваемых данных. Подробнее про формат кадра передачи данных CAN можно прочитать в статьях [6, 11].
Проблемы
Как мы уже говорили, CANopen может казаться очень привлекательной системой для применения в самых разных областях, но на деле — стать более сложным, чем ожидают системные интеграторы. Например, в сфере автоматизации часто используются устройства с высокими требованиями к габаритным размерам и долговечности. Объедините эти требования с жесткими условиями эксплуатации, и эти приложения могут стать обременительными для любой новой системы, которую необходимо внедрить.
Сложности и затраты, связанные с реализацией CANopen в настройках автоматизации, также становятся серьезными препятствиями.
Трудности в сфере автоматизации
Область автоматизации может поставить перед системными интеграторами, внедряющими решения CANopen, множество разных вызовов. Например, промышленные роботы исключительно точно настроены и занимают мало места, оставляя при этом крайне незначительное пространство для расширения интерфейса. Кроме того, скорость и точность, ожидаемые от такого оборудования, требуют, чтобы устройства соответствовали самым высоким стандартам качества с точки зрения компонентов и дизайна.
Производственные линии на «умных» предприятиях и в приложениях промышленного «Интернета вещей» (IIoT) включают большое число машин, датчиков и микроконтроллеров, действия которых должны быть скоординированы. Даже если только в одном компоненте производственной линии наблюдается падение производительности или недостаточная эксплуатационная надежность, все риски могут стать катастрофическими. Таким образом, системы коммуникаций, реализованные в таких приложениях, должны обеспечивать чрезвычайно точную координацию и, следовательно, высокую производительность, а также эффективную модульность в случае отказа компонента или устройства.
Сложность расширения интерфейса
Сложность систем, используемых на «умных» предприятиях, является одним из ключевых вызовов для любой новой системы внутренней коммуникации. Из-за огромного количества различных устройств (каждое из них — со своими индивидуальными и запутанными функциями и компоновкой аппаратного обеспечения) расширение интерфейса, необходимое для реализации такой системы, как CANopen, может выглядеть пугающим, если не просто невозможным.
Если каждое устройство в таких системах требуется перепроектировать для поддержки CANopen, затраты, время и сложности, связанные с такими мероприятиями, делают эту задачу невыполнимой или как минимум сомнительной с точки зрения финансовой целесообразности.
Еще одним сложным фактором является риск того, что индивидуальные проекты, обеспечивающие поддержку CANopen, в случае аппаратного сбоя представляют собой серьезную проблему для системных операторов. Без достаточной модульности при любом таком сбое оборудования может потребоваться, чтобы запасные части подверглись обширному процессу перепроектирования, а значит, возникнет риск длительного простоя со значительной потерей прибыли.
Проблемы среды эксплуатации
Аппаратные средства и компоненты, используемые в системах автоматизации, часто и в течение длительных периодов времени должны выдерживать значительные перегрузки и различные неблагоприятные воздействия среды эксплуатации. Поэтому крайне важно, чтобы все компоненты были надежными и имели те или иные технологии, помогающие компенсировать вредное воздействие жестких условий.
К факторам, представляющим наиболее значительный риск в средах автоматизации, относятся экстремальные температуры, воздействие ударов и вибраций, повышенный риск бросков и снижения напряжения, а также повреждения от разрядов статического электричества.
Разнообразие операционных сред приложений автоматизации способствует тому, что внедрение системы CANopen иногда возможно только при значительной степени настройки для учета уникальных факторов среды. Так, в некоторых приложениях, например в нефтяной и горнодобывающей промышленности, для целостности оборудования важной проблемой может оказаться воздействие опасного загрязнения.
Решения
Карты расширения шины CAN
Требования к оборудованию для реализации системы шины CAN, например системы, в которой используются протоколы высокого уровня CANopen или SAE J1939, могут быть удовлетворены с минимальными затратами и с большой гибкостью благодаря использованию плат расширения шины CAN. Платы расширения шины CAN, которые используют стандартные входные разъемы, такие как mPCIe, 5-контактный разъем и M.2, и общие интерфейсы (USB и PCI-Express), обеспечивают высокую степень гибкости, что позволяет использовать их в самых разных областях автоматизации, измерительных приборах и оборудовании. Таким образом, системным операторам не нужно перепроектировать устройства или их аппаратное обеспечение для поддержки шины CAN. Вместо этого достаточно использовать карты расширения CAN, которые для обеспечения желаемой функциональности можно легко подключить к уже существующим портам расширения (рис. 3).
Поддержка интерфейса и программное обеспечение
При использовании плат расширения шины CAN системным интеграторам необходимо учитывать целый ряд важных моментов. В первую очередь они должны убедиться в том, что карты расширения поддерживают желаемые протоколы более высокого уровня, например CANopen и SAE J1939. Также важно понять, могут ли карты расширения быть реализованы в программной среде, будь то система на основе Linux или Windows, и работают ли они на процессорах архитектуры ARM или x86.
При этом нужно помнить о том, что одно лишь обеспечение базовой аппаратной и программной совместимости не учитывает другие критические факторы, которые могут оказать существенное влияние на время и затраты, связанные с внедрением поддержки CANopen в системе. Настройки под конкретные требования заказчика и программирование, необходимые для обеспечения функционирования новой системы CANopen на удовлетворительном уровне, часто требуют значительных ресурсов и оценки рисков.
Таким образом, крайне важно выбрать карты расширения, которые имеют адекватное программное обеспечение, и поставщиков, способных обеспечить послепродажную поддержку. Например, комплексные API-интерфейсы могут значительно снизить потребность в длительных и дорогостоящих настройках, необходимых для полной интеграции системы. Более того, утилиты тестирования и примеры кода могут помочь системным интеграторам убедиться в том, что их системы функционируют в соответствии со спецификацией и ожиданиями пользователей. Для соблюдения сроков проекта и рамок выделенного на его реализацию бюджета в случае неожиданных трудностей, особенно вероятных при реализации сложных систем, или недостаточного собственного опыта по внедрению и обслуживанию могут оказаться просто неоценимыми комплексная и надежная послепродажная поддержка, а также индивидуальная настройка.
Специально разработанное оборудование
Платы расширения шины CAN требуются не только для поддержки правильных разъемов и интерфейсов, но и для соответствия конкретным требованиям к оборудованию. Прежде всего они должны физически вписываться в устройство, для которого они предназначены, что может быть серьезной проблемой из-за ограниченного пространства. В некоторых случаях для карт расширения могут даже потребоваться индивидуальные конструкции, соответствующие точным требованиям устройств, в которые они должны быть установлены.
Системным интеграторам, для того чтобы определить, какие факторы среды могут представлять риск для целостности оборудования и его долговечности, необходимо провести тщательную оценку предполагаемой операционной среды для таких плат расширения. Любые карты расширения интерфейса должны включать необходимые технологии или конструктивные решения, которые в достаточной степени учитывают и факторы риска воздействия окружающей среды. Например, для многих средств автоматизации могут потребоваться карты расширения, способные выдерживать экстремальные температуры. В оборудовании или устройствах, подверженных ударам и вибрации, может потребоваться установка плат расширения с монтажными отверстиями для обеспечения достаточно безопасного соединения с хост-устройством.
Только принимая во внимание все эти факторы и проблемы, связанные с работой в жестких условиях эксплуатации, при приобретении плат расширения шины CAN, предприятия могут обеспечить успешное внедрение системы CANopen в свои приложения автоматизации и достичь желаемой производительности без риска простоев и затрат, связанных с отказом оборудования.
Заключение
Хотя расширение интерфейса для размещения CANopen может показаться непомерно трудным и дорогостоящим, эта проблема может быть успешно решена путем использования плат расширения шины CAN, которые обеспечивают высокую производительность, обширную поддержку программного обеспечения и надежность, необходимую для приложений автоматизации. Благодаря своей модульности и долговечности такие карты расширения обеспечивают простой и экономичный способ реализации поддержки CANopen в любой системе автоматизации
- Powering Smart Automation with CANopen. White Paper. Feb 2020 Innodisk Corporation.
- Applications of controller area network (CAN) bus.
- Industrial Automation and Control.
- ISO 11898:1993 Road vehicles — Interchange of digital information — Controller area network (CAN) for high-speed communication.
- J1939-standard CANbus Solutions. White Paper. July 2017 Innodisk Corporation.
- CAN bus.
- can-cia.org/about-us.
- CANopen — The standardized embedded network.
- Object Dictionary.
- CANopen Explained — A Simple Intro (2020).
- The Basics of CANopen.
- What is Can Bus?
- can-cia.org/groups/specifications.