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: [email protected] КБ систем управления двигателемАвтор – Д.Б.Дударь 1. Введение. Данный документ базируется и разработан для конкретной реализации программного обеспечения (ПО) контроллера системы управления двигателем (ЭБУ) M1.5.4 в соответствии с текущим состоянием разработки ПО. В него включены специфичные для данного проекта диагностические функции и параметры.Для более детальной информации и общего описания протокола KWP2000, обращайтесь к международным стандартам ISO 14230-1…3 и German Implementation Specification – Part 3.^ 2. Нормативные документы. Данный документ содержит ссылки и базируется на следующих международных стандартах:ISO 14229 Road Vehicles – Diagnostic Systems Diagnostic Services SpecificationISO 14230-1 Road Vehicles – Diagnostic Systems Keyword Protocol 2000 Part 1: Physical LayerISO 14230-2 Road Vehicles – Diagnostic Systems Keyword Protocol 2000 Part 2: Data Link LayerISO 14230-3 Road Vehicles – Diagnostic Systems Keyword Protocol 2000 Part 3: ImplementationISO 14230-3G German Implementation Specification – Part 3SAE 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 – Пример отрицательного ответа на запрос testerPresent6.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}