В связи с ростом требований к безопасности, комфорту, уровню развлечений и охране окружающей среды электронные системы в автомобилях получают все больше функ­ций и характеризуются высоким уровнем сложности. Для сохранения этого уровня в будущем требуются самые современные тех­нологии, методы и инструменты системной архитектуры. Вот о том, как выглядит современная электронная архитектура в автомобилестроении, мы и поговорим в этой статье.

 

 

 

История развития электронной архитектуры автомобиля

 

На протяжении многих десятилетий в исто­рии автомобилестроения использовалось со­всем небольшое количество электрических систем: зажигание, освещение, стеклоочи­стители, звуковой сигнал, датчик уровня топлива, различные индикаторы и радиопри­емник. Полупроводники — за исключением радиоприемников — изначально использо­вались только для выпрямления (генератор постоянного тока был заменен генератором переменного тока лишь в 1963 году) и затем для электронного управления (транзисторное зажигание появилось в 1965 году).

Реализовать некоторые автомобильные функции электромеханическими средствами и дискретными электронными компонентами либо не удалось вовсе, либо удалось лишь при несопоставимо высокой сложности. К примеру, первая электронная антиблокиро­вочная система (ABS) была разработана еще в 1970 году, но так и не дошла до серийного производства из-за своего размера, массы и стоимости. К середине 70-х годов развитие интегральных схем для широкого спектра областей применения дошло и до автопрома и вызвало революционные изменения в авто­мобильной электронике.

Один из первых примеров объединения элек­тронных систем в сеть появился при разра­ботке системы управления тяговым усилием (TCS). Это объединение в сеть было изна­чально реализовано чисто механическими средствами. Дроссельная заслонка в воз­духозаборной системе ДВС была оснащена устройством, которое можно было активиро­вать непосредственно через систему управ­ления тяговым усилием. Системе управления двигателем было невозможно распознать, чем вызвано перемещение дроссельной заслонки — нажатием педали газа или вме­шательством системы управления тяговым усилием.

Следующим этапом стала реализация электронного подключения к блоку управ­ления двигателем через интерфейс ШИМ (широтно-импульсной модуляции) для улуч­шения динамической реакции. Его можно было использовать для передачи сигнала на блок управления двигателем для уменьше­ния крутящего момента двигателя. Тогда оно было реализовано в виде дросселирования подачи воздуха, уменьшения впрыска или опережения момента зажигания.

Из-за постоянного ужесточения требова­ний к составу отработавших газов те воз­можности, что имелись на момент соедине­ния системы управления тяговым усилием и системы управления двигателем были уже недостаточны. Теперь требовалось сообщить системе управления двигателем, как умень­шение крутящего момента, запрашиваемое системой управления тяговым усилием, осу­ществляется в воздушном, топливном кана­лах или цепи зажигания. Поэтому было не­обходимо создать более мощный интерфейс, через который система управления тяговым усилием могла бы передать системе управ­ления двигателем запрос на необходимый крутящий момент и динамическую реакцию. I/I наоборот, фактический момент, обороты двигателя и резерв настройки тока должны были передаваться на блок управления TCS. Это оказалось сложно и дорого в плане коли­чества проводов, необходимых для передачи этих разных данных через дискретные и, к примеру, ШИМ-интерфейсы. Система шин CAN (сеть контроллеров) была представлена в 1991 году в качестве альтернативы дискрет­ным проводам. Так был заложен фундамент для современного объединения автомобиль­ных систем в сеть.

 

Электронная архитектура сегодня

 

В современных автомобилях практически все ЭБУ прямо или косвенно (например, через шлюзы) соединены друг с другом (рис. » Соединение ЭБУ между собой в современном автомобиле среднего класса» ). Объ­единение в сеть дошло до того, что 60 и более ЭБУ общаются между собой по нескольким шинам CAN и другим шинам — FlexRay, MOST (транспорт для медиа ориентированных систем) и LIN (локальная сеть взаимодействия). Так, например, блок управления системы динами­ческой стабилизации (ESP) передает в сеть информацию о скорости автомобиля. Автомо­бильный радиоприемник может использовать эту информацию, к примеру, для адаптации громкости к скорости автомобиля.

 

 

