Пролог
Как известно в классическом CAN пакете можно поместить ну максимум 8байт полезных данных (MTU=8).
Одновременно с этим, в реальной жизни данные могут быть существенно больше, чем 8 байт. И тут возникает противоречие.
Как передать jumbo frame(ы), например, по 512-1024 байт пакет каждый кусками по 8 байт так, чтобы на принимающей стороне могли однозначно распознать начало и конец каждого массива?
Эту задачу как раз и призван решить протокол с названием ISO 15765-2. Его ещё называют ISO-TP.
В этом протоколе фигурирует адрес. Однако он берется из пакета канального уровня. По сути адрес CAN-Frame(ма)
Что надо из спецификаций?
№ | Код спеки | Пояснение | Версия | pages |
2 | ISO 11899-2 | Controller area network | ? | ? |
3 | ISO-15765 | Transport Layer | ? | 60 |
4 | ISO 15765-2 Road vehicles — Diagnostic communication over Controller Area | Спецификация протокола ISO-TP | Third edition 2016-04-11 | 60 |
Теория ISO 15765-2 (ISO-TP)
Протокол ISO 15765-2 это бинарный последовательный master-slave протокол. Причем роли не постоянные. Один ECU может быть сначала мастером потом slave(ом). Протокол ISO-TP в классической версии может передавать до 4095(0xFFF) байт за раз. В абстрактной модели OSI-7 протокол ISO-TP занимает сетевой (ISO-3 network layer) и транспортный (ISO-4 transport layer) уровни.
В протоколе ISO-TP всего-навсего 4 формата пакета: Single frame, First frame, Consecutive frame и Flow control frame. Вот их перечень.
список легальных пакетов протокола 15765-2
Иногда ещё показывают эту картинку. CAN-ID это адрес получателя. Пакеты ISO-TP всегда должны быть размером 8 байт. Если данных не достаточно то следует заполнять оставшийся payload канального CAN пакета константами padding (0x00 или 0x55).
У каждого пакета есть свой код (FrameID). В самом простом вырожденном случае, когда размер payload меньше или равен 7-ми байтам, то ISO-TP просто посылает Single Frame.
На Single Frame даже отвечать не надо, ибо физический и канальный уровень шины CAN сами гарантируют разрешение коллизий, саму доставку (битом подтверждения приема) и проверку CRC15 в канальном CAN пакете на уровне MAC!
В случае, когда данных в payload(e) больше, чем 7 байт, то изначальный передаваемый payload требуют дробления. Как это происходит? Сначала посылается First frame, который сообщает сколько будет данных. Для этого у него есть 12 бит для переменной Data Len. Получается, что можно передать максимум 4096 байт. Это бинарный протокол big endian компоновкой.
Стоит отметить, что ISO-TP - это диалоговый протокол. Их общение похоже на диалог. Оба устройства обязаны вести себя согласно протоколу. Своего рода правила этикета для компьютеров (говорить внятно, не перебивать и т. п.).
Приёмник в нужное время должен отвечать пакетом Flow control. Пакет Flow control используется для конфигурирования последующего общения учитывая способности приёмника. Поле Flag может принимать следующие значения
Flag value, dec | Flag value bin | интерпретация |
0 | 0b0000 | continie to send |
1 | 0b0001 | Wait |
2 | 0b0010 | overflow/abort |
Поле Block size сообщает мастеру ISO-TP сколько пакетов могут быть отправлены без контроля потока.
Значение параметра BS=0х00 должно использоваться для указания отправителю, что во время передачи раздробленного сообщения больше не будут отправляться кадры FC. Отправитель может смело отправить все оставшиеся последовательные кадры без остановки для дальнейших кадров FC от принимающего устройства сетевого уровня.
Проще говоря значение BS=0х00 интерпретируется, как оставшиеся пакеты могут быть отправлены без контроля потока. Любое положительное число в поле block size явно указывает количество пакетов которые можно смело отправить мастеру.
Поле Sepatation time(ST) указывает временной интервал который следует выдержать мастеру между отправками оставшихся пакетов.
Значение поля ST | единица измерения | минимальное значение | максимальное значение |
0x00.....0x7F | миллисекунды | 0ms | 127ms |
0xF1.....0xF9 | сотни микросекунд | 100us | 900us |
В качестве заполнителя рекомендуется прописывать либо 0x00 либо 0xAA.
Можно заметить, что в протоколе ISO 15765-2 заголовки имеют разный размер.
В первом байте заголовка и вовсе помещаются аж две переменные! То есть для реализации этого протокола потребуются манипуляция с битами и битовые поля.
Адресация
Адресация устроена весьма хитро. В CAN ID протокол ISO-TP инкапсулирует свой адрес N_SA (8bits) и адрес назначения N_TA(8bits). Но этот вариант пригоден для Extended CAN адресов. Есть же еще крохотные Standart CAN адреса. Поэтому это не единственный вариант адресации. В самой простой реализации протокола ISO-TP плата всегда испускает в CAN пакеты подписывая их только своим CAN-ID. Заинтересованный в этом ID узел отвечает. В результате никто не к кому не обращается явно.
Вот так можно представить временную диаграмму передачи данных по протоколу ISO 15765-2
Все переменные протокола ISO 15765-2 можно представить вот в этом реестре
Реализация
Когда говорят о реализации какого бы то ни было бинарного протокола, то обычно всё сводится к тому, что следует скомпоновать конечный автомат, который и будет нужные стимулы интерпретировать в нужные реакции. Для протокола ISO-TP, в первом приближении, конечный автомат может выглядеть вот так.
Есть всего 4 явных состояния.
Входами для этого автомата могут выть вот эти события
А это список легальных действия для данного автомата
Отладка
Так как протокол это чисто работа с массивами, то и отлаживать протоколы можно прямо на NetTop PC. Я написал консольное win приложение, которое пуляет массивы по протоколу ISO-TP между двумя экземплярами протокола ISO-TP. Вот так выглядит лог общения двух воображаемых CAN устройств между собой.
Как видно массив 000102030405060708090a0b0c0d0e0f1011121314151617 успешно передан от передатчика к приёмнику!
В качестве средств отладки можно воспользоваться переходником USB2CANFD_V1 и утилитой Savvy CAN. Там есть режим синтаксического разбора принятого ISO-TP
ISO-TP Decoder в программе Savvy CAN
Тестирование ISO-TP
Вот Вы нашли в интернете реализацию протокола ISO-TP. Как проверить, что протокол в самом деле работает? Для этого можно прогнать следующую последовательность тестов:
Внесение неисправностей
–Убедиться, что IsoTp корректно реагирует на внезапную потерю соединения. Что в случае отключения питания одного из устройств остальное перейден по таймауту в режим Idle и будет готово к новой сессии заново.
–Что если приемнику в IDLE придет не SINGLE_FRAME или FIRST_FRAME сразу Consecutive Frame или FLOW_CONTOL кадр?
--Что если приемнику в Idle поступил Flow Control пакет?
–Что если в Wait Consec Frame поступил второй FirstFrame?
–Что если в SingleFrame в 4-битном поле size окажется больше 8 байт?
–Чисто теоретически, при о��правке больших массивов ведомое устройство может прислать в очередном Flow control Frame другое значение STmin (interval between subsequent frames).
–В ответ на first flow в пакете flow control присылает абсурдный flag (например 0b0011=3 или 0xF=15). Надо чтобы передатчик и приемник перешли в idle.
–Отправить незнаковые PDU type (code) . Например от 4 до 15. Убедиться, что приемник остался в состоянии idle. Контроль валидного кода пакета. Валидные значение 0, 1, 2 и 3. Подать 5 6 7. Драйвер ISO-TP должен игнорировать абсурдные коды пакетов FRAME ID ( 4 ; 5; 6; ... 15).
–В ISO-TP пакетах есть порядковый номер пакета. Можно на стороне отправителя захардкодить отправку по ISO-TP 5 пакетов с преднамеренной потерей одного Consecutive Frame в середине. Надо убедиться, что приемник ISO-TP сорвется и перейдет в состояние IDLE.
--Попробовать отправить два Consecutive Frame с одинаковым номером пакета. По стандарту приемник должен прервать сессию и уйти в Idle.
Нагрузочные тесты
–Проверить что в одной CAN шине корректно происходят одновременно две-три ISO-TP сессии обмена. Что их пакеты расходятся (как корабли) и не нарушают процесс передачи данных.
–Попросить драйвер ISO-TP отправить 5k+ Byte данных. Убедиться, что драйвер выдаст ошибку.
--Попробовать отправить ровно 4k Byte payload. Убедиться, что данные передались корректно.
Функциональные тесты
--Убедиться, что можно использовать несколько экземпляров IsoTP протокола в одной прошивке.
–Убедиться, что каждый CAN интерфейс может работать, как в режиме мастера, так и в режиме slave в протоколе ISO-TP. Причем переключение должно происходить в run-time.
–Отправить 9 байт. Убедиться, что padding байты не помещаются в принимаемый массив. А то на стороне приемника может возникнуть переполнение массива.
–Так как ISO-TP это прежде всего алгоритм, то код ISO-TP можно протестировать вообще не выходя за корпус микроконтроллера (или консольной Windows утилиты написанной на Си). Надо просто создать внутри программы два экземпляра протокола ISO-TP и вместо отправки в CAN отправлять пакеты прямо на вход функции обработки принятого пакета в виде массива. Затем сравнить, что передаваемые данные совпали с принятыми бит в бит.
–Убедиться, что общая длительность процесса передачи данных не оказалась меньше, чем количество блоков умноженное на время STmin (interval between subsequent frames).
–Запросить отправку массива нулевого размера.
–Отправить 1 байт. Убедиться, что работает режим single-frame.
Достоинства протокола ISO-TP
++Есть контроль потока. Это 4х битное поле Serial Number (SN, index) в пакете Consecutive Frame (CF). Если пакет потеряется, то приемник это сможет зарегистрировать.
Недостатки протокола ISO-TP
--В пакете Consecutive Frame отсутствует длина payload в этом конкретном пакете.
В связи с этим, когда присылается самый последний пакет, то там может быть больше данных чем нужно. Приемник может принять padding байты за байты c данными, прописать их в RAM память и, тем самым, выйти за границы массива. Далее программа тихо падает. Поэтому приёмник ISO-TP обязан всегда помнить сколько байт ему обещал прислать передатчик. Это прописано в 12-битном поле Data Length в пакете First Frame.
Приёмник должен контролировать заполнение результирующего массива!
Итоги
ISO-TP это сравнительно простой протокол. Проще, чем его старший брат TCP. Надеюсь этот текст позволит кому-нибудь лучше понять суть бинарного протокола ISO-TP, реализовать его и использовать в своих проектах. Этот протокол можно попробовать использовать не только для CAN, но и в других интерфейсах, например LoRa/GFSK трансиверах. Там тоже присутствует ограничение на MTU для физического уровня. Везде где MTU имеет свои пределы можно применить протокол ISO-TP.
Словарь
акроним | расшифровка | Topic |
ECU | Electronic Control Units | HW |
ЭБУ | электронный блок управления | HW |
TP | Transport Protocol | SW |
ISO | International Organization for Standardization | DOC |
PCI | Protocol Control Information | ISO-TP |
TCP | Transmission Control Protocol | SW |
SF | Single Frame | ISO-TP |
FC | Flow Control | ISO-TP |
PDU | Protocol Data Unit | SW |
MTU | Maximum transmission unit | SW |
CAN | Controller area network | PHY |
N_AI | address information | ISO-TP |
Контрольные вопросы:
1--Как ISO-TP приемник поймет какому CAN ID ему отвечать, если в CAN пакете First Frame только ID получателя (его CAN-ID)? ISO-TP приемник всегда отвечает на тот же CAN ID, откуда пришел First Frame. Это позволяет обеспечить правильное взаимодействие между устройствами в сети CAN.
2--Нужно ли отвечать на пакет Single Frame (SF)? Нет
3--Есть ли какая-нибудь бесплатная клиентская Windows CAN утилита, которая посылает и принимает по ISO-TP огромные массивы сырых данных (бинарные файлы)? Утилита, которая оперирует не на канальном уровне, а на транспортном и сетевом уровне модели OSI-7. Что-нибудь типа аналога культовой программы NetCat, только не для Ethernet протокола, а для CAN протокола.
4--Существуют ли микроконтроллеры с аппаратной реализаций протокола ISO-TP? Скорее нет, чем да.
5--Как могут выглядеть модульные нагрузочные и интеграционные тесты для протокола ISO-TP?
6--Что приемник должен делать, если приходят два подряд Consecutive Frame с одинаковым счётчиком SN? Надо отменять сессию. (см .6.4.4 SequenceNumber (SN) error handling If a CF N_PDU message is received with an unexpected SequenceNumber not in accordance with the definition in 9.6.4.3, the message reception shall be aborted and the network layer shall make an N_ USData.indication service call with the parameter = N_WRONG_SN to the adjacent upper layer.)
7--Может ли в одной CAN шине происходить сразу две пересекающиеся во времени ISO-TP сессии? Да. Зависит от выбранного механизма адресации. Для адресации в соответствии с J1939 - да. в порядке вещей параллельная диагностика нескольких ECU, в этом случае один клиент общается с несколькими серверами.
8--Чисто теоретически, при отправке больших массивов ведомое устройство может прислать в очередном Flow control Frame другое значение STmin (interval between subsequent frames). Считается ли это ошибкой? Нет. Стандарт говорит, что смена размера блока и паузы может меняться на лету и это нормальное явление. "6.5.6 Dynamic BS/STmin values in subsequent FlowControl frames If the server is the receiver of a segmented message transfer (i.e. the sender of the FlowControl frame), it may choose either to use the same values for BS and STmin in subsequent FC (CTS) frames of the same segmented message or to vary these values from FC to FC frame."
Links\URLs
Название | URL |
UDS Explained - A Simple Intro (Unified Diagnostic Services) | https://www.csselectronics.com/pages/uds-protocol-tutorial-unified-diagnostic-services |
Протокол UDS | |
ISO 15765-2 | |
Подробная детализация бинарной структуры пакетов ISO-TP | |
Introduction to CAN-TP (ISO 15765) Tutorial | |
19 Атрибутов Хорошего Канального Протокола Передачи Данных |
