Пројектовање аутомобилског софтвера Модели развоја Кораци у пројектовању Архитектуре Оптимизације

Циљеви Након завршетка овог предавања имаћете: Боље разумевање неких од принципа пројектовања: Модели развоја и кораци у пројектовању АУТОСАР референтну архитектуру Преглед топологија и временског усклађивања

Преглед Шта смо радили: Овај час: Комплет аутомобилских магистрала: LIN, CAN, FlexRay, MOST, Ethernet, BroadR Reach Овај час: Модели развоја аутомобилског софтвера Принципи пројектовања аутомобилског софтвера Оптимизације: топологија и временско усклађивање АУТОСАР референтна архитектура

Модели развоја Аутомобилски софтвер

Заступљени модели Модел водопада В модел

Модел водопада енг. Waterfall Model Први уведени процесни модел: једноставност Линеарно-секвенцијални модел животног циклуса Употреба: мали пројекти без неизвесних захтева Надовезивање фаза: комплетирање претходне пре почетка следеће нема преклапања Свака фаза се ревидира: Провера напретка Могућност укидања пројекта Тестирање: након завршеног развоја и имплементације

Прегледни дијаграм

Предности водопада Једноставност и лакоћа разумевања Лакоћа управљања: ригидно настављање фаза и ревидирање Секвенцијално имплементирање: нема преклапања Одлично ради за мање пројекте са познатим комплетним захтевима

МАне водопада Немогућност/потешкоће мењања захтева кад тестирање крене Осмишљавање и пројектовање мора да буде беспрекорно Доступност радног софтвера: веома касно у циклусу Велики ризици и несигурност Неприлагођеност за комлекне и објектно оријентисане пројекте Потешкоће за дуге и започете пројекте Ризично за пројекте са променљивим захтевима

УПОТРЕБА Кратки пројекти Пројекти са познатим, јасним и непроменљивим захтевима Фиксиран опис производа Технологија позната и лако се влада Доступачност гомиле ресурса и потребна експертиза Мали уплив корисника током развоја Производ се показује тек на крају циклуса Сваки пропуст се наплаћује (време и новац): промене у корену

В модел енг. V- model Име долази од провере и потврде (енг. Verification and Validation) Секвенцијално извршавање фаза са паралелним тестирањем Потребно најпре завршити пар из претходне фазе

Дијаграм В модела

Кораци у В моделу Захтеви: почетна фаза као у водопад моделу (бизнис и системски захтеви) Паралелно а пре развоја: обезбедити тест план који покрива функционалности из захтева Пројектовање на високом нивоу: (енг. The high-level design (HLD)) Фокус: архитектура, платформа, систем, серфиси, процеси Паралелно: пројектовање тест за интеграцију – могућност заједничког рада свих делова Пројектовање на ниском нивоу: (енг. The low-level design (LLD)) Фокус: конкретне компоненте и интерна логика – дијаграм класа са односима Паралелно: пројектовање тест компоненти Имплементација: Фокус: програмирање појединачних компоненти и функција Излаз: извршни код Тестирање: Почиње по завршетку кодовања – пењемо се десном страном - тестови

Предности Једноставност и лакоћа коришћења Већа вероватноћа успеха: Тестирање се планира унапред пре саме имплементације Огромна уштеда времена Проактивно праћење пропуста: Могућност раног препознавања Немогућност пропагирања пропуста ка каснијим фазама Функционише добро за мање пројекте са јасним захтевима

Слабости Ригидни кораци и још мање флексибилности Недоступност раних прототипова: касна имплементација Промене у лету: Потребно изменити спецификације као и тест документацију

Употреба Пројекти мале и средње скале са јасним захтевима Доступност огромних ресурса и знања Високо поверење клијента: Велики ризик јер се касно доставља прототип

Принципи пројектовања Аутомобилски системи

Пројектни кораци Прикупљање и анализа захтева – инжењерска процена Логичка архитектура Архитектура софтвера Пројектовање мреже Опис и одабир компоненти Пројектовање повезивања и ожичавања Интеграција и валидација

Изазови у пројектовању електронска опрема Прекомерни број ECU, цена ХВ и паковања поставља ограничења Додатне функционалности потребно доделити истом или мањем броју ECU Потребно поновно искоришћење функција и СВ Дељење између истих линија возила или са различитим Распоређености и интеракција између функција Потребан висок ниво зрелости СВ Обезбедити на појединачном и глобалном нивоу Интеграција СВ различитих произвођача: OEM vs suppliers

Пројектни процес