Благодаря объединению ЭБУ в мощную сеть можно реализовать множество новых функций без какого-либо дополнительного оборудова­ния, т.е. исключительно путем обмена данными и с помощью программного обеспечения. Одним из примеров служит открывание дверных окон путем более длительного нажатия кнопки на брелоке дистанционного управления. Таким об­разом, например, можно равномерно вентили­ровать салон летом, когда открываются двери. Для этого блоки стеклоподъемников и система центрального запирания обмениваются необхо­димой информацией. Программное обеспечение запускается либо на ЭБУ системы центрального запирания, либо на ЭБУ стеклоподъемников. Во многих автомобилях эти две системы имеют общий ЭБУ, в этом случае новые программные функции можно реализовать даже еще проще.

Это демонстрирует тенденцию, изначально встречавшуюся в кузовной электронике: ин­теграция отдельных ЭБУ с образованием центрального ЭБУ (рис. «Сравнение децентралихованного и централизованного управления» ). Эти центральные ЭБУ соединяются с датчиками и исполнитель­ными механизмами либо через дискретные, аналоговые провода, либо через шины. По­следние значительно уменьшают количество штырьков в разъеме ЭБУ и, соответственно, стоимость проводки. Датчики и исполнитель­ные механизмы, подключаемые через шины, также называют «интеллектуальными». Для подключения к шине они должны иметь электронную схему, которая во многих слу­чаях также включает в себя функции конди­ционирования сигнала датчика или функции драйвера исполнительного органа. Но в то же время использование электронной схемы означает рост затрат на датчики и исполни­тельные механизмы. Таким образом, мини­мизация суммарных затрат, в том числе на электронику и провода, является важной задачей при определении концепций органи­зации сети.

 

 

К примеру, логическая цепь для функции защиты пальцев у блоков стеклоподъемников во многих исполнениях расположена прямо в ЭБУ на электроприводе стеклоподъемника. Сигнал активации нормальной работы, на­пример, при упомянутом выше открывании стекол с брелока, передается по шине LIN с центрального ЭБУ кузовной электроники (ВСМ). В этом отношении речь идет о сервер­ной архитектуре.

 

Тенденции развития электронной архитектуры

 

Упомянутая выше централизация и исполь­зование интеллектуальных датчиков и испол­нительных механизмов в области кузовной электроники нашла распространение в других функциональных областях автомобиля (ин­формация для водителя, динамика движения и безопасность) и продолжит расширяться в ближайших поколениях автомобилей. В до­полнение к комбинации функций различных ЭБУ в одном центральном ЭБУ используются локальные главные компьютеры (рис. «Возможный сценарий для автомобиля представительского класса в будущем» ).

 

 

ЭБУ интеллектуальных датчиков и испол­нительных органов автомобиля зависят от этих главных компьютеров (ВСМ, IHU и т.д.). Функции, требующие высокой степени инте­грации команд управления информацией в основном воспроизводятся на этих главных компьютерах в программном обеспечении. Чтобы эти функции могли работать и на ЭБУ других платформ, требуется стандартная программная архитектура. Добиться этого можно посредством инициативы AUTOSAR (см. раздел «AUTOSAR» ниже).

 

Архитектура электронных систем автомобиля

 

С увеличением количества электроники в автомобиле растет и потребность в мощных процессах разработки и методах их описания для архитектуры электрических и электрон­ных систем.

Понятие «архитектура» обычно обо­значает искусство строительства. В строи­тельстве архитектор проектирует здание, создавая чертежи в различных проекциях, и строители-подрядчики выполняют работу в соответствии с пожеланиями заказчика и гра­ничными условиями. Проект абстрагируется от реальности в плане конкретных аспектов (например, геометрических условий или электропроводки). Здание может быть воз­ведено окончательно на основании проектов всех необходимых аспектов.

Применительно к автомобилям это назы­вается «Е/Е-архитектурой». «Е/Е» означает электрические и электронные аспекты авто­мобиля. «Проекты» Е/Е-архитектора в даль­нейшем мы будем называть общим понятием «модель».

У автопроизводителей и их поставщиков раз­ные взгляды на то, сколько и каких моделей требуется для полного описания электри­ческих и электронных систем автомобиля. Представленные ниже модели хорошо за­рекомендовали себя на практике и являются необходимой основой для описания объема Е/Е-архитектуры.

