ARHITECTURA SOFTWARE PENTRU UNITATEA ELECTRONIC DE CONTROL

Drd. Ing. Clin ICLODEAN, Prof. Dr. Ing. Nicolae BURNETE

ABSTRACT: Unitatea electronic de control sau ECU este echipamentul cu cea mai dinamic expansiune n industria auto. Clasificarea unitilor electronice de control din punct de vedere al arhiecturii software asigur posibilitatea de a dezvolta componentele software ca aplicaii deschise care se pot adapta uor pentru diverse modele de autovehicule, nu doar pentru un singur producator ci pentru mai muli productori, permind astfel o reducere semnificativ a costurilor de cercetare, dezvoltare i implementare n producie. Deoarece un autovehicul modern are peste 100 de sisteme electronice de comand i control, prin aceast lucrare s-a fcut o clasificare a unitilor electronice de control din punct de vedere a categoriilor de sisteme pe care le deservesc. Pentru fiecare categorie s-a evideniat structura arhitecturii software care intr n componena acesteia. Cuvinte cheie: unitatea electronic de control ECU, arhitectura software, sistem de operare n timp rea, magistrala de comunicare CAN, conectorul de diagnosticare OBD. 1. INTRODUCERE Unitatea Electronic de Control ECU (Electronic Control Unit) este un complex de module electronice care este folosit n funcionarea autovehiculului pentru comanda i controlul unor anumii parametri. Modulele electronice de control ale motoarelor, au fost utilizate n primul rnd pentru reglarea aprinderii acestora. Din anul 1987 aceste module electronice au fost folosite pentru reglarea aprinderii i la motoarele diesel, iar din anii `90 sistemele de reglare mecanice la toate motoarele cu combustie intern, au fost nlocuite cu modulele de control electronice. Modulele de control electronice ECU din componena autovehiculelor includ urmtoarele sisteme: de control al motorului, de control al sistemului de frnare i traciune, de control al strii de croazier, de control al instrumentaiei de bord, de siguran a pasagerilor, de funcionaliti multimedia, de confort i de comunicare. Principiul dup care funcioneaz modulele de control electronice ECU este introducere date prelucrare date debitare date IPO (Input Process Output). Pentru nregistrarea valorilor sunt disponibili senzorii care msoar o caracteristic fizic, cum ar fi viteza, presiunea, temperatura, etc. Aceast valoare este comparat sau calculat cu o valoare standard stocat n memoria ECU. n cazul n care valoarea msurat i valoarea memorat n ECU nu se potrivesc, modulul de control electronic regleaz valoarea printr-un proces fizic, astfel nct valorile reale msurate s corespund cu dimensiunile nominale programate n ECU. Pentru comanda modificrii valorilor unor anumii parametri se folosesc actuatoare [1]. nainte de apariia modulelor electronice de control ECU, sistemele de aprindere electronic erau construite cu circuite electronice analogice, dar dezvoltarea tehnologic a adus unitile ECU de azi la nivelul de a fi nzestrate cu un sistem propriu de inteligen (Embedded System), care const ntr-un computer separat care este programat s decid n diverse situaii n funcie de datele pe care le are memorate. Dimensiunile acestui computer difer n funcie de complexitatea sarcinilor sale de la un sistem cu un microprocesor Microchip sau Motorola i cu memorie nevolatil, pn la sisteme complexe multiprocesor cu memorii reprogramabile de tip flash.

Programarea modulelor electronice de control ECU este realizat prin nscripionarea datelor stabilite de ctre productor n memoria nevolatil ROM (Read Only Memory), memorie care poate fi doar citit dup programare [1]. Unele sisteme moderne permit ns actualizarea datelor din modulele electronice de control ECU, prin reprogramarea memoriei flash folosind aparatur electronic de specialitate. Pentru a accesa informaiile care se refer la condiiile de funcionare i alte date relevante ale autovehiculului, sunt utilizate diferite sisteme de comunicare: magistrala CAN (Controller Area Network), magistrala LIN (Local Interconnect Network), reeaua MOST (Media Oriented Systems Transport), reeaua FlexRay, etc. Prin intermediul acestor sisteme de comunicare se poate face legtura la conectorii OBD (On Board Diagnostigs) [2]. Aceste sisteme de comunicare pot fi conectate la aparatele de diagnosticare sau la calculatoare personale (notebook), pentru diagnosticare sau pentru programarea diverselor aplicaii. 2. INFORMAII Evoluia i dezvoltarea sistemelor ECU a fost direct proporional cu evoluia i dezvoltarea autovehiculelor. Primele modele de sisteme ECU au fost construite pe baza unei arhitecturi hardware, fr a avea nici o component software integrat. Aceste modele erau costisitoare i limitate ca funcionalitate i adaptabilitate i au fost nlocuite odat cu apariia microcontrolerelor n industria autovehiculelor. Apariia microcontrolerelor a redus complexitatea i costurile realizrii unei unitii electronice de control, iar modelele constructive au devenit adaptabile, configurarea funciilor i a parametrilor realizndu-se din aplicaiile software. Funcionalitatea sistemelor ECU este asigurat de ctre software-ul sistemului. Comparativ cu perioada de nceput a implementrii sistemelor ECU n industria auto, n prezent ponderea componentelor hardware a sczut de la 80% la 60%, iar ponderea componentelor software a crescut de la 20% la 40%, conform studiilor AUTOSAR. n prezent un ciclu complet de proiectare a unui prototip pentru un sistem ECU dureaz ntre 24 i 36 luni, fa de 60 luni ct dura acest ciclu n urm cu 10 ani [5]. Pentru reducerea semnificativ a costurilor generate de implementarea componentelor software, n prezent se folosesc programe specializate cu interfee grafice care genereaz componenta software pentru sistemele ECU. Astfel mai mult de jumtate din produsele software care intr n componena aplicaiei sunt implementate sub form grafic. Testarea unui sistem ECU se face pe parcursul ntregului proces de proiectare, fiecare etap de lucru fiind supus unor teste specifice: teste pentru modele create, teste de simulare n laborator i teste de validare a rezultatelor pe autovehicul. Dezvoltarea unui sistem ECU se bazeaz pe modelul n V prezentat n figura 1, [4] unde fiecare din etapele de proiectare, testare, verificare i validare implic instrumente hardware i software furnizate de ctre diveri productori:

Fig. 1. Modelul V n dezvoltarea sistemelor ECU [4]

Durata ciclului de via pentru un astfel de model este de pn la 25 ani, din care faza de proiectare i dezvoltare a prototipului este de trei ani, faza de producie n serie de pn la apte ani i faza de exploatare de pn la 15 ani. Arhitectura software a unitii electronice de control este prezentat n figura 2. Componente software care acoper aspectele legate de partea hardware de intrare / ieire (I/O), sunt grupate n stratul de abstractizare hardware HAL (Hardware Abstraction Layer) coninut n platforma software a standardului OSEK/VDX [10]. Unitile de I/O necesare pentru comunicarea cu alte sisteme prin intermediul magistralei de date sunt excluse din stratul de abstractizare HAL. Platforma software include componente software din straturile de nivel superior care se folosesc n comunicarea cu unitile ECU din reeaua de comunicare, sau cu instrumentele i dispozitivele de testare i de diagnosticare. Aceste componente software ofer interfee standardizate de programare a aplicaiilor API (Application Programming Interfaces), interfae care accept aplicaii realizate de ctre diveri productori de autovehicule i care pot fi dezvoltate independent de hardware de baz [7]. Modalitatea de standardizare a tuturor componentelor pentru platformele software ofer un potenial suplimentar cu privire la economiile costurilor de producie i a controlului calitii [4].

Fig. 2: Arhitectura software pentru ECU (OSEK/VDX) [4]

Din 1994 standardul OSEK/VDX ofer o interfa open pentru programarea aplicaiilor API, care fcnd abstracie de hardware-ul folosit la baz faciliteaz proiectarea sistemelor de operare n timp real. Standardul OSEK/VDX definete un modul pentru nucleul aplicaiei (kernel) n timp real care este o interfa ntre software i hardware n care pot fi implementate diverse modele software n module de memorie pe 8-bii sau pe 16-bii [10]. OSEK este standardul german pentru sisteme deschise i interfeele corespondente pentru electronica auto (Offene Systeme und deren Schnittstellen fr die Elektronik im Kraftfahrzeug), iar VDX este standardul francez pentru comunicare ntre sistemele componente (Vehicle Distributed eXecutive). Sistemele software dezvoltate pentru unitile electronice de control sunt specifice fiecarui model de autovehicul i se clasifica n urmtoarele categorii: 1. Sisteme ECU cu control asupra emisiilor de noxe obinute n urma procesului de ardere care includ sistemul de control al motorului i sistemul de control a transmisiei. Aceast clas de sisteme ECU are rolul de a controla modulele electronice, mecanice i hidraulice printr-un altgoritm de control n timp real [3]. Arhitectura software este compus din apte componente care includ modulele:

 Application Control este modulul de control al aplicaiilor care ruleaz n sistem; Network Control este modulul de control al magistralei de comunicaie; OS in Real Time (RTOS) este sistemul de operare n timp real; Senzor Control este modulul de controlul al senzorilor; Actuator Control este modulul de control al actuatoarelor; On Board Diagnostic este modulul de diagnosticare intern; Self Test este modulul de autotestare al echipamentelor hardware. Diagrama arhitecturii software pentru aceast categorie este prezentat n tabelul 1.
Tabel 1 Sistemele ECU cu control asupra emisiilor de noxe Denumirea modulului Name of the module Controlul aplicaiilor Application Control Controlul magistralei de comunicaie Network Control Sistem de operare n timp real RTOS OS in Real Time Controlul senzorilor Senzor Control Controlul actuatoarelor Actuator Control Diagnosticare intern On Board Diagnostic Autotestare echipamente Self Test

Pentru a reduce costurile de dezvoltare i producie a sistemului de operare n timp real RTOS al unitii ECU i al modulul de control al magistralei de comunicaie i coordonare (Network Control), consoriul european al productorilor de autovehicule AUTOSAR a dezvoltat o viziune comun asupra arhitecturii software-ului de baz care s acopere aceste dou componente software [5]. 2. Sisteme ECU fr control asupra emisiilor de noxe includ sisteme electronice, electrice i mecanice a cror funcionare nu au legatur cu emisiile de noxe, spre exemplu unitatea central care controleaz funciile electronice ale autovehiculului BSC (Body System Control), modulul de control al unghiului de virare SAS (Steering Angle Sensor), modulul de control al frnrii BCM (Break Control Module), etc. [3]. Aceast clas de sisteme ECU au rolul de a controla modulele electronice, mecanice i hidraulice printr-un altgoritm de control n timp real. Arhitectura software folosit de sistemele ECU fr control asupra emisiilor este similar cu arhitectura software folosit de sistemele ECU cu control asupra emisiilor, avnd aceeai structur software de baz diferenele aprnd doar la nivelele critice de siguran. 3. Sisteme ECU pentru echipamentele telematice (Telematic System) integreaz echipamentele de telecomunicaii i informatic care ofer informaii despre i pentru autovehicul prin intermediul sistemului de transport inteligent ITS (Intelligent Transport System) [3]. Sistemul telematic este format din trei module: modulul de la bordul autovehiculului OBU (On Board Unit); infrastructura de conectare prin satelit sau GPS (Global Positioning System); sistemele de monitorizare la distan: ETC (Electronic Toll Collection), care asigur urmrirea i dispecerizarea terminalului mobil de date MDT (Mobile Data Terminal). Aceast tehnologie ofer acces n timp real la infrastructura de comunicaii de date pentru serviciile telematice, spre exemplu date despre poziia geografic a vehiculului urmrit i posibilitatea de comunicare cu acesta prin transmiterea i recepionarea de pachete de informaii. Arhitectura este compus din nou componente software care includ modulele: Application Control este modulul de control al aplicaiilor care ruleaz n sistem, care integreaz datele colectate de la senzorul de control i de la componentele sistemului GPS i dup asocierea acestora cu datele predefinite trimite rezultatele ctre sistemele de monitorizare;

 Mobile Communication este modulul care stabilete o legtur de comunicare cu operatorul de servicii telematice; Network Control este modulul de control al magistralei de comunicaie i coordonare; OS in Real Time (RTOS) este sistemul de operare n timp real; User Interface Management este interfaa cu utilizatorul care asigur interaciunea cu conductorul autovehiculului; GPS Control este modulul care asigur legtura cu satelitul de comunicaii i care colecteaz date despre poziia geografic a autovehiculului; Senzor Control este modulul de controlul al senzorilor; On Board Diagnostic este modulul de diagnosticare intern; Self Test este modulul de autotestare al echipamentelor hardware. Diagrama arhitecturii software pentru sistemele telematice este prezentat n tabelul 2.
Tabel 2 Sistemele ECU pentru echipamentele telematice Denumirea modulului Name of the module Controlul aplicaiilor Application Control Operator comunicaii mobile Mobile Communication Controlul magistralei de comunicaie Network Control Sistem de operare n timp real RTOS OS in Real Time Interfaa cu utilizatorul User Interface Management Modulul de control al poziiei geografice GPS Control Controlul senzorilor Senzor Control Diagnosticare intern On Board Diagnostic Autotestare echipamente Self Test

4. Sisteme ECU pentru echipamentele de divertisment i informare (Infotainment) gestioneaz toate echipamentele electronice de comunicaii i divertisment cu care este dotat autovehiculul: modulul AUD (AUDio Management) format din receptorul radio i CD / DVD, MP3, modulul de redare media MP (Media Player) format din aparatul TV digital, conexiunile de internet wireless, Bluetooth i 3G [9]. Pentru reducerea costurilor de implementare a sistemelor infotainment a fost dezvoltat sistemul OSGi (Open Service Gateway initiative), care este compus dintr-un set de aplicaii software dinamice formate din componente sofware adaptabile pe diverse structuri hardware [3]. Diagrama arhitecturii software pentru aceste sisteme este prezentat n tabelul 3.
Tabel 3 Sistemele ECU pentru echipamentele Infotainment Denumirea modulului Name of the module Interfaa cu utilizatorul User Interface Management Modul servicii instalare dispozitive Service Modul compatibilitate/portabilitate Intermediate Machine Control pentru caracteristici hardware Native Machine Controlul magistralei de comunicaie Network Control Sistem de operare n timp real RTOS OS in Real Time Diagnosticare intern On Board Diagnostic Autotestare echipamente Self Test

Arhitectura este compus din nou componente software care includ modulele: User Interface Management este interfaa cu utilizatorul care integreaz i prezint facilitile oferite de ctre componentele modulului servicii n afiajul Infotainment; Service este modulul servicii care permite adugarea i instalarea de dispozitive Infotainment suplimentare; Intermediate Machine este modulul care asigur compatibilitatea dispozitivelor hardware i portabilitatea produselor software folosite n sistemul Infotainment;

 Native Machine este modulul care conine mecanismul de control pentru caracteristicile hardware ale echipamentelor folosite; Network Control este modulul de control al magistralei de comunicaie; OS in Real Time (RTOS) este sistemul de operare n timp real; On Board Diagnostic este modulul de diagnosticare intern; Self Test este modulul de autotestare al echipamentelor hardware. 5. Sisteme ECU pentru diagnosticare extern (Off Board Diagnostic Tester) definesc un set de protocoale de comunicaie folosite n diagnosticarea autovehiculului. Pe baza acestui set de protocoale de comunicaie sistemul ECU are rolul de server de diagnosticare (Diagnostic Server), iar sistemul de diagnosticare extern are rolul de client de diagnosticare (Diagnostic Client) [3]. Clientul de diagnosticare trimite o cerere de colectare de date ctre sistemul ECU i primete rspunsul de service de la serverul de diagnosticare. Testerul de diagnosticare se conecteaz la magistrala de date a autovehiculului CAN, prin intermediul conectorului de testare OBD i interacioneaz cu toate modulele sistemului ECU de la care colecteaz i raporteaz eventualele stri de avarie stocate n memoria intern. Interfaa cu utilizatorul a testerului de diagnosticare faciliteaz comenzile de diagnosticare i vizualizarea rezultatelor [6]. Arhitectura este compus din apte componente software care includ modulele: User Interface Management este modulul care primete cererea de service de la utlizator i deschide o sesiune de diagnosticare (Diagnostic Session Service Control); Vehicle Model Database este baza de date cu valorile standard despre parametrii i caracteristicile tehnice ale autovehiculului; OS in Real Time (RTOS) este sistemul de operare n timp real; Diagnostic Sesion Service Control este sesiunea de diagnosticare i serviciul de control; CAN Bus Transport este magistrala de trasport a datelor de la sistemul ECU ctre testerul de diagnosticare extern; CAN Bus Data Link este magistrala de legtur cu testerul de diagnosticare extern; Wireless Adaptor asigur o conexiune radio la testerul de diagnosticare extern folosind tehnologie Wi-Fi, Bluetooth sau ZigBee. Diagrama arhitecturii software pentru aceste sisteme este prezentat n tabelul 4.
Tabel 4 Arhitectura software a sistemelor ECU pentru diagnosticare extern Denumirea modulului Name of the module Interfaa cu utilizatorul User Interface Management Baza de date a autovehiculului Vehicle Model Database Sistem de operare n timp real RTOS OS in Real Time Sesiune de diagnosticare Diagnostic Sesion Service Control Magistrala transport date CAN Bus Transport Legtur sistem diagnosticare CAN Bus Data Link Adaptor conexiune radio Wireless Adaptor

3. CONCLUZII Autovehiculele moderne integreaz un numr tot mai mare de dispozitive electronice fapt care duce la creterea complexitii i a costurilor n dezvoltarea i producerea de autovehicule. Pentru a reduce costurile de producie a autovehiculelor marile consorii auto au stabilit standarde de lucru pentru implementarea sistemelor electronice i pentru arhitectura software. Aceste standarde dezvoltate n comun asigur posibilitatea de reutilizare a

modelelor ECU pentru diverse tipuri constructive de autovehicule i n consecin reduc costurile de producie. n Japonia exist organizaia JASPAR (Japan Automotive Software Platform and Architecture), organizaie fondat n anul 2004 de ctre corporaiile Nissan i Toyota n calitate de membri fondatori [8], iar n Europa exist organizaia AUTOSAR (Automotive Open System Architecture) [5], organizaie fondat n anul 2003, organizaii care gestioneaz dezvoltarea i implementarea acestor standarde. 4. NOT: Aceast lucrare a beneficiat de suport financiar prin proiectul "Creterea calitii studiilor doctorale n tiine inginereti pentru sprijinirea dezvoltrii societii bazate pe cunoatere", contract: POSDRU/107/1.5/S/ 78534, proiect cofinanat din Fondul Social European prin Programul Operaional Sectorial Dezvoltarea Resurselor Umane 2007-2013. 5. BIBLIOGRAFIE [1] Bonnick, A., Automotive computer controlled systems diagnostic tools and techniques, Butterworth - Heinemann Ed., Oxford, UK (2001), ISBN: 0-7506-5089-3; [2] Bosch, R., CAN Specification version 2.0, Robert Bosch GmbH, Postfach 50, D-7000 Stuttgart 1, (1991); [3] See, W.-B., Vehicle ECU Classification and Software Architectural Implications, Technical report, Chia University, Taiwan, ROC, (2006); [4] Schuffele, J., Zurawka, T., Automotive Software Engineering Principles, Processes, Methods and Tools, SAE International, Warrendale, (2005), ISBN-10 0-7680-1490-5; [5] Website AUTOSAR: http://www.autosar. org/index.php?p=3&up=0&uup=0&uuup=0, (2012); [6] Website CIA-CAN: http://www.can-cia.org/index.php?id=can, (2012); [7] Website FLEXRAY: http://www.flexray.com/index.php?sid=626170724d85f586fa4dbaa 594b0cb02&pid=94&lang=de, (2012); [8] Website JASPAR: https://www.jaspar.jp/ english/guide/company.php, (2012); [9] Website MOST: http://www.mostcooperation.com/technology/most-network/index.html, (2012); [10] Website OSEK/VDX: http://portal.osekvdx.org/index.php?option=com_content&task =view&id=4&Itemid=3, (2012).