1. Мотивация.

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

1.1 UavCan (переименована в Cyphal).

UavCan является открытым протоколом для разработки систем с общей шиной. Достоинствами данной системы являются:

• Возможность использования на базе различных транспортных протоколов (CAN, ethernet и т.д.)
• Полностью открытая система.
• Peer-to-peer network, без использования центрального блока
• Система построения сообщений на базе собственного языка описания протокола.
• Возможность построения сложных систем обмена данными с большим трафиком.

Недостатки:

• Система сложна в реализации, без полного понимания протокола и его особенностей, невозможно ни построить систему, ни даже просто даже протестировать возможности
• Протокол требует достаточно больших вычислительных возможностей аппаратуры и большого запаса памяти и не учитывает особенностей построения программ на микроконтроллеры что делает почти невозможным его реализацию на простых микроконтроллерах и повышает стоимость и сроки разработки простых датчиков.
• Протокол во многом избыточен, для простых систем.
• Нет полноценной среды разработки, что требует использования открытых библиотек и даже для отладки требует написания собственного приложения

1.2 CanOpen.

CanOpen является частично открытым протоколом для создания систем промышленной автоматики. Достоинствами данной системы являются:

• Протокол относительно простой и хорошо ложится даже на «слабые» микроконтроллеры.
• Протокол предназначен для обмена данными и сбора информации с датчиков, и хорошо использует пропускную способность шины.
• Используется большим количеством производителей.
• Состоит из нескольких протоколов для разных видов обмена.

Недостатки:

• Для получения документации, требуется платное вхождение в сообщество OpenCan.
• Большое количество закрытых коммерческих расширений протокола.
• Стоимость сертифицированных устройств весьма высока.
• Протокол требует создание и ведение журналов, что усложняет разработку системы.

1.3 Основные функции и цели, закладываемые в нашу систему.

• Модульность. Система должна позволять строить сети с разным набором устройств, как с одним мастером так и множеством мастеров на шине. В виде программируемых устройств (устройства позволяющие выполнять пользовательское приложение), конфигурируемых устройств (устройства не позволяющие выполнять пользовательское приложение и выполняющее конкретную функцию. Напр. Датчик температуры или источник питания шины), и отладочное устройство, позволяющее конфигурировать сеть, устройства, программировать и отлаживать работу по общей сети передачи данных.
• Расширяемость. По минимуму протокол должен позволять обмен простыми данными в системе без сложных решений фрагментации, таким образом чтобы передаваемые данные в запросе или ответе умещались в один пакет транспортного уровня, для простой реализации устройств на базе «слабых» микроконтроллеров.
• Тем не менее, протокол должен иметь возможность расширять функционал для поддержки фрагментации длинных пакетов, в тех случаях, где это необходимо и позволяет использовать более высокопроизводительные контроллеры. Например файловый сервер.
• Протокол поддерживает вызов удаленных функций других устройств, системных сообщений, о функционировании каждого устройства и его присутствия на шине, система синхронизации времени и дублирования источников времени.
• Минимизация количества фильтров сообщений для уменьшения нагрузки на микроконтроллер и на шину.
• Поддержка до 127 нод на шине.
• Поддержка дублирования шины и хот-свап устройств.
• Создание пользовательского программы как единой, с возможностью распределения функций между всеми программируемыми устройствами, и поддержкой отладки по единой шине.
• Создание среды разработки для создания системы, написание общего приложения, отладки и мониторинга работы системы, используя общее API построения пользовательского приложения с минимальными требованиями к знаниям о структуре протокола.
• Система предусматривает требования к возможности питания устройств с единой шиной питания от одного или нескольких источников.
• Возможность автоматического выбора скорости работы на шине. А также автоопределение адреса так и использование фиксированного адреса.

1.4 Первые шаги по реализации.

Для отладки протокола и реализации требований к системе  были выбраны две платформы для отладки имея текущий опыт разработки: платформа для управления пеллетными котлами и платформа для управления дроном (в замен PX4). 

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

