Uloga Embedded softver inženjera u automobilskoj industriji

Prethodne nedelje predstavili smo uređaje koje razvijamo u Continental-u i poslovnoj jedinici Smart Mobility, kako se ti uređaji uklapaju u arhitekturu modernih komercijalnih vozila i koje su to timske uloge koje su neophodne kako bi zaokružili razvoj proizvoda. U ovom članku približićemo okvire rada i odgovornosti jednog embedded softver inženjera, odnosno programera koji razvija tzv. osnovni softver uređaja (Basic Software - BSW).

Kada govorimo o okvirima razvoja softvera u SMY, naša metoda izbora je moderna Agile metodologija. Da budemo precizni, koristimo iterativni i inkremenatlni pristup koji nam omogućava da postepeno razvijamo softver u kraćim etapama. Zašto? U jednu ruku, ovo u potpunosti odgovara prirodi razvoja softvera, jer programske funkcije čine druge manje funkcije i tako rekurzivno do osnovnih instrukcija programskog jezika. Takođe odgovara i modernom načinu testiranja u toku razvoja softvera, što treba da bude odgovornost svakog profesionalnog programera (TDD – Test Driven Development). Drugi važan razlog je da bismo bili u mogućnosti da pružimo mušterijama novu i potpunu funkcionalnost koja je spremna za upotrebu što je pre moguće. Mnogobrojni su i drugi razlozi, a jedan od njih je i mogućnost da se lakše uoče moguća poboljšanja, da se pravovremeno reaguje na izmenu, kao i da se omogući ponovljivost dobro pokazanih procesa i rešenja i na druge projekte (Reusability / Lessons Learned).

Ono što je zanimljivo jeste da naš poslovni model stavlja naglasak na saradnju i integraciju sa aplikativnim softverskim komponentama krajnjeg proizvođača vozila. Uređaj se isporučuje sa osnovnim softverom koji direktno upravlja hardverskim komponentama i slojem koji mogućava jednostavnu spregu na nivou signala, podataka i servisa prema aplikacijama koje ostvaruju konačnu logiku zahtevanu od strane mušterije. Ovo je danas najčešće traženi poslovni model, gde softver dobija svoju konačnu funkcionalnost kroz međusobnu saradnju. Ideja je da mušterija ima mogućnost da paralelno radi na razvoju, testiranju i unapređivanju svojih aplikacija (njihov zaštićeni “know-how”), dok mi inkrementalno i u kraćim koracima razvijamo i isporučujemo sve ostale niže slojeve softvera. Pored toga, i dalje je prisutan poslovni model gde mušterija zahteva kompletno rešenje, uključujući i razvoj krajnjih aplikacija.

Kako bismo to postigli efikasno, timovi na projektima su organizovani oko većih podsistema ili tema, poznatih kao “Feature”-i, i pokrivaju sve slojeve softvera po vertikali, od najnižeg nivoa koji je odgovoran za direktnu interakciju sa hardverom (HAL – Hardware Abstraction Layer), preko apstrakcije hardvera i servisa (ECU Abstraction Layer and Services), pa sve do najvišeg nivoa aplikativnog softvera (APP / SW-Cs).

Ova vertikalna organizacija se pokazala kao ključna za brzu implementaciju, nadogradnju i ispravku grešaka u softveru. S obrzirom na različite nivoe detalja, alate i okruženja koje koriste članovi tima za razvoj različitih slojeva softvera, važno je da se grupišu u jedinstvenu celinu. Na primer, programeri aplikativnog softvera često koriste Model-Based razvojna okruženja, poput Matlab/Simulink-a ili logi.CAD-a, gde koriste grafički pristup za programiranje i definisanje logike između ulaznih i izlaznih signala. Ovo je standard (IEC 61131-3) i koncept programabilnih logičkih kontrolera (PLC) preuzet iz klasične industrije, koji se pokazao kao siguran i pouzdan tokom više decenija, te primenjen i na automobilsku industriju. Sa druge strane, programeri nižih slojeva softvera i komponenti (BSW) koriste programski jezik C, koji je optimalan za rad sa procesorskim resursima i memorijom, kao i specijalizovano razvojno okruženje za integraciju i konfigurisanje BSW modula definisanih AUTOSAR (AUTomotive Open System Architecture) standardom. Nivo i vrsta detalja koje ove dve vrste programera moraju poznavati se razlikuje: jedni su više fokusirani na funkcionalnost

hardvera, optimalno iskorišćenje procesorskih mogućnosti i obezbeđivanje potrebnog interfejsa u vidu signala i srevisa prema aplikacijama (BSW programeri), dok su drugi više orijentisani na implementaciju logike krajnjih korisničkih zahteva (APP programeri).

Da bismo uspešno primenili agilne metode razvoja softvera, koristimo čitav niz alata koji su široko prihvaćeni u tradicionalnom IT svetu. Tu spadaju alati za kontrolu verzija softvera kao što su Git, GitHub i MKS/IMS, alati za praćenje projekata i grešaka poput Jira-e, zatim alati za automatizaciju projekata (CI/CD – Continuous Integration / Continuous Deployment) poput Jenkins-a, alati za automatsko testiranje softverskih modula kao što su Klockwork i GoogleTest, te mnogobrojni interni alati. Sve ovo omogućava efikasno upravljanje projektima, oraganizovanje, dokumentovanje i praćenje zahteva i specifikacija kroz alate kao što su Confluence i DOORS.

Kao što vidite, naša metodologija i alati su sve što vam treba da biste izgradili sofisticirane softverske sisteme koji se koriste u modernim vozilima. Agilnost je naše tajno oružje.

Raznovrsni uređaji koje smo ranije pomenuli imaju različite svrhe, ali svi dele nešto zajedničko – to su ugradbeni sistemi sa jednim ili više procesora, odnosno mikrokontrolera (Single-/Multi-Processors Embedded Systems). Pored toga, u Continental Automotive SMY svaki od ovih uređaja pripada jednoj od tri kategorije prema složenosti: Low-Line, Mid-Line i High-Line. Svaka naredna linija dodaje više funkcionalnosti u odnosu na prethodnu. Tipično, Low-Line uređaji su jednoprocesorski, dok su Mid-Line i High-Line uvek višeprocesorski sistemi.

Ovi uređaji obavljaju vremenski kritične funkcije koje zahtevaju brzu reakciju u stvarnom, realnom vremenu (Real-Time Systems) i minimalnu upotrebu procesorskih resursa. Za ove aplikacije, struktura i objekti sistema se kreiraju statički tokom kompajliranja i generisanja koda, a ne dinamički tokom izvršavanja. Te vremenski kritične aplikacije se izvršavaju na Real-Time procesoru (RC – Real-Time Controller), dok su servisi i aplikacije koje dozvoljavaju sporiji odgovor i duže vreme izvršavanja, često povezanim za obradu veće količine podataka, alocirani na Application procesoru (AC – Application Controller).

Na primer, kod Mid-Line i High-Line instrument panela, RC kontroler je odgovoran za obradu brzih digitalnih ulaza (npr. Wakeup signala koji treba da “probude“ odnosno startuju uređaj) i dijagnostičkih poruka na CAN mreži. Sa druge strane, AC kontroler upravlja displejom i grafičkim elementima što ne zahteva toliko brzo osvežavanje. RC i AC kontroleri razmenjuju podatke putem zaštićenog međuprocesorskog komunikacionog protokola (IPC – Inter-Processor Communication) putem fizičkih medijuma kao što su SPI (Serial Peripheral Interface) i USART (Universal Synchronous Asynchornous Receiver Transmiter) ili deljene memorije (Shared Memory) ukoliko su procesori u okviru istog čipa (SoC – System-on-Chip).

Recimo, kod High-Line telemetrijskih uređaja, može postojati više RC i više AC kontrolera integrisanih u jednom istom čipu (SoC). Svaki od RC kontrolera može imati svoju specifičnu ulogu, kao što su kontrola pristupa periferijama sistema, sigurnost i kriptovanje podataka, ili upravljanje glavnim vremenski kritičnim interfejsima kao što su CAN mreža, LIN mreža, tahograf, merna jedinica za inerciono kretanje (Accelerometer/Gyroscope), merna jedinica za stvarno vreme (Real Time Clock – RTC), temperaturni senzor i drugi. AC kontroleri obezbeđuju povezivanje vozila sa Cloud-om, infrastrukturom i drugim vozilima (V2X – Vehicle-to-Everything) i obezbeđuju pristup svim mrežnim interfejsima (Ethernet, Wifi, Bluetooth, GPS/GLONASS, GSM/LTE). Softver na AC kontrolerima koristi internu Linux

