Протокол KWP2000 в автомобильных диагностических приложениях

Протокол KWP2000 стал стандартом де-факто в автомобильных диагностических приложениях. Он стандартизован как ISO 14230-3. KWP2000 описывает внедрение различных диагностических служб, которые вы можете использовать в протоколе. Вы можете запустить KWP2000 на нескольких транспортных уровнях, таких как K-line (последовательный) или CAN.

Transport Protocol

Поскольку KWP2000 использует сообщения с длиной байтов с переменным байтом, транспортный протокол необходим для слоев с только четко определенной (короткой) длиной сообщения, такой как CAN. Транспортный протокол разбивает длинное сообщение KWP2000 на части, которые могут быть переданы по сети, и собирает эти фрагменты для восстановления исходного сообщения.

KWP2000 работает на CAN по различным транспортным протоколам, таким как ISO TP (ISO 15765-2), TP 1.6, TP 2. 0 (Volkswagen) и SAE J1939-21. Для KWP2000 Набор автомобильных диагностических команд поддерживает только протокол ISO TP (стандартизованный в соответствии с ISO 15765-2) и транспортные протоколы VW TP 2.0, соответствующие конкретным производителям.

Диагностические службы

Службы диагностики, доступные в KWP2000, группируются в функциональные блоки и идентифицируются однобайтовым кодом (ServiceId). Стандарт не определяет все коды; для некоторых кодов стандарт относится к другим стандартам SAE или ISO, а некоторые зарезервированы для расширений, специфичных для производителя. Набор автомобильных диагностических команд поддерживает следующие службы:

• Диагностическое управление

• Передача данных

• Сохраненная передача данных (диагностические коды неисправностей)

• Управление вводом / выводом

• Удаленная активация рутины

Загрузка / Загрузка и расширенные службы не входят в набор диагностических команд для автомобилей.

Диагностический сервисный формат

Диагностические службы имеют общий формат сообщений. Каждая служба определяет сообщение запроса, положительное ответное сообщение и сообщение отрицательного ответа. Сообщение запроса имеет ServiceId в качестве первого байта, а также дополнительные параметры, определенные сервисом. Сообщение с положительным ответом имеет эхо ServiceId с бит 6, установленным как первый байт, а также параметры ответа, определенные сервисом.

Сообщение об отрицательном ответе обычно представляет собой трехбайтовое сообщение: оно имеет отрицательный ответ ServiceId в качестве первого байта , эхо исходного ServiceId в качестве второго байта и ResponseCode в качестве третьего байта. Единственным исключением из этого формата является отрицательный ответ на службу EscapeCode; здесь третий байт является эхом определяемого пользователем служебного кода, а четвертым байтом является ResponseCode. Стандарт KWP2000 частично определяет ResponseCodes, но есть место для расширений, специфичных для производителя. Для некоторых из ResponseCodes KWP2000 определяет процедуру обработки ошибок. Поскольку как положительные, так и отрицательные ответы имеют эхо запрашиваемой услуги, вы всегда можете назначить ответы на их соответствующий запрос.

Connect / Disconnect

KWP2000 ожидает, что диагностический сеанс начнется с StartDiagnosticSession и завершится с помощью StopDiagnosticSession. Однако StartDiagnosticSession имеет параметр DiagnosticMode, который определяет тип сеанса диагностики. В зависимости от этого типа ECU может поддерживать или не поддерживать другие диагностические службы или работать в ограниченном режиме, где доступны не все функции ECU. Значения параметров DiagnosticMode являются специфическими для производителя и не определены в стандарте. Чтобы сеанс диагностики оставался активным, он должен периодически выполнять службу TesterPresent, если другая служба не выполняется. Если служба TesterPresent отсутствует в течение определенного периода времени, сеанс диагностики завершается, и ECU возвращается в обычный режим работы.

GetSeed / Unlock

Механизм GetSeed / Unlock может защитить некоторые диагностические службы. Однако соответствующие сервисы предоставляются производителю и не определяются стандартом. Вы можете выполнить механизм GetSeed / Unlock через службу SecurityAccess. Это определяет несколько уровней безопасности, но производитель назначает эти уровни определенным службам.

Чтение / запись памяти

Используйте службы Read / WriteMemoryByAddress для загрузки / загрузки данных на определенные адреса памяти в ECU. Адрес представляет собой трехбайтовое количество в KWP2000 и пятибайтовое количество (четырехбайтовый адрес и однобайтное расширение) в протоколах калибровки. Службы функционального блока «Загрузить / Загрузить» отличаются высокой спецификой для производителей и не определены в стандарте, поэтому они не являются хорошим способом обеспечения общего механизма загрузки / загрузки.

Измерения

Используйте службы ReadDataByLocal / CommonIdentifier для доступа к данным ЭКЮ способом, подобным списку DAQ. Local / CommonIdentifier описывает список количества ECU, которые затем передаются из ECU в тестер. Передача может быть либо однозначной, либо периодической, с медленной, средней или быстрой скоростью передачи. Скорость передачи зависит от производителя; вы можете использовать службу SetDataRates для их установки, но этот параметр специфичен для производителя. Набор автомобильных диагностических команд поддерживает одноточечные измерения.

Диагностические коды неисправностей

Основной диагностической особенностью является считывание диагностических кодов неисправностей (DTC). KWP2000 определяет несколько сервисов, которые получают доступ к кодам DTC на основе их группы или статуса.

Управление вводом / выводом

KWP2000 определяет службы для изменения внутренних или внешних сигналов ECU. Одним из примеров является перенаправление входов датчиков ECU на стимулированные сигналы. Параметры управления этими командами являются конкретными производителями и не определены в стандарте.

Удаленная активация рутины

Эти службы аналогичны функциям ActionService и DiagService для CCP. Вы можете вызвать внутреннюю процедуру ECU, идентифицированную локальным / CommonIdentifier или адресом памяти. В отличие от случая CCP выполнение этой процедуры может быть асинхронным; то есть существуют отдельные службы Start, Stop и RequestResult. Параметры управления этими командами являются конкретными производителями и не определены в стандарте.

Внешние ссылки

Для получения дополнительной информации о стандарте KWP2000 см. Стандарт ISO 14230-3.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *