UDS SID2E и SID22

Question

Есть ли в SID2E и SID22 условие, когда длина всего кадра будет превышать 7 байтов?

Если да, то как он будет отправлять или записывать байты данных?

Answer 1

Да, это общий случай использования в UDS, когда ответ на SID 0x22 (ReadDataByIdentifier) ​​или запрос к SID 0x2E (WriteDataByIdentifier) ​​превышает 7 байт в длину. Для этого отправляется сообщение, состоящее из нескольких кадров CAN, с использованием транспортного уровня ( ISO-TP, ISO 15765-2).

Рассмотрим обычное однокадровое сообщение, где верхний клев первого байта 0x0 т.е.

0x7E0   0x03 0x22 0xF1 0x90
0x7E8   0x04 0x62 0xF1 0x90 0x01

Здесь полезная нагрузка находится в пределах 7 байтов (как в запросе, так и в ответе), поэтому малый кусочек первого байта сообщает нам точную длину (0x03 в запросе, 0x04 в ответ). Поскольку полное сообщение помещается в один кадр CAN, больше ничего не требуется. Но для отправки более длинного диагностического сообщения его необходимо разделить на несколько кадров CAN (сегментация). Для этого требуется 3 различных типа сообщений:

1. Первый кадр отправляется получателю, чтобы начать передачу. Он содержит длину (до 4095 байтов) полных данных полезной нагрузки и первые 6 байтов сообщения. Высокий клев 0x1 первого байта указывает, что сообщение является первым кадром.
2. Кадр управления потоком, подтверждающий получение первого кадра, отвечает отправителю первого кадра. Он содержит дополнительную информацию, такую ​​как ожидаемое время STmin и размер блока. Высокий клев 0x3 первого байта указывает, что сообщение является кадром управления потоком.
3. Один или несколько последовательных кадров отправляются получателю, которые содержат до 7 байтов оставшейся полезной нагрузки - вместе со счетчиком для обеспечения возможности десегментирования данных в правильном порядке. Высокий клев 0x2 первого байта указывает, что сообщение является последовательным кадром.

Теперь рассмотрим следующий сценарий: приложение тестера отправляет один кадр 0x7E0 0x03 0x22 0xF1 0x90 как запрос ECU может захотеть отправить ответ 0x62 0xF1 0x90 0x01 0x02 0x03 0x04 0x05 (8 байт полезной нагрузки) в приложение для тестирования.

1. Таким образом, ECU сначала отправит первый кадр:

0x7E8 0x10 0x08 0x62 0xF1 0x90 0x01 0x02 0x03

2. И ждите кадр управления потоком из приложения тестера:

0x7E0 0x30 0x00 0x00 0x00 0x00 0x00 0x00 0x00

3. Затем ECU продолжит отправлять последовательные кадры, пока не будет передано полное сообщение:

0x7E8 0x21 0x04 0x05 0x00 0x00 0x00 0x00 0x00

Для SID 0x2E (WriteDataByIdentifier) ​​это будет очень похоже, только роли поменялись местами, как правило, приложение тестера хочет отправить длинное сообщение в запросе, и ECU ответит сообщением управления потоком. т.е.

0x7E0   0x10 0x08 0x2E 0xF1 0x90 0x01 0x02 0x03
0x7E8   0x30 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x7E0   0x21 0x04 0x05 0x00 0x00 0x00 0x00 0x00
0x7E8   0x03 0x6E 0xF1 0x90 0x00 0x00 0x00 0x00

Если требуется более одного последовательного кадра, первый байт будет просто увеличен с 0x21 вплоть до 0x2F а затем начать снова с 0x20 подсчитать.

0x7E0   0x10 0x76 0x2E 0xF1 0x90 0x01 0x02 0x03
0x7E8   0x30 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x7E0   0x21 0x04 0x05 0x06 0x07 0x08 0x09 0x0A
0x7E0   0x22 0x0B 0x0C 0x0D 0x0E 0x0F 0x10 0x11
...
0x7E0   0x2F 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0x7E0   0x20 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF