АО АвтоВАЗ. Keyword Protocol 2000. Спецификация канала связи с диагностическим оборудованием - Уровень обмена данными
Подождите немного. Документ загружается.
АО “АвтоВАЗ”
Генеральный Департамент Развития
Управление Проектирования Электроники и
электрооборудования
Keyword Protocol 2000
Спецификация канала связи с диагностическим
оборудованием - Уровень обмена данными
Состояние: Версия E - текущая серийная.
Дата: 10 мая 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
КБ систем управления двигателем
Автор - Д.Б.Дударь
АВТОВАЗ, Генеральный Департамент Развития дата:10 мая 2000г.
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.
Спецификация канала связи с диагностическим оборудованием - Уpовень обмена данными Стpаница:2
3. Физическая архитектура.
Концепция физической реализации последовательного канала передачи данных на
автомобилях ВАЗ показана ниже.
Рис. 1 - Архитектура.
K-линия используется для инициализации и обмена диагностическими сообщениями между
различными блоками управления и диагностическим тестером, L-линия в данной
архитектуре не используется. Изначально, контроллер подключен через W-линию только к
иммобилизатору и не имеет выхода на K-линию и диагностический разъем. В случае
успешного завершения процедуры иммобилизации, контроллер подключается, через
иммобилизатор, к K-линии и диагностическому разъему. Остальные устройства
подключаются к K-линии и диагностическому разъему непосредственно и иммобилизатор не
влияет на процесс их обмена с тестером.
Примечание: данная концепция физической реализации справедлива для автомобилей
укомплектованных иммобилизатором. При отсутствии иммобилизатора, контроллер подключен
непосредственно к K-линии.
K-линия
W-линия
К-линия
ТестеpИммобилизатоpЭБУ
4. Структура сообщения.
Структура сообщения, в общем виде, состоит из трех частей:
1) заголовок (Header);
2) байты данных (Data bytes);
3) контрольная сумма (Checksum).
4.1 Поддерживаемые типы заголовка сообщения.
Header Data bytes Checksum
Fmt Tgt Src
SId
1
... Data ... CS
3 байта макс. 63 байта 1 байт
Header Data bytes Checksum
Fmt Tgt Src Len
SId
1
... 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 Байт адреса источника.
Для диагностического тестера физический адрес принят равным F1h, для иммобилизатора
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 стоп бит, контроль четности отсутствует.
Механизм «быстрой» инициализации показан ниже:
T
iniL
StartCommunication
T
WuP
T
Idle
service request
StartCommunication
service response
P
2
Допустимые значения временных интервалов T
WuP
и T
inil
приведены в нижеследующей
таблице:
min max
T
iniL
25+-1 ms 24 ms 26 ms
T
WuP
50+-1 ms 49 ms 51 ms
Возможные значения времени T
Idle
:
- первая передача после включения питания: T
Idle
= >200 ms
- после выполнения запроса StopCommunication Service: T
Idle
= P
3min
- после завершения коммуникаций по таймауту P
3max
: T
Idle
= 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 Определение параметров.
Данная функция не имеет параметров.