Приступи у пројектовању Почетна фаза: прикупљање и анализа захтева Од горе ка доле: Крупна слика: пројектовање целог система/мреже Рана провера и потврда Могуће искоришћење за појединачне компоненте Од доле ка горе: Специфичне ситнице: појединачни захтеви и повратна информација Поновно прилагођавање пројекта

Прикупљање и анализа захтева Основа за развој функционалног модела возила Користи се за избор оптималне логичке архитектуре (Не)функционални захтеви: Ефикасност, одржавање, и проширења

Пројектовање мреже Засновано на расподели функција Основа за развој комуникационих концепата Технички кораци: Пројектовање и избор магистрале: топологије и оптимизације Спецификација комуникационих модула: протокол, управљање мрежом Пројектовањ метода за потврду: оптерећење магистрале, ЕМК Дијагностика Безбедносни концепти

Структурно пројектовање Принцип црне кутије: Дефиниција сигнала за улаз и излаз Сигнали описани: Именом који даје семантику Дужином, трајање, подразумеване вредности, формуле за претварање вредности Дефинисане интеракције између компоненти

Пројектовање мреже мапирање функција ХВ, СВ и механика СВ може додатно да се дели на под модуле Могућа симулација након завршетка

Мапирање Потребно зарад симулације: Физичко ожичење се упарује са одговарајућим протоколима Сваки СВ модул се упарује са ХВ У/И управљачки СВ се упарује са сигналима Постиже се виртуализација ресурса

Мапирање пример

Опис и одабир компоненти Дешава се након јасног распореда функција и пројекта мреже Потребно направити компромис код добављача: мале и велике серије Посебне компоненте Потребно дефинисати безбедносне захтеве за елементе Потребно поравнати са додатним елементима (сенс/акт)

Ожичавање и интеграција Развој и пројектовање комплетне мреже ожичења: Оптимизација дужина, тежине, цене Пројекат повезивања, избор утичница: избор ножица и опис линија Разматрање оптималног развођења напајања Потребно размишљати унапред: Производња брзог прототипа спремног за тестирање Симулација и додатна подешавања Подршка за лаку интеграцију и повезивање под-система

Функционална безбедност Део свих корака и процеса: утиче на развојни ток Процена ризика, анализа опасности, препознавање уских грла Одности се подједнако на СВ и ХВ Врло често подлеже стандардима: ISO 26262 ISO 25119 IEC 62061

Временска анализа

Мотивација Правилно темпирање и планирање догађаја: Обезбеђује исправност (физичку и функционалну) Пружа ефикасно коришћење ресурса Омогућава рад у реалном времену

Анализа Мрежних перформанси Традиционални приступи Анализа Мрежних перформанси Традиционални приступи Прорачун оптерећења Симулације Засновано на емпиријским мерењима Обезбеђује метрике за процену Основа за подешавање архитектуре Тешко процењује напредни саобраћај Нема провере ограничења Прецизни резултати Релативно комплексно/скупо Тешко покрива граничне случајеве Неприлагођено за оптимизацију

Анализа Мрежних перформанси Новији приступ Анализа Мрежних перформанси Новији приступ Формална анализа (SymTA/S) Могућност брзе процене и оптимизације Засновано на (не)комплетним мрежним спецификацијама Прорачун горње границе кашњења са променљивим оптерећењем: Комплетан спорадични саобраћај: сви догађаји груписани Огранилен спорадични саобраћај: апроксимација образаца догађаја Сценарио извршавања догађаја: нпр. кораци при паљењу мотора

Примена Процена различитих кандидата за архитектуру Подешавање нових сигнала и порука (нпр. CAN) Процена стратегија за усмеравање саобраћаја Дефинисање горњих граница за кашњење

Архитектуре Топологије Основна разматрања

Мотивација Повећање захтева за процесуирањем и пропусном моћи

Модуларна стратегија Значајно смањење развоја и цене кроз поновно коришћење ХБ/СВ компонменти, сучеља, алата, и тест процедура Омогућено одвојена оптимизација Омогућава повратну усклађеност Скалабилност Проширивост и подесивост

Расчишћавање топологије Садашњост: Хетерогене архитектуре: додавање током времена Тешко применљиви глобални концепти: безбедност, одржавање и дијагностика Будућност: Промена од дистрибуираног ка централизоване хијерархије Потребна промена (сетити се Ауто етернета)

Пример садашњег стања

Увођење Auto-Ethernet 2015 година

Еволуција Auto-Ethernet 2015-2017

Хибридна окосница доменски ECU

Eternet окосница доменски ECU

