В этой статье речь пойдет о локальной низкоскоростной сети взаимодействия блоков управления автомобиля BMW – I/K-bus. Точнее, о том, как с ним могут взаимодействовать Linux-приложения.
Я проиллюстрирую созданный мною вариант на картинках.
Итак, передо мной стояла задача расширить функциональные возможности моего автомобиля в области информационно-развлекательной системы.
Я просто очень этого хотел.
Машина хорошая, но старая.
Он был создан в то время, когда даже mp3 не имел широкого распространения.
Поэтому он лишен многих современных удобств.
Кроме того, у меня в голове есть дополнительные идеи, реализуя которые, я могу подчеркнуть свою индивидуальность.
Информационно-развлекательная система работает на устройствах на базе контроллеров со встроенными программами.
Здесь я буду называть эти устройства блоками управления.
Каждый такой блок управления несет свою функциональную нагрузку, будь то поддержание температуры в салоне, регулировка положения сидений, воспроизведение музыки и видео, навигация и т. д. Весь этот набор блоков управления должен взаимодействовать между собой, управляться со стороны водителя.
и пассажирские сиденья и передают диагностические данные.
Для этой цели была разработана сеть I-bus. Впоследствии появились технически идентичные сети K-bus и их объединение I/K-bus. Архитектура сети I-bus выполнена по схеме «общая шина», т.е.
импульсы данных от узлов (блоков управления) передаются по обычному медному проводу, соединенному в одной точке.
Следовательно, узлы должны использовать общую среду передачи и передавать данные по очереди.
Я не знаю, как определяется эта очередь или приоритет, я думаю шина просто прослушивается на предмет занятости и с учетом защитного интервала и незанятой шины принимается решение о передаче.
В «тихом» состоянии уровень потенциала на шине относительно кузова составляет от 7 В до напряжения питания автомобиля.
При подаче на шину доминантного бита потенциал падает до 2 В или ниже.
Битовая скорость взаимодействия между узлами постоянна и составляет 9600 бит/с.
Рисунок знаком по UART. Но есть сходство не только в скорости передачи, но и формат символов в I-bus соответствует одному из вариантов, доступных в UART. Символ состоит из 11 бит: стартовый бит, 8 бит данных, бит четности, стоповый бит. Эти функции позволяют физически подключаться к шине через интерфейсы UART или RS-232. Вам останется только позаботиться о преобразовании уровней сигнала с помощью простой схемы или готового преобразователя.
Для этой цели вполне подойдет известный в диагностических интерфейсах адаптер k-line. На физическом уровне они полностью совместимы.
Кстати, я им пользуюсь.
Я рассказал о физическом уровне сети I-bus в целом, теперь кратко опишу канальный уровень, если следовать последовательности многоуровневой модели OSI. Так будет логичнее.
Как я упоминал ранее, при передаче используется общая среда, которую необходимо разделить по времени и передавать данные разным получателям.
Здесь можно провести аналогию с Ethernet — данные передаются в кадрах, которые содержат адрес отправителя, адрес получателя, полезную нагрузку (данные) и контрольную сумму.
Фрейм не имеет фиксированного размера и составляет от 5 до 37 символов.
Я нарисовал формат кадра ниже: 
Здесь TX ID — адрес отправителя, 1 символ;
LEN — размер кадра минус первые два символа, 1 символ;
RX ID — адрес получателя, 1 символ;
ДАННЫЕ – полезная нагрузка, 1 – 33 символа;
CK SUM – контрольная сумма, 1 символ.
Корректность полученного кадра определяется символом контрольной суммы.
Отправитель не проверяет правильность полученного кадра получателем.
Возможно, это делается на уровне получения собственного кадра.
Если на шине не было коллизий или других сбоев, то отправитель корректно получит собственный кадр и не будет пытаться отправить его повторно.
По информации, которую я нашел во Всемирной паутине, сказано, что отправитель ждет 100 мс положительного получения от получателя.
Увы, на практике я этого не видел.
Возможно, это используется для особо важных сообщений и в протоколах более высокого уровня.
То, что включено в полезную нагрузку кадра, принадлежит протоколу следующего уровня.
Работу с этим протоколом лучше делегировать на уровень приложения и работать с ним в приложениях.
В очередной раз ищу приложение для сетевой связи I/K-bus в операционной системе на базе ядра Linux. Функции блоков управления будут выполнять приложения в пользовательском пространстве.
Организовать взаимодействие приложений внутри операционной системы несложно; существуют механизмы межпроцессного взаимодействия (IPC).
Но основная задача – связать их с процессами блоков управления автомобиля.
Для примера обратимся к более известному варианту сети взаимодействия контроллера – CAN. В Linux эта технология развивается в двух проектах: SocketCAN и can4linux. Первый проект основан на драйвере сетевого устройства и протоколах, которые выполняют предварительную обработку кадров и связывают сетевое устройство с интерфейсом сокета.
Второй вариант основан на символьном устройстве; Подробностей реализации этого проекта я не знаю, так как не работал с ним.
Но я думаю, что аналогом can4linux для I/K-bus является драйвер tty. Достаточно настроить скорость и формат символов последовательного порта и путем чтения/записи файла ttyS данные будут приниматься/отправляться на шину.
Конечно, если он подключен к последовательному порту с помощью переходника.
Вариант SocketCAN мне показался более привлекательным, и я пошел по тому же пути.
Я объясню почему.
Драйвер состоит из двух независимых частей: сетевого устройства и сетевого протокола.
Сетевое устройство решает вопросы взаимодействия с оборудованием и множественного доступа, а модуль сетевого протокола занимается фильтрацией сообщений и взаимодействием с пользовательскими процессами.
Приложения подключаются к сети I/K-bus через сокеты, при этом устраняются задачи множественного доступа и фильтрации.
В принципе, можно делегировать фильтрацию и множественный доступ какому-нибудь серверу, подключенному к tty-устройству, и не лезть в ядро.
В целом да, но без межпроцессорной связи всё равно не обойтись, а это, как вариант, тот же сокет. Кроме того, сетевой стек Linux решает множество проблем с очередями сообщений, которые придется реализовать на сервере.
И ко всему этому, использование сетевого устройства гармонично вписывается в философию администрирования операционной системы.
Например, с помощью команды ifconfig вы можете просмотреть состояние интерфейса, остановить или запустить его.
Драйвер сетевого устройства для I/K-bus я сделал на основе slcan, который основан на SLIP. Я не видел тех дней, когда IP-пакеты передавались между компьютерами через последовательный порт. Они еще могут передаваться таким способом, но это не актуально.
Но передача кадров I/K-шины таким способом является хорошим вариантом.
Драйвер tty сложен, и доступ к его низкоуровневой части можно получить через дисциплину линии.
Это то, что делается в SLIP и slcan, и это то, что я делал, когда писал драйвер slibus. При активации созданной линейной дисциплины через tty-устройство в системе появится сетевое устройство ibusN, где N равно 0,1,2. Чтобы было понятнее, приведу схему.
В нем зеленым цветом отмечены квадраты, функции которых выполняет модуль ядра slibus. 
Функциональные возможности модуля сетевого протокола отмечены оранжевым цветом.
Опять же, я не стал изобретать велосипед и по аналогии с модулями can и can_raw создал модуль af_ibus_raw. При загрузке этот модуль регистрирует новое семейство протоколов PF_IBUS, а также реализует сокет RAW для полнокадрового доступа.
Вызвав setockopt, вы можете включить фильтр полученных сообщений по идентификаторам отправителя и получателя.
По умолчанию сокет принимает все сообщения от шины.
Надо сказать, что есть одна неприятность, и она заключается в том, что для возможности загрузки этих модулей необходимо патчить ядро.
Теперь посмотрим, как все это работает. Загрузим модули ядра, инициализируем линейную дисциплину номером, соответствующим slibus, и поднимем сетевой интерфейс ibus0. Команда ifconfig в терминале покажет нам что-то вроде этого: 
Как видите, сетевой интерфейс успешно запущен и имеет статистику трафика.
Прежде чем сделать скриншот, я специально прогнал данные через интерфейс.
Я использую драйверы, которые сделал, уже несколько месяцев, и у меня не возникло никаких проблем.
Но есть недостатки, которые до сих пор не устранены.
Я вернусь к ним позже, а пока работаю над приложениями, так как есть свободное время.
Сильные стороны этого подхода заключаются в ряде аспектов.
Приложения, работающие в операционной системе, имеют полный доступ к шине и взаимодействуют через нее друг с другом.
Допустим, в моей машине нет CD-чейнджера.
Все, что мне нужно сделать, это написать приложение, эмулирующее это устройство.
При этом он будет воспроизводить различные форматы файлов и онлайн-радио.
Потом я захочу добавить телефонный модуль, которого у меня нет или не нравится стандартный.
Я просто напишу еще одну программу, которая будет подключаться к смартфону по Bluetooth и осуществлять ввод/вывод голоса и информации в штатные места.
Или создать что-то свое, например, поиграв с электроосветительными приборами.
Таким образом, приложения разрабатываются независимо друг от друга и могут быть установлены и удалены по желанию владельца.
На рисунке ниже показана работа программ ibusdump и ibussend. Что делают эти команды, думаю, понятно из названия.
Последние две строки ibusdump показывают, что сообщения, которые я отправлял через ibussend, передавались по шине.
Пожалуй, я остановлюсь здесь.
О том, что передается в кадре полезной нагрузки и для каких блоков управления, я расскажу в другой раз.
Теги: #i-bus #can #bmw #Разработка систем связи
-
Фильтровать По Динамическим Атрибутам
19 Oct, 24 -
Все Идет По Плану
19 Oct, 24 -
Кто Такой Ux-Дизайнер И За Что Ему Платят?
19 Oct, 24 -
Последние Обновления
19 Oct, 24 -
Сравнительный Анализ Корзин Покупок
19 Oct, 24
