В этой статье вы сможете прочитать про протокол Высокого уровня — Can Kingdom, который в свою очередь ложится поверх ISO 11898 CAN. Статья будет состоять из двух частей:

1. Can Kingdom и надёжные системы (общие понятия, примеры)
2. Собранная система с Can Kingdom. Королевство без Короля.

Немало можно найти про CAN Open материалов на любом языке, это связано с широкой распространённостью данного протокола, однако CAN Kingdom во некоторых моментах более прост (как в реализации, так и в понимании). В этой статье я хотел поделится с вами как и общей информацией о CAN Kingdom (на русском не нашёл ничего в интернете), так и примером собранной мною системы на его базе.

Часть 1

Введение

ISO 11898 CAN это протокол низкого уровня. Любая система требует протокол высокого уровня, который сделает её максимально надёжной. Конечно, надежность системы зависит от устройств, которые она содержит, а также от возникаемых с ней ситуаций. К примеру, гидравлическое масло лесопильной машины перегревается. Если она передвигается по ровной твёрдой поверхности, очевидным решением проблемы будет просто остановится, но если машина едет по болотистому грунту, то остановка приведёт к тому, что её начнёт засасывать в землю. Или другой пример, самолёт может вполне безопасно выключить двигатели, если находится на земле, но никак не в воздухе. Очевидно, что Вы легко сможете привезти ещё много примеров, такие как пропеллеры, процессы, автоматизированное производство и др., все эти системы подходят для использования CAN протокола, но имеют весьма специфические ограничение и требования к протоколу высокого уровня. CAN Kingdom предназначен для решения этой проблемы, предоставляя системному разработчику возможность оптимизировать протокол высокого уровня своей системы, всё ещё используя стандартный продукт.

Четыре фундаментальных основы CAN Kingdom:

Чёткое разделение между модулем и уровнем системы
Любые взаимосвязи в системе предопределены
Предоставление «строительных» блоков для кустомизации протокола высокого уровня
Отсрочка решения, насколько это возможно

Разделение между модулем и системным уровнем — это ключ к надёжности системы. Разделение можно сделать основываясь на факте того что любые взаимосвязи в системе предопределены. Предопределение взаимосвязей — это сердце системы. Любой модуль, взаимодействующий с другим, делает это согласно хорошо продуманному набору правил, разработанному системным разработчиком.
CAN Kingdom позволяет это сделать используя «строительные» блоки, которые есть в каждом модуле. Подобная архитектура системы даёт возможность меня правила когда угодно, даже во время непосредственной работы. Это напоминает старинное королевство: Король издаёт законы для своего королевства, и Мэры каждого из городов следят за их локальным выполнением. Мэры несут ответственность исключительно перед королём, который контролирует их верность. Король может менять законы время от времени, для поддержания стабильности и эффективности королевства в периоды кризиса. Это и есть CAN Kingdom, сильнейший инструмент в руках системного разработчика.

Чтобы избежать двусмысленности в CAN Kingdom используется специфическая семантика, которая будет изложена ниже.

Система и модули

Как организовать и управлять надёжной системой сильно зависит от самой системы и от её структуры. Структура системы, в свою очередь, зависит от состояния различных модулей в текущий момент времени. Надёжная система всегда должна быть безопасной, однако в большинстве случаев, это невозможно иметь абсолютно безопасную систему вовремя её работы. Самолёт может считаться безопасным, когда стоит на взлётной полосе, без экипажа, и с выключенными системами. Но каждый шаг на пути к взлёту увеличивает риск. Безопасность и возможность — противоречивые требования и итоговая система должна быть компромиссом между ними. Поэтому очень важно различать ответственность системы и ответственность модуля. В CAN Kingdom, разработчик модуля сконцентрирован на решении локальных проблем и на возможность предоставить выбор, при появлении спорной ситуации. Системный разработчик должен организовать систему и сделать этот выбор.

