Управление сетью

Система управления сетью (NMT) работает по принципу “ведущий-ведомый” и используется для управления узлами сети. С помощью NMT можно инициализировать, запускать, контролировать, останавливать или перезапускать узлы. Каждый узел в NMT имеет уникальный идентификатор Node-ID в диапазоне от 1 до 127.

Для работы NMT необходимо, чтобы одно из устройств в сети исполняло функцию NMT.

Службы NMT

Module Control Services. С помощью службы управления модулями NMT master управляет состоянием устройств NMT slave. Атрибут состояния может быть одним из значений {STOPPED, PRE-OPERATIONAL, OPERATIONAL, INITIALISING}. Module Control Services могут быть выполнены над одним определенным узлом или над всеми узлами сети одновременно. NMT master управляет своей собственной машиной состояний NMT через локальные службы, зависящие от реализации. Module Control Services, кроме службы Start Remote Node, могут быть инициированы локальным приложением.

Подсказка

NMT команды могут быть отправлены таким же образом как и команды SDO:

• Через NMT команды отправляемые в USB модуля на основе CAN bp, данным способом можно получить доступ к всему словарю это наиболее гибкий способ настройки модуля, для подключения

• Через NMT команды WEB интерфейса, данным способом можно получить доступ к всему словарю но необходимо что бы в сети CAN был модуль с WEB интерфейсом.

• Через NMT интерфейс, самый удобный способ, необходимо, что бы в сети CAN был модуль с WEB интерфейсом.

Start Remote Node

Через эту службу NMT Master устанавливает состояние выбранных узлов NMT Slaves в состояние OPERATIONAL.

Эта служба не подтверждаемая. После завершения службы состояние выбранных узлов сети (remote nodes) будет OPERATIONAL.

Stop Remote Node

Через эту службу NMT Master устанавливает состояние выбранных узлов NMT Slaves в состояние STOPPED.

Эта служба не подтверждаемая. После завершения службы состояние выбранных узлов сети (remote nodes) будет STOPPED.

Enter Pre-Operational

Через эту службу NMT устанавливает состояние выбранного узла NMT Slave (или узлов) в состояние PREOPERATIONAL.

Эта служба не подтверждаемая. После завершения службы состояние выбранных узлов сети (remote nodes) будет PRE-OPERATIONAL.

Reset Node

Через эту службу NMT переводит состояние выбранного узла NMT Slave (или узлов) из любого состояния в промежуточное состояние «сброс приложения».

Эта служба не подтверждаемая. После завершения службы состояние выбранных узлов сети (remote nodes) будет RESET APPLICATION.

Reset Communication

Через эту службу NMT переводит состояние выбранного узла NMT Slave (или узлов) из любого состояния в промежуточное состояние «сброс обмена данными». После завершения этой службы выбранные узлы сети будут в состоянии RESET COMMUNICATION.

Эта служба не подтверждаемая, и её наличие обязательно для всех устройств.

Служба контроля ошибок

Через службы контроля ошибок NMT определяет отказы в сети CAN. Локальные ошибки на узле могут, например, приводить к сбросу или изменению состояния узла. Определение локальных ошибок не попадает в область рассмотрения этой спецификации.

Службы Error Control реализованы по принципу периодической отправки сообщений устройством. Имеется 2 варианта выполнения Error Control.

Так называемая защита (guarding) достигается передачей запросов guarding (протокол Node guarding) от устройства NMT Master. Если устройство NMT Slave не отвечает в определенный интервал времени (node life time, время жизни узла), или если неожиданно поменялся статус коммуникации NMT Slave, то NMT Master информирует свое приложение об этом событии.

Если поддерживается Life guarding (устройство NMT slave защищает устройство NMT master), то slave-устройство использует время защиты (guard time) и множитель времени жизни (lifetime factor) из своего OD, чтобы определить время жизни узла. Если NMT Slave оказался не защищен за это время жизни, то NMT Slave оповещает свое локальное приложение об этом событии. Если параметры guard time и life time factor равны 0 (значения по умолчанию), то NMT Slave не защищает NMT Master.

