„Software-defined Vehicle (SWdV)“ и ефектите върху бордовата мрежа

От домейнова към зонова архитектура – Software-defined Vehicle (SWdV) и изискванията към проводниците за данни на бъдещето

Когато четете специализирани автомобилни статии, в момента има два термина, които се появяват отново и отново. От една страна четем постоянно за т. нар. „Зонова архитектура“, а в тази връзка също и за „Software-defined Vehicle (SWdV)“.

За какво се отнасят тези понятия? Как ще се отразят те на бъдещите поколения превозни средства? Точно с тези въпроси се занимаваме в тази статия от блога.

Поглед в миналото: Сложно окабеляване и голямо тегло

За какво се отнасят понятията „Зонова архитектура и „Software-defined Vehicle (SWdV)“? Как ще се отразят те на бъдещите поколения превозни средства? За да можем да отговорим на въпросите, нека направим едно малко пътешествие в миналото. Първата форма на топология на бордова мрежа е наречена „разделена“ или „модулна архитектура“. Всички сензори и изпълнителни механизми са свързани поотделно и директно към контролер. Всеки сензор или изпълнителен механизъм има необходимата интелигентност за функцията и само управляващи сигнали и вече обработени измервателни сигнали се прехвърлят към контролерите чрез проводници и шинни системи (обикновено Lin- или Can-bus). Във всеки автомобил са инсталирани няколкостотин сензора и до сто контролера. Отделните проводници достигат дължина до 16,5 m. В резултат на това не е необичайно общата дължина на проводниците в автомобила бързо да надхвърли границата от километър. Резултатът е много сложно окабеляване и голямо тегло на кабелния сноп.

модулна архитектура

Всеки от контролерите трябва да бъде програмиран със софтуер (фърмуер), който е изключително специфичен за функционалността.
Актуализацията на фърмуера обикновено може да се прилага само директно върху устройството със специален кабел за програмиране. Това прави посещението в специализиран сервиз абсолютно необходимо и актуализации се извършват само в много редки случаи.

Последващото разширяване на функциите на автомобила с допълнителни функции се оказва много трудно, ако не и невъзможно. За всяка функция трябва да се прокара поне един допълнителен проводник през автомобила, за да се свърже с контролера. Често e необходима актуализация на фърмуера на контролера, за да се поддържа новата функция. Така усилията бързо надхвърлят желаната полза.

С нарастващия брой функции на автомобила, включително в областта на безопасността и комфорта, границите на този тип окабеляване бързо са достигнати.

Това е и началото на „Домейновата архитектура“.

Текущо равнище на техническо развитие Домейновата архитектура

За разлика от „модулната архитектура“, домейновата архитектура следва подхода за структуриране на сензорите и изпълнителните механизми според техните функции и задачи (домейн). Дефинирани са различни функционални домейни, като задвижване, комфорт или инфотейнмънт. Всеки от тях се следи и управлява от контролер от по-високо ниво, домейн контролер (DCU: Domain Control Unit). Връзката към сензора/изпълнителния механизъм може да се осъществи чрез нископроизводителна шинна връзка (напр. Lin- или Can-bus). Самите DCU са свързани към мощна и ориентирана към по-лесно сервизиране мрежа, така наречения гейтуей (напр. Ethernet). По този начин преоборудването с допълнителен домейн или DCU с нова функция, като напр. ADAS (Advanced Driver Assist System), е възможно по всяко време без никакви проблеми

домейнова архитектура

Недостатъкът на тази технология обаче бързо става очевиден, когато функциите на даден домейн не могат да бъдат физически инсталирани на едно и също място в автомобила.
Това от своя страна води до дълги проводници от DCU до сензора или изпълнителния механизъм.
Функцията „Мигач“ може да се даде като лесен пример за това: Най-малко 6 светлини за мигачите трябва да бъдат свързани в различни ъгли на автомобила, но всички те се управляват от DCU. Този тип топология на автомобила в момента все още е най-актуалното равнище на техническо развитие!