Врсте архитектура окоснице

autosar Преглед

Увод AUTOSAR (Automotive Open System Architecture) Разлози: Стандардизација: 2003 - OEMs and suppliers Референтна архитектура за ECU SW Прво издање: AUTOSAR Version 3.0. Разлози: Смањивање комплексност Обезбеђивање будућег развоја: корисници и легислатива Потреба да се помире супростављени захтеви (нпр. безбедност и екологија) Груписање сличних или идентичних СВ за различите магистрале/произвођаче Сарадња између основних функција Глобални оптимум и дистрибуција СВ Ограничење: немогућност описивања функционалног понашања

Циљеви/Користи Циљеви: Користи: Стандардизација сучеља између апликација и базичног(управљачког) SW Дефиниција референтне архитектуре за ECU SW Стандардизација формата за размену података између развојних процеса Користи: Оптимизација кроз прилагођење, интеграцију и замену блокова Контрола претеране комплексности Одрживост током целог развојног циклуса производа

Компоненте Basic Software (BSW): модули који пружају фундаменталне сервисе приступ и комуникација на магистрали, управљање меморијом, У/И, систем и дијагностика Software Components (SWCs): формално описано са јасним сучељима ка BSW Runtime environment (RTE) Контрола и управљање везама између разних SWC и везе од SWC ка BSW сервисима The Virtual Functional Bus (VFB): Концептуална основа целокупне комуникације (веза између SWC и BSW) Доноси независност SWC од ХВ реализације ECU Могућност поновне употребе SWC на другим пројектима и платформама Имплементација: специфично возило, спец. подеш. RTE и BSW за сваки ECU

Virtual Functional Bus

SWC mapping

AUTOSAR слојеви Апстраховани слојеви за ECU SW: BSW, RTE, APP The Microcontroller Abstraction Layer (MCAL): управљач за меморију, У/И, и ком The ECU Abstraction Layer (ECUAL): униформни приступ функционалностима – независно од компоненти које обезбеђују The Service Layer: позадински сервиси за апликацију – ОС припада овом слоју The Runtime Environment (RTE): апстракција и одвајање BSW и APP Управљање текућег понашања и размене информација APP: свака функционалност као посебан модул Олакшава се портовање СВ и смањење ризика: Потребно само само заменити управљач мКонтролера Остатак СВ: само се измене подешавања за ECUALa

сучеља AUTOSAR Interface: Standardized AUTOSAR Interface генеричко сучеље Пружа га RTE: Повезује SWC или SWC и ECU управљач (IoHwAb, Complex Drivers) Пример: читање и упис вредности Standardized AUTOSAR Interface Специјализовано сучеље: дефинисано у AUTOSAR стандарду Употреба: SWC приступа AUTOSAR сервисима пруженим од BSW Пример:  ECU State Manager or the Diagnostic Event Manager. Standardized Interface Дефинисано у стандарду као API у Це језику Употреба: између BSW унутар ECU, између RTE и OS, или RTE и BSW Com

Развојни кораци Методологија задата у AUTOSAR Развој подељен у процесе и акције са дефинисаним форматима за размену података (XML) Пројектовање система: System Description дефиниција архитектуре: дефинисање и додела SWC на ECU Мрежна комуникација Развој ECU: ECU Configuration Description имплементација SWC и специфична подешавање BSW and RTE Програмирање ниског нивоа: писање или исправљање делова BSW на основу ECU Configuration Description RTE се прави да буде специфичан за сваки ECU Апликација: развој независтан Сучеља ка SWC дефинисана у SWC Descriptions Раздвојено тестирање и интеграција

Примет тока и алата sada

Начини миграције AUTOSAR нуди подршку за миграцију: Дефиниција специфичног Complex Driver Специјална врста SWC која не захтева формалан опис на основу SWC модле (енг. template) Могућ директан приступ BSW без коришћења RTE Апликација трпи минорне промене и има утисак да се само BSW променио Могуће кренути и од апликације при миграцији – најмање захтевно Могући делимични бенефити од неких AUTOSAR функционалности Нпр. дијагностика и комуникација преко RTE док језгро апликације није по стандарду Постепена замена делова апликације са стандардизованим Могућа оптимизација и повећање ефикасности Већи бенефити након потпуног преласка

AUTOSAR закључци AUTOSAR – надолазећи стандард са растућим значајем Генерички приступ – груписање функционалности Апстракција неких слојева изнад реализације ECU Подршка за миграцију – циљ потпуни прелазак Битно бити део групе кад стандард добије моментум