13.1. Подробности реализации caNсетей в автомобиле

На первый взгляд мегабитная CAN-сеть способна удовлетворить все потребности "навороченного" автомобиля, в котором имеется порядка двух десятков контроллеров. Однако на практике дело обстоит гораздо сложнее. Имеется несколько сетей, которые объёдинены сетевым контроллером (BSI–BodySerialInterface??). Эти подсети даже удаётся понятным образом назвать. Так блок управления двигателем, блокиABS,ESPвходят в подсетьCANHSI/S(HighSpeedInterconnectSystem). Подсеть "Комфорт" включает панель приборов, … Подсеть "Кузов" включает блокCOM2003 (иммобилайзер, управление дворниками, )

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

- но иногда, это усложнение, наоборот, затрудняет поиск проблем. Неисправность самого BSIможет привести к частичному или полному параличу сетей. КогдаBSIисправен, сети функционируют как бы изолированно друг от друга. Диагностический прибор, подключаемый к колодке диагностики, фактически подключается к высокоскоростной подсети (двигатель,ABS…)

- не понятно, откуда идут сообщения (кто отправляет) и тем более - кто их получает

- удалённые кадры как увидеть?

- не понятно, как передаются сообщения из одной подсети в другую (что делается с идентификатором?)

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

- зачем длина идентификатора с 11 битов версии CAN 2.0a увеличена до 29 битов в версии CAN 2.0b?11 битов идентификатора позволяют иметь 2К различных сообщений, что для реальных систем вполне достаточно (используется не более 100-200). Здесь можно вспомнить о протоколах верхнего уровня, в которых встречаются "стандартные" сообщения, которые имеют свои идентификаторы и уже нельзя или не рекомендуется использовать их в качестве "своих". Другое применение – фактическое увеличение порций данных свыше незыблемых 8 байтов. Например, в поле идентификатора можно занять несколько битов для адресации массивов. Так если мы займём для этой цели, к примеру, 5 битов, то наш массив будет иметь длину 2⁵* 8 байтов = 256 байтов.

- в одной сети идентификаторы могут иметь длину либо 11 битов, либо 29 и приёмники не путаются. Почему?Расстановка битов в сообщениях такова. В начале битSOF=0 (StartofFrame), затем 11 битов идентификатора (т.е. весь или его старшая часть), далее битRTR(RemoteTransmissionRequest) или на его месте в случае длинного и.SRR=1 (SubstituteRemoteRequest), далее битIDE(IdentifierExtension) по состоянию которого и распознаётся длина идентификатора:IDE=0 (11 битов) иIDE=1 - (29 битов), далее, для короткого сообщения следуют контрольные биты, содержащие резервный битRB0=0 и 4 битаDLC3-0 (DataLengthCode), информирующие о длине поля данных. Для длинного сообщения здесь будет выводиться оставшаяся часть идентификатора – 18 битов, вслед за ними - битRTR=0/1, который не выводился (вместо него былSRR), потом контрольные биты – два резервныхRB1,0= 0 и 4 битаDLC3-0. Дальше оба битовых потока одинаковые – байты данных (от 0 до 8), полеCRC(CyclicRedundancycheck) – циклическая контрольная сумма 15+1 бит, поле подтвержденияAcknowledge1+1 бит (все приёмники должны дёрнуть линию в 0) и конец (минимум 3 бита).

- рассуждения о пропускной способности.Допустим, один из узлов периодически выводит в линию своё сообщение и эта периодичность пусть равна 10мс или 100 сообщений в секунду. При длине сообщения в 8 байтов общее время трафика, включая минимальный тайм аут (3 бита) и максимальное число автоматически вставляемыхstaff-битов (23 или 28) при скорости 0.5Мбит/с или 2мкс/бит составит 100*(108+3+23)бит * 2мкс/бит= 26.8мс. При 29-битном идентификаторе та же величина будет равна 100*(128+3+28)бит * 2мкс/бит= 31.8мс. Таким образом, можно загрузить линию полностью, выводя с названной периодичностью разные сообщения, и число этих сообщений за секунду составит всего лишь 1000/26.8 = 37 или 1000/31.8 = 31.

Шина SAE J1850 используется для диагностики и обмена данными приложений в транспортных средствах. Шина J1850 существует в двух несовместимых формах: 41.6 Кб/с широтно-импульсной модуляции (PWM), двухпроводная дифференциальная, 10.4 Кб/с переменной шириной импульса (VPM), однопроводный вариант. Однопроводной подход может иметь длину до 35 метров (с 32 узлами).

Интерфейс J1850 протокола класса В. Высокий уровень напряжения находится между 4.25 В и 20 В, а низкий – ниже 3.5 В. Высокие и низкие значения передаются как битные символы (а не как одиночные биты). Время символов 64 мкс и 128 мкс для однопроводного подхода. Сигналы высокого уровня считаются доминирующими.

Тайминги на скорости 10.4 Кб/с :

Passive “1”: 128 мкс (Low) Active “1”: 64 мкс (High) Passive “0”: 64 мкс (Low) Active “0”: 128 мкс (High) SOF / EOD : 200 мкс (High)

Широтно-импульсный модулятор (PWM) использует ширину импульса для обозначения символов в передаче. На скорости 41.6 Кб/с применяются следующие тайминги:

Active Phase “ 1” : 7 мкс Active Phase “ 0” : 15 мкс Bit time : 24 мкс SOF/EOD time : 48 мкс EOF time : 72 мкс IFS Time : 96 мкс Active SOF : 31 мкс Active BRK : 39 мкс BRK to IFS time : 120 мкс

OBD ключ поддерживает PWM. Общий формат кадра данных в сообщении J1850:

Idle::SOF::DATA_0::::::DATA_N::CRC::EOD::NB::IFR_1::::::::IFR_N::EOF::IFS::idle

Где : idle : Ожидание (происходит до SOF и после IFS ) SOF : Начало кадра DATA : Байт данных (каждый длиной 8 бит) EOD : Конец данных (только, когда используется IFR ) CRC : CRC байт обнаружения ошибок (может также происходить и в IFR ) NB : Бит нормализации (только 10.4 Кб/с) IFR : Байт внутрикадрового ответа EOF: Конец кадра IFS: Разрыв кадра

Примечание: Прерывание (BRK) может быть отправлено на J1850 в любое время. Линии интерфейса J1850 можно найти в разъеме OBD-II , которые расположены строго на своих местах. Использование J1850, разработанного в 1994 году, может быть прекращено для новых конструкций. Считается неперспективным для новых автомобилей.