Концепция принципа обмена информацией по CAN шине, Мой вариант - критика и комментарии приветсвтуются Опции

[syoma]

Привет.
CAN шина - вещь хорошая, но без правильного представления принципа обмена ее ценность может упасть до нуля. Лепить протоколы высокого уровня типа CANopen на 8-и битные контроллеры тоже не имеет смысла.
Поэтому я для себя разработал концепцию обмена по CAN шине, которая меня устраивает, при этом использует все преимущества CANа, и сравнительна проста в реализации.

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

1. Принцип обмена
Базовой единицей информации в системе является "сигнал". Передача информации осуществляется по изменению сигнала или по требованию получателя. Источниками сигналов являются датчики,контроллеры и модули ввода-вывода. Получателями сигналов являются контроллеры, модули ввода-вывода и исполнительные устройства.
2. Определения:
2.1. Датчик – электрическое устройство, которое при определенном физическом воздействии генерирует электрический сигнал;
2.2. Исполнительное устройство – электрическое устройство, которое при подаче на него электрического сигнала выполняет какое либо действие (включается, загорается,вращается и т.д.)
2.3. Контроллер – микропроцессорное устройство, выполняющее определенные задания и вычисления, для которых в качестве входных и выходных данных используются сигналы.
2.4. Модуль ввода- вывода – немикропроцессорное устройство, не выполняющее никаких заданий и вычилений, а служащее только для преобразовывания виртуальных сигналов в реальные и наоборот(см. ниже)
2.5. В дальнейшем в тексте контроллеры и модули ввода вывода будут называться одним словом «контроллер», если не будет специально оговорено.
3. По отношению к конкретному контроллеру сигналы делятся на следующие типы:
3.1. Входные реальные сигналы – сигналы, которые принимаются данным контроллером от датчиков, непосредственно подключенных к нему.
3.2. Входные виртуальные сигналы – сигналы, которые принимаются данным контроллером в виде сообщений шины CAN от датчиков, подключенных к другим контроллерам системы. При этом виртуальный сигнал может быть не связан с физическим датчиком, а генерироваться контроллером на основании каких- либо вычислений. Например, сигнал "Авария" не генерируется каким либо датчиком, а генерируется контроллером на основании имеющейся у него информации о состоянии группы датчиков.
3.3. Выходные реальные сигналы – сигналы, которые генерируются контроллером и управляют работой исполнительных устройств, непосредственно, подключенных к данному контроллеру.
3.4. Выходные виртуальные сигналы – сигналы, которые генерирует данный контроллер в виде сообщений шины CAN, для передачи другим контроллерам. При этом виртуальный сигнал может быть простым отображением реального сигнала от датчика , или может не иметь физической связи с каким либо реальным сигналом, а генерироваться на основании вычислений.
4. Каждый контроллер в своей оперативной памяти должен иметь "виртуальное" отображение текущего состояния всех используемых им сигналов. При этом в случае если изменяется реальный сигнал – контроллер должен произвести обновление своей памяти и сгенерировать соответствующий виртуальный сигнал.
5. В случае если в памяти отображается виртуальный сигнал, то при получении нового сообщения по шине CAN контроллер должен обновить информацию, хранящуюся в памяти.
6. Так как в шине CAN есть возможность определения приоритетности сообщений, то каждому сигналу присваивается приоритет в зависимости от необходимой времени реакции на изменение данного сигнала.

По поводу моего принципа я вижу следующие преимущества:
1. Идентификатор сообщения определяет сигнал, передаваемый в нем, а не адрес. Контроллер, которому интересен данный сигнал его принимает и обрабатывает, другие нет. Т.о система не должна перенастраиваться при добавлении и удалении контроллеров.
2. Система предусматривает генерацию сообщений только если произошло изменение сигнала на входе. Т.е. трафик минимальный.
3. Приоритет сообщения однозначно определяет критичность времени реакции на конкретный сигнал. Выше приоритет- быстрее будет реакция.
4. Простота реализации. При приеме сообщения в прерывании надо просто обновить память. В цикле опроса входных сигналов при изменении сигнала поставить флаг на генерацию соответствующего сообщения. Основная программа работает только с памятью и таким образом нет задержек из-за отсылки, приема сообщений.
5. Использование MCP25020 подходит - так как у него есть режим передачи сообщения по изменению входа. Я уже это проверил.
6. Простота реализации "Черных ящиков" и сервисных приборов, так как все сигналы присутвтуют на шине.
7. Можно реализовать програмное назначение виртуальных сигналов на соответствующие пины контроллеров.Тогда возрастает гибкость.

Потенциальные недостатки :
1. Недостаток в том, что оперативка каждого контроллера в сети должна хранить все сигналы, которые он использует. Если сигналов много, то памяти может сожнрать тоже много. Я пытался рализовать принцип использования одной ячейки для разных сигналов, когда программа выполняется в определенных циклах, но выход и вход требуют генерации Remote frame для обновления информации, а это почему-то медленно работает по CANу даже с автоматическими ответами.
2. Подразумевается, что если какойто контроллер сгенерил сообщение, то все его примут 100% - это вроде гарантируется спецификацией. И этот принцип тоже на это расчитывает, поэтому нет периодических посылок и т.д. Но если это не гарантируется, тогда надо что-то думать. Я не знаю так ли это?
3. Теоретически для время реакции на критические сигналы будет маленьким, но так ли это я не знаю.

[Dog Pawlowa]

Привет.
CAN шина - вещь хорошая, но без правильного представления принципа обмена ее ценность может упасть до нуля. Лепить протоколы высокого уровня типа CANopen на 8-и битные контроллеры тоже не имеет смысла.
Поэтому я для себя разработал концепцию обмена по CAN шине, которая меня устраивает, при этом использует все преимущества CANа, и сравнительна проста в реализации...

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

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

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

[syoma]

А каким образом будет обеспечиваться, чтобы трафик не превысил пропускную способность шины?

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

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

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

Подразумевается, что если какойто контроллер сгенерил сообщение, то все его примут 100% - это вроде гарантируется спецификацией.
Никакой гарантии. А в CANopen есть (можно использовать) либо периодические посылки данных, либо посылка телеграммы "я живой" для диагностики наличия узла в сети.

Естественно в сети будет телеграмма я живой, но очень редко и для других целей.
Но почему никакой гарантии? Если подразумевать, что каждый контроллер постоянно слушает шину, то при посылке сообщения любым другим контроллером - если этот контроллер не понял сообщение то он генерит Error Frame. И все повторяется. Если же он посылает сообщение, то он ждет Acknowledge при посылке и если его нет - значит его никто не услышал.
То есть помоему единственный вариант, чтобы контроллер пропустил сообщение - это если он его вообще не услышал из-за отключения от шины.