Понятие архитектуры часто используется в литературе и публикациях для обозначения самих моделей. Здесь четко различают ра­бочую операцию (разработка архитектуры) и представление результата (модель).

 

Модели Е/Е-архитектуры

 

Модели Е/Е-архитектуры отражают ре­зультаты различных аспектов интеграции электронных систем в автомобиле (рис. «Модели Е/Е-архитектуры» ). Эти аспекты обычно рассматриваются одно­временно, так, как и геометрия (структура кузова) и новые системы анализируются на этапе разработки концепции. В процессе раз­работки автомобиля может возникнуть ситуа­ция, когда электронная система в выбранной технологии не вписывается в имеющееся пространство. В этом случае нужно найти компромисс.

 

 

 

Функциональная сеть

 

Функциональные модели — предваритель­ная стадия конкретных технических систем. Они описывают элементы, необходимые для реализации необходимых характеристик, не вдаваясь в конкретную технологию. На при­мере рулевого управления с наложением это означает разбивку на такие элементы, как:

• Переменное передаточное отношение;
• Управление стабилизацией;
• Модель автомобиля;
• Исполнительный механизм;
• Автомобиль;
• Водитель.

 

 

 

Функциональные модели (рис. «Схема протекания сигнала со стандартными элементами на примере рулевого управления с наложением» ) обычно создаются в виде схемы прохождения сигна­лов по DIN 19226.

 

Сеть компонентов

 

Технологическая модель

 

Технологическая модель описывает, какая техническая реализация используется для ука­занных элементов без объединения их в мо­дули, такие как электронные блоки управления (ЭБУ). Создаются «технологические блоки».

Таким образом, фильтрацию сигналов можно реализовать с дискретными ком­понентами с помощью цифровой цепи или фильтрующего программного обеспечения в микроконтроллере. С помощью цифровой цепи или микроконтроллера можно даже реализовать функцию контроллера. Стаби­лизации напряжения можно добиться либо с помощью сглаживающего конденсатора, либо конвертера напряжения DC/DC.

На выбор технической реализации с одной стороны влияет функция, а с другой — затраты. Прежде чем сгруппировать технологические блоки в модули в виде ЭБУ, первым делом нужно попытаться найти синергизм с технологическими блоками, интегрируемыми в будущем. Создается технологическая активная цепь (рис. «Пример технологической активной цепи» ). Если, к примеру, имеется конкретная сенсорная технология для звена активной цепи, сигнал которого нужен другой активной цепи, то она тоже будет использоваться. Это происходит даже при переопределении этого датчика под дополнительного пользователя, т.е. при менее строгих требованиях, например, к дальности приема сигналов или к точности.

 

 

Вместе с тем, важно хранить исходное требование в базе данных, так как этого си­нергизма может не оказаться в другом авто­мобиле.

В автомобильной промышленности для описания оборудования обычно использу­ется номенклатура по DIN EN 60617.

 

Узловая модель

 

Звенья технологических активных цепей объединяются в группы в различных местах, называемых узлами. Здесь поддерживается строгое соблюдение оптимальных затрат на интеграцию технологических блоков. Например, делаются попытки интеграции программных частей нескольких техноло­гических активных цепей на общем микро­контроллере. Там, где это возможно, исполь­зуются сигналы датчиков и исполнительные механизма. Но история показывает, что заме­чательного синергизма можно добиться даже в области механики — например, в создании вакуума для пневматического усилителя тор­мозов через впускной трубопровод двигателя с искровым зажиганием.

 

Аппаратная модель ЭБУ

 

Эта модель описывает структуру электрон­ного оборудования ЭБУ. Она создается путем отнесения конкретных электронных компо­нентов из технологических активных цепей электронному модулю в узле. Поэтому ЭБУ, вообще говоря, является сборным пунктом электронных компонентов различных систем, «интеграционной платформой».

Программное обеспечение для управления различными системами из различных источ­ников (автопроизводителей или их постав­щиков) интегрируется в микроконтроллеры, размещенные в ЭБУ. Путем объединения ЭБУ в сеть можно реализовывать сложные рас­пределенные функции, использующие дат­чики и исполнительные механизмы из раз­личных мест установки в автомобиле.

