Читаем информацию с автомобиля с помощью Arduino по BT
Добрый день всем.
Хочу рассказать вам о своей поделке, с помощью которой я читаю данные с датчиков автомобиля и коды ошибок. Заранее скажу, что мой вариант наверное подойдет только владельцам стареньких хонд.
Изначально делал все это для себя, что бы можно было считать ошибки когда будет нужно и вообще посмотреть что там твориться. Как раз тогда ошибка кошмарила и можно было протестировать роботу данного творения)
И так в состав входит:
— Автомобиль, в моем случае Хонда с OBD1 могзом =)
— Arduino Nano, сойдет и копия
— Блютуз модуль HC-05
— Проводочки
— Стабилизатор L7809CV3
— Телефон или планшет на Android или экран к Ардуино.
Подключаем все это, по такой схеме:
TX и RX (1 и 2) — соединяем вместе и подключаем подключаем к ножке K-line на мозгах.
Питание подключается к пинам VIN и GND (30 и 29) через стабилизатор L7809CV3.
от второго пина GND(4) будет 2 проводка. Один идет к земле на мозгу. Второй на блютуз.
Блютуз модуль HC-05 подлючается 4я проводами. Vcc в +5v Arduino. Gnd в Gnd. Tx в D11. Rx в D10.
Я решил все поместить в коробочку с выключателем, и подключать когда мне нужно будет. Вот сама коробочка(да, паяльщик я не очень.):
Дальше было написано приложение на Андроид. Демка, которая будет по ссылке ниже, выглядит так:
Сейчас решил сделать не много редизайн приложения, в будущем его может выложу тоже. Новое выглядит вот так:
Arduino-OBD2 Ч.1. Концепция и используемые материалы.
Дорогие друзья, всем привет!
Уже прошло пол года с тех пор, как я приобрел стартер-кит Arduino.
В комплекте было все, чтобы потренироваться в программировании в данной среде (надо отметить, что среда эта — практически литературный английский. Я немного владею Pascal и VB, по этому с логикой упрощенного языка C++ особых проблем не возникло) Проблемы возникли с тем, что я не знаю куда применить все это дело на практике, да так, что получилось бы дело, а не бессмысленный опыт на брэдборде. Сегодня утром, сидя в машине и лязгая зубами от холода я понял, чего мне не хватает в зимнее время в данном автомобиле — датчика температуры ОЖ, точнее датчик то есть, но индикации его нет. (Да, я знаю, что можно вывести на РТ6 инфо о температуре ОЖ, но поползет управление экранами на приборной панели и кроме того, будет отображаться ложная информация о датчиках давления воздуха в шинах) Да и вообще — руки чешутся поковыряться с этим LEGO для бородатых дядек.
Короче, решил запилить свой экран с отображением температуры ОЖ, который будет подключаться к разъему OBDII. Старт положен.
Для начала о концепции:
Существуют уже готовые решения, Такие как carduino и подобные, но стоят они дорого и смысла в них особого нет.
У меня валяется ELM327 BT, исключив модуль синезуба можно получать и передавать данные непосредственно по serial.
Ардуино прекрасно переваривает данную инфу с помощью уже готовой библиотеки ArduinoOBD.
Вот одни из самых ходовых PID которые можнополучить:
PID_RPM – Engine RPM (rpm)
PID_ENGINE_LOAD – Calculated engine load (%)
PID_COOLANT_TEMP – Engine coolant temperature (°C)
PID_ENGINE_LOAD – Calculated Engine load (%)
PID_ABSOLUTE_ENGINE_LOAD – Absolute Engine load (%)
PID_TIMING_ADVANCE – Ignition timing advance (°)
PID_ENGINE_OIL_TEMP – Engine oil temperature (°C)
PID_ENGINE_TORQUE_PERCENTAGE – Engine torque percentage (%)
PID_ENGINE_REF_TORQUE – Engine reference torque (Nm)
PID_INTAKE_TEMP – Intake temperature (°C)
PID_INTAKE_PRESSURE – Intake manifold absolute pressure (kPa)
PID_MAF_FLOW – MAF flow pressure (grams/s)
PID_BAROMETRIC – Barometric pressure (kPa)
PID_SPEED – Vehicle speed (km/h)
PID_RUNTIME – Engine running time (second)
PID_DISTANCE – Vehicle running distance (km)
PID_THROTTLE – Throttle position (%)
PID_AMBIENT_TEMP – Ambient temperature (°C)
PID_CONTROL_MODULE_VOLTAGE – vehicle control module voltage (V)
PID_HYBRID_BATTERY_PERCENTAGE – Hybrid battery pack remaining life (%)
Вобщем, как можно понять — это практически все параметры, которые может выцыганить любой нештатный БК. Казалось бы его и купить, но так жить скучно.
Собственно пока так. Надеюсь, что эта тема будет интересна и мы вместе запилим народный БК — возможности то почти неограничены, хочешь вспышку, хочешь писчик по скорости и т.п. — вариантов массы с открытым исходным кодом. я в свою очередь все движения буду описывать в БЖ.
Update! Замылил куда-то свой ELM, заказал новый, еще более компактный по этому потихоньку накидываю скетч и рисую общую концепцию:
Если все будет ок, закажу Arduino nano и размещу в компактном корпусе.
Хакаем CAN шину авто. Виртуальная панель приборов
В первой статье «Хакаем CAN шину авто для голосового управления» я подключался непосредственно к CAN шине Comfort в двери своего авто и исследовал пролетающий траффик, это позволило определить команды управления стеклоподъемниками, центральным замком и др.
В этой статье я расскажу как собрать свою уникальную виртуальную или цифровую панель приборов и получить данные с любых датчиков в автомобилях группы VAG (Volkswagen, Audi, Seat, Skoda).
Мною был собран новый CAN сниффер и CAN шилд для Raspberry Pi на базе модуля MCP2515 TJA1050 Niren, полученные с их помощью данные я применил в разработке цифровой панели приборов с использованием 7″ дисплея для Raspberry Pi. Помимо простого отображения информации цифровая панель реагирует на кнопки подрулевого переключателя и другие события в машине.
В качестве фреймворка для рисования приборов отлично подошел Kivy для Python. Работает без Иксов и для вывода графики использует GL.
CAN сниффер из Arduino Uno
Чтобы послушать, что отправляет VCDS в CAN шину я собрал сниффер на макетке из Arduino и модуля MCP2515 TJA1050 Niren.
Схема подключения следующая:
Для прослушивания трафика использовал анализатор CanHackerV2 и прошивку arduino-canhacker для Arduino, которая реализует API совместимое с этой программой. Прошивка в гите https://github.com/autowp/arduino-canhacker.
CanHackerV2 позволяет смотреть пролетающий трафик, записывать и проигрывать команды с заданным интервалом, что очень сильно помогает в анализе данных.
Подслушиваем запросы с помощью диагностической системы VAG-COM (VCDS)
Описание VCDS с официального сайта ru.ross-tech.com:
Программно-аппаратный сканер VCDS предназначен для диагностики электронных систем управления, устанавливаемых на автомобилях группы VAG. Доступ ко всем системам: двигатель, ACP, АБС, климат-контроль, кузовая электроника и т.п., считывание и стирание кодов неисправностей, вывод текущих параметров, активация, базовые установки, адаптация, кодирование и т.п.
Подключив сниффер к линиям CAN_L и CAN_H в диагностическом шнурке я смог увидеть какие запросы делает VCDS и что отвечает авто.
Особенность авто группы VAG в том, что OBD2 разъем подключен к CAN шине через шлюз и шлюз не пропускает весь гуляющий по сети трафик, т.е. подключившись в OBD2 разъем сниффером вы ничего не увидите. Чтобы получить данные в OBD2 разъёме нужно отправлять шлюзу специальные запросы. Эти запросы и ответы видно при прослушивании трафика от VCDS. Например вот так можно получить пробег.
В VCDS можно получить информацию почти с любого датчика в машине. Меня в первую очередь интересовала информация, которой вообще нет на моей приборке, это:
Разработка панели приборов на основе Raspberry Pi и 7″ дисплея
В качестве аппаратной части я выбрал Raspberry Pi. Была идея использовать Android планшет, но показалось, что на Raspberry Pi будет проще и быстрее. В итоге докупил официальный 7″ дисплей, и сделал CAN шилд из модуля TJA1050 Niren.
OBD2 штекер использовал от старого ELM327 адаптера.
Используются контакты: CAN_L, CAN_H, +12, GND.
Тесты в машине прошли успешно и теперь нужно было все собрать. Плату дисплея, Raspberry Pi и блок питания разместил на куске черного пластика, очень удачно подобрал пластмассовые втулки, с ними ничего не болтается и надежно закреплено.
Местом установки выбрал бардачок на торпедо, которым я не пользуюсь. По примеркам в него как раз помещается весь бутерброд.
Напильником довел лист черного пластика до размера крышки бардачка, к нему прикрепил бутерброд и дисплей. Для прототипа сойдет, а 3D модель с крышкой для дисплея и всеми нужными крепежами уже в разработке.
Софт панели приборов на Python и Kivy (UI framework)
Параллельно со сборкой самой панели приборов я вел разработку приложения для отображения информации с датчиков. В самом начале я не планировал какой либо дизайн.
Первая версия панели приборов
По мере разработки решил визуализировать данные более наглядно. Хотел гоночный дизайн, а получилось, что-то в стиле 80-х.
Вторая версия панели приборов
Продолжив поиски более современного дизайна я обратил внимание какие цифровые приборки делают автопроизводители и постарался сделать что-то похожее.
Третья версия панели приборов
Ранее, я никогда не разрабатывал графические приложения под Linux поэтому не знал с чего начать. Вариант на вебе простой в разработке, но слишком много лишних компонентов: иксы, браузер, nodejs, хотелось быстрой загрузки. Попробовав Qt PySide2 я понял, что это займет у меня много времени, т.к. мало опыта. Остановился на Kivy — графический фреймворк для Python, простой в понимании с полной библиотекой графических элементов и дающий возможность быстро создать мобильный интерфейс.
Kivy позволяет запускать приложение без Иксов, прямо из консоли, в качестве рендера используется OpenGL. Благодаря этому полная загрузка системы может происходить за 10 секунд.
Алгоритм работы следующий, используется 3 потока:
Проект цифровой панель приборов открытый. Рад буду предложениям и комментариям!
Видео работы цифровой панели приборов на базе Raspberry Pi
Приложение на телефон Виртуальная панель приборов
Для телефона написал приложение — виртуальная панель приборов, данные от машины передаются через ELM327 Wi-Fi адаптер. Адаптер подключается в OBD2 разъем, делает запросы по CAN шине и возвращается ответы в приложение по Wi-Fi.
Приложение VAG Virtual Cockpit уже в AppStore. Пока, что только под iPhone/iPad, но Android версия планируется. Приложение решил сделать платным с минимальной символической стоимостью.
Если есть желание поддержать проект, то вот ссылка на приложение, принимаю любые замечания и предложения!
VAG Virtual Cockpit
Разъем диагностики 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, которые уже используются в транспортных средствах и доступны для широкого применения.
На сегодня, интересным и очень перспективным решением автомобильного IoT, является платформа Open Connected Car компании Mojio. Эта платформа с открытым интерфейсом (API) предоставляет облачный сервис для «подключенных» авто и уже доступны коммерческие предложения. Например, телекоммуникационный гигант Т-Mobile, на базе этой платформы, предоставляет сервис SyncUP DRIVE. Это программно-аппаратное решение на базе портативного устройства, подключаемого к автомобилю через разъем диагностики OBD-II, и соответствующее мобильное приложение. Благодаря такому подходу можно эффективно выполнять непрерывный мониторинг параметров работы своего автомобиля и в любой момент времени получать его текущее месторасположение. Приложение может рассказать о стилях вождения, предупредить о профилактическом обслуживании, а также уведомить владельца о проблемах с транспортным средством. Кроме того, SyncUP DRIVE разворачивает в автомобиле точку доступа Wi-Fi, используя доступ по высокоскоростному протоколу мобильного стандарта LTE.
The Open Connected Car Platform – Mojio
Для подключения к автомобилю используется стандартный диагностический разъем OBD-II. Большинство серийных автомобилей, выпущенных после 1996 года, уже оснащены таким разъемом. Хотя такой разъем диагностики и стандартизирован, но в нем поддерживаются сразу несколько протоколов различных систем управления двигателем (физически используются разные контакты на разъеме), которые должен «знать» коммуникационный модуль IoT. Соответственно в разных марках автомобилей могут быть разные внутренние шины получения данных диагностики с бока управления двигателя (ECU — Electronic control unit). Для работы с сервисом SyncUP DRIVE предлагается решение на основе модуля VM6200S компании ZTEWelink.
Модуль 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. Дальше можно рассмотреть сценарии использования агрегированной информации, полученной от автомобилей, применять различные методики обработки Big Data, и при этом не нужно забывать о перспективах объединения таких данных с информацией от инфраструктуры «умных» дорог. Но прежде чем заняться обработкой данных, нужно их сначала получить, поэтому в этой публикации уделим основное внимание аппаратной составляющей реализации сценариев работы на уровне диагностического разъема OBD-II.
Так или иначе, но все ранее рассмотренные решения – это более совершенные промышленные изделия, по сравнению с обычным устройством считывания кодов диагностики на базе микросхемы ELM327 канадской компании Elm Electronics. ELM327 – это универсальный преобразователь протоколов, используемых в диагностических шинах автомобилей, в последовательный протокол типа RS-232.
Структурная схема микросхемы ELM327 v2.2 – Elm Electronics
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
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, так же проблема парковок, поиска свободных мест на стоянке, и многое-многое другое.
Надеемся, что идея этой публикации достигнута – в одном месте собраны материалы по работе с диагностическим разъемом OBD-II, как на уровне простого считывания кодов неисправностей, так и эмуляции физического подключения к автомобилю. Также надеемся на комментарии читателей. В завершении хочется отметить, что рассмотрены лишь некоторые вопросы разработки устройств Connected Car, но «за кадром» остались многие технологии, которые, так или иначе, превращают современный автомобиль в устройство IoT и делают поезки более комфортными и безопасными. Разумеется мы будем возвращаться к этим темам в наших будущих публикациях.