Steve V
Вчера 22:35
Какое максимальное количество идентификаторов OBD2 я могу получить одновременно?
У меня Mazda 5 2014 года выпуска
Недавно я приобрёл регистратор OBD2, который позволяет получать большое количество (несколько сотен) идентификаторов PID, в том числе стандартных (SAE) и специальных идентификаторов PID, предоставляемых надстройкой Mazda Enhanced. Все эти данные передаются по Bluetooth на мой телефон и сохраняются в CSV-файле.
Я хочу устранить некоторые периодические проблемы с электричеством и (не зная, что ещё может быть затронуто) пытаюсь зарегистрировать как можно больше идентификаторов PID, которые мой автомобиль может безопасно поддерживать. Однако я пока не нашёл никаких рекомендаций по поводу того, сколько идентификаторов PID мне следует пытаться получить одновременно. Не перегрузит ли это CAN-шину или контроллер OBD2 моего автомобиля, если я попытаюсь получить слишком много идентификаторов PID или делать это слишком часто?
Будет ли иметь значение, если эти идентификаторы поступают из разных подсистем? («Модуль управления кузовом Mazda», «Модуль управления трансмиссией Mazda» и т. д.)
Вот скриншот со всеми доступными PID-кодами
[обновление]
На случай, если кому-то интересно, вот проблема, которую я пытался решить, собирая эти PID:
Почти каждый раз после сильного дождя и ветра машина не заводилась или двигатель просто терял мощность или полностью останавливался во время движения. Через день или два машина «высыхала», и всё возвращалось в норму до следующего дождя.
Вот коды ошибок, полученные после последнего такого случая:
IC (Instrument Cluster) U0401:68-08 Invalid Data Received From ECM/PCMA
PCM (Powertrain Control Module) P0340:00-AC Camshaft Position Sensor A Circuit (Bank 1 Or Single Sensor)
PCM (Powertrain Control Module) P061D:00-AC Internal Control Module Engine Air Mass Performance
TCM (Transmission Control Module) U0401:00-2C Invalid Data Received From ECM/PCMA
ABS (Anti-Lock Brake System) U0401:00-68 Invalid Data Received From ECM/PCMA
EPS (Electronic Power Steering) U2023-FF Fault Received From External Node
Поскольку после дождя двигатель терял мощность или просто глох, я надеялся получить какие-то PID-коды, указывающие на то, что именно пошло не так перед тем, как двигатель заглох. (были несколько стоп-кадров, но я не увидел там ничего подозрительного, и мой механик тоже, поэтому я пытаюсь собрать больше данных для «обычной» езды и «проблемных» случаев.
Перевод вопроса с Mechanics Stack Exchange
Лицензия: CC BY-SA (2.5–4.0)
Оригинальный вопрос: https://mechanics.stackexchange.com/questions/94575/what-is-the-maximum-number-of-obd2-pids-i-can-reasonably-retrieve-at-the-same-ti
Я бы не стал беспокоиться. В большинстве случаев ваш адаптер обычно работает намного медленнее, чем
CAN-соединение, поэтому, если ваш OBD2-адаптер не имеет собственной логики (что есть
лишь у немногих), невозможно насытить CAN-шину
последовательным адаптером на базе ELM327. Но давайте произведем некоторые вычисления.
Начнём с шины — предположим, что её пропускная способность составляет 500 Кбит/с (протокол ELM327, версия 6), а при скорости 250 Кбит/с
она увеличится вдвое.
Один PID OBD2 в виде CAN-фрейма (с 8 байтами данных и стандартной адресацией) имеет размер до 125 бит.
При скорости передачи данных 500 кбит/с на передачу одного бита уходит около 2 мкс, поэтому на передачу запроса по шине потребуется 250 мкс
и ещё 250 мкс на получение ответа.
Сейчас мы понятия не имеем, сколько времени требуется электронному блоку управления, чтобы ответить на запрос. Это не самые быстрые
устройства. Для простоты вычислений предположим, что это очень быстрое
устройство, которому требуется всего 500 мкс, чтобы выполнить этот запрос.
Таким образом, на один запрос/ответ у нас уходит 1 мс, что на данный момент соответствует теоретическому
максимуму в 1000 PIDs в секунду.
Если предположить, что это адаптер Bluetooth 3.x (адаптеры Bluetooth 2.x обычно работают ещё медленнее из-за накладных расходов GATT),
то скорость будет зависеть от протокола RFCOMM. Как правило, вы получите
450–500 Кбит/с.
К сожалению, скорость во многом зависит от внутренней скорости передачи данных UART
в ELM327, которая часто составляет 115 200 бит/с.
Поскольку ELM327 обменивается данными, отправляя символы ASCII, последовательность запросов/ответов
для типичного ПИД-регулятора, такого как 010C (текущие обороты), выглядит следующим образом:
Это 22 символа, то есть 220 бит для UART. 220 бит на UART при скорости 115 200 бит/с
занимают 1909 мкс, то есть почти 2 миллисекунды.
(Да, существует специальный синтаксис ELM327 для объединения нескольких запросов PID, но давайте пока не будем об этом)
При общей продолжительности взаимодействия между запросом и ответом в 3 миллисекунды теоретический максимум составит
333 PID в секунду.
Устройству, к которому подключен адаптер (компьютеру, смартфону, микроконтроллеру), также
требуется некоторое время, чтобы считать следующий PID из своего списка. Мы не знаем, сколько времени это занимает, но
скорее всего, это время можно не учитывать.
Хотя 333 PID в секунду — это довольно хороший показатель, он также зависит от того, используете ли вы
широковещательную адресацию. Если вы не знаете, сколько ECU ответят на ваш запрос,
адаптеру ничего не остаётся, кроме как ждать. Это ожидание обычно добавляет 100–250 мс на
запрос, поэтому мы быстро опускаемся до 5–10 PID в секунду.
Тем не менее, реальные значения, которые я видел, варьируются от 50 до 100 PID в секунду, последнее
только при использовании комбинаций хорошего программного обеспечения и высококачественных аппаратных адаптеров.