На стадии разработки для электрических и электронных компонентов ЭБУ изначально используются традиционные электрические схемы. Затем определяется механика ЭБУ, дизайн и технология подключения. Модель на ранней стадии разработки ограничивается очень грубым представлением.

 

Программная модель ЭБУ

 

Из классической информационной технологии (для систем персональных компьютеров) име­ется несколько признанных методов разработки архитектуры программного обеспечения с соот­ветствующими моделями (например, Product Line Approach). Однако до сих пор не было разрабо­тано стандарта на разработку архитектуры про­граммного обеспечения в автомобилестроении. С появлением стандарта AUTOSAR архитектура программного обеспечения в автомобиле в на­стоящее время определяется непосредственно.

Стандарт AUTOSAR определяет структуру программного обеспечения близко к уровню аппаратной части и интерфейсы между функциями приложений (рис. «Изображение архитектуры AUTOSAR» ). Кроме того, AUTOSAR определяет стандартизированные форматы обмена, поддерживаемые популяр­ными инструментами моделирования.

 

 

Различают базовое и прикладное про­граммное обеспечение. Блоками базового программного обеспечения являются, напри­мер, драйверы устройств, программное обеспечение для связи, операционная система и аппаратная абстракция.

 

Сетевая модель связи

 

Поскольку все технологические блоки авто­мобиля на предыдущих этапах были распре­делены между ЭБУ, мы получаем сеть этих ЭБУ с их коммуникационными взаимосвя­зями. Сетевая модель связи представляет все ЭБУ в автомобиле, подключенные к шине и, соответственно, прямо или косвенно соеди­ненные друг с другом.

Каждый сигнал, передаваемый между двумя или несколькими ЭБУ, относится к подходящей шинной системе. В этом плане AUTOSAR определяет стандартизированные форматы обмена, позволяющие описать связь по шине. Формат обмена AUTOSAR, на­чиная с версии 3.0, содержит стандарт ASAM FIBEX.

 

Электрическая схема

 

Отнесение технологических блоков к ЭБУ и модулям датчиков и исполнительных ме­ханизмов также привело к появлению сети электрических нагрузок/потребителей, тре­бующей подходящего энергоснабжения. С одной стороны, важно защитить отдельные электрические цепи, чтобы короткое замы­кание не повлияло на всю сеть. С другой стороны, не на все цепи, должна подаваться электроэнергия в каждом рабочем режиме.

Для этого был введен принцип «выводов». К примеру, на вывод 15 электроэнергия по­дается только при включении зажигания.

Электрическая схема (рис. «Электрическая схема на примере автомагнитолы» ) показывает электрическое соединение и защиту предо­хранителями отдельных модулей без учета монтажного положения. Здесь можно уви­деть цвета проводов (на рисунке не показаны) и соответствие выводу или предохранителю. Выводы обозначаются по DIM 72552.

Плюс напряжения питания обычно изобра­жается в верхней половине, а минус (масса) — в нижней.

 

 

Жгут проводов и пространство установки

 

Эта модель группирует электрические и электронные модули в определенном месте в автомобиле (рис. «Пример двухмерной пространственной модели» ). Таким образом, провода, соединяющие между собой ЭБУ, и провода питания нагрузок/потребителей сводятся вместе на станках для скрутки жгутов. Так получаются жгуты проводов. Здесь необхо­димо соблюдать множество разных гранич­ных условий:

• Концепция изготовления (одно- или много­составный жгут проводов);
• Поперечные сечения (гибкость);
• Электромагнитная совместимость (ЕМС);
• Рассеяние тепла;
• Масса;
• Стоимость (например, меди);
• Устройство автомобильного жгута про­водов.

 

Структура описывает возможные пути про­кладки проводов в кузове, например, струк­тура Н, состоящая из двух основных ветвей от передней до задней части автомобиля и перекрестной ветви, идущей с левой стороны автомобиля к правой.

На стадии разработки общей концепции автомобиля обычно достаточно двухмерны моделей; подробные трехмерные модели используются на более поздних стадиях про­ектирования.

 

Процесс разработки Е/Е-архитектуры

 

