Реферат: 2. Нормативные документы

АО “АвтоВАЗ”
Генеральный Департамент Развития
Управление Проектирования Электроники и электрооборудования



Keyword Protocol 2000

Спецификация канала связи с диагностическим оборудованием - Уровень обмена данными


Состояние: Версия FB - текущая серийная.


Дата: 302516 июляоктября 2000г.


Этот документ базируется на международном стандарте ISO 14230 - 3 Keyword Protocol 2000 и представляет собой спецификацию канала передачи данных между контроллерами системы управления двигателем Motronic 1.5.4 или “Январь-5” и диагностическим оборудованием. Для систем управления под нормы Россия-83.


Пожалуйста присылайте Ваши замечания и предложения:

тел. (8469) 37-80-67

e-mail: dbd@a3151.dd.vaz.tlt.ru



КБ систем управления двигателем
Автор - Д.Б.Дударь
1. Введение.
Данный документ базируется и разработан для конкретной реализации программного обеспечения (ПО) контроллера системы управления двигателем (ЭБУ) M1.5.4 в соответствии с текущим состоянием разработки ПО. В него включены специфичные для данного проекта диагностические функции и параметры.

Для более детальной информации и общего описания протокола KWP2000, обращайтесь к международным стандартам ISO 14230-1...3 и German Implementation Specification - Part 3.

^ 2. Нормативные документы.
Данный документ содержит ссылки и базируется на следующих международных стандартах:


ISO 14229 Road Vehicles - Diagnostic Systems

Diagnostic Services Specification


ISO 14230-1 Road Vehicles - Diagnostic Systems

Keyword Protocol 2000 Part 1: Physical Layer


ISO 14230-2 Road Vehicles - Diagnostic Systems

Keyword Protocol 2000 Part 2: Data Link Layer


ISO 14230-3 Road Vehicles - Diagnostic Systems

Keyword Protocol 2000 Part 3: Implementation


ISO 14230-3G German Implementation Specification - Part 3


SAE J1930 E/E Systems Diagnostic Terms, Definitions,

Abbreviations & Acronyms.


SAE J2012 Diagnostic Trouble Codes.


3. Физическая архитектура.


Концепция физической реализации последовательного канала передачи данных на автомобилях ВАЗ показана ниже.








^ Рис. 1 - Архитектура.


K-линия используется для инициализации и обмена диагностическими сообщениями между различными блоками управления и диагностическим тестером, L-линия в данной архитектуре не используется. Изначально, контроллер подключен через W-линию только к иммобилизатору и не имеет выхода на K-линию и диагностический разъем. В случае успешного завершения процедуры иммобилизации, контроллер подключается, через иммобилизатор, к K-линии и диагностическому разъему. Остальные устройства подключаются к K-линии и диагностическому разъему непосредственно и иммобилизатор не влияет на процесс их обмена с тестером.

Примечание: данная концепция физической реализации справедлива для автомобилей укомплектованных иммобилизатором. При отсутствии иммобилизатора, контроллер подключен непосредственно к K-линии.

^ 4. Структура сообщения.


Структура сообщения, в общем виде, состоит из трех частей:

заголовок (Header);

байты данных (Data bytes);

контрольная сумма (Checksum).


^ 4.1 Поддерживаемые типы заголовка сообщения.


Header

Data bytes

Checksum

Fmt

Tgt

Src




SId1

...

Data

...




CS

3 байта

макс. 63 байта

1 байт




Header

Data bytes

Checksum

Fmt

Tgt

Src

Len




SId1

...

Data

...




CS

4 байта

макс. 255 байт

1 байт


Где:

Fmt - байт определяющий формат сообщения;

Tgt - байт определяющий адрес приемника сообщения;

Src - байт определяющий адрес источника сообщения;

Len - байт определяющий длину сообщения при 4-x байтном заголовке;

1 - байт определяющий тип передаваемых данных, является частью байтов данных;

CS - байт контрольной суммы.


Данная реализация протокола поддерживает два вышеприведенных типа заголовка.


4.2 Заголовок.


Заголовок может содержать три или четыре байта. Байт формата сообщения(Fmt) содержит информацию о типе сообщения, байты адреса приемника(Tgt) и источника сообщения(Src) содержат физические адреса контроллера системы управления двигателем и диагностического тестера.


^ 4.2.1 Байт формата сообщения.


Байт формата сообщения включает 2 бита определяющих режим задания адресной информации (т.е. тип заголовка) и 6 бит определяющих длину сообщения (справедливо только для 3-х байтного заголовка). Распределение битовых полей байта формата выглядит следующим образом:


7

6

5

4

3

2

1

0

Бит

A1

A0

L5

L4

L3

L2

L1

L0

Условное обозначение


Поля A1,A0 определяют тип заголовка который используется в сообщении. Содержание данных полей для реализации коммуникационного канала между блоком управления и диагностическим тестером приведено в следующей таблице.


A1

A0

Режим

1

0

с физической адресацией


Поля L5...L0 определяют длину сообщения от начала поля данных до байта контрольной суммы (не включается), включая байт типа передаваемых данных(SId). Таким образом, для сообщений с 3-х байтным заголовком возможная длина поля данных сообщения находится в диапазоне от 1 до 63 байт. Для сообщений с 4-х байтным заголовком, возможная длина поля данных сообщения находится в диапазоне от 1 до 255 байт.

За дополнительной информацией обращайтесь к стандарту “ISO/WD14230-2: Keyword Protocol 2000 - Part2:Data Link Layer”.


^ 4.2.2 Байт адреса приемника.


В реализации данного протокола используется физическая адресация. Поэтому, под адресом приемника сообщения подразумевается физический адрес блока управления, которому предназначено конкретное сообщение. Байт адреса приемника всегда используется совместно с байтом адреса источника. Согласно стандарту SAE J2178, физический адрес контроллера системы управления двигателем назначен равным 10h.


^ 4.2.3 Байт адреса источника.


Для диагностического тестера физический адрес принят равным F01h, для иммобилизатора C0h. Иные адреса, данной реализацией не поддерживаются.


^ 4.2.4 Байт длины поля данных.


Для данной реализации ПО блока управления M1.5.4 справедливы следующие ограничения длины буферов приема/передачи:

длина буфера приема - 128 байт;

длина буфера передачи - 128 байт.


В соответствии с этими ограничениями возможные значения длины поля данных при приеме/передаче приведены ниже.


Тип заголовка

Прием

Передача




макс. кол-во байт

макс. кол-во байт

3-х байтный

63

63

4-х байтный

128

128


^ 4.3 Байты данных.


Поле данных может содержать различное число байт информации. Первым байтом поля данных всегда является байт типа передаваемых данных, который характеризует назначение передаваемой информации. Подробно значение байта типа передаваемых данных описано в разделах 5 и 6.


^ 4.4 Байт контрольной суммы.


Байт контрольной суммы вставляется в конец пакета сообщения и определяется как простая 8-ми битная сумма всех байт сообщения, исключая контрольную сумму.

5 Протокол передачи данных.


В данном разделе подробно обсуждаются возможные форматы поля данных при передаче и приеме сообщений. Контроллер Motronic M1.5.4 поддерживает только “быструю” инициализацию. Для инициализации и передачи начальных сообщений диагностический тестер должен использовать скорость передачи данных равную 10400 бод. Длина слова данных 8 бит, 1 стоп бит, контроль четности отсутствует.


Механизм “быстрой” инициализации показан ниже:




Допустимые значения временных интервалов TWuPи Tinilприведены в нижеследующей таблице:








min

max

TiniL

25+-1 ms

24 ms

26 ms

TWuP

50+-1 ms

49 ms

51 ms


Возможные значения времени TIdle:

- первая передача после включения питания: TIdle = >200 ms

- после выполнения запроса StopCommunication Service: TIdle= P3min

- после завершения коммуникаций по таймауту P3max: TIdle = 0


^ 5.1 Временные параметры протокола передачи данных.


В данной реализации протокола блок управления поддерживает набор нормальных временных параметров. Стандарт ISO 14230-2 определяет следующие временные параметры:

Наименование

Описание

P1

Межбайтовый интервал для ответа блока управления

P2

Время между запросом тестера и ответом блока управления

P3

Время между окончанием ответа блока управления и началом следующего запроса диагностического тестера

P4

Межбайтовый интервал для запроса диагностического тестера


Временные соотношения для блока управления M1.5.4 приведены в таблице 5.1.

Временные

Граничные значения

параметры

минимальное

разрешение

максимальное

разрешение

P1

0

-

20

-

P2

25

0.5

50

0.5

P3

100

0.5

5000

100

P4

0

0.5

20

0.5

