Мережевий інтерфейс для BMW

У даній статті мова буде про локальної низькошвидкісний мережі взаємодії блоків управління автомобіля 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 символів. Формат кадру я намалював нижче:

image

Тут TX ID — адресу відправника, 1 символ;
LEN — розмір кадру з вирахуванням двох перших символів, 1 символ;
RX ID — адреса одержувача, 1 символ;
DATA — корисне навантаження, 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 — bus кадри таким способом хороший варіант. Драйвер tty складний і доступ до низькорівневої його частини можна отримати через лінію дисципліни. Так робиться в SLIP і slcan, так вчинив і я, написавши драйвер slibus. Коли через tty пристрій активізується створена лінія дисципліни, сисема з'явиться мережеве пристрій ibusN, де N — 0,1,2… Що б було зрозуміліше, наведу схему. У ній відзначені зеленим квадрати, функції яких виконує модуль ядра slibus.

image

Помаранчевим кольором відзначено функціонал модуля мережевого протоколу. Знову ж таки не став винаходити велосипед і за аналогією модулів can і can_raw створив модуль af_ibus_raw. При завантаженні цей модуль реєструє нове сімейство протоколів PF_IBUS і в ньому ж реалізований RAW-сокет для повного доступу до кадру. За допомогою виклику setsockopt можна включити фільтр прийнятих повідомлень по ідентифікаторах відправника і одержувача. За замовчуванням сокет приймає всі повідомлення з шини.

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

А тепер давайте подивимося, як це все працює. Завантажимо модулі ядра, ініціалізуємо лінію дисципліни під номером, що відповідає slibus, і піднімемо мережевий інтерфейс ibus0. Команда ifconfig в терміналі покаже нам щось подібне:



Як бачимо мережевий інтерфейс успішно запущений і має статистику трафіку. Перш ніж зробити скріншот, я спеціально поганяв дані по інтерфейсу. Користуюся зробленими драйверами кілька місяців, збоїв не спостерігалося. Але є недоробки, які ще не усунув. До них повернуся пізніше, а поки працюю над додатками по мірі вільного часу.

Сильні сторони даного підходу полягають у ряді аспектів. Програми запущені в операційній системі мають повноцінний доступ до шини і через неї ж взаємодіють один з одним. Припустимо в комплектації мого автомобіля відсутній CD-чейнджер. Мені достатньо написати додаток емулює це пристрій. При цьому воно буде відтворювати різні формати файлів і онлайн радіо. Потім я захочу доукомплектувати телефонним модулем, якого у мене немає або не подобатися штатний. Я просто напишу ще програмку, яка по блютуз підключається до смартфону і виконає введення-виведення голосу та інформації в штатні місця. Або створити щось своє, наприклад гра світловими приладами e-light. Таким чином програми розробляються незалежно один від одного, можуть встановлюватися і видалятися за бажанням власника.

На малюнку нижче показана робота програм ibusdump і ibussend. Що роблять ці команди думаю зрозуміло з назви. Останні два рядки ibusdump показують, що по шині передавалися повідомлення, які я відправив через ibussend.



На цьому зупинюся, мабуть. Про те, що передається в корисному навантаженні кадру і для яких блоків управління я розповім іншим разом.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.