В момента обаче автомобилният свят е в процес на изключителна промяна.
В допълнение към замяната на двигателите с вътрешно горене с алтернативни задвижвания, мегатенденцията „автономно шофиране“ завладява цялата индустрия, която изисква нови концепции за бордовата мрежа на утрешния ден.

Бордовата мрежа на бъдещето: Зонова архитектура и Software-defined Vehicle

 Домейновата архитектура със сигурност има някои предимства. Въпреки това, за да можем да се справим със сложността на съвременните превозни средства и да можем да покрием бъдещите изисквания, е необходим различен подход: зоновата архитектура.

При зонален подход (зонова архитектура), за разлика от домейн-ориентирано решение, функциите са подредени според позицията им в автомобила, а не според тяхната задача.
В обикновен автомобил би могло да има само четири зони, по една на всеки ъгъл на автомобила. Всички устройства в дадена физическа зона се управляват от зонален контролер или зонален шлюз, съотв. ECU (Electronic Control Unit). Тези зонални контролери на свой ред са свързани към централен процесор чрез Backbone връзка (високоскоростна връзка за данни).

Всички задачи в дадена физическа зона, които се наблюдават от устройство за зонално управление, се присвояват на тази зона. Осветлението, сензорите за изображение, мигачите, спирачките, кормилното управление, окачването и др. могат да бъдат обединени в една обща зона.

зонална архитектура

В допълнение към опростяването на окабеляването, модулността и гъвкавостта играят много важна роля, така че предимствата на това решение да могат да се използват напълно.

Тук модулността означава, че различни задачи могат да се реализират с един и същ хардуер (напр. идентични ECU).

Гъвкавостта е способността да се извършват актуализации, корекции на грешки, конфигурации, а също и разширения без много усилия за водача. С така наречената функция „Over the Air“ е възможно тези действия да се извършват чрез връзка с интернет, без да се налага да посещавате сервиз.
Автомобилът проверява дали има налични актуализации и зарежда или инсталира софтуера на своите ECU напълно самостоятелно. Подобно на принципа на магазините за приложения на добре познатите доставчици на операционни системи за мобилни устройства, опциите и разширенията могат да бъдат закупени и инсталирани от собственика на автомобила.

За да се постигне тази модулност и гъвкавост на практика, е необходимо в бъдеще подобни функции да бъдат заложени в софтуера, вместо в хардуера. И тук моделът на съвременния смартфон служи като пример, в който приложенията позволяват голямо разнообразие от задачи и начини на употреба за потребителя. В допълнение към провеждането на телефонни разговори, можете да използвате вашия смартфон и за да правите снимки или да навигирате. Ако желаете, можете дори да извършвате банкиране или да се информирате в социалните медии.

Този подход в автомобила се нарича „Software-defined Vehicle“. На практика всички функции в автомобила вече не се изпълняват чрез хардуерно базирани контролери, а дадена програма (приложение) решава задачите на универсален компютър за управление (зонов контролер).
Предимството е, че много приложения работят едновременно (Multitasking) и следователно всички функции на дадена зона могат да бъдат реализирани само на един зонов контролер. Разбира се, това изисква много висока изчислителна мощност, но също така и голям брой интерфейси към сензорите/изпълнителните механизми, които трябва да бъдат инсталирани в зоновия контролер.

Друга задача на тези зонови контролери е да комуникират с централния процесор. За тази цел онези данни, които се изпращат до тази централа, се филтрират предварително и се приоритизират от зоновия контролер. По този начин сложността на системата се намалява драстично и централният процесор може да се фокусира върху обработката на релевантните данни (напр.: ADAS функции, оценка на данни от изображения и т.н.).

Връзките за данни между зоновите контролери и централния процесор изискват надеждна и бърза комуникация. Автомобилните Ethernet решения (напр. MultiGiG) са средството за постигане на тази цел.

Тази връзка се нарича Backbone.

Комуникация Зонален шлюз – Централен компютър

Подходът „Software-defined Vehicle“ неизбежно води до голяма промяна на парадигмата за OEM производителите. Докато производителите на автомобили преди са били носителите на ноу-хау за технологията (хардуер), инсталирана в превозното средство, функциите и добавената стойност сега се изместват почти напълно от хардуер към софтуер.

Фокусът вече не е върху самия автомобил, а по-скоро върху функцията и се адаптира индивидуално към желанията на клиента. Досега обаче разработването на софтуер всъщност не е било основна компетентност на OEM производителите. Ето защо тук вече можем да видим различни тенденции. Докато някои, често по-млади компании, са насочени към доставчици на софтуерни услуги или дори цялостни системи, напр. Android от Google, „класическите“ OEM производители са склонни да се опитват да запазят своето ноу-хау в компанията и да инвестират в създаването на собствен софтуерен отдел. Във всеки случай остава интересно да видим кой от тези пътища ще надделее в дългосрочен план.

Също толкова интересно е, че тук се появяват напълно нови бизнес модели.

Самата функция вече не е обвързана с автомобила. Търговците на употребявани автомобили или клиентите могат сравнително лесно да дооборудват с нови функции и по този начин да създадат добавена стойност за автомобила. Стойността на автомобила се запазва през целия жизнен цикъл или дори може да бъде увеличена.

Вече може да се предложи дори ограничена във времето употреба на дадени функции или абонаментно решение.

Друг плюс е, че автомобилът може да комуникира със заобикалящата го среда. Може да събира данни по време на работа и напр. да ги съхранява в облак. Този обмен на данни позволява непрекъснато подобряване на функциите и услугите, които след това могат да се актуализират отново в автомобила „в движение“. Директната комуникация между няколко превозни средства също е технически възможна. Всички тези възможности са друг важен крайъгълен камък по пътя към автономното шофиране.

Перспектива: Огромни изисквания към изчислителната мощност и проводниците за данни

Със сигурност ще отнеме известно време, преди архитектурата на бордовата мрежа да бъде преобразувана в зони. Все още има нерешени предизвикателства като необходимата изчислителна мощност и проводниците за пренос на данни със скорост от 25 Gbit/s или повече. Според прогнозите обаче това може да се случи чак към 2030 г. Техници по целия свят вече работят интензивно върху решения.

С продуктовото си портфолио MD ELEKTRONIK е много силен и компетентен партньор, чийто фокус е именно върху тези изисквания. Предлагаме правилното решение за коаксиални кабели, UTP- и STP- _(*), USB продукти, както и за оптичен пренос на данни. Благодарение на силно автоматизираната производствена стратегия, нашите продукти отговарят на най-високите стандарти за качество. 

Обобщение

Светът на автомобилите се променя бързо. Не само преминаването към електрическо задвижване поставя големи предизвикателства за производителите на автомобили. Също толкова важно е да представим решения за идеята „смартфон на четири колела“.

Важен подход тук е да се повиши ефективността на бордовата мрежа чрез замяна на големия брой отделни проводници „от точка до точка“ с по-малко, високопроизводителни мрежови линии (като MultiGiG Ethernet). От една страна, тук предимството е, че теглото намалява много. В същото време обаче, това представлява и огромно предизвикателство за производителите на ECU, тъй като много функции, които преди това са били внедрени в отделни сензори или в самите изпълнителни механизми, сега са интегрирани в ECU като софтуерни решения. Тези два подхода се описват съответно като „зонова архитектура“ и „Software Defined Car“.

Заключение

Изискванията по отношение на изчислителната мощност и преноса на данни са много високи и все още има много място за подобрение. Проводниците за данни на бъдещето трябва да бъдат проектирани за надежден пренос в диапазона до 25 Gbit/s или повече. Тук все повече се предлагат оптични линии за данни като добра алтернатива на проводниците на базата на мед.

(*)
UTP – Unshielded Twisted Pair
STP – Shielded Twisted Pair