distribuciju (LEAP) prilagođenu primeni u automobilskoj industriji, zbog čega ih često nazivamo i Linux kontrolerima (LC).

Međutim, važno je napomenuti da potpuna funkcionalnost i sigurnost ovih uređaja dolazi do izražaja samo kroz integraciju sa RC kontrolerima i odgovarajućim softverom koji i dalje pripada “embedded” svetu. Ovo je i dalje ključ za ispravan, pouzdan i bezbedan rad uređaja, i to će verovatno tako ostati dugi niz godina.

Ali šta je to što čini naš RC softver tako sigurnim i stabilnim? To je arhitektura koja je bazirana na AUTOSAR Classic platformi. Ova organizacija omogućava stvaranje optimalnog softvera za upravljačke jedinice vozila i odgovarajuće Real-Time mikrokontrolere. AUTOSAR standard je prihvaćen (i napravljen) od strane svih vodećih kompanija u automobilskoj industriji (uključujući i Continental Automotive), što garantuje interoperabilnost i kvalitet softvera. AUTOSAR specificira programske module osnovnog softvera, njihovu funkcionalnost, ponašanje, atribute i servise, kako bi se omogućio pouzdan ali istovremeno brz razvoj uređaja uz ograničene resurse. To treba da omogući konkurentnost proizvođača vozila u aplikativnom sloju, a posledično, njihovo takmičenje da krajnjem korisniku vozila obezbede više pouzdanijih, bezbednijih i bogatijih funkcionalnosti uređaja.

Softver u RC kontrolerima je složen i po AUTOSAR-u organizovan u tri sloja:

1. Aplikacije (APP SW-Cs): Ovaj sloj obuhvata aplikacije ili aplikativne softverske komponente, koje mogu da kombinuju signale iz različitih podsistema ili sa različitih sistema i ostvaruju potrebnu zahtevanu logiku. Za neke namene, aplikacije nisu potrebne, kao što je slučaj kada RC funkcioniše kao “Gateway“ između različitih mrežnih interfejsa (npr. Ethernet-to-CAN).

2. Radno/izvršno okruženje (Runtime Environment – RTE): Ovaj sloj predstavlja okvir za izvršavanje koda i spregu između APP SW-Cs i BSW-a. On se koristi za mapiranje podataka, signala, događaja i izvršnih entiteta (glavnih funkcija/servisa) između aplikacija i BSW-a. RTE postavlja glavne funkcije, interfejse i servise u kontekst Real-Time operativnog sistema.

3. Osnovni softver (Basic Software – BSW): Ovo je srce RC softvera i može se podeliti u različite funkcionalne grupe i slojeve. Ove grupe uključuju sistemske servise (operativni sistem), komunikacione servise, dijagnostičke servise, servise za kriptovanje i zaštitu podataka, servise za upravljanje memorijom, servise za upravljanje ulazima/izlazima i kompleksne drajvere. Kompleksni drajveri su moduli kojim se obuhvataju specifični korisnički zahtevi koji nisu definisani standardom ili ih nije moguće implementirati jednostavno pomoću standardnih BSW modula. Tada se javlja potreba da BSW programeri dizajniraju i implementiraju posebne programske module, tzv. plugin-ove za AUTOSAR razvojno okruženje.

BSW programeri su pravi stručnjaci u svetu “embedded“ softvera. Moraju da savladaju različite proizvode, prateće sistemske koncepte i funkcionalnosti, standarde, mikrokontrolere, hardverske interfejse i periferije, komunikacione mreže i protokole, operativne sisteme za rad u stvarnom vremenu, kao i različite softverske alate (editori, kompajleri, debug okruženja, build okruženja, skripting programske jezike, okruženja za razvojni tok po AUTOSAR-u kao što su EB Tresos Studio i Autosar Builder i mnoga druga). Ovaj posao zahteva obimno znanje i veštine, ali omogućava stvaranje sofisticiranog softver inženjera koji je ključ nastanka savremenih upravljačkih jedinica u vozilima.

Ako ste tehnički nastrojeni entuzijasta i strastveni ste prema novim tehnologijama, Continental i poslovna jedinica Smart Mobility su mesto gde će vaša strast za automobilskom industrijom, vozilima i tehnologijom oživeti. U našem timu, vaša kreativnost i inovacije mogu napraviti razliku.

Zajedno gradimo sigurniju, pametniju i održivu budućnost na putevima širom sveta.