- АВТОСАР - Як усе починалося?
- Важливість AUTOSAR
- Різні шари архітектури AUTOSAR
- Завдання AUTOSAR
- Переваги AUTOSAR
- Що можна очікувати від AUTOSAR?
AUTOSAR (Автомобільна архітектура відкритої системи) можна визначити як загальну платформу для всієї автомобільної промисловості, яка призначена для розширення сфери застосування функціональних можливостей автомобіля, не впливаючи на поточну модель експлуатації. AUTOSAR - це, в основному , відкрита та стандартна архітектура програмного забезпечення, яка була спільно розроблена виробниками автомобілів, постачальниками та розробниками інструментів. У цій статті ми дізнаємося, що таке AUTOSAR та про різні шари в його архітектурі.
Головний девіз AUTOSAR - «Співпрацювати за стандартами, конкурувати за впровадження». Ця унікальна архітектура була розроблена для того, щоб встановити та підтримувати загальний стандарт серед виробників, постачальників програмного забезпечення та розробників інструментів, щоб результат процесу міг бути доставлений без будь-яких змін.
АВТОСАР - Як усе починалося?
У 2003 році партнерство AUTOSAR було сформовано як альянс виробників OEM (виробник оригінального обладнання), автомобільних постачальників шини 1, виробників напівпровідників, програмного забезпечення, постачальників інструментів та інших. Вони заснували AUTOSAR як відкритий галузевий стандарт для архітектури програмного забезпечення для автомобілів, врахувавши різні автомобільні архітектури E / E, які були присутніми та пов'язані та будуть сформовані в майбутньому.
У 10 Основні партнери AUTOSAR є BMW Group, Bosch, Continental, DaimlerChrysler, Ford Motor Company, General Motors, PSA Peugeot Citroen, SiemensVDO, Toyota Motor Corporation і Volkswagen.
Важливість AUTOSAR
Інфраструктура AUTOSAR не проста, але чому потрібно запроваджувати таку складну інфраструктуру для автомобільної промисловості? З першого боку, навіщо нам АВТОСАР?
Оскільки попит на інтелектуальний, безпечний та розумніший автомобіль збільшує конкуренцію в автомобільній промисловості, також зростатиме. Весь цей інтелект та функціональність транспортного засобу не можуть бути застосовані одним органом влади.
Наприклад, автомобіль має подушки безпеки, систему GPS, розумну інтеграцію тощо. Усі ці функції реалізовані на різних ЕБУ (електронних блоках управління) різними автомобілебудівними галузями, тому всі різні автомобільні агрегати повинні мати можливість працювати рука об руку, щоб отримати бажану торгову точку.
Це також допомагає в процесі розробки програмного забезпечення, оскільки до недавнього часу програмне забезпечення, розроблене для автомобільної промисловості, було зосереджене лише на забезпеченні функціональних можливостей системи, і вони ніколи не дбали про те, які ефекти вона може надати системі. Це ускладнилося через безліч функціональних можливостей у різних ЕБУ в різних мережах автомобілів. Це стало більш критичною проблемою із збільшенням кількості нестандартних процедур розробки. Отже, вони розробили АВТОСАР.
Різні шари архітектури AUTOSAR
Якщо ви заглянете у зображення, наведене вище, ви зможете визначити, що архітектура AUTOSAR складається з трьох основних шарів, які є
- Шар додатків
- Середовище виконання (RTE)
- Основне програмне забезпечення (BSW)
Кожен із цих шарів має своє власне призначення та має виконати певну операцію
Шар додатків
Рівень додатків AUTOSAR складається з різних програм та конкретних програмних компонентів, які призначені для виконання конкретного завдання згідно з даними інструкціями. Прикладний рівень - це найвищий рівень архітектури програмного забезпечення AUTOSAR, тому він є критично важливим для всіх додатків автомобіля. Рівень програми містить три найважливіші компоненти, які слід враховувати. Вони є компонентами прикладного програмного забезпечення, портами цих компонентів та інтерфейсами портів.
Програмні компоненти забезпечують функціональність підсистеми, яка включає операції та елементи даних, необхідні програмному забезпеченню, та ресурси, необхідні компонентам. Причому джерело програми не залежить від розташування інтерактивних компонентів, типу ЕБУ, на які компонент відображається, і кількості випадків, коли компонент створюється у системі.
Рівень середовища виконання (RTE)
Рівень середовища виконання створює відповідне середовище для роботи програмних компонентів (SWC). SWC завжди залежить від інтерфейсу, наданого RTE.
Це можна розглядати як центр зв'язку між ЕБУ, що знаходяться всередині мережі. Це допомагає програмним компонентам працювати незалежно від механізмів зв'язку та каналів. RTE робить це можливим шляхом відображення зв'язків зв'язку між компонентами, які реалізовані в різних шаблонах, до конкретного механізму внутрішнього зв'язку, такого як виклик, або механізмів зв'язку між ЕБУ, таких як повідомлення COM.
RTE несе відповідальність за управління життєвим циклом SWC, він повинен запускати та вимикати функції на основі потреб. Він також діє як розділовий шар між прикладним програмним забезпеченням (ASW) та базовим програмним забезпеченням (BSW), де базове програмне забезпечення мало дозвіл на прямий виклик будь-якої функції API або інших модулів, але прикладне програмне забезпечення може здійснювати зв'язок лише через порти.
RTE формується у дві фази
- Контрактна фаза: Ця фаза не залежить від ECU, і вона забезпечує контракт між прикладним програмним забезпеченням та RTE, тобто API кодових компонентів ASW може кодуватися.
В результаті з’явився заголовок компонента ASW, який ми можемо включити до вихідного коду. Файл заголовка складається з усіх функцій RTE API, які можна використовувати в ASW, а також необхідні типи даних та структури, необхідні компонентам ASW, оголошені у файлі заголовка.
- Фаза генерації: Ця фаза буде зосереджена на формуванні конкретного коду для даного ЕБУ. За допомогою компонентів ASW та файлів заголовків, створених на фазі контракту, та всього необхідного коду BSW, згенерований код можна скомпілювати у виконуваний файл для ЕБУ.
Основне програмне забезпечення (BSW)
Рівень базового програмного забезпечення можна визначити як стандартизоване програмне забезпечення, яке може надавати послуги програмним компонентам AUTOSAR, а також воно використовується для запуску функціональної частини програмного забезпечення. Базове програмне забезпечення включає стандартизовані компоненти та компоненти ECU.
Рівень базового програмного забезпечення також розділений на 4 основні частини, а саме рівень послуг, рівень абстракції ECU, шар абстракції мікроконтролера та складні драйвери.
I. Рівень обслуговування
Це найвищий рівень базового програмного рівня, він забезпечує основні програмні модулі прикладного програмного забезпечення і не залежить від мікроконтролера та апаратного забезпечення ЕБУ.
Сервісний рівень забезпечує такі функції, як
- Служби пам'яті (управління NVRAM)
- Діагностичні послуги (включаючи UDS
пам'ять зв'язку та помилок) - Зв'язок та управління транспортними мережами
- Управління державою ЕКЮ
- Операційна система (ОС)
Монтаж цього шару спеціалізується на мікроконтролері (MCU), частинах апаратного забезпечення ЕБУ та їх додатках.
II. Абстракційний шар ECU
Цей рівень діє як інтерфейс рівня абстракції мікроконтролера, який також містить деякі драйвери зовнішніх пристроїв. Він має доступ до периферійних пристроїв та пристроїв, незалежно від того, де вони розташовані всередині або зовні мікроконтролера. Він також пропонує API для взаємодії з мікроконтролером.
III. Шар абстракції мікроконтролера (MCAL)
Рівень мікроконтролера - це шлях доступу для зв'язку з апаратним забезпеченням. Цей шар був обрамлений, щоб уникнути прямого доступу до реєстрів мікроконтролерів. Мікроконтролер абстрактний рівень (MCAL) являє собою апаратний шар призначений для забезпечення стандартного інтерфейсу до компонентів базового програмного забезпечення. Він забезпечує незалежні значення мікроконтролера для компонентів базового програмного забезпечення, а також управляє периферійними пристроями мікроконтролера.
MCAL забезпечений механізмом сповіщення, щоб він міг підтримувати розподіл команд, відповідей та інформації для різних процесів. Крім цього, MCAL може включати деякі функції та пристрої, такі як цифровий ввід / вивід (DIO), аналого-цифровий перетворювач (ADC), модулятор ширини імпульсу (де) (ШІМ, ШІ), EEPROM (EEP), спалах (FLS), Capture Compare Uni (CCU), Watchdog Timer (WDT), послідовний периферійний інтерфейс (SPI), I2C Bus.
IV. Складний драйвер пристрою (CDD)
Цей шар має особливі терміни та функціональні вимоги для роботи зі складними датчиками та виконавчими механізмами. CDD використовується для обробки складних функцій, його неможливо знайти в будь-яких інших шарах, і він має можливість безпосереднього доступу до мікроконтролера. Комплекс функцій включає управління впорскуванням, контроль електричних значень, виявлення збільшення положення тощо.
Завдання AUTOSAR
AUTOSAR був створений з певних причин, які є корисними для сьогодення і які будуть корисними в майбутньому, деякі цілі перелічені нижче.
- Впровадження та стандартизація основних функцій як загальногалузеве “стандартне ядро”.
- Інтеграція функціональних модулів від різних постачальників.
- Легко підтримувати процес протягом усього життєвого циклу.
- Можливість масштабування різних транспортних засобів, незалежно від платформи.
- Активація надмірності.
- Врахування вимог щодо доступності та безпеки.
- Проста передача функцій з одного ЕБУ на інший ЕБУ всередині мережі.
- Більше використовуйте комерційне устаткування (COTS).
- Регулярні оновлення та оновлення програмного забезпечення протягом усього терміну експлуатації автомобіля.
Переваги AUTOSAR
AUTOSAR забезпечує різні переваги на різних етапах життєвого циклу автомобіля
OEM-виробники: за допомогою AUROSAR ви можете використовувати один і той же код програмного забезпечення знову і знову для різних OEM-виробників. Він більш гнучкий для адаптації до різних конструкцій, а також зменшує час і вартість виробництва.
Постачальники: Постачальники можуть підвищити свою ефективність функціонального розвитку та створити власну бізнес-модель, яка їм підходить.
Постачальник інструментів: AUTOSAR має загальний інтерфейс, який допомагає постачальнику інструментів стандартизувати процес розробки.
Новий учасник ринку: для нових учасників AUTOSAR виступає як прозорий та визначений інтерфейс, який може допомогти їм зрозуміти галузеві стандарти, а також створити власні бізнес-моделі.
Що можна очікувати від AUTOSAR?
AUTOSAR призначений для різних цілей різних підрозділів автомобільної промисловості. Оскільки він універсальний та гнучкий, ви можете робити з нього багато речей, крім цього, деякі основні результати, які може дати вам AUTOSAR, - це можливість повторного використання програмного забезпечення в ньому для декількох блоків, а використовуване програмне забезпечення можна обмінювати, коли воно є що потрібно, AUTOSAR діє як стандартна платформа для всіх програмних засобів автомобіля, і він не має власного застосування.
Він має ОС з основними функціями та програмним забезпеченням інтерфейсу, і головна перевага полягає в тому, що один і той же інтерфейс може використовуватися у всьому базовому програмному забезпеченні. Функціональні можливості AUTOSAR поставляються як програмні компоненти, а всі задіяні компоненти не залежать від апаратного забезпечення.