AUTOSAR (Automotive Open System Architecture - архитектура автомобильной открытой системы) можно определить как общую платформу для всей автомобильной промышленности, предназначенную для расширения сферы применения функциональных возможностей транспортных средств, не затрагивая текущую операционную модель. AUTOSAR — это, по сути, открытая и стандартная архитектура программного обеспечения , которая была совместно разработана производителями автомобилей, поставщиками и разработчиками инструментов. В этой статье мы узнаем, что такое AUTOSAR, рассмотрим различные уровни ее архитектуры и сферы применения.
Главный девиз AUTOSAR – «Сотрудничать по стандартам, конкурировать по внедрению». Эта уникальная архитектура была разработана для того, чтобы установить и поддерживать общий стандарт среди производителей, поставщиков программного обеспечения и разработчиков инструментов, чтобы результат процесса мог быть достигнут без каких-либо изменений общей архитектуры.
AUTOSAR – как все начиналось?
В 2003 году партнерство AUTOSAR было сформировано как альянс производителей OEM (Original Equipment Manufacturer - производителей оригинального оборудования), поставщиков автомобилей Tire 1, производителей полупроводников, поставщиков программного обеспечения, поставщиков инструментов и других. Они установили AUTOSAR в качестве открытого отраслевого стандарта для архитектуры автомобильного программного обеспечения, принимая во внимание различные существующие автомобильные архитектуры, которые связаны между собой и будут сформированы в будущем.
Десятью основными партнерами AUTOSAR являются BMW Group, Bosch, Continental, DaimlerChrysler, Ford Motor Company, General Motors, PSA Peugeot Citroen, SiemensVDO, Toyota Motor Corporation и Volkswagen.
Важность AUTOSAR
Инфраструктура AUTOSAR непростая, но почему тогда необходимо внедрять такую сложную инфраструктуру в автомобильную промышленность? Зачем вообще понадобилась AUTOSAR?
Поскольку спрос на интеллектуальные, более безопасные и умные автомобили растет, конкуренция в автомобильной промышленности также будет возрастать. Все эти исследовательские функции и функции транспортных средств не могут быть реализованы одним органом.
Например, в автомобиле есть подушки безопасности, система GPS, интеллектуальная интеграция и т. д. Все эти функции реализованы в различных ЭБУ (электронных блоках управления, в англ. ECUs - Electronic Control Unit) в разных автомобильных отраслях, поэтому все различные автомобильные устройства должны работать "рука об руку", чтобы получить желаемый результат.
Это также помогает в процессе разработки программного обеспечения, поскольку до недавнего времени программное обеспечение, разработанное для автомобильной промышленности, было сосредоточено только на обеспечении функциональности системы, и их никогда не заботило, какой эффект оно может оказать на систему. Все усложнилось из-за множества функций различных ЭБУ в разных транспортных сетях. Эта проблема стала еще более острой с увеличением количества нестандартных процедур разработки. Поэтому они разработали AUTOSAR.
Различные уровни архитектуры AUTOSAR
Если вы посмотрите на изображение выше, вы увидите, что архитектура AUTOSAR состоит из трех основных уровней:
- Прикладной уровень
- Среда выполнения (RTE)
- Базовое программное обеспечение (BSW)
Каждый из этих слоев (уровней) имеет свое назначение и выполняет определенную операцию. Рассмотрим эти уровни более подробно.
Прикладной уровень
Прикладной уровень AUTOSAR состоит из различных приложений и конкретных программных компонентов, которые предназначены для выполнения конкретной задачи в соответствии с заданными инструкциями. Уровень приложений — это самый верхний уровень архитектуры программного обеспечения AUTOSAR, поэтому он важен для всех автомобильных приложений. Прикладной уровень состоит из трех наиболее важных компонентов, которые следует принимать во внимание. Это компоненты прикладного программного обеспечения, порты этих компонентов и интерфейсы портов.
Компоненты программного обеспечения обеспечивают функциональность подсистемы, которая включает в себя операции и элементы данных, необходимые программному обеспечению, а также ресурсы, необходимые компонентам. И источник приложения не зависит от местоположения интерактивных компонентов, типа ЭБУ, на котором отображается компонент, и количества раз, когда компонент создается в системе.
Уровень среды выполнения (Runtime Environment, RTE)
Уровень среды выполнения создает подходящую среду для работы программных компонентов (software components, SWCs). SWC всегда зависят от интерфейса, предоставляемого RTE.
Этот уровень можно рассматривать как центр связи между ЭБУ, находящимися в сети. Это помогает компонентам программного обеспечения работать независимо от механизмов и каналов связи. RTE делает это возможным, сопоставляя коммуникационные отношения между компонентами, которые реализованы в различных шаблонах, с конкретным механизмом внутренней связи, таким как вызов, или механизмами связи между ЭБУ, такими как сообщение COM.
RTE несет ответственность за управление жизненным циклом SWC. Он должен запускать и отключать функции в зависимости от потребностей. Он также действует как разделительный уровень между прикладным программным обеспечением (Application Software, ASW) и базовым программным обеспечением (Base Software, BSW), где базовое программное обеспечение имеет разрешение напрямую вызывать любую функцию API или другие модули, но прикладное программное обеспечение может взаимодействовать только через порты.
RTE генерируется в два этапа
- Этап контракта: этот этап не зависит от ЭБУ и обеспечивает контракт между прикладным программным обеспечением и RTE.
В результате появляется заголовок, указанный компонентом ASW, который мы можем включить в исходный код. Файл заголовка состоит из всех функций API RTE, которые можно использовать в ASW, а также необходимые типы данных и структуры, необходимые компонентам ASW, объявлены в файле заголовка.
- Фаза генерации: на этом этапе основное внимание уделяется созданию конкретного кода для данного ЭБУ. Благодаря компонентам ASW и заголовочным файлам, созданным на этапе заключения контракта, а также всему необходимому коду BSW, сгенерированный код можно скомпилировать в исполняемый файл для ЭБУ.
Базовое программное обеспечение (BSW)
Уровень базового программного обеспечения можно определить как стандартизированное программное обеспечение, которое может предоставлять услуги программным компонентам AUTOSAR, а также используется для запуска функциональной части программного обеспечения. Базовое программное обеспечение включает в себя стандартизированные и определенные для ЭБУ компоненты.
Уровень базового программного обеспечения далее разделен на 4 основные части, а именно: уровень служб, уровень абстракции ЭБУ, уровень абстракции микроконтроллера и сложные драйверы. Рассмотрим каждую из этих частей более подробно.
I. Сервисный уровень
Это самый верхний уровень базового программного обеспечения. Он предоставляет базовые программные модули для прикладного программного обеспечения и не зависит от аппаратного обеспечения микроконтроллера и ЭБУ .
Уровень обслуживания предоставляет такие функции, как
- Службы памяти (управление NVRAM);
- Диагностические услуги;
- Связь и управление автомобильной сетью;
- Управление состоянием ЭБУ;
- Операционная система (ОС).
Монтаж этого уровня предназначен для микроконтроллеров (MCU), частей аппаратного обеспечения ЭБУ и их приложений.
II. Уровень абстракции ЭБУ
Этот уровень действует как интерфейс уровня абстракции микроконтроллера, который также содержит некоторые драйверы внешних устройств. Он имеет доступ к периферийным устройствам независимо от того, где они расположены: внутри или снаружи микроконтроллера. Он также предлагает API для взаимодействия с микроконтроллером.
III. Уровень абстракции микроконтроллера (Microcontroller Abstraction Layer, MCAL)
Уровень микроконтроллера — это маршрут доступа для связи с оборудованием. Этот уровень был создан для того, чтобы избежать прямого доступа к регистрам микроконтроллера. Уровень абстракции микроконтроллера (MCAL) — это аппаратный уровень, предназначенный для обеспечения стандартного интерфейса с компонентами базового программного обеспечения. Он предоставляет независимые от микроконтроллера значения для компонентов базового программного обеспечения, а также управляет периферийными устройствами микроконтроллера.
MCAL снабжен механизмом уведомлений, позволяющим поддерживать распределение команд, ответов и информации различным процессам. Помимо этого, MCAL может включать в себя некоторые функции и устройства, такие как цифровой ввод-вывод (Digital I/O, DIO), аналогово-цифровой преобразователь (АЦП) , широтно-импульсный (De) модулятор ( PWM , PWD), EEPROM (EEP), флэш-память ( FLS), Capture Compare Unit (CCU), сторожевой таймер (Watchdog Timer, WDT), последовательный периферийный интерфейс (SPI), шина I2C .
IV. Комплексный драйвер устройства (Complex Device Driver, CDD)
Этот уровень имеет особые временные и функциональные требования для работы со сложными датчиками и исполнительными механизмами. CDD используется для обработки сложных функций, его нельзя найти ни на каких других уровнях, и он имеет возможность прямого доступа к микроконтроллеру. Комплексные функции включают в себя управление впрыском, контроль электрических величин, обнаружение положения и т. д.
Цели AUTOSAR
AUTOSAR был создан по определенным причинам, которые полезны в настоящее время и будут полезны и в будущем. К наиболее важным целям его создания можно отнести следующие:
- Внедрение и стандартизация базовых функций в качестве общеотраслевого «стандартного основного» решения.
- Интеграции функциональных модулей от разных поставщиков.
- Легкость поддержания процесс на протяжении всего жизненного цикла автомобиля.
- Возможность масштабирования различных транспортных средств независимо от платформы.
- Активация резервирования.
- Учет требований доступности и безопасности.
- Легкая передача функций с одного ЭБУ на другой ЭБУ в сети.
- Увеличение возможностей использования коммерческого готового оборудования (commercial off the shelf, COTS).
- Регулярные обновления программного обеспечения на протяжении всего срока службы автомобиля.
Преимущества AUTOSAR
AUTOSAR привносит различные преимущества в автомобильную промышленность на разных этапах жизненного цикла автомобиля.
OEM-производители: с AUROSAR вы можете снова и снова использовать один и тот же программный код для разных OEM-производителей. Это позволяет более гибко адаптироваться к различным конструкциям, а также сокращает время и стоимость производства.
Поставщики: они могут повысить эффективность функционального развития и создать подходящую для них собственную бизнес-модель.
Поставщик инструментов: AUTOSAR имеет общий интерфейс, который помогает поставщику инструментов стандартизировать процесс разработки.
Новый участник рынка: для новых участников AUTOSAR действует как прозрачный и определенный интерфейс, который может помочь им понять отраслевые стандарты, а также создать свои собственные бизнес-модели.
51 просмотров