• Программируемое устройство с реле для управления двигателем подачей пеллетов. На котором реализуются функции управления шнеком, защитой от блокировки и аварийных ситуаций.
• Программируемое устройство сбора данных с аналоговых датчиков температуры воды, горения, кислорода. Реализуются функции фильтрации данных, преобразование в натуральные величины, определение ошибок датчиков и критических событий.
• Программируемое устройство управления исполнительными устройствами, трехходовой клапан, автоподжиг
• Программируемое устройство вывода информации, которое использует данные проходящие по шине для отображения текущего состояния и параметров работы. А также подачи команд по остановке и запуску системы.
• Опционально: GSM модем для возможности передачи параметров работы системы на сервер с целью отладки построения протокола TCP на базе текущего протокола.
• Программируемое устройство получения цифровых данных, для обработки критических событий типа кнопка, SPI датчик температуры.
• Источник питания шины AC-DC (220V AC – 12V DC)

Платформа для управления UAV дроном, для отладки построения системы с централизованным управлением требует следующих плат:

• Центральная плата обработки информации и алгоритмов управления полетом. Требует высокопроизводительный микроконтроллер.
• Программируемые устройства получения данных с цифровых устройств (та же что и для котла) для получения данных с SPI акселерометр/гироскоп, UART – глонас, радио ресивер 6xPWM, lidar, высотомер, а также выдачу 4х PWM для управления контроллерами двигателей.
• Контроллеры управления электродвигателями по шине. 
• Контроллер питания шины с батареи и его дублирование.

Также для разработки требуется создание платы переходника USB-CAN для отладки и разработки системы. И в будущем использования в среде разработки, отладки и мониторинга программ.

1.5 Основные этапы разработки.

• Создание набора вышеописанных плат, для построения системы и отладки в соответствии с требованиями. В качестве элементной базы предполагается на первом этапе использовать микроконтроллеры WCH (Китай) на базе архитектуры RISC-V
• Создание библиотек и ОС для данных микроконтроллеров используя текущий опыт и без использования сторонних библиотек.
• Отладка протокола и проработка единого пользовательского API для создания приложений в данной системе.
• Доработка и отладка минимального функционала работы вышеописанных платформ с целью уточнения всех возможных ньюансов системы..
• Разработка программ для программирования отладки и мониторинга на ПК.
• Объединение все в единую систему разработки с граф интерфейсом и единым сервером хранения информации о существующих устройствах.

2. Описание платформы.

Данная платформа предназначена для гибкого создания, изменения, конфигурирования и отладки систем на базе набора устройств объединенных общей шиной передачи данных.

В качестве общей шины передачи данных используется шина CAN ISO 11898-2 с максимальной скоростью передачи данных до 1Mbit/c (CAN 2.0B) и до 5Mbit/s (CAN-FD)

3. Cостав платформы.

В состав платформы входят следующие элементы:

• Рабочие устройства
• Общая шина передачи данных CAN ISO 11898-2
• Сервер хранения данных
• Система конфигурирования
• Среда разработки
• Система мониторинга
• Проекты системы

3.1 Общая шина передачи данных CAN ISO 11898-2.

Шина CAN используется для обмена данными между устройствами в сети, а также обеспечения питания устройств в режиме конфигурирования и маломощных устройств. Данный протокол использует только сообщения с 29 битным идентификатором без возможности удаленных запросов

3.1.1 Физическое соединение.

Физическое соединение устройств осуществляется в соответствии со спецификацией общей шины CAN и должно быть терминировано 120 Омным сопротивлением с каждого конца линии.

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

Для подключения сигналов CAN_H CAN_L должна быть использована витая пара чтобы уменьшить влияние EMI.

3.1.2 JST GH 4 circuit коннектор.

Данный коннектор является основным для данной системы и предназначен для конфигурирования и  питания маломощных устройств. За счет компактности устройства с таким коннектором могут быть использованы в небольших системах. Возможна установка на плату.

Рекомендуется устанавливать такой коннектор на всех устройствах для упрощения конфигурирования и универсальности. 

Максимальная нагрузка питания для данного коннектора 1A и позволяет использовать провода AWG-30 до AWG-26.

Максимальное рекомендуемое потребление устройства при использовании данного коннектора 2,5Ватт.

Распиновка:

Номер пина	Название	Описание
1	+V	Питание, цвет провода сине-белый либо красный
2	CAN_HI	CAN_H,  цвет провода желтый, витая пара
3	CAN_LO	CAN_L, цвет провода желто-белый, витая пара
4	GND	Земля, цвет провода синий или черный

