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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

43. Еволуција Auto-Ethernet

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

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

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

47. autosar
Преглед

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

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

50. Компоненте
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

51. Virtual Functional Bus

52. SWC mapping

53. 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

55. сучеља 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

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

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

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

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