AUTOSAR е гръбнакът на AV и ADAS, но за колко време?

AUTOSAR стана повсеместен в разработването на автомобилни ECU, но ролята му може да се промени с появата на пазара на нови и по-сложни технологии за автономни превозни средства. От Мартин Хоул и Ален Дюнойе

AUTOSAR стана повсеместен в разработването на автомобилни ECU при много OEM производители, но с появата на нови и по-сложни технологии за автономни превозни средства каква роля ще играе AUTOSAR?

Автономни превозни средства – ниво 3

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

Фигура 1. SAE нива на автоматизация

SAE Ниво 3 ще бъде огромна стъпка за производителите на превозни средства (нивото на здравина, което трябва да се демонстрира, е подобно на стандартите за гражданска авиация). Хората са адаптивни и обикновено могат да заобикалят лошите контроли и инструкции. Но когато превозно средство от ниво 3 има пълен контрол, вече не е водачът, който трябва да се адаптира към ограниченията на превозното средство. Превозното средство трябва да се адаптира към ограниченията на своя водач – всеки водач. Ако превозното средство реши, че трябва да предаде контрола на водача, то трябва да е в състояние да предаде това бързо, здраво и ясно.

И така, как превозно средство от ниво 3 безопасно прехвърля контрола върху задачата за шофиране между превозното средство и водача?

Има няколко аспекта на прехвърлянето на контрола (фигура 2):

Шофьор до превозно средство:

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

Превозно средство до шофьор:

  • Превозното средство трябва да започне процедура за прехвърляне на контрол, ако:
    • Автомобилът не може да поддържа контрол (авариен трансфер)
    • Шофьорът не реагира на системата за наблюдение на водача
    • Необходимите условия за системата вече не се изпълняват
  • Шофьорът трябва да поеме контрола над превозното средство, ако бъде поискано
  • Стандартно прехвърляне на контрол — в контролирана процедура за 30-60 секунден прозорец, в зависимост от изпълнението
  • Аварийно прехвърляне на управлението — водачът трябва да поеме контрола поради аварийни условия, за повечето системи това би било минимум 5-10 секунди
  • Ако водачът не поеме контрола или не реагира на системата за наблюдение на водача, автомобилът ще се върне в безопасното си състояние, в повечето случаи това ще доведе до спиране на автомобила в лентата и започване на спешно повикване.
Фигура 2 Прехвърляне на контрол.  Източник: sbdautomotive.com (Наблюдение на водача и кабината - доклад 810)
Фигура 2 Прехвърляне на контрол. Източник: sbdautomotive.com (Наблюдение на водача и кабината – доклад 810)

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

В повечето случаи ще има комбинация от визуален HMI, използващ различните налични дисплеи, аудио обратна връзка под формата на звънци или евентуално гласови команди, хаптична обратна връзка чрез задвижващи механизми на седалката или волана и бутони и превключватели на волана за въвеждане на водача (фигура 3 ). Използването на множество HMI системи гарантира излишък и позволява декомпозиция на изискванията за функционална безопасност от по-висок ASIL – D рейтинг към по-нисък ASIL – B / A, намалявайки въздействието на промените в дизайна върху отделните системи и увеличавайки вероятността от ангажиране на водача, ако те са разсеяни от дисплеите или вероятно с увреден слух или дори глух, което означава, че аудио обратната връзка никога не се чува.

Фигура 3. Прехвърляне на CHF контрол.  Източник: sbdautomotive.com (Наблюдение на водача и кабината - доклад 810)
Фигура 3. Прехвърляне на CHF контрол. Източник: sbdautomotive.com (Наблюдение на водача и кабината – доклад 810)

Цялостният дизайн на системата за система от ниво 3, както може да се очаква, ще включва редица сензори и интелигентни сензори, ECU и задвижващи механизми в домейните за управление на движението, тялото и AV / ADAS, но също и поради прехвърлянето на изискванията за управление това вече ще има влияние и върху домейните за аудио и инфотейнмънт. Това води до изключително сложен цялостен дизайн на системата в множество домейни и ECU, от различни доставчици от Tier 1, за да се предостави система за автономно шофиране от ниво 3, която ще има ASIL-D изисквания за функционална безопасност. Използването на AUTOSAR може да помогне за облекчаване на някои от главоболията при разработка чрез предоставяне на обща рамка за софтуерна архитектура.

EE архитектури и софтуерно дефинирано превозно средство

Друга значителна тенденция е, че с по-голяма способност на електронния хардуер и софтуер има консолидиране на технологиите в множество домейни в по-малък брой по-сложни, многофункционални ECU. EE архитектите преминават от функционално ориентирани ECU към по-сложни функционални домейн контролери и в бъдеще към централизирани и зонални архитекти (фигура 4). Това в крайна сметка ще позволи напълно мащабируеми архитекти, ориентирани към услуги, постигане на това, което мнозина наричат софтуерно дефинираният автомобил, с други думи, превозно средство, за което по-голямата част от неговата функционалност е изградена върху хардуерно-независими софтуерни платформи. Тази концепция позволява на производителите да разработват софтуер, независим от различните му хардуерни конфигурации, като същевременно се възползват от предимствата на обновяемите платформи за превозни средства в производството.

За да постигнат това, повечето производители увеличават вътрешните екипи за разработка на софтуер, за да управляват пътната карта на софтуерния продукт на превозното средство, за разлика от външните партньори или Tier 1s. В повечето случаи Tier 1 все още ще доставят хардуерните и софтуерните компоненти, но собствеността върху системата ще бъде на OEM производителите. Те ще трябва да интегрират тези сложни системи с компоненти от множество доставчици. Използването на рамката AUTOSAR позволява на OEM да дефинира преносими софтуерни компоненти и комуникационните интерфейси между тях. Това може да помогне при трудната системна интеграция и задачи за отстраняване на грешки и ще означава, че много софтуерни компоненти могат да бъдат използвани повторно с развитието на EE архитектите.

Фигура 4. Прогнозна еволюция на електрическите архитекти в превозното средство.  Източник: sbdautomotive.com (EE Architecture Platforms - доклад 630) Autosar
Фигура 4. Прогнозна еволюция на електрическите архитекти в превозното средство. Източник: sbdautomotive.com (EE Architecture Platforms – доклад 630)

AUtomotive Open System Architecture (AUTOSAR) е партньорство за разработка на автомобилни OEM производители, ниво 1 и технологични разработчици, основано през 2003 г. за създаване на отворена стандартизирана софтуерна архитектура за автомобилни ECU. Архитектурата дефинира стандартни софтуерни модули и сервизни интерфейси за осигуряване на хардуерна независимост чрез капсулиране на софтуерни компоненти (фигура 5). Първата версия на платформата беше през май 2006 г., а първата реализация на технологията AUTOSAR беше пусната на пазара през 2008 г.

AUTOSAR класическа платформа.
Фигура 5 Класическа платформа AUTOSAR. Източник: https://www.autosar.org/standards/classic-platform/

Първоначалната платформа беше насочена към базирани на микроконтролери ECU, предоставящи единични функции и спечели значително навлизане на пазара след въвеждането си с повечето автомобилни OEM производители, които сега си партнират с организацията AUTOSAR.

С нарастването на сложността на автомобилната система имаше преминаване от прости еднофункционални ECU, базирани на микроконтролери, към по-сложни многофункционални ECU, базирани на микропроцесори. Това изисква по-развита софтуерна архитектура, която поддържа разширени функции като свързаност, синхронизация на времето, киберсигурност, V2X, SOTA и др.

В отговор на това AUTOSAR разработи адаптивната платформа (фигура 6), осигуряваща POSIX-базирана операционна система, предназначена да работи на многоядрени SoC. Оригиналната платформа беше преименувана на Classic, а споделените изисквания и спецификации на ниско ниво бяха поставени в стандарт на Foundation.