3.1.3 Circular M8 B-coded 5 cirquit connector.

Коннектор совместим со стандартом CiA103(openCAN) позволят пропускать большую нагрузку и обеспечивает более надежное соединения. Тем не менее значительно больше по размеру GST-GH-4, что ограничивает его использование в малых системах. Позволяет использовать экранированный кабель.

Максимальное рекомендуемой потребление устройства при использовании данного коннектора 6W

Распиновка:

Номер пина	Название	Описание
1	+V	Питание
2	SHIELD	Экран
3	CAN_HI	CAN_H,  витая пара
4	CAN_LO	CAN_L, витая пара
5	GND	Земля

3.1.4 Дублирование.

На устройствах допускается использование двух CAN интерфейсов для работы в двух сетях или в целях дублирования системы.

Дублирование датчиков с одним интерфейсом возможно установкой двух идентичных датчиков на две различные шины

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

3.1.5 Скорости передачи.

В данной системе используется 4 скорости передачи данных. Каждое устройство может быть настроено для работы на конкретной скорости либо на предпочитаемой скорости позволяя устройству определить скорость исходя из текущей скорости на шине.

Настройки протокола CAN:  TSEG1,TSEG2, SJW определяются исходя из требуемой скорости передачи и тактовой частоты периферийного модуля в соответствии с «Automatic Baudrate Detection in CANopen Networks», U. Koppe, MicroControl GmbH & Co. KG CAN in Automation, 2003

Варианты скорости передачи:

• BUS_SPD_1000K  — 1Мбит/с, SmplPoint=75-90%, Максимальная длина шины – 40м, длина ответвления – 0.3м
• BUS_SPD_500K — 500Кбит/с, SmplPoint=85-90%, Максимальная длина шины – 100м, длина ответвления – 0.3м
• BUS_SPD_250K — 250Кбит/с, SmplPoint=85-90%, Максимальная длина шины – 250м, длина ответвления – 0.3м
• BUS_SPD_125K — 125Кбит/с, SmplPoint=85-90%, Максимальная длина шины – 500м, длина ответвления – 0.3м

3.1.6 Питание по шине.

Все устройства должны иметь возможность питаться с шины CAN как минимум для возможности конфигурирования устройства. Каждое устройство может быть как источником так и потребителем на шине, либо совмещать оба этих режима.

Питание устройств по шине осуществляется в двух режимах:

• BUS_CFV_5V – питание шины используемое только для конфигурирования устройства, в данном режиме устройства должны потреблять минимальное количество энергии, необходимое лишь для обновления прошивки, настройки и т.д. Основной источник – питание с шины USB.
• BUS_CFV_12V – нормальное питание на шине, предназначено как для конфигурации так и рабочего режима. Диапазон номинального напряжения в данном режиме варьируется исходя из требований системы и может быть в пределах от 6,2 до 13,5 V, что соответствует питанию шины с LiPo батареи 2S-3S. 

При питании с шины устройство должно обеспечивать следующие функции:

• Реализовывать возможность питания с шины в пределах 4.5-13.5V.
• Мониторить напряжение питания на шине и переключатся в соответствующие режимы
• Даже если устройство имеет внешнее питание, оно должно быть конфигурируемо используя питание только по шине.
• В случае выхода напряжения питания из рабочих диапазонов для конкретного устройства, устройство должно переходить в режим DEV_MODE_UFUNC (рабочий) и сигнализировать об этом в состоянии.
• При восстановлении нормального для данного устройства питания, устройство автоматически должно переходить в полнофункциональный режим из DEV_MODE_UFUNC

Источником питания может выступать одно из устройств системы и соответствовать требованиям:

• Источников питания может быть на шине несколько либо образовывать разные домены питания частей сети
• Устройство должно иметь аппаратную защиту от обратного тока.
• Устройство должно иметь аппаратную возможность отключать питание на шине.
• Устройство должно подавать питание на шину и мониторить напряжение питания и ток с устройства и выключать подачу питания в случае выхода параметров за рамки характеристик данного устройства не зависимо от режимов работы. Возможен вариант при котором напряжение данного устройства может отличаться от другого источника на шине. Например одно устройство питает 12В другое используется как backup с питанием 8В, таким образом устройство должно мониторить собственное напряжение и не допускать выхода его за свои рамки, при этом не допуская обратный ток и не отключая собственное.
• Устройство должно подавать питание на шину по умолчанию при нормальной работе, не зависимо от режимов работы
• Устройство должно питаться с шины как минимум с целью конфигурации, и также потреблять ограниченный ток для своих нужд. Например устройство с собственной батареей может использовать питание с шины, если является резервным с целью зарядки, но не больше допустимого для одного устройства

3.1.7 Константы шины.

В данном документе определены следующие константы для определения работы на шине

Наименование	Значение	Описание
BUS_CFG_HR_TIME	1сек	Время посылки сообщения MSG_SRV_HR
BUS_CFG_TXERR_MAX	128	Максимальное значение счетчика ошибок посылки перед отключением шины
BUS_CFG_TXERR_MAX	128	Максимальное значение счетчика ошибок приема перед отключением шины

3.2 Рабочие устройства.

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

Все устройства должны обеспечивать следующие функции:

• работу на шине CAN в соответствии с данным протоколом
• питание устройства должно осуществляться с шины CAN в двух режимах: BUS_CFV_5V или BUS_CFV_12V – питание с шины с минимальным потреблением для конфигурирования. CFV_12V либо дополнительное внешнее питание для полноценной работы. 
• работу в одном из описанных ниже режимах
• обрабатывать команды общего управления MSG_SRV_CFG_MASK
• выдавать на шину сигнал присутствия MSG_SRV_HR
• иметь функционал для тестирования и визуального определения устройства. (напр. При подаче сигнала TEST по шине сигнализировать светодиодом или звуком, чтобы была возможность физически определять конкретное устройство на шине )
• Иметь возможность обновлять прошивку устройства по шине CAN
• Осуществлять проверку целостности программы устройства.
• Иметь аппаратную защиту от зависания (WatchDog)
• Иметь возможность блокирования изменения конфигурации и прошивки
• Обеспечивать защиту и разграничение доступа пользовательского приложения к функциям прошивки устройства (программируемые устройства)

Все устройства должны содержать описательные поля:

Название	Размер	Описание
DEV_INFO_GID	6 байт	Глобальный идентификатор устройства. Уникальный для каждого типа устройств. Используется для идентификации устройства на сервере и получения данных для управления и разработки. Фиксированное значение и не может быть изменено средой разработки.
DEV_CFG_UID	6 байт	Идентификатор устройства в рабочем режиме. Является уникальным в рамках конкретной системы и используется для идентификации функционального устройства. Задается в виде текстовой строки 8 символов 6ти битного кодирования. Устанавливается пользователем либо средой разработке при проектировании.
DEV_INFO_SN	4 байт	Серийный номер устройства. 0 – если не используется. Фиксированное значение, устанавливаемое производителем
DEV_INFO_FW_MAJ	2 байт	Старший номер версии прошивки. В рамках одного и того же номера предоставляемые сервисы должны быть одни и те же и позволять выполнять один и тот же пользовательский код.
DEV_INFO_FW_MIN	2 байт	Младший номер прошивки.
DEV_INFO_PROG	1 бит	Устанавливается в 1 если устройство программируемо
DEV_INFO_FPU	1 бит	Устройство имеет возможность работать с Float данными
DEV_INFO_CPU	16 бит	Тип ядра используемого процессора: 0x0001 – RISC_V RV32I 0x0002 – RISC_V RV32E
DEV_INFO_CPU_FLAGS	16 бит	Флаги команд процессора пока не определены
DEV_CFG_BSPD	8 бит	Настройка скорости передачи данных, является частью конфигурации и хранится в энергонезависимой памяти 0 — BUS_SPD_125K фиксированная 1 — BUS_SPD_250K фиксированная 2- BUS_SPD_500K фиксированная 3 — BUS_SPD_1000К фиксированная 128- BUS_SPD_125K предпочитаемая 129- BUS_SPD_250K предпочитаемая 130- BUS_SPD_500K предпочитаемая 131- BUS_SPD_1000K предпочитаемая
DEV_CFG_ADDR	8 бит	Установленный адрес для данного устройство, является частью конфигурации и хранится в энергонезависимой памяти Значение 0- указывает что адрес не определен и может устанавливаться автоматически В других случаях: Если старший бит равен 0 то адрес содержащийся в младших 7 битах является фиксированным, иначе адрес является предпочитаемым и может быть изменен Младшие 7 бит указывают на адрес устройства
DEV_CFG_AUTOSTART	1 бит	0 – устройство стартует в конфигурируемом режиме 1 – устройство по возможности переходит в рабочий режим

3.2.1 Программируемые устройства.

Программируемые устройства представляют из себя устройства которые позволяют выполнять программу разработанной в данной платформе. Таким образом позволяя распределять выполняемый код в системе между всеми такими устройствами как единой вычислительной средой. 

Программируемые устройства могут быть как законченным функциональным устройством (напр. Датчик температуры) так и многофункциональным (напр. Устройство АЦП). Или включать в себя комбинацию разных функций.

Все программируемые устройства должны включать следующие  элементы:

• Boot – базовый загрузчик, запускающийся сразу после подачи питания, выполняющий инициализацию периферийных блоков системы и реализующий минимальную работу устройства на шине с целью либо запуска рабочей прошивки, либо обеспечить возможность загрузить прошивку. Boot0 должен обеспечить возможность всегда перепрограммировать устройство использую шину CAN и не допускать состояния при котором устройство не может быть перепрограммировано.
• FW – основная прошивка устройства, которая разрабатывается разработчиком устройства в соответствии с требованиями данного документа. Разработка прошивки не является частью данной платформы. В процессе разработки должны быть созданы файлы описания API и настроек прошивки для работы со средой разработки.
• USER_SPACE- место загрузки пользовательского кода. 

3.2.2 Конфигурируемые устройства.

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

Тем не менее все такие устройства должны также содержать Boot с теми же функциями что и программируемое устройство, а также прошивку, предоставляющую определенные сервисы и файлы описания настроек и сервисов прошивки.

3.2.3 Устройство отладки и мониторинга.

Устройство отладки и мониторинга может быть в виде конфигурируемого устройства или программируемого устройство, может выбирать 0 адрес по умолчанию в случае отсутствия на шине других устройств отладки и выполнять кроме основных — дополнительные функции:

• Предоставлять интерфейс для подключению к среде разработки или системе мониторинга посредством USB или ethernet etc.
• Обеспечивать независимо от режима работы доступ к шине(ам) CAN для получения всех сообщений и отсылки любого сообщения на шину.
• Возможность устанавливать фильтры сообщений для передачи на ПК.
• Обеспечивать достаточную скорость для получения и отправки всех сообщений исходя из пропускной способности всех CAN шин, к которым может подключаться
• Реализовывать отдельные функции для настройки и управлением собственной прошивкой, сервисами, обновлением устройства.

3.2.4 Режимы работы устройств.

Все устройства выполняют функционал в одном из режимов работы:

• DEV_MODE_INIT – Этот режим используется сразу после включения устройства либо при обнаружении нерешаемой коллизии на шине CAN. Устройство не доступно по шине.
• DEV_MODE_ARSLV – режим определения адреса для использования на шине, устройство недоступно по шине, либо доступ ограничен.
• DEV_MODE_CFG/ DEV_MODE_BOOT – режимы конфигурации устройства
• DEV_MODE_WORK/ DEV_MODE_UFUNC – рабочие режимы устройства.
• DEV_MODE_IDLE – режим пониженного потребления, ограниченный рабочий режим.

3.2.4.1 DEV_MODE_INIT.

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

В данный режим устройство переходит сразу после подачи питания или при обнаружении нерешаемых проблем на шине. Предназначен для первичного определения скорости и требований для работы в сети. 

Определение скорости на шине выполняется по аналогии с CiA 801 application note 5.2.3. Процедура подключения к шине следующая.

1. После включения устройство переключает передатчик в режим Silent и настраивает скорость шины на скорость DEV_CFG_BUS_SPEED, или если таковая не определена на BUS_SPD_125K.
2. Устройство ожидает в silent режиме получения всех пакетов на шине 1.5*BUS_CFG_HR_TIME
3. При получении корректных пакетов, устройство переходит в режим DEV_MODE_ARSLV п.0. 
4. При получении  ошибок шины, устройство, если требуемая скорость является предпочитаемой, либо не определена, увеличивает скорость по циклу или не меняет ее, если скорость DEV_CFG_BSPD является фиксированной и переходит на п. 1.
5. В случае отсутствия пакетов после таймаута, устройство считает что на шине нету устройств, либо они еще не определены и  переходит в режим DEV_MODE_ARSLV п. 1.

3.2.4.2 DEV_MODE_ARSLV.

В этом режиме осуществляется проверка доступности адресов на шине и/или возможность автоматического выделения адреса. В данном режиме выполняется следующее:

1. Устройство получает все сообщения с шины в течении 1.5*BUS_CFG_HR_TIME при этом, анализируя все валидные msg.src и msg.dst адреса и строя таблицу занятых адресов.
2. По истечению таймаута, устройство выбирает свой предпочитаемый адрес, если он не занят, либо случайный незанятый адрес, либо фиксированный адрес (Если фиксированный адрес занят, то переходит в п.0.) исходя из DEV_CFG_ADDR и случайный временной интервал в диапазоне BUS_CFG_HR_TIME.
3. Если по истечении этого интервала, не было других сообщений или ошибок на шине, устройсво выключает Silent режим посылает сообщение MSG_SRV_HR без автоматической повторной передачи . При успешной отсылке которого переходит в один из рабочих либо конфигурируемых режимов исходя из настроек.
4. Если в течении данного интервала было получено другое валидное сообщение с тем же адресом, то устройство переходит п.1. Если были сообщения с другими адресами, то переходит в рабочий или конфигурируемый режим
5. Если в течении данного интервала было превышено количество ошибок на шине, то устройство переходит в режим DEV_MODE_INIT п.1

3.2.4.3 DEV_MODE_CFG/ DEV_MODE_BOOT.

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

В данные режимы устройство переходит при следующих условиях:

• Настройки устройства из DEV_CFG не предполагают автоматический запуск устройства
• DEV_CFG_ADDR не имеет предпочитаемого либо фиксированного адреса
• DEV_CFG_UID – поле не заполнено, либо неуникально
• Устройство было удаленно переведено в этот режим для настройки
• Устройство питается в режиме конфигурации или нет дополнительного питания
• Устройство не имеет прошивки.

И осуществляет следующие функции:

• Мониторить ошибки шины и при превышении порога BUS_CFG_ERR_CNT переходить в режим DEV_MODE_INIT
• Отслеживать сообщения MSG_SRV_HR для определения свободных и занятых адресов на шине и проверять уникальность собственного DEV_CFG_UID
• Отслеживать сообщения с валидными msg.src имеющие тот же адрес что и собственный
• В случае обнаружения использования такого же адреса на шине что и собственный, устройство должно перейти в режим DEV_MODE_ARSLV
• В случае обнаружения рабочего устройства с тем же DEV_CFG_UID не давать переходить в режим DEV_MODE_WORK
• Посылать одно сообщение MSG_SRV_HR в течении интервала BUS_CFG_HR_TIME, для обозначения присутствия на шине
• Обрабатывать все сервисы доступные для данного режима с целью настройки устройства, обработки системных сервисов (режим DEV_MODE_CFG), обновление прошивки и пользовательского кода и выдачи системной информации
• В данном режиме устройство не посылает запросы, только ответы на команды (кроме MSG_SRV_HR)

Таким образом в данном режиме требуется настроить следующие фильтры входящих сообщений:

• Маска всех широковещательных запросов от рабочих устройств
• Маска всех запросов от рабочих устройств для конкретного адреса.
• Маска собственного адреса 
• Маска всех MSG_SRV_HR 

3.2.4.4 DEV_MODE_WORK/ DEV_MODE_UFUNC.

Данный режим выполняется в следующих условиях:

• Устройство было сконфигурировано и запрограммировано с корректной пользовательской программой и запущенно автоматически либо удаленно
• Устройство имеет фиксированный или предпочитаемый адрес DEV_CFG_ADDR
• Устройство имеет валидный и уникальный DEV_CFG_UID

И осуществляет следующие функции:

• Мониторить ошибки шины и при превышении порога BUS_CFG_ERR_CNT переходить в режим DEV_MODE_INIT
• Отслеживать сообщения MSG_SRV_HR для определения свободных и занятых адресов на шине и проверять уникальность собственного DEV_CFG_UID
• Отслеживать сообщения с валидными msg.src имеющие тот же адрес что и собственный от рабочих устройств
• В случае обнаружения использования такого же адреса на шине что и собственный от другого рабочего, устройство должно перейти в режим DEV_MODE_ARSLV
• В случае обнаружения рабочего устройства с тем же DEV_CFG_UID переводится в режим DEV_MODE_CFG
• Посылать одно сообщение MSG_SRV_HR в течении интервала BUS_CFG_HR_TIME, для обозначения присутствия на шине
• Обрабатывать все сервисы доступные для данного режима с целью обеспечения выполнения пользовательских сервисов, обработки системных команд, выдачи системной информации
• В данном режиме устройство свободно посылать любые запросы и ответы в рамках данного протокола

Таким образом в данном режиме требуется настроить следующие фильтры входящих сообщений:

• Маска широковещательных системных запросов и MSG_SRV_HR от рабочих устройств 
• Маска системных запросов и MSG_SRV_HR от рабочих устройств данному устройству
• Маска широковещательных рабочих запросов 
• Маска адресных рабочих запросов 
• Дополнительные маски на получение ответов, зависит от реализации

Оба режима DEV_MODE_WORK/ DEV_MODE_UFUNC работают одинаково на шине, отличие заключается лишь в том, что режим DEV_MODE_UFUNC – режим при котором имеет ошибки не позволяющие выполнять свои функции и таким образом ожидает исправления ошибки. Это указывается в сообщениях MSG_SRV_HR и обрабатывается другими устройствами.

3.2.4.5 DEV_MODE_IDLE

Данный режим предназначен для работы устройства в режиме пониженного энергопотребления. Перевод в этот режим осуществляется по внешней команде. Возможны три варианта реализации:

• Постоянный режим, в котором устройство выключает по возможности всю периферию и может выйти из этого режима только по сбросу питания.
• Управляемый режим. Этот режим может быть реализован только на микроконтроллерах позволяющих выходить из режима сна по приходу соответствующей команды на шине CAN. Таким образом устройство выключает всю периферию, настраивает фильтр на приход конкретной команды и выход из этого состояния по прерыванию от таймера или события с шины CAN. При этом просыпаясь раз в BUS_INFO_HR_TIME интервал для отсылки сообщения о доступности MSG_SRV_HR. 
• Эмуляция. На устройствах без возможности получения сообщений с CAN в спящем режиме, это состояние может эмулироваться без ухода самого микроконтроллера в сон, но при этом должно быть выключено максимально возможное количество потребителей.

4. Сообщения.

• Все посылаемые сообщения не могут иметь один и тот же заголовок (CAN 2.0B)
• Доминантным битом является 0, который позволяет получить приоритет при коллизии (CAN 2.0B)
• Сообщения могут как содержать данные, так и быть без данных (обозначается как NULL)
• Адрес 0 зарезервирован для использования Debug устройством для возможности подключения как минимум одного такого устройства на шину. В случае подключения нескольких таких устройств, дополнительные определяют адрес на шине по общим правилам.

4.1 Формат сообщений.

28	27	26	25	24	23-17	16-10	9-0	< 8 Байт
U	D	R	B	ERR	SRC	DST	SRV	DATA

• U :  0 — нода посылающее сообщение в режиме DEV_MODE_WORK 

1 — В одном из нерабочих режимов

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

• D :  0 — Адресуемое устройство DEV_MODE_WORK

1 — в одном из нерабочих режимов

Для обмена рабочими данными между нодами этот бит всегда устанавливается в 0. Для обращения к конфигурируемым нодам этот бит устанавливатся в 1. Таким образом конфигурируемые ноды могут фильтровать сообщения только с D=0

• R :   0 — Request. Запрос к сервису

1 – Response. Ответ от устройства.

При формировании запроса к сервису ноды, этот флаг устанавливается в 0, что позволяет установить фильтр ноды на запросы. В случае ожидания ответа, нода может установить фильтр либо на конкретный адрес и/или сервис и/или ответ.

• B :   0 — Target. сообщение предназначено конкретному устройству