^ Таблица 5.1 Временные параметры диагностического протокола.


Примечание: все значения временных параметров приведены в мсек.


Блок управления M1.5.4 не поддерживает изменение значений временных параметров.


^ 5.2 Общий вид потока передачи данных.

5.2.1 Типовой поток сообщений с положительным/отрицательным ответом.


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


^ Диагностический тестер

Контроллер

<Идентификатор> Запрос[...]


<Идентификатор> Положительный Ответ[...]

<Идентификатор> Запрос[...]


<Идентификатор> Запрос[...]



<Идентификатор> Отрицательный Ответ[КО]


<Идентификатор> Положительный Ответ[...]


Где:

Идентификатор - первый байт поля данных, который определяет формат поля данных и тип передаваемых данных;

КО - код ответа, определяет дальнейшие действия в случае отрицательного ответа.


^ 5.2.2 Типовой поток сообщений с отрицательным ответом и кодом ответа “занят-повтори запрос”.


Таблица приведенная ниже описывает поток сообщений с отрицательным ответом и кодом ответа установленным в значение “занят-повтори запрос”.


^ Диагностический тестер

Контроллер

<Идентификатор> Запрос[...]


<Идентификатор> Отрицательный Ответ[занят-повтори запрос]

<Идентификатор> Запрос[...]


<Идентификатор> Запрос[...]



<Идентификатор> Отрицательный Ответ[занят-повтори запрос]


<Идентификатор> Положительный Ответ[...]


^ 5.2.3 Типовой поток сообщений с отрицательным ответом и кодом ответа “запрос получен корректно-задержка ответа”.


Таблица приведенная ниже описывает поток сообщений с отрицательным ответом и кодом ответа установленным в значение “запрос получен корректно-задержка ответа”.


^ Диагностический тестер

Контроллер

<Идентификатор> Запрос[...]


<Идентификатор> Отриц. Ответ[запрос получен корректно-задержка ответа]

<Идентификатор> Отриц. Ответ[запрос получен корректно-задержка ответа]

<Идентификатор> Положительный Ответ[...]



5.3 Сводная таблица значений идентификатора.


В левой колонке нижеследующей таблицы приводится список определяемых настоящим документом имен идентификатора при обмене сообщениями между контроллером системы управления двигателем и диагностическим тестером. В средней колонке приводятся назначенные им шестнадцатиричные(Hex) коды запроса. В правой колонке соответствующие им коды положительного ответа. Коды положительного ответа формируются из соответствующих им кодов запроса установкой значения бита 6 равным логической “1”. Идентификатор отрицательного ответа всегда равен 7F(Hex).

^ Междунаpодное наименование идентификатора

Сокращение

Значение кода(Hex)







Запpос

Ответ

startCommunication

STC

81

C1

stopCommunication

SPC

82

C2

startDiagnosticSession

STDS

10

50

stopDiagnosticSession

SPDS

20

60

ecuReset

ER

11

51

clearDiagnosticInformation

CDI

14

54

readDiagnosticTroubleCodesByStatus

RDTCBS

18

58

readEcuIdentification

REI

1A

5A

readDataByLocalIdentifier

RDBLI

21

61

inputOutputControlByLocalIdentifier

IOCBLI

30

70

writeDataByLocalIdentifier

WDBLI

3B

7B

testerPresent

TP

3E

7E

^ Таблица 5.3 Описание идентификаторов поля данных сообщения.


5.4 Сводная таблица значений кодов ответа.


В нижеследующей таблице приводится список и назначенные значения кодов ответа специфицируемых настоящим документом.


^ Hex Значение

Код ответа

Сокращение

10

generalReject

Запрос отклонен, но приемник не специфицирует причину отклонения.

GR

11

serviceNotSupported

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

SNS

12

subFunctionNotSupported-invalidFormat

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

SFNS-IF

21

busy-RepeatRequest

Этот код ответа показывает, что приемник временно слишком занят, чтобы выполнить запрашиваемое действие. В этой ситуации повторный запрос будет выполняться с заполнением всего поля данных. Когда приемник сможет завершить выполнение запрашиваемого действия, он пошлет положительный ответ.

B-RR

31

requestOutOfRange

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

ROOR

72

transferAborted

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

TA

77

blockTransferDataChecksumError

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

BTDCE

^ Таблица 5.4 Описание кодов ответа.

^ 6 Описание реализуемых функций обмена данными.

