После замены блока автомобиль может видеть его при диагностике, но часть функций остаётся недоступной. Одна из возможных причин — защита компонентов: установленный блок ещё не связан с этим автомобилем так, как требует система. Для восстановления этой связи может понадобиться KDS-токен.

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

Что такое KDS

KDS — электронная защита отдельных компонентов автомобиля от кражи. Она связывает защищённый компонент с автомобилем. Если такой компонент переставить в другую машину, система обнаружит несоответствие. В зависимости от компонента его функции могут быть ограничены или отключены.

Эта защита дополняет защиту самого автомобиля. Её задача — затруднить использование снятого компонента в другой машине. Поэтому исправность блока и его присутствие в диагностике ещё не означают, что он готов полноценно работать после установки.

Состав защищённых компонентов зависит от автомобиля. Увидеть участников KDS можно при чтении системы; переносить список блоков с одной машины на другую не следует.

Master, Client и Pairing простыми словами

В KDS есть центральный участник — Master, и защищённые компоненты — Clients. В описанной системе эту роль выполняет BCP — центральный электронный блок автомобиля, через который защищённые компоненты связаны с машиной. Название Client здесь относится к блоку автомобиля.

Pairing означает связь между центральным участником и защищённым компонентом. По её состоянию система определяет, правильно ли они связаны друг с другом. В программе можно отдельно увидеть проблемы на стороне Master и Client.

У участников есть KDS-ID — идентификаторы внутри системы защиты. Они помогают программе различать участников. VIN обозначает автомобиль целиком, поэтому эти обозначения выполняют разные задачи.

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

Зачем нужен KDS-токен

При ремонте иногда требуется заново связать защищённый компонент с автомобилем. Такая необходимость возможна после замены самого компонента или центрального блока BCP. В документации восстановление связи называется Refurbish, а повторное связывание — Re-Pairing.

KDS-токен — защищённое разрешение для определённой операции KDS. Для восстановления связи процедура должна быть авторизована BMW. Программа использует токен при выполнении этой операции.

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

Получение токена и выполнение ремонта — отдельные этапы. Готовый токен ещё требуется применить в соответствующей процедуре, после чего проверить состояние системы и работу компонента.

Как KDS связан с кодированием, SFA и FSC

Кодирование задаёт настройки блока под автомобиль и его оборудование. После замены блока это может быть частью работы, но настройки сами по себе не подтверждают правильную связь участников KDS.

SFA управляет разрешениями на защищённые функции. Например, после ремонта может потребоваться восстановить разрешение функции. У KDS другая задача: восстановить правильную связь защищённого компонента с автомобилем. Поэтому запрос на SFA и запрос на KDS относятся к разным операциям.

FSC тоже относится к разрешениям, причём такие коды использовались и в прежних схемах защиты компонентов. Конкретный способ определяется системой автомобиля. По одному сообщению «функция недоступна» нельзя выбрать между FSC, SFA и KDS: нужный механизм показывает диагностика и процедура ремонта.

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

Почему для услуги нужен исходный запрос

VIN сообщает, с каким автомобилем ведётся работа. Исходный KDS-запрос содержит данные для конкретной операции, которую подготовила программа. Поэтому одного VIN для получения ответа KDS недостаточно.

Запрос создают в той процедуре, где возникла необходимость в токене. Его сохраняют без ручного изменения данных и загружают при заказе KDS-токена. После успешной обработки запроса результат услуги — один токен.

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

Общий порядок работы выглядит так:

  1. Диагностика показывает проблему связи защищённого компонента.
  2. Процедура определяет необходимую операцию и создаёт исходный запрос.
  3. Получают один KDS-токен для операции, указанной в запросе.
  4. Результат применяют в исходной процедуре.
  5. Повторно читают состояние KDS и проверяют работу компонента.

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

Пример: чтение состояния KDS в E-Sys

После замены защищённого компонента нужно прочитать участников KDS и проверить состояние их связи. В этом примере используется E-Sys 25.10.01, модуль KDS Extended.

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

1. Прочитать участников

На вкладке Standard actions нажмите Read KDS. Программа прочитает систему KDS и покажет участников в разделах Master и Clients.

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

2. Проверить состояние

Перейдите на вкладку KDS Status и нажмите Quick check. Программа выполнит проверку системы и покажет результат.

Например, MASTER_OK_CLIENT_OK означает, что проверка сообщает нормальное состояние обеих сторон. MASTER_OK_CLIENT_INVALID указывает на проблему на стороне Client при нормальном состоянии Master. ERROR_CLIENT_NOT_PAIRED сообщает, что компонент не связан с центральным участником.

Это помогает понять направление дальнейшей диагностики. Сообщение о недействительном состоянии ещё не описывает весь ремонт: нужно определить затронутый компонент и требуемую операцию.

Результат чтения используйте, чтобы определить, нужна ли процедура восстановления связи.

Как после диагностики восстанавливают связь

Процедуру восстановления выбирают по результатам диагностики. У неё свои действия и условия доступа.

Для повторного связывания в KDS Extended предусмотрен тип запроса Re-Pairing на вкладке Extended actions. Кнопка Create request file создаёт запрос для выбранных участников или всей системы. Выбор должен соответствовать операции, определённой диагностикой.

Эти действия описывают процедуру E-Sys. Перед получением ответа через услугу нужно проверить, что она выдаёт результат именно для выбранной операции и этого модуля.

В том же разделе предусмотрена запись подходящего ответа через нижнее поле File Name и кнопку Write Secure Token (Set).

Как проверить результат восстановления

После выполнения предусмотренной процедуры снова прочитайте KDS и выполните Quick check. Сравните состояние с тем, которое было до ремонта. Затем проверьте работу компонента в автомобиле.

Так становится понятно, что изменилось: программа подтверждает состояние связи, а проверка в машине показывает, восстановилась ли нужная работа компонента. Если связь уже в порядке, а функция по-прежнему недоступна, диагностику продолжают с учётом настроек, ПО, разрешений и состояния самого блока.

Получить ответ KDS для своей операции

Сохраните исходный KDS-запрос. До заказа проверьте назначение ответа для выбранной процедуры. Один VIN не заменяет запрос; результат услуги — один токен.

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

Перейти к услуге KDS