1 — Broadcast. Широковещательное сообщение.

Нода может формировать широковещательные или целевые запросы или ответы.

В случае широковещательного сообщения, поле удаленного адреса заполняется значением RND7

• ERR : 0 — ошибка возникла при обработке запроса

    1 — нет ошибки

В случае ответа на запрос и невозможности его обработать, отвечающая нода устанавливает этот флаг в 0, поле DATA при этом может содержать DEV_SRV_ERROR_CODE с кодом ошибки, либо посылать ответ без данных. В остальных случаях этот бит должен быть установлен в 1.

• SRC : Адрес источника сообщения

Временный либо постоянный адрес источника. Должен быть установлен всегда уникальным на шине. Адрес 0 зарезервирован для использования устройства DEBUG

• DST : Адрес получателя.

Устанавливает адрес ноды которому предназначается сообщение. В случае широковещательного сообщения (B=1) используется значение RND7

• SRV : идентификатор сервиса.

Номер сервиса для запроса или ответа.

• DATA : 0-8 байт данных сообщений

Данные сообщения может не использоваться, в этом случае в описании указывается DATA=NULL

4.2 Приоритеты по флагам.

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

• Сообщения от сконфигурированного устройства (U=0)
• Сообщения на конфигурируемое устройство (D=0)
• Запросы к сервисам (R = 0)
• Не широковещательные сообщения (B = 0)
• Ответы с ошибками
• Наименьшее значение адреса источника
• Наименьшее значение адреса назначения
• Наименьшее значение номера сервиса

Таким образом, например при возникновении коллизии сообщения от сконфигурированного устройства и несконфигурированного, сконфигурированное получит приоритет.

4.3 Возможные типы сообщений.

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

• Значение x в бите указывает, что значение бита не важно и устанавливается в соответствии с общими требованиями к конкретному биту
• Вызовы от конфигурируемой ноды к конфигурируемой, а также конфигурируемой к рабочей — не используются

Название	Используемые биты	Описание
MSG_TYPE_REQ_CC_TGT	U=0, D=0, R=0, B=0, Err=0	Вызов сервиса от рабочей ноды у рабочей ноды. Ответ обязателен.
MSG_TYPE_REQ_СC_BCST	U=0, D=0, R=0, B=1, Err=0	Широковещательный вызов сервиса от рабочей ноды, всем рабочим нодам. Ответ не обязателен.
MSG_TYPE_RSP_CC_TGT	U=0, D=0, R=1, B=0, Err=x	Ответ на MSG_TYPE_REQ_CC_TGT либо на MSG_TYPE_REQ_СC_BCST (если ответ требуется только запрашиваемому устройству) при этом rsp.dst=req.dst, rsp.D=req.U
MSG_TYPE_RSP_CC_UNSC	U=0, D=0, R=1, B=1, Err=x	Возможный ответ на  MSG_TYPE_REQ_СC_BCST если требуется рассылка данных ответа многим устройствам, также может использоваться как широковещательная рассылка данных без запроса
MSG_TYPE_REQ_CU_TGT	U=0, D=1, R=0, B=0, Err=0	Вызов сервиса от рабочей ноды к конфигурируемой.
MSG_TYPE_REQ_СU_BCST	U=0, D=1, R=0, B=1, Err=0	Широковещательный вызов сервиса от рабочей ноды, всем конфигурируемым нодам. Ответ не обязателен.
MSG_TYPE_RSP_CU_TGT	U=1, D=0, R=1, B=0, Err=x	Ответ на MSG_TYPE_REQ_CU_TGT либо на MSG_TYPE_REQ_СU_BCST (если ответ требуется только запрашиваемому устройству) при этом rsp.dst=req.dst, rsp.D=req.U
MSG_TYPE_RSP_CU_UNSC	U=1, D=0, R=1, B=1, Err=x	Возможный ответ на  MSG_TYPE_REQ_СU_BCST если требуется рассылка данных ответа многим устройствам, также может использоваться как широковещательная рассылка данных без запроса
MSG_TYPE_DEBUG	U=1, D=1, R=1, B=1, Err=1	Отладочное сообщение. Rsp.Dst=127. Rsp.Srv- содержит код сообщения. Data содержит параметры.