6.1 Функции инициализации и окончания обмена.


6.1.1 Функция startCommunication.


Данная функция инициализирует процесс обмена данными между диагностическим тестером и контроллером. На запрос startCommunication не может быть получен отрицательный ответ. В случае успешного завершения, сеанс обмена данными всегда заканчивается функцией stopCommunication.


^ 6.1.1.1 Определение параметров.


Параметр KeyBytes используется в положительном ответе функции startCommunication, чтобы информировать диагностический тестер о поддерживаемых форматах обмена данными.


^ Hex Значение

Описание параметра

6B8F

Данное значение KeyBytes однозначно определяет поддерживаемые типы заголовка и временные параметры обмена.

Таблица 6.1.1.1 Определение величины KeyBytes.


^ 6.1.1.2 Формат поля данных сообщения.


Байт данных

Имя параметра

^ Значение Hex

Сокращение

#1

Идентификатоp запроса startCommunication

81

STC

^ Таблица 6.1.1.2.1 - Пример сообщения с запросом startCommunication


Байт данных

Имя параметра

^ Значение Hex

Сокращение

#1

Положительный ответ startCommunication

C1

STCPR

#2

Keybyte1

6B

KB1

#3

Keybyte2

8F

KB2

Таблица 6.1.1.2.2 - Пример положительного ответа на запрос startCommunication


^ 6.1.2 Функция stopCommunication.


Данная функция завершает процесс обмена данными между диагностическим тестером и контроллером.


6.1.2.1 Определение параметров.


Данная функция не имеет параметров.


6.1.2.2 Формат поля данных сообщения.


Байт данных

Имя параметра

^ Значение Hex

Сокращение

#1

Идентификатоp запроса stopCommunication

82

SPC

^ Таблица 6.1.2.2.1 - Пример сообщения с запросом stopCommunication


Байт данных

Имя параметра

^ Значение Hex

Сокращение

#1

Положительный ответ stopCommunication

C2

SPCPR

^ Таблица 6.1.2.2.2 - Пример положительного ответа на запрос stopCommunication


Байт данных

Имя параметра

^ Значение Hex

Сокращение

#1

Отpицательный ответ

7F

NR

#2

Идентификатоp запроса stopCommunication

82

SCR

#3

responseCode=[Код ответа { табл. 5.4 }]

xx=[00-FF]

RC_...

Таблица 6.1.2.2.3 - Пример отрицательного ответа на запрос stopCommunication


^ 6.2 Функции управления обменом диагностической информацией.


6.2.1 Функция startDiagnosticSession.


Данная функция используется, чтобы начать сеанс диагностического обмена данными между блоком управления и тестером, и позволяет тестеру выбрать различные режимы диагностического обмена. Сеанс диагностики может начаться, только если предварительно была разрешена коммуникационная сессия.


^ 6.2.1.1 Определение параметров.


Параметр diagnosticMode используется, чтобы диагностический тестер мог выбрать необходимый режим диагностического обмена данными. Данный документ определяет следующее значение этого параметра:




^ Hex Значение

Описание параметра

Сокращение

81

defaultMode-StandartDiagnosticMode

Данное значение однозначно определяет режим диагностического обмена данными. Наличие функции startDiagnosticSession с параметром defaultMode не является обязательным в протоколе обмена. Данный режим устанавливается по умолчанию после полного завершения процедуры инициализации обмена данными между блоком управления и тестером.

DCM_DTM

^ Таблица 6.2.1.1.1 Определение значения параметра diagnosticMode.


Параметр baudrateMode используется, чтобы установить желаемую скорость обмена диагностическими данными, отличную от стандартной. Данный параметр не определяется стандартом ISO14230. Тестер может переключиться на новую скорость передачи данных только после получения положительного ответа. Настоящий документ определяет следующие значения этого параметра:




^ Hex Значение

Описание параметра

Сокращение

0A

normalBaudrate

Данное значение параметра означает, что для диагностического обмена данными используется скорость 10400 бод, определяемая стандартом ISO14230.

BRM_NBR

26

highBaudrate

Данное значение параметра означает, что для диагностического обмена данными используется скорость 38400 бод, не определяемая стандартом ISO14230.

BRM_HBR

39

enhancedBaudrate

Данное значение параметра означает, что для диагностического обмена данными используется скорость 57600 бод, не определяемая стандартом ISO14230.

BRM_EBR

Таблица 6.2.1.1.2 Определение значения параметра baudrateMode.


^ 6.2.1.2 Формат поля данных сообщения.


Байт данных

Имя параметра

^ Значение Hex

Сокращение

#1

Идентификатоp запроса startDiagnosticSession

10

STDS

#2

diagnosticMode

81

DCM_DTM

#3

baudrateMode=highBaudrate

26

BRM_HBR

^ Таблица 6.2.1.2.1 - Пример сообщения с запросом startDiagnosticSession


Байт данных

Имя параметра

^ Значение Hex

Сокращение

#1

Положительный ответ startDiagnosticSession

50

STDSPR

#2

diagnosticMode

81

DCM_DTM

^ Таблица 6.2.1.2.2 - Пример положительного ответа на запрос startDiagnosticSession


Байт данных

Имя параметра

^ Значение Hex

Сокращение

#1

Отpицательный ответ

7F

NR

#2

Идентификатоp запpоса startDiagnosticSession

10

STDS

#3

responseCode=[Код ответа { табл. 5.4 }]

xx=[00-FF]

RC_...

Таблица 6.2.1.2.3 - Пример отрицательного ответа на запрос startDiagnosticSession


^ 6.2.2 Функция stopDiagnosticSession.


Данная функция используется чтобы закрыть текущий режим диагностического обмена данными.


При использовании данной функции должны соблюдаться следующие правила:


Сеанс диагностики может быть остановлен, только если предварительно были разрешены сессии обмена данными и диагностики.




Если не была загружена какая-либо диагностическая сессия, активным является режим диагностики по умолчанию. Режим диагностики по умолчанию не может быть запрещен функцией stopDiagnosticSession.




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




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




Если блок управления получает запрос stopDiagnosticSession, находясь в диагностическом режиме принятом по умолчанию, он должен послать тестеру сообщение с положительным ответом и немедленно обновить все временные параметры обмена данными.




Тестер должен посылать сообщение с запросом stopDiagnosticSession до прекращения обмена данными при помощи функции stopCommunication, но только в том случае, если предварительно диагностическая сессия была запущена при помощи функции startDiagnosticSession.




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


^ 6.2.2.1 Определение параметров.


Данная функция не имеет параметров.


6.2.2.2 Формат поля данных сообщения.


Байт данных

Имя паpаметpа

^ Значение Hex

Сокращение

#1

Идентификатоp запpоса stopDiagnosticSession

20

SPDS

^ Таблица 6.2.2.2.1 - Пример сообщения с запросом stopDiagnosticSession


Байт данных

Имя паpаметpа

^ Значение Hex

Сокращение

#1

Положительный ответ stopDiagnosticSession

60

SPDSPR

^ Таблица 6.2.2.2.2 - Пример положительного ответа на запрос stopDiagnosticSession


Байт данных

Имя паpаметpа

^ Значение Hex

Сокращение

#1

Отpицательный ответ

7F

NR

#2

Идентификатоp запpоса stopDiagnosticSession

20

SPDS

#3

responseCode=[Код ответа { табл. 5.4 }]

xx=[00-FF]

RC_...

Таблица 6.2.2.2.3 - Пример отрицательного ответа на запрос stopDiagnosticSession


^ 6.2.3 Функция testerPresent.


Данная функция должна использоваться, чтобы тестер мог сообщить блоку управления о своем присутствии на диагностической линии связи. Данная функция требуется, чтобы предотвратить возврат блока управления к нормальному режиму работы при отсутствии, в течение некоторого времени (см табл.5.1), запросов от тестера.


При этом должны соблюдаться следующие правила:


Наличие этого запроса поддерживает наличие связи между тестером и блоком управления.




Наличие положительного ответа на этот запрос показывает, что блок управления находится в диагностическом режиме работы.


^ 6.2.3.1 Определение параметров.


В данной функции используется параметр responseRequired, который показывает блоку управления требуется ли посылать ответное сообщение или нет. Значения этого параметра определены в таблице приведенной ниже:


^ Hex Значение

Описание паpаметpа

Сокращение

01

yes

Блок управления должен послать ответное сообщение на запрос тестера.

Y

02

no

Блок управления не должен посылать ответное сообщение на запрос тестера.

NO

Таблица 6.2.3.1 Определение значений параметра responseRequired.


^ 6.2.3.2 Формат поля данных сообщения.


Байт данных

Имя паpаметpа