Защита запускается для slave, когда принят первый запрос на передачу для его guarding-идентификатора. Это может произойти на фазе загрузки (boot-up) или позже.

Механизм heartbeat устанавливается через циклическую передачу сообщения от heartbeat-продюсера. Одно или большее количество устройств в сети знают об этом сообщении подтверждения работоспособности. Если цикл heartbeat был нарушен для heartbeat-продюсера, то локальное приложение heartbeat-потребителя будет оповещено об этом событии.

Реализация либо системы guarding, либо heartbeat является обязательной.

Node Guarding

Протокол Node Guarding. Этот протокол используется для определения сетевых ошибок (remote errors). Каждое устройство NMT Slave использует один remote COB-ID для протокола Node Guarding. Этот протокол реализует инициируемые провайдером службы Error Control.

Примечание *: если произошла ошибка защиты (guarding error).

s: состояние NMT

• 4: STOPPED

• 5: OPERATIONAL

• 127: PRE-OPERATIONAL

t: toggle bit. Значение этого бита должно каждый раз меняться между двумя соседними ответами от NMT Slave. Значение бита toggle первого ответа после активизации протокола Guarding будет равно 0. Toggle Bit в протоколе guarding сбрасывается в 0 только когда передан reset_communication (никакие другие переходы между состояниями узла не сбрасывают бит toggle). Если принят ответ с тем же самым значением бита toggle, как и в предыдущем ответе, то тогда новый ответ обрабатывается как пропуск сообщения ответа.

NMT Master опрашивает каждый узел NMT Slave с регулярными интервалами времени. Этот интервал называется guard time, и он может отличаться для каждого NMT Slave. Ответ от NMT Slave содержит его состояние. Параметр времени жизни (node life time) узла дается как guard time, умноженное на life time factor. Время жизни узла может отличаться для каждого NMT Slave. Если NMT Slave не был опрошен в свой интервал времени life time, будет показана ошибка дальнего узла (remote node error) через службу Life Guarding Event. Ошибка remote node error показывается через службу Node guarding event, если:

• Запрос RTR не был подтвержден за время node life time.

• Состояние, сообщенное NMT slave, не соответствует ожидаемому.

Если была индикация, что произошла ошибка remote error, и ошибки в протоколе guarding исчезли, то это будет показано как исправление remote error с помощью служб Node Guarding Event и Life Guarding Event.

Для интервала guard time и для life time factor имеются значения по умолчанию, заданные в соответствующих элементах OD.

Heartbeat

Протокол Heartbeat. Этот протокол определяет службу контроля ошибок (Error Control Service) без необходимости посылать фреймы RTR. Продюсер Heartbeat циклически передает сообщение Heartbeat. Один или большее количество потребителей Heartbeat принимают эту индикацию. Взаимодействие между продюсером и потребителем конфигурируется через OD. Потребитель Heartbeat защищает прием Heartbeat в пределах интервала Heartbeat Consumer Time. Если сообщение Heartbeat не было принято в этом интервале, то генерируется Heartbeat Event, сообщающее об ошибке.

r: зарезервировано (всегда 0)

s: состояние продюсера Heartbeat

• 0: BOOTUP

• 4: STOPPED

• 5: OPERATIONAL

• 127: PRE-OPERATIONAL

Если Heartbeat Producer Time сконфигурировано на устройстве, то протокол Heartbeat немедленно начинает работу. Если устройство запускается со значением для Heartbeat Producer Time, не равным 0, то протокол Heartbeat запускается в момент перехода из состояния INITIALISING в состояние PRE-OPERATIONAL. В этом случае сообщение Bootup считается как первое сообщение heartbeat. Не разрешено для одного устройства использовать оба механизма защиты одновременно, Guarding Protocol и Heartbeat Protocol. Если интервал Heartbeat Producer Time не равен 0, то для защиты используется протокол Heartbeat.

Служба загрузки

Bootup

Протокол Bootup. Этот протокол используется для сигнала о том, что устройство NMT slave вошло в состояние узла PRE-OPERATIONAL перед тем, как оно было в состоянии INITIALISING. Протокол использует тот же идентификатор, что и протоколы контроля ошибок.

Передается 1 байт данных со значением 0.

Процедура инициализации

Ниже показан общий алгоритм процесса инициализации сети, управляемый приложением мастера NMT или конфигурирующим приложением.

Диаграмма процесса инициализации сети.

На шаге A устройства находятся в состоянии узла PRE-OPERATIONAL, в которое они входят автоматически после включения питания. В этом состоянии устройства доступны через их Default-SDO при использовании идентификаторов, которые были назначены в соответствии с принципом Predefined Connection Set. На этом шаге конфигурация параметров устройства осуществляется на всех узлах, которые поддерживают конфигурацию параметра.

Это осуществляется специальным конфигурирующим приложением или инструментарием, которое находится на узле, являющемся клиентом для объектов SDO по умолчанию. Для устройств, которые поддерживают эти функции выбора и/или конфигурирования объектов PDO, отображение объектов приложения (PDO mapping), конфигурирование дополнительных SDO и опционально установку идентификаторов COB-ID, все это конфигурирование может быть осуществлено через объекты SDO по умолчанию.

Во многих случаях конфигурирования даже не требуется, поскольку достаточны значения по умолчанию и параметры коммуникации, заданные для всего приложения.

Если приложение требует синхронизации всех или некоторых узлов сети, то подходящие механизмы могут быть инициированы на опциональном шаге B. Это может использоваться для гарантии, что все узлы засинхронизированы объектом SYNC перед входом в состояние OPERATIONAL на шаге D. Первая передача объекта SYNC начинается в пределах 1 цикла синхронизации после входа в состояние PRE-OPERATIONAL. На шаге C может быть активирован механизм контролирования узлов Node guarding (если он поддерживается), с использованием параметров guarding, которые были сконфигурированы на шаге A.

С шагом D все узлы разрешены для обмена через свои объекты PDO.

Состояния устройств

Ниже показана диаграмма состояний устройства. Устройства входят в состояние PRE-OPERATIONAL сразу после завершения своей инициализации. Во время этого состояния возможна параметризация устройства и выделение ID через SDO (например, с помощью инструментария конфигурирования). Затем узлы могут быть сразу переключены в состояние OPERATIONAL.

Машина состояний NMT определяет поведение блока функции обмена данными (Communication function unit). Машина состояний приложения вместе с машиной состояния NMT зависит от устройства, и попадает в область действия профилей устройства.

Минимальная процедура загрузки (Boot-Up) состоит из одной телеграммы CAN: широковещательного (broadcast) сообщения Start_Remote_Node.

Диаграмма состояний устройства (узла сети CANopen).

	В состояние инициализации после включения питания / сброса устройство CANopen входит самостоятельно (без команды от Master).
	Инициализация завершена - автоматический вход в состояние PRE-OPERATIONAL (без команды от Master).
(3), (6)	Индикация в сеть (NMT-сообщение) Start Remote Node («сетевой узел запустился»).
(4), (7)	Индикация в сеть Enter PRE-OPERATIONAL («вход в предварительное рабочее состояние, готовность к работе»).
(5), (8)	Индикация в сеть Stop Remote Node («сетевой узел остановлен»).
(9),(10),(11)	Индикация в сеть Reset Node («сброс узла»).
(12),(13),(14)	Индикация в сеть Reset Communication («сброс коммуникаций»).

Подсказка

«Индикация в сеть» означает отправку устройством соответствующего NMT-сообщения, которое обычно регистрируется мастером сети CANopen.

Инициализация

Состояние «Инициализация» делится на три sub-состояния, чтобы позволить выполнить полный или частичный сброс узла.

1. Initialising: это первое sub-состояние устройство, в которое оно входит после включения питания или аппаратного сброса. После завершения базовой инициализации узла устройство само входит в состояние Reset_Application.

2. Reset_Application: в этом состоянии устанавливаются в свое состояние «после включения питания» параметры (power-on values), относящиеся либо к специальному профилю устройства производителя, либо к стандартизованному профилю устройства. После установки этих настроек устройство автоматически входит в состояние Reset_Communication.

3. Reset_Communication: в этом состоянии устанавливаются в параметры профиля коммуникации в свои значения «после включения питания» (power-on values). После этого состояние Инициализации завершается, и устройство запускает службу «write boot-up» (короче говоря, выдает в сеть NMT-сообщение boot-up) и входит в состояние PRE-OPERATIONAL.

Значения «после включения питания» это значения настроек, которые были сохранены последний раз (если устройство имеет энергонезависимую память для хранения настроек), или настройки, установленные перемычками. Если сохранение не поддерживается, или не было выполнено, или если сбросу предшествовала команда restore_default (объект OD 1011H), то the power-on values будут соответствовать настройкам по умолчанию в соответствии со спецификациями коммуникации и профиля устройства.

Структура состояния инициализации.

	В состояние инициализации после включения питания / сброса устройство CANopen входит самостоятельно (без команды от Master).
	Инициализация завершена - автоматический вход в состояние PRE-OPERATIONAL (без команды от Master).
(9),(10),(11)	Индикация в сеть Reset Node («сброс узла»).
(12),(13),(14)	Индикация в сеть Reset Communication («сброс коммуникаций»).
	Инициализация завершена, в состояние Reset Application (сброс приложения) узел входит самостоятельно.
	Сброс приложения завершен, в состояние Reset Communication («сброс коммуникаций») устройство входит самостоятельно.

PRE-OPERATIONAL

В состоянии PRE-OPERATIONAL возможен обмен данными через объекты SDO. Объекты PDO не существуют, поэтому обмен PDO не разрешен. Конфигурирующим приложением (обычно это мастер сети CANopen) может быть выполнено конфигурирование объектов PDO, параметров устройства и также выделение в нем объектов приложения (отображение переменных приложения на объекты PDO, так называемое PDO-mapping). Узел сети устройства может быть переключен по NMT-команде в состояние Operational (запрос мастера сети Start Remote Node).

OPERATIONAL

В состоянии OPERATIONAL активны все коммуникационные объекты устройства (SDO, PDO, TIME, SYNC). Переход в OPERATIONAL создает все объекты PDO; конструктор использует параметры, как это описано в OD. Возможен доступ к OD через SDO. Однако аспекты реализации машины состояний приложения могут потребовать ограничить доступ к определенным объектам во время рабочего состояния, потому что объект может содержать программу приложения, и его нельзя изменять во время выполнения.

Stopped

После переключения устройства в состояние Stopped оно принудительно останавливает весь свой обмен (кроме протоколов защиты сети node guarding или heartbeat, в зависимости от того, что из этого активно). Кроме того, это состояние может использоваться для достижения определенного поведения приложения. Определение этого поведения попадает в область действия спецификации профилей устройства.

Взаимосвязь состояния и объекта коммуникации

(Communication Object). Таблица показывает взаимоотношение между состояниями коммуникации и объектами коммуникации. Службы на перечисленных объектах коммуникации могут быть выполнены только если устройства, вовлеченные в коммуникацию, находятся в подходящих состояниях коммуникации.

Состояния и объекты коммуникации.

Объекты.	Состояния:
	INITIALISING	PRE-OPERATIONAL	OPERATIONAL	STOPPED
PDO			X
SDO		X	X
SYNC		X	X
TIMESTAMP		X	X
EMCY		X	X
Boot-Up	X
NMT		X	X	X

Переходы между состояниями могут быть вызваны:

• Приемом объекта NMT, используемого для служб управления модулем (Module Control Services).

• Аппаратным сбросом.

• Службы управления модулем инициированы локально событиями приложения, как это определено в профилях устройства.