Распределенное управления (РСУ)¶

CANopen обеспечивает функциональность распределенного управления

Существуют некоторые недопонимания относительно функциональности мультимастера в системах управления на базе CANopen. Нижележащий уровень канала передачи данных CAN представляет собой протокол с несколькими ведущими устройствами, и каждый узел CAN имеет право запросить доступ к шине в любое время. В зависимости от приоритета кадра данных CAN узел получает немедленный доступ к шине или ему приходится ждать.

Прикладной уровень CANopen предоставляет несколько протоколов. Единственным моноведущим протоколом является протокол управления сетью (NMT). Обычно существует только одно ведущее устройство NMT, которое отправляет сообщение NMT для управления другими устройствами CANopen. Чтобы избежать единой точки отказа, CANopen предоставляет дополнительную функцию «летающего» ведущего устройства NMT. Это означает, что в сети есть дополнительные устройства CANopen, обеспечивающие функциональность NMT master, но эта функция еще не активирована. Если активное ведущее устройство NMT теряет соединение с сетью, остальные устройства со «спящими» функциями NMT-мастера начинают договариваться о том, какое из них будет выступать в роли ведущего NMT. Каждое ведущее устройство NMT имеет уникальный приоритет, назначенный разработчиком системы. Если временно отключенное устройство с поддержкой мастера NMT подключается снова, оно запрашивает приоритет активного мастера NMT и, возможно, запускает вышеупомянутый процесс согласования. Главный процесс NMT «Flying» состоит из четырех протоколов.

Heartbeat — это сервис производителя/потребителя. Это означает, что любой узел генерирует сигнал Heartbeat, указывающий на то, что он все еще находится в сети. Все остальные устройства CANopen могут использовать Heartbeat других устройств. Разработчик системы может настроить это для каждого узла по-разному. Сообщение EMCY (экстренное) также является услугой производителя/потребителя. Разработчик системы может настроить прием EMCY с помощью стандартизированных параметров в словаре объектов CANopen.

Объекты данных процесса (PDO) также следуют модели производитель/потребитель, что делает их настоящей системой с несколькими главными устройствами. Они рассылаются широковещательно всем подключенным узлам и в зависимости от реализованной аппаратной и программной фильтрации сообщений обрабатываются или игнорируются. Одно из недоразумений связано с предопределенным набором соединений CAN-ID. Базовый документ CANopen (CiA 301) определяет назначение CAN-ID по умолчанию для различных протоколов связи. Существует всего четыре предопределенных CAN-ID для передачи PDO для каждого узла. Кроме того, существует четыре предопределенных CAN-ID для приема PDO. Это означает, что существует предварительно настроенный набор PDO, которые обычно используются и создаются хост-контроллером. Но разработчик системы может настроить устройства CANopen таким образом, чтобы обеспечить перекрестную связь PDO, а также их многоадресную рассылку, что позволяет настроить полносвязную связь PDO.

Еще одно недоразумение касается связи с объектами служебных данных (SDO) по умолчанию. SDO используются для записи или чтения параметров в словаре объектов. Это связь клиент/сервер. Клиент всегда имеет инициативу, а сервер отвечает на запрос на запись или чтение подтверждением. В случае чтения сервер SDO предоставляет запрошенные данные в подтверждении. Вышеупомянутый заранее определенный набор соединений CAN-ID включает только связь Default-SDO, то есть каждый узел CANopen имеет только один заранее определенный CAN-ID для получения запроса от клиента SDO и еще один для передачи подтверждения на SDO-клиент. Обычно хост-контроллер владеет всеми клиентами SDO для всех Default-SDO других устройств CANopen, но можно назначить неиспользуемые CAN-ID непредопределенным каналам SDO. В конце концов, каждое устройство CANopen может быть клиентом SDO друг для друга и наоборот. Это будет полностью объединенная сеть SDO.

CANopen можно использовать для проектирования сети с несколькими хост-контроллерами. В этом случае хост-контроллеры могут совместно использовать сеть для связи PDO и SDO. Кроме того, они могут совместно использовать подключенные другие устройства CANopen. Например, модуль ввода-вывода может передавать свои входы одному PDO одному хост-контроллеру, а другому PDO — другие входы другому хост-контроллеру. Модуль ввода-вывода может даже быть хост-контроллером сам по себе.

Одно устройство CANopen может реализовать несколько серверов SDO, чтобы его могли настраивать разные хост-контроллеры. Такие реальные распределенные системы управления могут иметь единую точку отказа, если не реализована функциональность «летучего» ведущего устройства NMT. Подводные контроллеры используют резервные главные устройства NMT, а некоторые другие критически важные приложения реализуют «летающие» главные протоколы NMT. В сфере управления лифтами используются несколько хост-контроллеров, которые совместно используют сеть и обмениваются данными по одним и тем же линиям шины с назначенными устройствами CANopen. Несколько хост-контроллеров также используются в приложениях для железнодорожных транспортных средств на базе CANopen. В системах управления промышленными машинами большинство приложений реализуют только один «большой» хост-контроллер, собирающий все входные данные и передающий все команды исполнительным механизмам. В системах управления мобильными машинами иногда используются несколько хост-контроллеров. Тенденция модульного проектирования машин также будет адаптирована для промышленного и другого оборудования, такого как лабораторная автоматизация и медицинская аппаратура. CANopen предоставляет все необходимые функции для таких архитектур распределенного управления.

– Хольгер Зельтвангер — управляющий директор CAN in Automation

Ключевые идеи¶

CANopen можно использовать для проектирования сети с несколькими хост-контроллерами. В этом случае хост-контроллеры могут совместно использовать сеть для связи PDO и SDO.
Тенденция модульного проектирования машин также будет адаптирована для промышленного и другого оборудования, такого как лабораторная автоматизация и медицинская аппаратура. CANopen предоставляет все необходимые функции для таких архитектур распределенного управления.
Базовый документ CANopen (CiA 301) определяет назначение CAN-ID по умолчанию для различных протоколов связи. Существует всего четыре предопределенных CAN-ID для передачи PDO для каждого узла.