Разъем диагностики OBD-II, как интерфейс для IoT / Хабр
Когда-то давно, примерно в середине 90-х, во время появления процессора Pentium Pro, один из основателей компании Intel Гордон Мур заметил, что: «Если бы автомобилестроение развивалось со скоростью эволюции полупроводниковой промышленности, то сегодня Роллс-Ройс мог бы проехать полмиллиона миль на одном галлоне бензина, и было бы дешевле его выбросить, чем платить за парковку». Но, пожалуй, уже сегодня автомобилестроение совершает гигантский шаг развития в направлении, как кардинальной смены типа топлива, так и технологий управления автомобилем. Практически недавно представлены коммерческие электромобили и авто на водородном топливе, а автопилот становится желаемым компонентом электронной «начинки» транспортного средства. В большинстве своем, как раз стремительный рывок автопрома обусловлен появлением надежных и безопасных решений на основе умной электроники для автомобильных бортовых систем управления.
Но, где же в повседневной жизни Интернет в автомобиле, где же технологии Интернета вещей (IoT), а также многим известная концепция подключенного к сети автомобиля (Connected Car)?
The Rolls-Royce 103EX. Rolls-Royce unveils driverless, electric concept car, complete with silk love seat – The Telegraph.
На самом деле, все вышеперечисленные технологии уже существуют и используются, однако, только в достаточно обособленных решениях. Виною тому, строгие требования к обеспечению безопасности, которые непременно должны быть реализованы при запуске любой новой технологии или решения на транспорте. Поэтому, нельзя сказать, что, садясь в автомобиль со смартфоном, можно автоматически получить решение IoT или Connected Car. В большинстве стран, и это очень логично, существует запрет на использование смартфона или других гаджетов за рулем, а если говорить о голосовых ассистентах, то в большинстве случаев они сейчас раздражают и отвлекают, как водителя, так и пассажиров.
На сегодня, интересным и очень перспективным решением автомобильного IoT, является платформа Open Connected Car компании Mojio. Эта платформа с открытым интерфейсом (API) предоставляет облачный сервис для «подключенных» авто и уже доступны коммерческие предложения. Например, телекоммуникационный гигант Т-Mobile, на базе этой платформы, предоставляет сервис SyncUP DRIVE.
The Open Connected Car Platform – Mojio
Для подключения к автомобилю используется стандартный диагностический разъем OBD-II. Большинство серийных автомобилей, выпущенных после 1996 года, уже оснащены таким разъемом. Хотя такой разъем диагностики и стандартизирован, но в нем поддерживаются сразу несколько протоколов различных систем управления двигателем (физически используются разные контакты на разъеме), которые должен «знать» коммуникационный модуль IoT.
Модуль VM6200S поддерживает подключение по мобильному протоколу LTE, содержит интегрированный 3-х осевой датчик ускорений и 3-х осевой гироскоп, приемник GPS-сигналов, чип OBD-II, с поддержкой протоколов ISO 15765-4 (CAN), ISO 14230-4 KWP (Keyword Protocol 2000), ISO 9141-2 (Chrysler, Euro, and Asian automobiles), SAE J1850 PWM (Ford vehicles), SAE J1850 VPW (GM vehicles). Таким образом, модуль позволяет развернуть точку доступа Wi-Fi 802.11 b/g/n/, регистрировать события во время движения, выполнять диагностику работы двигателя, оценивать экономичность расхода топлива и т.п. А поскольку партнерами Mojio являются проекты Amazon Alexa, сервис IFTTT и другие, то для разработчиков и интеграторов решений открываются все перспективы вплоть до создания социального IoT на основе «подключенного» автомобиля, как составляющей такой инфраструктуры.
VM6200S4G OBD Device – ZTEWelink Corporation
Но не только SyncUP DRIVE сейчас представлена на рынке, например, многие компании предоставляют нечто подобное. Конечно, недавно появившийся Samsung Connect auto device – одно из таких интересных предложений, превращающих автомобиль в подключенное устройство. Решение от Samsung аналогичным образом использует мобильную сеть поколения 4G LTE и разворачивает внутри автомобиля точку доступа Wi-Fi: 802.11 a/b/g/n. Connect auto device поддерживает подключение Bluetooth v4.1, содержит GPS-приемник, датчик ускорений, гироскоп и базируется на 4-х ядерном процессоре с частотой 1.2GHz и операционной системе Tizen. Следует отметить, что корейский электронный гигант Samsung говорит о защищенности системы за счет использования Samsung Knox – мобильного решения с защитой уровня предприятия. Фактически Samsung Knox – это программно-аппаратное решение для усиления защиты операционной системы Android.
Samsung Connect auto
Таким образом, информация, полученная по средствам считывания данных OBD-II, текущие координаты месторасположения с GPS-приемника и параметры динамики движения автомобиля, полученные с гиро-сенсоров, на текущий момент времени и де-факто, стали основой для превращения любого транспортного средства в устройство IoT.
Так или иначе, но все ранее рассмотренные решения – это более совершенные промышленные изделия, по сравнению с обычным устройством считывания кодов диагностики на базе микросхемы ELM327 канадской компании Elm Electronics. ELM327 – это универсальный преобразователь протоколов, используемых в диагностических шинах автомобилей, в последовательный протокол типа RS-232.
Структурная схема микросхемы ELM327 v2.2 – Elm Electronics
Взаимодействие с ELM327 осуществляется стандартными AT-командами, поддерживаемыми микросхемой.
Нужно просто организовать обмен текстовыми сообщениями по, уже ставшему классикой, протоколу RS-232 (или правильнее UART, т.к. речь идет только о потоке данных, а не уровнях сигнала). А само физическое соединение низкого уровня по USB, Bluetooth или Wi-Fi просто реализуется, с применением микросхем преобразования последовательного протокола UART. Получается, чтобы превратить автомобиль в устройство IoT вполне достаточно, не забыв о согласовании уровней напряжений, подключить микросхему ELM327 к диагностическому разъему OBD-II и на выходе этой микросхемы, например, поставить преобразователь последовательного интерфейса в Bluetooth или Wi-Fi. Затем, можно со своего смартфона «считывать» диагностику автомобиля. Впрочем, таких готовых модулей или блоков на рынке предостаточно. А их цена на AliExpress колеблется в пределах US $2.50 – US $10. Хотя модуль и не должен потреблять много энергии, но будет очень удобно, если на нем уже присутствует кнопка отключения питания. Кстати, с точки зрения защищенности – это тоже не плохо.
Mini ELM327 Bluetooth OBD-II Car Diagnostic Adaptor V1.5
Теперь можно подключить стандартный модуль Mini ELM327 Bluetooth OBD-II V1.5 (интересно, что во многих источниках советуют использовать модули со старой прошивкой версии 1.5, а не новые с версией 2.2, т.е. как аргумент высказывается более стабильная работа модуля на старой прошивке и поддержка большего количества авто, но это очень субъективно) и поэкспериментировать с подключением смартфона к выбранному модулю, например, для платформы Android можно использовать одну из самых популярных программ диагностики Torque Lite (OBD2 & Car) или Torque Pro (OBD 2 & Car), а также что-нибудь попроще или использовать свои наработки.
Работа приложения Torque Pro под Android.
Кстати, хочется отметить, очень удобный сервис MockUPhone с бесплатными mock-up современных гаджетов, который очень пригодился, для подготовки скриншота работы программы Torque. Но это небольшое отступление от темы публикации.
Нужно заметить, что в большинстве случаев, разъем OBD-II, к которому подключается модуль диагностики, находится под рулевой колонкой автомобиля.
Getting Started with OBD-II – SparkFun Electronics
Понятно, что уже готовых решений существует множество. Но если речь идет о разработке сервиса на основе IoT или более конкретно – реализуется концепция Connected Car, то достаточно удобно использовать эмулятор бортовой информационной сети автомобиля, чтобы не бегать каждый раз к автомобилю. Например, Mojio для работы со своим API предлагает онлайн симулятор автомобиля, а на примере работы с облачным сервисом IBM Watson IoT Platform в статье: «Sending Vehicle Data to the IBM Watson IoT Platform – IBM developerWorks Recipes» предлагается для отправки в облако данных с транспортного средства использовать мобильное приложение, например, «IBM IoT for Automotive — OBDII Fleet Management App for Android», которое взаимодействует с разворачиваемым облачным сервисом «IBM IoT for Automotive (Bluemix) — Fleet Management Starter Application», но если не отвлекаться на эти проекты можно использовать просто эмулятор данных: «Car Simulator».
ECUsim 2000 OBD Simulator – ScanTool
Конечно, профессиональный эмулятор не заменишь, но энтузиастов и гиков вполне может заинтересовать самостоятельная реализация менее сложного проекта на Arduino или Raspberry Pi. Например, можно ограничиться только наиболее распространенным интерфейсом CAN (Controller Area Network). В свое время, стандарт CAN, предложенный компанией Bosch, совершил заметный прогресс в разработке систем для автомобильной электроники. Если автомобиль в сети Интернет появился только недавно, то концепция сети внутри автомобиля существует уже с середины 80-х. Идея очень проста, и как Ethernet совершил прорыв в компьютерных сетях, так и CAN стал основой надежных коммуникаций внутри автомобиля.
An Arduino Based CAN Bus Network – Henry’s Bench
Раньше в автомобиле, как правило, к центральному блоку управления двигателем «стекались» шины и провода различных подключенных модулей и устройств. Последовательная двухпроводная шина CAN позволила реализовывать уже независимые интеллектуальные модули, например, центральный блок управления стал просто одним из таких модулей, которые «общаются» друг с другом фактически по сетевому протоколу. При этом значительно уменьшается количество проводки внутри автомобиля.
В отличие от Ethernet, сеть CAN значительнее надежнее, что обусловило ее применение не только в автопроме, но и в системах промышленной автоматики, решениях умного дома и т.п. На физическом уровне в CAN используется двухпроводная линия, CAN Lo и CAN Hi, которые побитно передают данные, упакованные в пакет. На концах шины присутствуют согласующие сопротивления по 120 Ом, а также для подавления помех следует использовать скрутку проводов. Скорость передачи данных может достигать 1 Мбит/с.
A Controller Area Network (CAN bus)
Передача данных в CAN bus чем-то напоминает модель «издатель-подписчик», где каждое устройство на шине имеет уникальный идентификатор и, когда передает данные одно устройство, то все остальные слушают, и принимают решение на основе этого идентификатора – нужны ли конкретно им эти данные для приема и обработки или нет. В общем, протокол достаточно сложен, но для микроконтроллера или микропроцессора вряд ли придется писать реализацию CAN, а также думать об особенностях физической среды передачи данных. Для решения этих задач уже есть готовые аппаратные контроллеры шины, а для согласования уровней, зачастую применяются интегральные преобразователи. Например, контроллер MCP2515 с интерфейсом SPI и трансивер (согласовательная микросхема уровней) MCP2551. Как раз на базе этих микросхем и предложен проект Arduino OBD2 Simulator, опубликованный на площадке Instructable. Для его реализации потребуется лишь плата Arduino UNO и CAN-BUS Shield, например, компании Seeed Technology.
Эксперименты с применением Arduino OBD2 Simulator
В принципе, для разработки эмулятора данных OBD-II, не помешает наличие блока питания DC на 12V для модуля ELM327, а также разъем OBD-II. Впрочем, no-name преобразователь DC-DC-USB-TO-12V вполне может решить проблему, т.к. несколько блоков питания на 5V, пожалуй, будут под рукой у любого разработчика для Интернета вещей и не только. Для подключения к OBD-II потребуется два информационных провода CAN_H и CAN_L, а также наличие питания 12 V, но как было замечено ранее, 12 V нужно только для обеспечения работоспособности для модуля ELM327.
CAN-BUS Shield V1.2 — Seeed Development Limited Wiki
На плате расширения CAN-BUS Shield очень удобно использовать не разъем D-SUB, а просто клеммник на два контакта (CAN_H, CAN_L). С точки зрения разработки программного кода, следует отметить, что прототип энтузиасты выложили на GitHub. Сейчас платы от Seeed изменились, да и в любом случае для контроллера MCP2515 лучше использовать новые драйверы все той-же Seeed-Studio.
Конечно, оригинальную программу нужно будет немного доработать под новые драйверы, но это дело на пару минут.
Работа с CAN-BUS в среде Arduino IDE на основе low cost OBD2 ECU Simulator
Однако, рассмотренный пример очень примитивен, так как все параметры, отправляемые по протоколу OBD-II, просто генерируются случайным образом, нет связи параметров работы двигателя между собой и т.д. Как продолжение проекта очевидным является разработка приложения, похожего на Freematics OBD-II Emulator GUI. Это графическая оболочка с открытым исходным кодом, которая используется в аппаратном решении Freematics OBD-II Emulator.
Freematics OBD-II Emulator GUI – Freematics
Таким образом, собрав на базе Arduino модуль, позволяющий работать с CAN, вполне можно создать эмулятор OBD-II, так как протокол диагностики хорошо описан и его несложно реализовать. Следует отметить, что реализация взаимодействия микроконтроллера и бортовой шины CAN – это совсем другая задача и нужно понимать, что внутренние высокоуровневые протоколы этой шины не документируются автопроизводителями, да и с другой стороны – не следует внедрятся во внутреннее устройство автомобильной электроники, чтобы не коим образом не снизить безопасность эксплуатации транспортных средств.
Если говорить о CAN в общем, то для разработки своих устройств на базе этой шины вполне можно использовать высокоуровневый открытый протокол CANopen.
Остается дело за малым – немного свободного времени и в удовольствие выполнять разработку своего кода. Правда, где же это время найти в конце года? Но будем оптимистами. А вот, если говорить о применении такого эмулятора OBD-II, то самое прямое направление – это разработка уже своего модуля для диагностического разъема. Например, за отправную точку можно взять открытый проект Carloop, который нацелен на создание модуля подключения автомобиля к облаку с использованием технологий 3G, Wi-Fi или Bluetooth.
Carloop Bluetooth
Проект Carloop основывается на использовании плат: Particle Photon (на базе Wi-Fi модуля Cypress BCM43362, который поддерживает стандарт 802.11b/g/n; контроллера семейства ARM Cortex M3 – STM32F205 на частоте 120Mhz; 1MB флеш-памяти; 128KB оперативной памяти) и Electron (платы с поддержкой подключения к сети мобильной связи 3G/2G).
Платформа Particle и сама очень интересна, поскольку базируется на облачном сервисе подключения устройств IoT, облачной IDE для разработки, например, на базе плат Photon, где используется язык похожий на C/C++ для Arduino. Фактически Particle – это отдельная тема для публикации, а проект Carloop однозначно заслуживает отдельного внимания со сороны энтузиастов автомобиля, как подключенного устройства IoT.
Подключив автомобиль к сети Интернет и сервисам IoT, можно реализовать множества сценариев, которые несомненно будут способствовать удобству эксплуатации транспортных средств, повышению комфорта и, просто, эфективному решению повседневных задач, конечно, включая и решение транспортных перевозок. Например, данные о стиле вождения, надежности работы двигателя и агрегатов автомобиля, вполне могут и уже сейчас учитываются страховыми компаниями. Текущее месторасположение автомобиля будет актуально для сервисов такси и аренды автомобилей. Взаимодействие участников дорожного движения стает более удобной при использовании IoT, так же проблема парковок, поиска свободных мест на стоянке, и многое-многое другое.
https://www.youtube.com/watch?v=m4ypWq9dMV0
Надеемся, что идея этой публикации достигнута – в одном месте собраны материалы по работе с диагностическим разъемом OBD-II, как на уровне простого считывания кодов неисправностей, так и эмуляции физического подключения к автомобилю. Также надеемся на комментарии читателей. В завершении хочется отметить, что рассмотрены лишь некоторые вопросы разработки устройств Connected Car, но «за кадром» остались многие технологии, которые, так или иначе, превращают современный автомобиль в устройство IoT и делают поезки более комфортными и безопасными. Разумеется мы будем возвращаться к этим темам в наших будущих публикациях.
Интересные ресурсы и ссылки:
— Car Hacking: так ли безопасны системы безопасности автомобиля? – Хабрахабр
— Микропроцессору- 25 лет! – Computerworld
— T‑Mobile SyncUP DRIVE – T-MOBILE
— ZTE и Mojio сделают практически любой автомобиль частью Интернета вещей – ZTE Corporation
— Samsung Knox – SAMSUNG
— Возможности CAN протокола – Журнал «СТА»
— Интернет вещей в вашем доме — подключите к дому свою машину – IBM developerWorks
— Vehicle telematics analytics using Watson IoT Platform Cloud Analytics – IBM developerWorks Recipes
— Использование сети CAN и стека CANopen – Хабрахабр
— Протокол высокого уровня CANopen – Журнал РАДИОЛОЦМАН
— Бортовой компьютер для авто на Arduino своими руками – Geektimes
— Wiring the MCP2515 Controller Area Network CAN BUS Diagnostics – 14CORE
— Arduino OBD2 ELM327 I2C-LCD HC05 Bluetooth – Instructables
—Разработка Android приложения для работы с OBDII протоколом – Хабрахабр
OBDII — система бортовой диагностики автомобилей
Бортовая диагностика, или OBD, это автомобильный термин, который имеет прямое отношение к системе самодиагностики автомобиля.
OBD предоставляет доступ к важнейшей информации о состоянии систем автомобиля механику или его владельцу. Количество диагностической информации сильно изменилось с момента появления первых систем в начале 80-х гг. Первые OBD управляли включением индикаторной лампы неисправности, или MIL, при возникновении поломки — но сопровождающая информация, связанная с возможной причиной неисправности, в этих системах отсутствовала. Современные системы OBD используют стандартный цифровой разъем для передачи данных в режиме реального времени и диагностических кодов неисправности, или DTC, которые позволяют быстро выявить неисправность и найти способ ее устранения.
История систем OBD
1969 г.:
Фольксваген устанавливает первый бортовой компьютер с функцией сканирования систем на модели типа 3 с инжекторной системой подачи топлива.
1975 г.:
Датсан 280Z Бортовые компьютеры начинают устанавливаться на пассажирских автомобилях, в основном, в связи с необходимостью регулярных настроек инжекторных систем подачи топлива.
Появляется простейшая система OBD, в которой отсутствовал стандартный протокол мониторинга и передачи данных.
1980 г.:
Дженерал Моторс создает собственный интерфейс и протокол для тестирования ЭБУ двигателя (ECM) на сборочной линии. Протокол «Диагностика на сборочной линии» (ALDL) работает со скоростью передачи данных 160 бод в режиме широтно-импульсной модуляции (ШИМ) и контролирует работу лишь небольшого числа систем автомобиля. ALDL присутствовала на автомобилях, проданных в Калифорнии, в 1980 г. и затем в США в 1981 г.. ALDL не предназначалась для диагностики систем вне заводских стен. Единственной доступной для владельца функцией был так называемый «Мигающий код». После замыкания контактов A и B (при включенном зажигании и выключенном двигателе), лампа «Проверить двигатель» (CEL) или «Требуется обслуживание» (SES) начинает мигать в режиме двузначного цифрового кода, которому соответствует определенная неисправность. Автомобили с инжекторами двигателями марки «Кадиллак» (бензиновые) оснащались полноценной системой бортовой диагностики, которая выдавала коды неисправностей, выполняла контроль исполнительных устройств и датчиков с помощью новейшего цифрового экрана системы климат-контроля.
Одновременное нажатие кнопок «Off» (Выкл.) и «Warmer» (Обогрев) в течение нескольких секунд включало режим самодиагностики, поэтому внешнее диагностическое устройство не требовалось.
1986 г.:
Появляется обновленная версия протокола ALDL, работающая на скорости передачи данных до 8192 бод с использованием однопроводного UART (универсальный асинхронный приемопередатчик). Этот протокол получил название GM XDE-5024B.
1988 г.:
Общество автомобильных инженеров (SAE) рекомендует стандартизировать диагностический разъем и диагностические сигналы.
1991 г.:
Совет по воздушным ресурсам Калифорнии (CARB) требует, чтобы все новые автомобили, проданные на территории Калифорнии в 1991 году и позже, имели режим OBD. Эти требования относятся к «OBD-I», хотя данное название официально не использовали до введения протокола OBD-II. Разъем для передачи данных и его расположение не были стандартизированы, как и сам протокол передачи данных.
1994 г.:
Мотивируя свое желание внедрить программу проверки токсичности автомобилей в США, CARB выпускает спецификацию для OBD-II и требует, чтобы система была установлена на всех автомобилях, проданных в Калифорнии, начиная с 1996 модельного года (см.
CCR, параграф 13, раздел 1968.1 и 40 CFR, часть 86, раздел 86.094). Коды DTC и диагностический разъем, рекомендованные обществом SAE, включены в указанные требования.
1996 г.:
Требования OBD-II обязательны для всех автомобилей, проданных на территории США.
2001 г.:
Европейский Союз вводит систему EOBD , которая становится обязательной для всех автомобилей с бензиновыми двигателями, проданных на территории ЕС с 2001 модельного года (см. Стандарты токсичности в ЕС Директива 98/69/EC).
2004 г.:
Европейский Союз вводит систему EOBD, которая становится обязательной для всех автомобилей с дизельными двигателями, проданных на территории ЕС.
2008 г.:
Все автомобили, проданные на территории США, должны соответствовать стандарту ISO 15765-4 (шина типа Бортовой контроллер связи (CAN)).
2008 г.:
Ряд легковых автомобилей в Китае в соответствии с требованиями Администрации по защите окружающей среды должны быть оснащены системой OBD (стандарт GB18352) к 01 июлю 2008 г.
За исключением некоторых провинций Китая.
2010:
HDOBD (автомобили высокой грузоподъемности) стандарт обязателен для определенных коммерческих (непассажирских) автомобилей, проданных на территории США.
Стандартные интерфейсы
ALDL
Интерфейс ALDL Дженерал Моторс (диагностика на сборочной линии) иногда называют предшественником или заводской версией OBD-I. Интерфейс имел множество вариантов в зависимости от блоков управления (PCM, ECM, ECU). Разные варианты немного отличались раскладками разъемов и скоростями передачи данных в бодах. Более ранние версии работали на скорости 160 бод, а более поздние – на скорости до 8192 бод и использовали двунаправленную линию передачи данных, связанную с ЭБУ PCM.
OBD-I
Стандарт OBD-I был создан для того, чтобы мотивировать автопроизводителей на разработку более надежных систем снижения токсичности, которые должны эффективно работать в течение всего полезного срока службы автомобиля. Цель состояла в том, чтобы путем ежегодной проверки токсичности автомобилей в Калифорнии, отказывать в регистрации тем автомобилям, которые не проходят данный тест, таким образом, это должно было стимулировать владельцев на покупку более надежных автомобилей.
В целом, программа OBD-I себя не оправдала, так как диагностическая информация не была стандартизирована, а сложности с получением надежной информации о токсичности выбросов привели к провалу в реализации ежегодной программы контроля токсичности автомобилей.
OBD-1.5
OBD 1.5 представляет собой половинчатую версию системы OBD-II, которую компания Дженерал Моторс использовала на некоторых автомобилях 1994, 1995 и 1996 г. выпуска (компания не указывала термин OBD 1.5 в документации на данные автомобили — в руководствах по ремонту присутствовали разделы OBD и OBD-II).Например, Корвет 94–95 г. выпуска имел один датчик кислорода, установленный после каталитического нейтрализатора (хотя автомобили оснащались двумя каталитическими нейтрализаторами), и неполный набор кодов OBD-II.
В Корветах 1994 г. выпуска использовались следующие коды OBD-II: P0116-P0118, P0131-P0135, P0151-P0155, P0158, P0160-P0161, P0171-P0175, P0420, P1114-P1115, P1133, P1153 и P1158. Эта гибридная система была установлена на автомобилях Дженерал Моторс с платформами H-body 94-95 г.
выпуска, W-body (Бьюик Регал, Шевроле Люмина (только 95 г. выпуска), Шевроле Монте-Карло (только 95 г. выпуска), Понтиак Гран при, Олдсмобил Котлас Суприм) 94-95 г. выпуска, L-body (Шевроле Берета/Корсика) 94-95 г. выпуска, Y-body (Шевроле Корвет) 94-95 г. выпуска, F-body (Шевроле Камаро и Понтиак Файрберд) 95 г. выпуска, J-Body (Шевроле Кавалер и Понтиак Санфайр) и N-Body (Бьюик Скайларк, Олдсмобил Ачива, Понтиак Гранд Ам) 95 и 96 г. выпуска и также Сааб 94-95 г. выпуска с атмосферными двигателями 2,3 л.
Раскладка разъема ALDL на этих автомобилях выглядела так:
В разъемах ALDL контакт 9 предназначен для передачи данных, контакты 4 и 5 выполняют роль заземления, а контакт 16 – напряжение АКБ.
Для OBD 1.5 предусмотрен совместимый сканер для считывания кодов OBD 1.5. Диагностика других систем автомобиля также выполнялась через указанный разъем. Например, на Корветах предусмотрены интерфейсы для последовательной передачи данных Класса 2 ЭБУ PCM, диагностирования СCM, передачи данных радиосистемы, системы пассивной безопасности, системы настройки подвески в зависимости от стиля вождения, системы предупреждения о низком давлении в шинах, системы бесконтактного доступа в автомобиль.
OBD 1.5 была установлена также на автомобилях Митсубиси 95-97 г. выпуска, некоторых Фольксвагенах с двигателем VR6 1995 г. выпуска, а также на моделях Бьюик Ривьера 1995 г. выпуска, Форд Скорпио начиная с 95 г. выпуска.
OBD-II
OBD-II представляет собой дальнейшее развитие системы OBD-I с точки зрения стандартизации и совместимости. Стандарт OBD-II предусматривает наличие диагностического разъема определенного типа (это касается также раскладки разъема) и использование протоколов для передачи данных в форме сигналов и в формате сообщений. Он также содержит список параметров автомобиля. В диагностическом разъеме предусмотрен контакт с напряжением АКБ для питания сканера, поэтому нет необходимости подключать диагностический прибор отдельно к источнику питания. Но, некоторые механики все-таки продолжают это делать во избежание потери данных в случае исчезновения бортового питания автомобиля или из-за неисправности. Наконец, стандарт OBD-II имеет более широкий список кодов DTC.
В результате стандартизации на автомобиле применяется одно устройство, которое опрашивает все блоки управления автомобиля. OBD-II реализована в двух версиях: OBD-IIA и OBD-IIB. Стандартизация OBD-II введена с целью удовлетворения автомобилем жестких требований токсичности, и, несмотря на то, что диагностический разъем предназначался только для передачи данных, связанных с контролем эмиссии, и соответствующих кодов неисправности, большинство автопроизводителей стали использовать разъем OBD-II для диагностики и перепрограммирования всех систем автомобиля. Диагностические коды неисправности OBD-II состоят из 4 символов, которые предваряет буква: P – для двигателя и трансмиссии, B для кузова, C для шасси и U для сети.
Диагностический разъем OBD-II
Стандарт OBD-II имеет стандартизированный интерфейс – 16-контактный (2×8) J1962 разъем. В отличие от разъема OBD-I , который иногда располагался под капотом автомобиля, разъем OBD-II должен находиться в 2 футах (0,61м) от рулевой колонки (за исключением отдельных случаев, но, тем не менее, в зоне досягаемости водителя).
SAE J1962 определяет следующую раскладку контактов разъема:
| 1. На выбор автопроизводителя.
Дженерал Моторс: J2411 GMLAN / SWC / Однопроводная CAN. Фольксваген / Ауди: непостоянный +12В Информирует диагностический сканер о включении зажигания в автомобиле. | 9. — |
| 2. Положительный сигнал шины SAE-J1850 ШИМ и SAE-1850 пер.ШИМ | 10. Отрицательный сигнал шины SAE-J1850 только ШИМ (не SAE-1850 пер.ШИМ) |
| 3. DCL(+) Форд Аргентина, Бразилия (до OBD-II) 1997-2000 г., США, Европа и т.д., Крайслер: шина CCD (+) | 11. DCL(-) Форд Аргентина, Бразилия (до OBD-II) 1997-2000 г., США, Европа и др., Крайслер: шина CCD (-) |
| 4. Масса кузова | 12. — |
5. Масса сигнала | 13. — |
| 6. Высокий уровень CAN (ISO 15765-4 и SAE-J2284) | 14. Низкий уровень сигнала CAN (ISO 15765-4 и SAE-J2284) |
| 7. K-линия ISO 9141-2 и ISO 14230-4 | 15. L-линия ISO 9141-2 и ISO 14230-4 |
| 8. – На выбор автопроизводителя.
Большинство автомобилей BMW: вторая K-линия для систем, которые не являются OBD-II (кузов/шасси/информационная система). | 16. Напряжение АКБ |
EOBD
Стандарт EOBD (Европейская система бортовой диагностики) является европейским эквивалентом OBD-II и используется на всех пассажирских автомобилях категории M1 (до 8 пассажирских мест и полной массой 2500 кг и ниже), зарегистрированных на территории государств-членов ЕС, начиная с 01 января 2001 года для автомобилей с бензиновыми двигателями и с 01 января 2004 года для автомобилей с дизельными двигателями.
Для новых автомобилей стандарт вступил в силу годом ранее, то есть 01 января 2000 года для автомобилей с бензиновыми двигателями и 01 января 2003 года для автомобилей с дизельными двигателями.
Для пассажирских автомобилей полной массой свыше 2500 кг и легких коммерческих автомобилей стандарт начал действовать с 01 января 2002 г. для автомобилей с бензиновыми двигателями, 01 января 2007 г. для автомобилей с дизельными двигателями.
С технической точки зрения EOBD в основном аналогична системе OBD-II, имеет тот же самый диагностический разъем SAE J1962 и протокол передачи данных.
В соответствии с экологическими стандартами Евро V и Евро VI пороговые значения включения оповещения в системе EOBD были снижены по сравнению с предыдущими стандартами Евро III и IV.
Коды неисправности EOBD
Каждый код неисправности EOBD состоит из пяти символов. Буква предшествует четырем цифрам. Она указывает на систему автомобиля, с которой связан данный код, например, трансмиссия. Далее следует цифра 0, если речь идет о стандарте EOBD. Поэтому данный код выглядит как P0xxx.
Следующий символ связан с подсистемой автомобиля.
P00xx – топливная и воздушная системы, дополнительные системы контроля токсичности
P01xx – топливная и воздушная системы
P02xx – топливная и воздушная системы (контур инжекторной подачи топлива)
P03xx – система зажигания, определение пропусков зажигания
P04xx – дополнительные системы контроля токсичности
P05xx – контроль скорости автомобиля и холостого хода двигателя
P06xx – бортовая компьютерная система
P07xx – управление трансмиссией
P08xx – управление трансмиссией
Следующие два символа характеризуют конкретную неисправность в каждой подсистеме.
EOBD2
Термин «EOBD2» является рыночным и используется некоторыми автопроизводителями для описания особенностей, которые отсутствуют в стандартах OBD или EOBD. В этом случае «E» означает расширенный.
JOBD
JOBD представляет собой версию OBD-II для автомобилей, проданных в Японии.
ADR 79/01 и 79/02 (Австралийский стандарт OBD)
ADR 79/01 (стандарт для автомобилей (Австралийский стандарт проектирования 79/01 – контроль токсичности легковых автомобилей) 2005) стандарт Австралии, эквивалентный OBD-II.
Он касается всех автомобилей категорий M1 и N1 с полной массой 3500 кг или ниже, зарегистрированных в Австралии и произведенных, начиная с 01 января 2006 года для автомобилей с бензиновыми двигателями и с 01 января 2007 года для автомобилей с дизельными двигателями.
Для новых автомобилей стандарт вступил в силу годом ранее – 01 января 2005 года для автомобилей с бензиновыми двигателями и 01 января 2006 года для автомобилей с дизельными двигателями.
Стандарт ADR 79/01 был дополнен стандартом ADR 79/02, который ввел более жесткие требования, ограничивающие выбросы автомобилей M1 и N1 с полным весом не более 3500 кг, с 01 июля 2008 года для новых моделей, с 01 июля 2010 года для всех моделей автомобилей .
Данный стандарт имеет аналогичное техническое исполнение как и система OBD-II, он имеет такой же диагностический разъем SAE J1962 и протоколы передачи данных.
OBD-II протоколы
Существует пять протоколов, которые поддерживает интерфейс OBD-II. На большинстве автомобилей использован только один протокол. Зачастую определить протокол, который был использован, можно по раскладке контактов в разъеме J1962:
SAE J1850 ШИМ (широтно-импульсная модуляция — 41,6 кБит/сек, стандарт для Форд Мотор Компании)
контакт 2: Bus+ (Шина +)
контакт 10: Bus– (Шина -)
Высокое напряжение +5 В
Длина сообщения ограничена 12 байтами, в том числе CRC. Используется арбитражная шина с несколькими ведущими, которая относится к «Вероятностным сетевым протоколам канального уровня» с неразрушающим арбитражем (CSMA/NDA)
SAE J1850 VPW (переменная ШИМ — 10,4/41,6 кБит/сек, стандарт Дженерал Моторс)
контакт 2: Bus+ (Шина+)
Шина с низким уровнем ожидания
Высокое напряжение +7В
Пороговое напряжение +3,5 В
Длина сообщения ограничена 12 байтами, в том числе CRC.
Использует CSMA/NDA
Физический уровень идентичен ISO 9141-2
Скорость передачи данных 1,2 до 10,4 кбод
Сообщение может содержать до 255 байт в поле данных
ISO 15765 CAN (250 кБит/сек или 500 кБит/сек). Протокол CAN был разработан компанией Bosch для автомобильного и промышленного секторов экономики. В отличие от других OBD протоколов данный вариант широко распространен за пределами автомобильной промышленности. Он не соответствовал требованиям OBD-II для автомобилей в США до 2003 года. Автомобили, проданные в США в 2008 года, должны оснащаться шиной CAN с данным протоколом.
контакт 6: CAN Высокий уровень
контакт 14: CAN Низкий уровень
Все разъемы OBD-II одинаковы, но отличаются расположением контактов, за исключением контакта 4 («масса») и контакта 16 (питание АКБ).
Диагностическая информация OBD-II
OBD-II обеспечивает доступ к данным ЭБУ (ECU) и представляет собой ценный источник информации для выполнения поиска и устранения неисправностей.
Стандарт SAE J1979 определяет метод запроса диагностической информации и список стандартных параметров, который можно получить от ЭБУ. Каждый параметр имеет адрес или «идентификационный номер параметра», то есть PID, как указано в J1979. Список основных PID, их описание, формулы для преобразования выходных сигналов OBD-II в диагностические единицы измерения, представлены в OBD-II PIDs. Автопроизводителям не требуется использовать все PID, перечисленные в J1979, они могут включить в список параметров собственные PID. PID и информационно-поисковая система (ИПС) предоставляет доступ к рабочим параметрам в режиме реального времени, а также к отмеченным кодам DTC. Список кодов OBD-II DTC, предложенный SAE, указан в таблице кодов OBD-II . Некоторые автопроизводители дополнили систему кодов OBD-II, добавив собственные DTC.
Режим работы
В этом разделе приведены общие сведения о протоколе обмена данными OBD согласно ISO 15031:
Режим $01 используется для идентификации типа привода и вывод текущей информации сканера.
Режим $02 отображает данные статических кадров.
Режим $03 содержит списки «подтвержденных» диагностических кодов неисправности систем снижения токсичности. Он имеет цифровой вид, 4 цифры указывают на неисправность.
Режим $04 используется для удаления диагностической информации. Операция включает в себя удаление подтвержденных/ожидаемых кодов DTC и данных статических кадров.
Режим $05 отображает результат проверки кислородных датчиков.
Предлагается десять кодов диагностики:
$01 пороговое напряжение датчика O2 (при переходе от обогащенной к обедненной смеси)
$02 пороговое напряжение датчика O2 (при переходе от обедненной к обогащенной смеси)
$03 низкое пороговое напряжение датчика при измерении времени переключения
$04 высокое пороговое напряжение датчика при измерении времени переключения
$05 время переключения в мс (при переходе от обогащенной к обедненной смеси)
$06 время переключения в мс (при переходе от обедненной к обогащенной смеси)
$07 минимальное напряжение для тестирования
$08 максимальное напряжение для тестирования
$09 время между сменами напряжения в мс
Режим $06 результаты тестирования систем постоянного и периодического контроля.
Это минимальное, максимальное и текущее значение для каждого устройства периодического контроля.
Режим $07 запрос кодов неисправности систем снижения токсичности после выполнения текущего или последнего ездового цикла. Он позволяет проводить тест «ожидаемых» диагностических кодов неисправности, обнаруженных в текущем или последнем ездовом циклах. Используется техническими специалистами для проверки качества выполненного ремонта или после удаления диагностической информации.
Режим $08 позволяет внешнему диагностическому устройству контролировать работу бортовой системы или компонента системы.
Режим $09 используется для получения информации об автомобиле. Среди прочего информация включает в себя:
VIN (идентификационный номер автомобиля): ID
CALID (калибровки): ID (идентификатор) программы ЭБУ
CVN (верификационный номер): используется для проверки целостности программного обеспечения. Автопроизводитель несет ответственность за метод расчета CVN, например, с использованием контрольных сумм.
Регистраторы параметров
Бензиновый двигатель: нейтрализатор, первичный кислородный датчик, система улавливания паров топлива, система рециркуляции отработанных газов, система изменения фаз газораспределения VVT, система вторичной подачи воздуха, вторичный кислородный датчик.
Дизельный двигатель: нейтрализатор NMHC, нейтрализатор NOx, абсорбер NOx, сажевый фильтр, датчик температуры отработавших газов, система рециркуляции отработанного газа, система изменения фаз газораспределения VVT, управление давлением турбонаддува, топливная система.
Режим $0A содержит список постоянных кодов неисправности. Согласно CARB все диагностические коды, которые включают MIL и сохраняются в ПЗУ, должны регистрироваться как постоянные коды неисправности.
Программные средства для работы с OBD
Существует большое множество разных приборов, которые подключаются к диагностическому разъему OBD для доступа к функциям бортовой диагностики, начиная от самых простых приборов для рядовых пользователей до высокотехнологичных диагностических средств, которые выпускают OEM и устройств телематики.
Мультимарочные сканеры
| Автосканер MaxiDAS DS708 | |
| Автосканер Launch X-431 Master | |
| Автосканер Scantronic 2 |
Предлагается следующий набор сканеров.
- Простые сканеры для считывания/удаления кодов в основном ориентированные на простого потребителя.
- Профессиональные переносные сканеры с расширенными функциональными возможностями, включая:
- доступ к дополнительным функциям диагностики
- выбор параметров определенного ЭБУ
- доступ к другим системам управления, например, системе пассивной безопасности или АБС
- мониторинг в режиме реального времени или графическая интерпретация параметров двигателя для диагностики или настройки
Переносные устройства
Программы для мобильных устройств, например, сотовых телефонов и планшетов позволяют отображать данные OBD-II, получаемые через кабели USB или адаптеры беспроводной связи, подключенные к автомобильному разъему OBD II.
Сканеры на базе ПК
| Автосканер Сканматик 2 USB | |
| Автосканер ELM327 USB | |
| Автосканер KKL USB |
Простой диагностический интерфейс USB KKL, работающий без использования протоколов передачи данных. Интерфейс применяется для настройки уровня сигналов.Сканер на базе ПК преобразует сигналы OBD-II в последовательный набор данных (через USB или последовательный порт) для передачи в ПК и Макинтош. Программа расшифровывает полученные данные и выводит на экран. Наиболее популярные интерфейсы выполнены на базе ELM или STN1110[17] OBD Interpreter ICs, оба совместимы с пятью протоколами OBD-II. Некоторые адаптеры используют J2534 API, это позволяет получать доступ к протоколам данных OBD-II пассажирских и грузовых автомобилей.
Помимо функций сканирования устройства на базе ПК позволяют получить:
Регистраторы данных
| Авторегистратор OBD LOG | |
| Авторегистратор OBD MATRIX | |
| Авторегистратор Launch CRecorder 2 |
Компактный регистратор с возможностью передачи данных на ПК через разъем USB.
Регистраторы позволяют записывать данные в момент исправной работы автомобиля для последующего анализа.
Процесс регистрации включает в себя
- Мониторинг работы двигателя и автомобиля с целью диагностики и регулировки.
- Некоторые страховые компании в США предлагают более низкую стоимость страховки, если установлены регистраторы OBD-II или камеры — и водитель соблюдает правила дорожного движения. Это форма отбора риска
- Контроль за поведением водителя со стороны оператора автопарка.
- Анализ данных черного ящика автомобиля выполняется периодически, автоматически передается третьей стороне по беспроводной системе связи или для судебного разбирательства после происшествия, например, аварии, нарушения ПДД или механической поломки.
- Контроль эмиссии
Большинство штатов США используют OBD-II вместо проверки состава отработавших газов на автомобилях, поддерживающих OBD-II (1996 г.
и позднее). Так как система OBD-II хранит коды неисправности для систем снижения токсичности, сканер может направить запрос бортовой системе и проверить отсутствие кодов неисправностей, а также соответствие автомобиля требованиям экологического стандарта с учетом его модельного года.
В Нидерландах автомобили, выпущенные в 2006 году и позднее, проходят ежегодную проверку токсичности с использованием EOBD.[21]
Дополнительные устройства в автомобиле
Дополнительные устройства в автомобиле установлены помимо заводских устройств и предназначены для информирования водителя о работе систем. В отличие от сканеров устройства используются для диагностики неисправностей, настройки и фоновой записи данных.
Автомобилисты-энтузиасты традиционно устанавливают дополнительные устройства для измерения разрежения во впускном коллекторе и тока АКБ. Интерфейс OBD расширяет возможности для изобретателей, поскольку предоставляет доступ к широкому набору диагностической информации, в том числе мгновенному расходу топлива.
Устройства также выполнены в форме специализированных маршрутных компьютеров, автомобильных ПК, интерфейсов для PDA, смартфонов или блоков навигации Гармин.
Компьютер – это ПК, аналогичное программное обеспечение можно загрузить в сканеры на базе ПК, все зависит от целей использования программы.
Эти системы могут иметь функциональные возможности, которые применяются в других сканерах.
Автомобильная телематика
OBD II предназначена не только для профессионалов и любителей, занимающихся ремонтом автомобиля. Информация OBD II также используется в устройствах телематики, которые осуществляют контроль за движением подвижного состава, топливной экономичности, соблюдения правил ПДД, а также удаленную диагностику и страховку по схеме «Едешь-Платишь». Несмотря на то, что изначально эти цели не преследовались, данные OBD II, в том числе скорость автомобиля, частота вращения вала двигателя, уровень топлива в баке позволяют системам мониторинга (диспетчерским пунктам) с помощью GPS (глобальной системы позиционирования) отслеживать скоростные режимы движения, стоянку с включенным двигателем или превышение оборотов двигателя.
С помощью OBD II DTC компания моментально получает информацию о том, что в одном из автомобилей возникла проблема с двигателем. Интерпретация кода позволяет определить характер проблемы. OBD II также используется для блокирования мобильных телефонов при движении автомобиля и записи данных для страховых компаний.
Стандарты
SAE по OBD-II
J1962 – описывает требования к разъему для интерфейса OBD-II
J1850 – описывает протокол последовательной передачи данных. Существует два варианта протокола – 10,4 кБит/с (однопроводная система, переменная ШИМ) и 41,6 кБит/с (двухпроводная система, ШИМ). В основном используется автопроизводителями США, также известен как PCI (Крайслер, 10,4K), класс 2 (Дженерал Моторс, 10,4K) и SCP (Форд, 41,6K)
J1978 – устанавливает минимальные требования к сканерам OBD-II
J1979 – определяет стандарты для режимов диагностики
J2012 – описывает стандартные коды неисправности с объяснением
J2178-1 – устанавливает стандарты для форматов пакетных сообщений и физическую адресацию
J2178-2 – выдает описание параметров
J2178-3 – определяет стандарты идентификаторов для кадров сообщений с однобайтовыми заголовками
J2178-4 – устанавливает стандарты для сообщений с трехбайтовыми заголовками*
J2284-3 — описывает 500K CAN физический уровень и уровень передачи данных
J2411 – описывает протокол GMLAN (однопроводный CAN), который применяется в новых автомобилях Дженерал Моторс.
В разъеме OBD выводится на контакт 1 для новых автомобилей Дженерал Моторс
J1939 – описывает протокол передачи данных в системах автомобилей высокой грузоподъемности
Ошибка чтения данных коннектором Connect-IT. — Обсуждения пользователей Service Manager
Здравствуйте,
Я хотел бы использовать соединитель ServiceCenter/Service Manager в Connect-It для чтения данных (продукции документов) из SM. Я сталкиваюсь с проблемой, когда коннектор создает определенное количество документов, он завершается следующей ошибкой:
null[
Вот все строки из журнала CIT, касающиеся этой ошибки:
21.06.2020 10:43:45.875 0 16 [(entitiesDst) entity] Идентификатор используемого документа ‘entitiesDst’, имя документа ‘entities’.
21.06.2020 10:43:45.882 0 16 Запрос=\n
21.06.2020 10 :43:45.980 0 16 Значение кода ответа равно 500:
21.06.2020 10:43:46.048 0 16 Запрос=\n
21.06.2020 10:43:46.120 0 16 Response=
peregrine.com/PWS\»/ >\n
21.06.2020 10:43:46.204 0 1 (0) null[
21.06.2020 10:43:46.286 0 16 Запрос=\n
2020/06/21 10:43:46.378 0 16 Значение кода ответа 500:
21/06/2020 10:43:46.461 0 16 Запрос=\n
xmlsoap.org/soap/envelope/\»>
21.06.2020 10:43:46.544 0 16 Response=
21.06.2020 10:43:46.625 0 2 null[
2020/06 /21 10:43:46.705 0 4 Повторите действие…
21.06.2020 10:43:46.775 0 16 Значение кода ответа 500:
21.06.2020 10:43:46.855 0 16 Запрос=\n
xmlsoap.org/soap/envelope/\»>
21.06.2020 10:43:46.917 0 16 Response=
21.06.2020 10:43:46.970 0 1 (0) null[
21.06.2020 10:43:47.041 0 1 (0) java.lang.Exception: null[
21.
06.2020 10:43:47.105 1 16 на com.hp.ov.cit .connector.smc.SMClient.closeQuery (SMClient.java:638)
21.06.2020 10:43:47.147 1 16 на com.hp.ov.cit.connector.smc.SMRecordSet.close (SMRecordSet.java: 146)
21.06.2020 10:43:47.198 1 16 на com.hp.ov.cit.connector.smc.recordset.SmcRecordsetProxy.close (SmcRecordsetProxy.java:48)
Также есть разница в количестве документов, это зависит от того, какой коннектор их потребляет. Например, если я использую текстовый соединитель с разделителями для записи данных в текстовый файл, ошибка возникает после создания 3100 документов. Когда я использую коннектор «Управление как услуга» для записи данных непосредственно в SMAX, ошибка возникает каждый раз после создания 500 документов.
Есть ли какие-либо параметры ограничения, которые необходимо изменить в ConnectIt, или почему именно эти значения могут вызвать ошибку?
Спасибо за любую помощь
Вы не авторизованы для чтения записей активности. Пользователь, под которым вы входите в Google Workspace, должен быть администратором.
salesforce.com:443 
Узнать больше