Базовая архитектура системы CAN Kingdom это один наблюдающий модуль, Столица, с наблюдающей программой, Королём. Это собственность системного разработчика, Основателя Королевства. Он несёт полную ответственность за поведение системы. Разработчик модуля, основатель города, ответственен исключительно за свой модуль, Город, и за программу этого города, Мера. Король и каждый Мэры имеют библиотеку общих процедур, Королевские документы, которыми король может распространять управляющие сообщения, и документы Мэра, которыми Мэр может отвечать. Простая система изображена на рисунке 1.

Можно выделить четыре основных узла, Столицу с Королём, 2 сенсорные узла, Город 1 и Город 2, и последний узел, Город 3, использующий информацию от сенсоров. Программы(узлы) разбиты на части. Каждый узел имеет как минимум 3 части, Королевские документы и документы Мэра, для управления системой, и третья часть для основной программы. Записи CAN сообщений располагаются в раздельных папках, предоставляя возможность для контроля потока данных на системном уровне.

Резюмируем: есть Столица, в которой находится программа управляющая системой — Король, Король управляет Городами (модулями), через написанные для этого программы — Мэров. CAN сообщения хранятся в специальных папках. Которые можно разделить на 3 части: Королевские, Мэровские и Специальные. Папки создаёт основатель города (разработчик модуля). Конверт — CAN сообщение. Страница — специальный байт, позволяющий понять какой именно Королевский или Мэровский документ пришёл.

Управляющие сообщения

Королевские документы это набор управляющих сообщений каждое, из которых конфигурирует модуль для работы в системе. Все они имеют один CAN Id, по умолчанию 00h. Первый байт данных в сообщении это адрес одного из элементов системы, или группы элементов. Адрес 00h передаётся всем узлам. Следующий байт это номер страницы, чтобы идентифицировать различные команды.
Форма Королевской страницы х:

Имя документа: Королевский Документ
Список документа: 0.1 Столица / х.0 Город
Номер документа: 0 Столица / 0 Город
Тип документа: Передача (Столица)
Получение (Город)

Описание страницы.
Номер страницы:
Количество строк: 8
Описание данных:
Описание строк.
Строка 0: Адрес города или группы
Строка 1: хххххххх (Страница х)
Строка 2: rrrrrrrr Команды
Строка 3: rrrrrrrr
Строка 4: rrrrrrrr
Строка 5: rrrrrrrr
Строка 6: rrrrrrrr
Строка 7: rrrrrrrr

Королевский документ — это набор, передаваемых королём, сообщений и получаемых сообщений Мэром. Каждый Мэр имеет одно сообщение для отправки в качестве ответа. CAN Id для этого сообщения это номер узла плюс «базовый номер», который присваивается Королём вовремя загрузочной последовательности.

Форма страницы 0 Мэра:

Имя документа: Документ Мэра
Список документа: 0.1
Номер документа: 1.1
Тип документа: Передача
Описание страницы.
Номер страницы: 0
Количество строк: 8
Описание данных: Идентификация города, EAN-13 код
Описание строк.
Строка 0: RRRRRRRR зарезервировано R = 0
Строка 1: хххххххх (Страница х)
Строка 2: rrrrrrrr Ответ
Строка 3: rrrrrrrr
Строка 4: rrrrrrrr
Строка 5: rrrrrrrr
Строка 6: rrrrrrrr
Строка 7: rrrrrrrr

Членское соглашение

Основатель Королевства (Системный разработчик) может нести ответственность за свою систему только в том случае, если он утвердил все Города. Никаких других модулей не должно быть подключено. Есть 2 способа проверки членов: опросом их идентификаторов, и отслеживанием трафика шины. Каждый Город в CAN Kingdom имеет уникальный EAN или UPC номер. Это говорит производитель, номер продукта и серийный номер Города.

Когда Мэр получает Королевскую страницу, он, как только это возможно, отвечает запрашиваемой Страницей из его (Мэра) документов. Страница 0 содержит EAN/UPC код, Страница 1 — серийный номер. Расписывать сами страницы я не буду, их можно найти в документации.
Король используя Страницу 1, запрашивает от Мэра Документ Страницы 0 в качестве ответа, каждый Город должен ответить своим EAN/UPC кодом. Взяв Базовый номер из каждого Конверта (сообщения), Король получает адрес каждого Города и из полученной Страницы номер продукта. Дальше он может проверить, правильность ассоциации адреса и оборудования. Новый запрос Страницы 1 Мэра даст Королю серийный номер, и сохранив его, он сможет отслеживать любые замены Городов, а также загружать специфические системные настройки по необходимости.

Контроль доступа шины

Основной контроль доступа к шине CAN это побитовый арбитраж. Даже если CAN Kingdom поддерживает планирование времени и гирляндовый доступ, побитовый арбитраж обосновывается базовым режимом, позволяя быстрые незапланированные аварийные сообщения и использование в качестве запасного режима, если расписание или цепь разрушились. Надёжность CAN системы в значительной степени зависит от правильности приоритета каждого отдельно взятого сообщения. Системный разработчик обладает полным пониманием всей системы в целом и ответственен за назначение приоритетов. В системе CAN Kingdom каждый Город имеет только один CAN Id изначально, Конверт для приёма Письма Короля. Он получает переданный Конверт, для Страницы Мэра по первой Королевской Странице (установка базового и физического номера), и для всех остальных по второй Королевской Странице (номера конвертов).

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

Мы не будем вдаваться в подробности о времени в CanKingdom, но стоит отметить, что Король может установить максимальное время повторной отправки для каждого Конверта. Это не решает проблему «Бормочущего идиота», но позволяет вычислить максимальное время задержки и правильно настроить любое сообщение.

Чисто событийная коммуникация или коммуникация, опирающаяся на местные не синхронизированные часы будет приводить время от времени к ситуациям, в которых будут теряться сообщения при 100% нагрузке шины. Один из способов узнать живы ли Города, это сообщение-гирлянда. Одно сообщение будет вызывать отправку другого. Такое поведение настраивается Королевской Страницей 5. Этой страницей Король приказывает Мэру, разрешить Странице из одного Документа реагировать на другую Страницу другого Документа. Этот приём может быть использован не только в планировании сообщений, но и для подтверждения приложений, срабатывания событий в других Узлах и т.п. Функция может управляться путем включения / отключения Папки и связь может быть удалена, путем удаления Документа из фактической Папки.

Часто можно услышать, что CAN нельзя использовать для надёжной системы, построенной на обработке событий. Это не совсем правда. Стандарт 11898 только определяет поведение CAN контроллера. Побитовая проверка решает bus collisions (п.п. bus collisions- столкновения или проблемы в шине) в предсказуемое время. Ничто никому не запрещает использовать CAN в системах временного планирования. CAN предоставляет возможность создание в Королевстве единых синхронизированных часов, и отправку сообщений согласно временнОму расписанию. Эта тема здесь не обсуждается, и подробнее с ней можно ознакомится в спецификации CAN Kingdom, которая может быть скачана с официального сайта.

Загрузочная последовательность:

Для безопасного функционирования Почтовой системы (системы коммуникации) в Королевстве
важно, чтобы любой город действовал созвучным и безопасным путём, когда подключался к Почтовой Системе.

Город может оборвать связь двумя наиболее вероятными путями:

1. Используя другую скорость передачи, отличную от скорости Почтовой Системы;
2. Передачей Письма(Сообщения CAN) в Конверте (CAN Id) предназначенному для передачи в другой Город.

Во избежание подобных происшествий, Город должен хранить молчание пока Почтальон (CAN контроллер) не получит корректное Письмо. Если Мэр знает Базовый Номер Королевства, он сообщает о своём присутствии, в противном случае он будет ожидать, пока его не опросит Король.

Следующая процедура запуска описана для Городов CAN Kingdom:

1. Мэр выполняет внутренние тесты
2. Мэр устанавливает скорость передачи Почтовой системы в 125 кбит/сек, и режим «Молчания»(без подтверждений и без сообщений об ошибках) на 200мс и ожидает Стандартного Письма с конвертом 2031Std содержащего Страницу, в которой все 8 Строк содержат ААhex.
2a. Если такое письмо получено в течении 200мс, Мэр сохраняет на настройку регистров и переключается в режим «Только Слушать», ожидая Королевское Письмо.
2b. Если такое письмо НЕ получено в течении этого периода, Мэр устанавливает Почтамт в настройки регистров согласно предполагаемому Королевству и месту, сохраняя режим «молчания» и ожидает корректного письма.
Когда Письмо получено корректно:
3a. Если Базовый номер известен, Мэр устанавливает Почтамт в Режим «Коммуникации» и передаёт своё Письмо со страницей 0
2b. Если Базовый номер НЕ известен, Мэр переключается в режим «Только Слушать» и ожидает письмо от Короля.

Настройка конвертов

После успешной настройки базового и физического номера, системный разработчик должен настроить Конверты, связав ими папки между городами. По факту, каждая папка в городе является её интерфейсом. К примеру, у выключателя на стене есть 1 интерфейс — toggle Light. А у ПЛК их будет больше 10. Разработчик системы должен задать, что, скажем, Интерфейс № 1 выключателя, должен получать сообщения от Интерфейса №10 ПЛК. Остальные же сообщения Выключатель должен отфильтровывать и игнорировать. Именно так настраивается система в Can Kingdom с помощью 2ой королевской страницы.

Кроме этого не стоит забывать про приоритет сообщений. Он зависит от CAN Id, т.е. ситуация может выглядеть так:

Device #A, TX (transmit) Folder X — присваивается id N
Device #B, RX (recieve) Folder Y — присваивается id N и id M
Device #C, TX (transmit) Folder Z — присваивается id M
при этом N < M, тогда если Device A и Device C одновременно отправят свои конверты, то Device #B вначале получит Конверт от A потом от C.

Есть ещё 1 важный аспект. TX Folder может обладать только 1 Can ID. RX Folder в свою очередь может иметь несколько.

Разработчик Системы (Король) фактически назначает, кто будет слышать кого. И какие интерфейсы устройств (Городов) будут работать в системе, получать и отправлять сообщения.

Контроль во время работы

Страницей 0 Король сообщает Мэрам, что настройки завершены, и что они должны перевезти соответственные города в режим работы. Также её можно использовать, чтобы заморозить работу Города или группы Городов в режиме работы, остановить пересылку любых Писем, перезагрузки и т.п. Таким образом, Король не только активность каждого города, но и их связи. Иногда это важно во время экстремальных условий. Части Королевства должны быть отключены от шины, но всё ещё оставаться активными, высвобождая канал для других частей. Когда город заморожен, Мэр должен быть способен обработать все типы Королевского Письма. Город может иметь больше одного режима «Заморозки», «Работы» или «Перезагрузки», которые могут быть выбраны с помощью Страницы 0. Король может отправить это сообщение, как в один Город, так и в группу Городов, или во все Города.

Как бы то ни было, Страница 0 это основной инструмент Короля в управлении Королевством в Режиме работы, он свободно может использовать другие Страницы. Города могут быть добавлены или удалены во время работы, в зависимости от того как Системный разработчик задал им подобное поведение. Если Базовый номер известен априори, Мэр сообщит о себе, как только увидит валидное сообщение в шине, иначе он (номер) будет назначен Королём. Соответственно Король может решить, когда и как Город будет добавлен в Королевство.

Выводы

CAN Kingdom спроектирован для создания стабильных и надёжных систем основанных на CAN протоколе. Благодаря разделению системы и модуля, Системный разработчик может полностью контролировать и нести ответственность за конечную систему. Система может быть перенастроена с помощью управляющих сообщений. Эта черта может использоваться не только для изящной деградации системы при сбоях, но также для модернизации системы на стадии разработки или после «рождения». Общие проблемы различных систем, такие как членское соглашение, контроль шины и контроль в режиме работы могут быть решены с помощью CAN Kingdom.