Процесс разработки Е/Е-архитектуры соеди­няет между собой отдельные стадии проекти­рования на логической и временной основе и обеспечивает критерии качества в начале и в конце стадии проектирования.

Поскольку Е/Е-архитектура для автомоби­лестроения — все еще молодая дисциплина, процессы у автопроизводителей и их постав­щиков пока сильно разнятся. Это относится и к количеству, и последовательности стадий проектирования, и к критериям качества.

 

Управление требованиями

 

Требования решающим образом определяют действия Е/Е-архитектора. Рекомендуется различать функциональные и нефункцио­нальные требования. Функциональные тре­бования означают желаемые характеристики при эксплуатации автомобиля. Нефункцио­нальные требования означают техническое решение и поэтому их также называют про­ектными ограничениями.

Таким ограничением может быть, напри­мер, свободное пространство в центральной консоли для установки ЭБУ. Другим ограни­чением может быть максимально допустимое рассеяние тепла в месте, которое влияет на размещенную там силовую электронику.

Таким образом, например, аудиоусилители часто устанавливаются в багажниках, так как тепло в области панели приборов не может адекватно рассеиваться.

После подготовки документации по функ­циональным и нефункциональным требова­ниям начинается фактическая разработка Е/Е-архитектуры.

 

Разработка Е/Е-архитектуры

 

Разработка Е/Е-архитектуры может идти двумя путями: по принципу «снизу-вверх», т.е. начиная с существующих компонентов, и по принципу «сверху вниз», т.е. с реализа­цией всех ранее описанных этапов моделиро­вания, начиная с функциональных и нефунк­циональных требований.

Принцип «снизу-вверх», вовремя соз­дания Е/Е-архитектуры, начиная с функ­циональности существующих компонентов, предусматривает дополнение этих компо­нентов функционально-коммуникативными аспектами и прохождение соответствующих этапов моделирования. Этот подход обычно выбирается для создания Е/Е-архитектур по­следующих поколений существующих авто­мобильных платформ.

Принцип «сверху вниз» фокусируется на сложности функций и обычно выбирается для создания Е/Е-архитектур новых автомо­бильных платформ.

Использование Е/Е-концепций позво­ляет обмениваться данными с партнерами- разработчиками электронных компонентов и жгутов проводов.

 

Оценка моделей

 

Для всех методов необходимо соблюдать следующее: при переходе от одной модель­ной иерархии к следующей (например, от функциональной модели к технологической), список критериев оценки (например, по­вторное использование или тестируемость) сравнивается с набором конкретных реше­ний (например, шинных технологий). Оценка конкретных решений по критериям позволяет решению принять форму на основе чисто функциональных требований и неизбежных граничных условий (критерий «MUST»). Эту процедуру также называют QFD (Развертыва­ние функции качества).

Альтернативная процедура заключается в сравнении опорного решения (например, предыдущей модели организации сети) с аль­тернативными с помощью критериев оценки.

Она дает поистине быстрые результаты, но не абсолютный оптимум.

Поскольку критерии оценки всегда взве­шиваются автопроизводителями по-разному, электронные системы автомобилей иногда значительно различаются.

 

Инструменты разработки Е/Е-архитектуры

 

Для моделирования архитектуры идеально подходит инструмент, который может соединить между собой различные модели и уровни моделей Е/Е-архитектуры. Таким образом, создается полностью соединенная документация. Это позволяет реализовывать различные дисциплины, являющиеся частью процесса разработки, в нужных точках. Кроме того, должна обеспечиваться возможность числовой регистрации свойств моделирова­ния, чтобы можно было обеспечить оценку.

Между тем на рынке появились раз­личные инструменты для разработки Е/Е-архитектуры, позволяющие выполнять моделирование архитектуры с помощью инструментов. Важным моментом является стандартизация моделей и их форматов дан­ных. Только это обеспечивает конкуренцию между изготовителями инструментов и от­крывает различным дисциплинам возможно­сти для присоединения к процессу в разных точках.

Для будущего плавного перехода к кон­фигурации системы и ЭБУ с помощью тех­нологий AUTOSAR требуется инструмент разработки Е/Е-архитектуры для поддержки форматов обмена AUTOSAR, таких как «Опи­сание системы» и «Описание компонентов программного обеспечения». Поэтому мы остановимся на стандарте AUTOSAR более подробно.

 