AUTOSAR
Фигура 6. Адаптивна платформа AUTOSAR

Първата версия на адаптивната платформа беше през март 2017 г. и сега двете платформи съществуват съвместно и се допълват. Адаптивната платформа не се разглежда като заместител на класическата платформа; те имат различни атрибути и са подходящи за различни реализации. Пълната рамка включва също тестване за приемане, позволяващо валидиране на системата, и стандартни интерфейси на приложения между определени домейни, поддържащи по-голяма повторна употреба на софтуера и възможност за обмен (фигура 7). ECU в рамките на една и съща система могат да работят с която и да е платформа и все пак да използват оперативната съвместимост на ECU, предлагана от комуникационните функции на AUTOSAR.

AUTOSAR
Фигура 7. Стандарти на AUTOSAR. Източник: https://www.autosar.org/

AUTOSAR и автономни превозни средства

AUTOSAR Classic Platform се използва в много ADAS системи от ниво 1 и ниво 2, които са на пазара днес, често в ECU с една функция като ACC, AEB и LKA. AUTOSAR Adaptive сега започва да се използва в по-усъвършенствани функции на ADAS със софтуерната обработка, внедрена във високопроизводителни изчислителни платформи.

Много OEM производители налагат използването на AUTOSAR в техните ECU, особено за управление на комуникационни мрежи на превозни средства през CAN / Flexray / LIN / Ethernet. Това често се дължи на необходимостта на OEM производителите да притежават и управляват своите мрежи. Конфигурациите на ECU и каталозите на съобщенията могат да бъдат пуснати в множество нива 1 по контролиран начин и използването на конфигурационния файл на AUTOSAR ECU (ARXML) за постигане на това е широко разпространено. Въпреки че някои ECU могат да бъдат освободени от това изискване, ако то не е напълно пригодено за тяхната функция.

Тъй като преминаваме към по-сложни системи за превозни средства, включително автономни системи за превозни средства, става ясно, че AUTOSAR ще играе роля в много OEM производители. Системите, внедряващи автономни функции от ниво 3, ще включват множество ECU в много домейни, а оперативната съвместимост на ECU, протоколите за функционално безопасно съобщение от край до край (E2E), преносимостта на софтуера и функциите за функционална безопасност правят разработването в рамките на AUTOSAR очевиден избор. Това също така ще улесни прехода на традиционно нефункционално безопасните HMI системи, позволявайки прехвърлянето на контролни аспекти, за да отговори на техните изисквания за функционална безопасност чрез разширяване на функциите на AUTOSAR, които вече поддържат.

Като казахме всичко това AUTOSAR ще предоставя само някои от софтуерните слоеве в рамките на системите. Въпреки че имат донякъде монопол върху мрежата за превозни средства, адаптивната платформа може да не е основният избор за внедряване на сложни автономни функции и има много други софтуерни системи, както собствени, така и с отворен код, включително OpenCL, операционна система за робот (ROS), и Mobileye и др. За щастие на разработчиците и AUTOSAR, системите могат да бъдат изградени с най-доброто от двата свята, като се използва стека AUTOSAR за комуникации и критични за безопасността възстановяване, но се използва междинен софтуер като SOME / IP и DDS за свързване към други системи от по-високо ниво.

Безопасно е да се каже, че за момента AUTOSAR осигурява гръбнака за AV / ADAS и много други системи в автомобила. Въпреки това, той е част от непрекъснато развиваща се екосистема, включваща много други софтуерни системи, и тъй като по-високите нива на автономия се развиват при по-централизирани и зонално базирани архитекти, точната роля на AUTOSAR все още предстои да бъде определена.


За авторите: Martin Howle е Domain Principle, EE Architecture, в SBD Automotive. Ален Дюнойе е директор по знания и таланти в SBD Automotive

Leave a Comment