^ Значение Hex

Сокращение

#1

Идентификатоp запpоса testerPresent

3E

TP

#2

responseRequired=[см.таблицу 6.2.3.1]

xx

RRD_...

^ Таблица 6.2.3.2.1 - Пример сообщения с запросом testerPresent


Байт данных

Имя паpаметpа

^ Значение Hex

Сокращение

#1

Положительный ответ testerPresent

7E

TPPR

Таблица 6.2.3.2.2 - Пример положительного ответа на запрос testerPresent


^ Байт данных

Имя паpаметpа

Значение Hex

Сокращение

#1

Отpицательный ответ

7F

NR

#2

Идентификатоp запpоса testerPresent

3E

TP

#3

responseCode=[Код ответа { табл. 5.4 }]

xx=[00-FF]

RC_...

^ Таблица 6.2.3.2.3 - Пример отрицательного ответа на запрос testerPresent


6.2.4 Функция ecuReset.


Данная функция предназначена для выполнения сброса блока управления. Вид сброса определяется значением параметра resetMode. Положительный ответ на запрос ecuReset должен быть послан блоком управления до того как он выполнит процедуру сброса.


^ 6.2.4.1 Определение параметров.


В данной функции используется параметр resetMode, который определяет тип сброса выполняемого блоком управления. Значение этого параметра определено в таблице приведенной ниже:


^ Hex Значение

Описание паpаметpа

Сокращение

01

powerOn

Это значение параметра означает, что блок управления должен выполнить сброс аналогичный полному аппаратному сбросу, который происходит во время цикла выключения/включения ключом зажигания. После того как блок управления выполнит процедуру сброса, тестер должен восстановить связь по диагностической линии.

PO

^ Таблица 6.2.4.1 Определение значений параметра responseRequired.


Параметр resetStatus, который может использоваться в сообщении с положительным ответом на запрос ecuReset, не применяется в данной реализации диагностического протокола.


^ 6.2.4.2 Формат поля данных сообщения.


Байт данных

Имя паpаметpа

^ Значение Hex

Сокращение

#1

Идентификатоp запpоса ecuReset

11

ER

#2

resetMode

01

RM_PO

^ Таблица 6.2.4.2.1 - Пример сообщения с запросом ecuReset


Байт данных

Имя паpаметpа

Значение Hex

Сокращение

#1

Положительный ответ ecuReset

51

ERPR

^ Таблица 6.2.4.2.2 - Пример положительного ответа на запрос ecuReset


Байт данных

Имя паpаметpа

^ Значение Hex

Сокращение

#1

Отpицательный ответ

7F

NR

#2

Идентификатоp запpоса ecuReset

11

ER

#3

responseCode=[Код ответа { табл. 5.4 }]

xx=[00-FF]

RC_...

Таблица 6.2.4.2.3 - Пример отрицательного ответа на запрос ecuReset


^ 6.2.5 Функция readEcuIdentification.


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


^ 6.2.5.1 Определение параметров.


В данной функции используется параметр identificationOption, который определяет тип идентификационных данных запрашиваемых тестером. Значение этого параметра определено в таблице приведенной ниже:


^ Hex Значение

Описание паpаметpа

Сокращение

80

ECUIdentificationDataTable

Данное значение информирует блок управления, что тестер должен получить полную таблицу идентификационных данных. Информация содержащаяся в ECUIdentificationDataTable включает в себя все данные из диапазона значений параметра identificationOption от 90h до 9Ah.

ECUIDT

90

VIN(Vehicle Identification Number)

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

VIN

91

vehicleManufacturerECUHardwareNumber

Данное значение параметра означает, что блок управления сообщает тестеру свой заводской номер согласно конструкторской документации.

VMECUHN

92

systemSupplierECUHardwareNumber

Данное значение параметра означает, что блок управления сообщает тестеру код блока управления по обозначению поставщика.

SSECUHN

94

systemSupplierECUSoftwareNumber

Данное значение параметра означает, что блок управления сообщает тестеру код программного обеспечения блока управления по обозначению поставщика.

SSECUSN

97

systemNameOrEngineType

Данное значение параметра означает, что блок управления сообщает тестеру условное наименование системы и тип двигателя.

SNOET

Hex Значение

^ Описание паpаметpа

Сокращение

98

repairShopCode

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

RSC

99

ProgrammingDate

Данное значение параметра означает, что блок управления сообщает тестеру дату подготовки прошивки ПЗУ.

PD

9A

vehicleManufacturerECUIdentifier

Данное значение параметра означает, что блок управления сообщает тестеру идентификационные данные согласно обозначению производителя.

VMECUID

^ Таблица 6.2.5.1.1 Определение значений параметра identificationOption.


Примечание: значения параметра identificationOption равные 90h и 98h в текущей версии программного обеспечения (версия О) передаются блоком управления, но могут не содержать необходимой информации.


В таблице приведенной ниже приводится пример идентификационных данных блока управления:


^ Наименование паpаметpа

Значение

Длина данных

Тип
Масштабирования

VIN(Vehicle Identification Number)

VAZ21083-0000010-20

19

ASCII

vehicleManufacturerECUHardwareNumber

2112 -1411020-60

16

ASCII

systemSupplierECUHardwareNumber

0261123456

10

ASCII

systemSupplierECUSoftwareNumber

1411000-00

10

ASCII

systemNameOrEngineType

SAMARA-1.5L, 8V

15

ASCII

repairShopCode

2850358

7

ASCII

ProgrammingDate(ДД-ММ-ГГГГ-ММ-ДД)

05-07-1996-07-05

10

ASCII

vehicleManufacturerECUIdentifier

M1V13F04

8

ASCII

Таблица 6.2.5.1.2 Пример идентификационных данных блока управления.


^ 6.2.5.2 Формат поля данных сообщения.


Байт данных

Имя паpаметpа

^ Значение Hex

Сокращение

#1

Идентификатоp запpоса readECUIdentification

1A

REI

#2

identificationOption=ECUIdentificationDataTable

80

IO_ECUIDT

^ Таблица 6.2.5.2.1 - Пример сообщения с запросом readECUIdentification


Байт данных

Имя паpаметpа

^ Значение Hex

Сокращение

#1

Положительный ответ readECUIdentification

5A

REIPR

#2

identificationOption=ECUIdentificationDataTable

80

IO_ECUIDT

#3

vehicleIdentificationNumber {V}

56

VIN

#4

vehicleIdentificationNumber {A}

41

VIN

#5

vehicleIdentificationNumber {Z}

5A

VIN

#6

vehicleIdentificationNumber {2}

32

VIN

#7

vehicleIdentificationNumber {1}

31

VIN

#8

vehicleIdentificationNumber {0}

30

VIN

^ Байт данных

Имя паpаметpа

Значение Hex

Сокращение

#9

vehicleIdentificationNumber {8}

38

VIN

#10

vehicleIdentificationNumber {3}

33

VIN

#11

vehicleIdentificationNumber {-}

2D

VIN

#12

vehicleIdentificationNumber {0}

30

VIN

#13

vehicleIdentificationNumber {0}

30

VIN

#14

vehicleIdentificationNumber {0}

30

VIN

#15

vehicleIdentificationNumber {0}

30

VIN

#16

vehicleIdentificationNumber {0}

30

VIN

#17

vehicleIdentificationNumber {1}

31

VIN

#18

vehicleIdentificationNumber {0}

30

VIN

#19

vehicleIdentificationNumber {-}

2D

VIN

#20

vehicleIdentificationNumber {2}

32

VIN

#21

vehicleIdentificationNumber {0}

30

VIN

#22

vehicleManufacturerECUHardwareNumber {2}

32

VMECUHN

#23

vehicleManufacturerECUHardwareNumber {1}

31

VMECUHN

#24

vehicleManufacturerECUHardwareNumber {1}

31

VMECUHN

#25

vehicleManufacturerECUHardwareNumber {2}

32

VMECUHN

#26

vehicleManufacturerECUHardwareNumber { }

20

VMECUHN

#27

vehicleManufacturerECUHardwareNumber {-}

2D

VMECUHN

#28

vehicleManufacturerECUHardwareNumber {1}

31

VMECUHN

#29

vehicleManufacturerECUHardwareNumber {4}

34

VMECUHN

#30

vehicleManufacturerECUHardwareNumber {1}

31

VMECUHN

#31

vehicleManufacturerECUHardwareNumber {1}

31

VMECUHN

#32

vehicleManufacturerECUHardwareNumber {0}

30

VMECUHN

#33

vehicleManufacturerECUHardwareNumber {2}

32

VMECUHN

#34

vehicleManufacturerECUHardwareNumber {0}

30

VMECUHN

#35

vehicleManufacturerECUHardwareNumber {-}

2D

VMECUHN

#36

vehicleManufacturerECUHardwareNumber {6}

36

VMECUHN

#37

vehicleManufacturerECUHardwareNumber {0}

30

VMECUHN

#38

systemSupplierECUHardwareNumber {0}

30

SSECUHN

#39

systemSupplierECUHardwareNumber {2}

32

SSECUHN

#40

systemSupplierECUHardwareNumber {6}

36

SSECUHN

#41

systemSupplierECUHardwareNumber {1}

31

SSECUHN

#42

systemSupplierECUHardwareNumber {1}

31

SSECUHN

#43

systemSupplierECUHardwareNumber {2}

32

SSECUHN

#44

systemSupplierECUHardwareNumber {3}

33

SSECUHN

#45

systemSupplierECUHardwareNumber {4}

34

SSECUHN

#46

systemSupplierECUHardwareNumber {5}

35

SSECUHN

#47

systemSupplierECUHardwareNumber {6}

36

SSECUHN

^ Байт данных

Имя паpаметpа

Значение Hex

Сокращение

#48

systemSupplierECUSoftwareNumber {1}

31

SSECUSN

#49

systemSupplierECUSoftwareNumber {4}

34

SSECUSN

#50

systemSupplierECUSoftwareNumber {1}

31

SSECUSN

#51

systemSupplierECUSoftwareNumber {1}

31

SSECUSN

#52

systemSupplierECUSoftwareNumber {0}

30

SSECUSN

#53

systemSupplierECUSoftwareNumber {0}

30

SSECUSN

#54

systemSupplierECUSoftwareNumber {0}

30

SSECUSN

#55

systemSupplierECUSoftwareNumber {-}

2D

SSECUSN

#56

systemSupplierECUSoftwareNumber {0}

30

SSECUSN

#57

systemSupplierECUSoftwareNumber {0}

30

SSECUSN

#58

systemNameOrEngineType {S}

53

SNOET

#59

systemNameOrEngineType {A}

41

SNOET

#60

systemNameOrEngineType {M}

4D

SNOET

#61

systemNameOrEngineType {A}

41

SNOET

#62

systemNameOrEngineType {R}

52

SNOET

#63

systemNameOrEngineType {A}

41

SNOET

#64

systemNameOrEngineType {-}

2D

SNOET

#65

systemNameOrEngineType {1}

31

SNOET

#66

systemNameOrEngineType {.}

2E

SNOET

#67

systemNameOrEngineType {5}

35

SNOET

#68

systemNameOrEngineType {l}

6C

SNOET

#69

systemNameOrEngineType {,}

2C

SNOET

#70

systemNameOrEngineType { }

20

SNOET

#71

systemNameOrEngineType {8}

38

SNOET

#72

systemNameOrEngineType {V}

56

SNOET

#73

repairShopCode {2}

32

RSC

#74

repairShopCode {8}

38

RSC

#75

repairShopCode {5}

35

RSC

#76

repairShopCode {0}

30

RSC

#77

repairShopCode {3}

33

RSC

#78

repairShopCode {5}

35

RSC

#79

repairShopCode {8}

38

RSC

#80

ProgrammingDate {10}

310

PD

#81

ProgrammingDate {95}

395

PD

#82

ProgrammingDate {-9}

392D

PD

#83

ProgrammingDate {06}

360

PD

#84

ProgrammingDate {7-}

2D37

PD

#85

ProgrammingDate {-0}

230D

PD

#86

ProgrammingDate {17}

371

PD

^ Байт данных

Имя паpаметpа

Значение Hex

Сокращение

#87

ProgrammingDate {9-}

2D39

PD

#88

ProgrammingDate {90}

309

PD

#89

ProgrammingDate {65}

356

PD

#90

vehicleManufacturerECUIdentifier {M}

4D

VMECUID

#91

vehicleManufacturerECUIdentifier {1}

31

VMECUID

#92

vehicleManufacturerECUIdentifier {V}

56

VMECUID

#93

vehicleManufacturerECUIdentifier {1}

31

VMECUID

#94

vehicleManufacturerECUIdentifier {3}

33

VMECUID

#95

vehicleManufacturerECUIdentifier {F}

46

VMECUID

#96

vehicleManufacturerECUIdentifier {0}

30

VMECUID

#97

vehicleManufacturerECUIdentifier {4}
<