AUTOSAR

 

Партнерство AUTOSAR (открытая системная архитектура для автомобилестроения) было учреждено в июле 2003 года автопроизводи­телями и их поставщиками. Его главной целью является совместная разработка от­крытой программной архитектуры для ав­томобильных приложений будущего. Цели партнерства включают в себя стандартиза­цию фундаментальной инфраструктуры ЭБУ (базовое программное обеспечение), форма­тов обмена и функциональных интерфейсов. Они призваны заменить существовавшие в компаниях индивидуальные решения. Для того чтобы успевать за постоянным услож­нением систем, в связи с появлением новых функций, используются концепции и методы на базе моделей. Требования к качеству и на­дежности выполняются путем использования проверенных стандартов.

На основе программного обеспечения со стандартизированной инфраструктурой, со­стоящей, главным образом, из стандартных модулей, каждый автопроизводитель может реализовать свой контент (прикладное про­граммное обеспечение).

 

Цели и концепции AUTOSAR

 

Стандарт AUTOSAR преследует следующие цели:

• Повторное использование программного обеспечения для разных ЭБУ, автомобиль­ных платформ и автопроизводителей;
• Поддержка в интеграции программного обеспечения третьих лиц в области как ба­зового, так и прикладного программного обеспечения;
• Поддержка смещения прикладного про­граммного обеспечения между ЭБУ (ста­тичная);
• Обмен стандартными аппаратными бло­ками (например, трансивер CAN) без из­менений в прикладном программном обеспечении.

 

Программная архитектура, определяемая стандартом AUTOSAR (рис. 7), поддерживает четкое разделение между базовым и при­кладным программным обеспечением. Это достигается несколькими абстрактными уровнями в базовом программном обеспе­чении — от драйверов устройств до сложных инфраструктурных сервисов и среды прогона (RTE) стандарта AUTOSAR.

Поскольку интерфейсы большинства мо­дулей базового программного обеспечения в этих слоях стандартизированы, то стандарт­ные аппаратные блоки и соответствующие драйверы можно заменить без изменения прикладного программного обеспечения.

И наоборот, прикладное программное обеспечение, ограничивающееся исполь­зованием этих стандартных интерфейсов, можно гораздо проще ввести в ЭБУ на ста­дии разработки и даже переместить в другой ЭБУ. Например, одно и то же прикладное программное обеспечение контроллера ско­рости автомобиля в зависимости от плат­формы автомобиля может работать на блоке управления двигателем, блоке управления трансмиссией или другом ЭБУ без измене­ния прикладного программного обеспечения. Для этого, естественно, требуется достаточно мощный ЭБУ и соответствующая организация сети.

Стандартизация базового программного обеспечения и возможность его конфигура­ции в зависимости от требований к приклад­ному программному обеспечению позволяет повторно использовать модули базового программного обеспечения для разных авто­мобильных платформ и автопроизводителей. Это повышает качество программного обе­спечения, поскольку никаких изменений на Уровне продукта не происходит, сокращает затраты на разработку путем повторного ис­пользования и образует устойчивую основу. Для постоянного роста сложности и объеди­нения функций приложений.

Партнерство AUTOSAR также разрабатывает концепции на базе моделей для раннего Утверждения проекта системы. На основе Формализованного описания выполняется проверка соответствия интерфейсов прикладного программного обеспечения друг другу, при этом прикладное программное обеспечение не обязательно должно быть в виде полной программы.

 

Перспективы развития электронных систем

 

С ростом количества и степени интеграции электронных систем необходимо использо­вать подходящие процессы, методы и ин­струменты при разработке Е/Е-архитектуры. Разработка Е/Е-архитектуры в автомоби­лестроении превратилась в независимую задачу и оказывает решающее влияние при разработке новых автомобилей. Если описан­ные здесь процедуры будут последовательно применяться и развиваться, то в будущем ав­томобильная электроника будет управляемой и продолжит вносить значительный вклад в улучшение потока перевозок, безопасности движения, повышение комфорта и эконо­мичности.

 

РЕКОМЕНДУЮ ЕЩЁ ПОЧИТАТЬ: