ARHITECTURA SOFTWARE PENTRU UNITATEA ELECTRONICĂ DE CONTROL

Drd. Ing. Călin ICLODEAN, Prof. Dr. Ing. Nicolae BURNETE

ABSTRACT:

Unitatea electronică de control sau ECU este echipamentul cu cea mai dinamică expansiune în industria auto. Clasificarea unităților electronice de control din punct de vedere al arhiecturii software asigură posibilitatea de a dezvolta componentele software ca aplicații deschise care se pot adapta ușor pentru diverse modele de autovehicule, nu doar pentru un singur producator ci pentru mai mulți producători, permițând astfel o reducere semnificativă a costurilor de cercetare, dezvoltare și implementare în producție.

Deoarece un autovehicul modern are peste 100 de sisteme electronice de comandă și control, prin această lucrare s-a făcut o clasificare a unităților electronice de control din punct de vedere a categoriilor de sisteme pe care le deservesc. Pentru fiecare categorie s-a evidențiat structura arhitecturii software care intră în componența 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 funcționarea autovehiculului pentru comanda și controlul unor anumiți parametri. Modulele electronice de control ale motoarelor, au fost utilizate în primul rând 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 componența autovehiculelor includ următoarele sisteme: de control al motorului, de control al sistemului de frânare și tracțiune, de control al stării de croazieră, de control al instrumentației de bord, de siguranță a pasagerilor, de funcționalități multimedia, de confort și de comunicare.

Principiul după care funcționează modulele de control electronice ECU este introducere date – prelucrare date – debitare date IPO (Input – Process – Output). Pentru înregistrarea valorilor sunt disponibili senzorii care măsoară 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 măsurată și valoarea memorată în ECU nu se potrivesc, modulul de control electronic reglează valoarea printr-un proces fizic, astfel încât valorile reale măsurate să corespundă cu dimensiunile nominale programate în ECU. Pentru comanda modificării valorilor unor anumiți parametri se folosesc actuatoare [1].

Înainte de apariția modulelor electronice de control ECU, sistemele de aprindere electronică erau construite cu circuite electronice analogice, dar dezvoltarea tehnologică a adus unitățile 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 situații în funcție de datele pe care le are memorate. Dimensiunile acestui computer diferă în funcție de complexitatea sarcinilor sale de la un sistem cu un microprocesor Microchip sau Motorola și cu memorie nevolatilă, până la sisteme complexe multiprocesor cu memorii reprogramabile de tip flash.

Programarea modulelor electronice de control ECU este realizată prin înscripționarea datelor stabilite de către producător î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 informațiile care se referă la condițiile de funcționare și alte date relevante ale autovehiculului, sunt utilizate diferite sisteme de comunicare: magistrala CAN (Controller Area Network), magistrala LIN (Local Interconnect Network), rețeaua MOST (Media Oriented Systems Transport), rețeaua FlexRay, etc. Prin intermediul acestor sisteme de comunicare se poate face legătura 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 aplicații.

2. INFORMAȚII

Evoluția și dezvoltarea sistemelor ECU a fost direct proporțională cu evoluția și

dezvoltarea autovehiculelor. Primele modele de sisteme ECU au fost construite pe baza unei arhitecturi hardware, fără a avea nici o componentă software integrată. Aceste modele erau costisitoare și limitate ca funcționalitate și adaptabilitate și au fost înlocuite odată cu apariția microcontrolerelor în industria autovehiculelor. Apariția microcontrolerelor a redus complexitatea și costurile realizării unei unității electronice de control, iar modelele constructive au devenit adaptabile, configurarea funcțiilor și a parametrilor realizându-se din aplicațiile software.

Funcționalitatea sistemelor ECU este asigurată de către software-ul sistemului. Comparativ cu perioada de început a implementării sistemelor ECU în industria auto, în prezent ponderea componentelor hardware a scăzut 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 cât 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 interfețe grafice care generează componenta software pentru sistemele ECU. Astfel mai mult de jumătate din produsele software care intră în componența aplicației 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 către diverși producători:

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

Durata ciclului de viață pentru un astfel de model este de până la 25 ani, din care faza de proiectare și dezvoltare a prototipului este de trei ani, faza de producție în serie de până la șapte ani și faza de exploatare de până la 15 ani.

Arhitectura software a unității electronice de control este prezentată în figura 2. Componente software care acoperă aspectele legate de partea hardware de intrare / ieşire (I/O), sunt grupate în stratul de abstractizare hardware HAL (Hardware Abstraction Layer) conținut în platforma software a standardului OSEK/VDX [10]. Unităţile 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 unitățile ECU din reţeaua de comunicare, sau cu instrumentele și dispozitivele de testare și de diagnosticare. Aceste componente software oferă interfeţe standardizate de programare a aplicaţiilor API (Application Programming Interfaces), interfațe care acceptă aplicații realizate de către diverși producători de autovehicule și care pot fi dezvoltate independent de hardware de bază [7]. Modalitatea de standardizare a tuturor componentelor pentru platformele software oferă un potenţial suplimentar cu privire la economiile costurilor de producție și a controlului calității [4].

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

Din 1994 standardul OSEK/VDX oferă o interfaţă open pentru programarea aplicațiilor

– API, care făcând abstracție de hardware-ul folosit la bază facilitează proiectarea sistemelor de operare în timp real. Standardul OSEK/VDX defineşte un modul pentru nucleul aplicației (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-biți sau pe 16-biți [10]. OSEK este standardul german pentru sisteme deschise şi interfeţele corespondente pentru electronica auto (Offene Systeme und deren Schnittstellen für die Elektronik im Kraftfahrzeug), iar VDX este standardul francez pentru comunicare între sistemele componente (Vehicle Distributed eXecutive).

Sistemele software dezvoltate pentru unitățile electronice de control sunt specifice fiecarui model de autovehicul și se clasifica în următoarele categorii:

1. Sisteme ECU cu control asupra emisiilor de noxe obținute î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 aplicațiilor care rulează în sistem; Network Control este modulul de control al magistralei de comunicație; 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 aplicațiilor Application Control Controlul magistralei de comunicație 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 producție a sistemului de operare în timp real

RTOS al unității ECU şi al modulul de control al magistralei de comunicație și coordonare (Network Control), consorţiul european al producătorilor 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 fără control asupra emisiilor de noxe includ sisteme electronice,

electrice și mecanice a căror funcționare nu au legatură cu emisiile de noxe, spre exemplu unitatea centrală care controlează funcțiile electronice ale autovehiculului BSC (Body System Control), modulul de control al unghiului de virare SAS (Steering Angle Sensor), modulul de control al frânării 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 fără control asupra emisiilor este similară cu arhitectura software folosită de sistemele ECU cu control asupra emisiilor, având aceeași structură software de bază diferențele apărând doar la nivelele critice de siguranță.

3. Sisteme ECU pentru echipamentele telematice (Telematic System) integrează echi-

pamentele de telecomunicații și informatică care oferă informații 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ă

urmărirea şi dispecerizarea terminalului mobil de date MDT (Mobile Data Terminal). Această tehnologie oferă acces în timp real la infrastructura de comunicaţii de date

pentru serviciile telematice, spre exemplu date despre poziţia geografică a vehiculului urmărit şi posibilitatea de comunicare cu acesta prin transmiterea și recepționarea de pachete de informații.

Arhitectura este compusă din nouă componente software care includ modulele: Application Control este modulul de control al aplicațiilor 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 către sistemele de monitorizare;

Mobile Communication este modulul care stabilește o legătură de comunicare cu operatorul de servicii telematice;

Network Control este modulul de control al magistralei de comunicație și coordonare;

OS in Real Time (RTOS) este sistemul de operare în timp real; User Interface Management este interfața cu utilizatorul care asigură interacţiunea cu

conducătorul autovehiculului; GPS Control este modulul care asigură legătura cu satelitul de comunicații și care

colectează date despre poziţia 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 aplicațiilor Application Control Operator comunicații mobile Mobile Communication Controlul magistralei de comunicație Network Control Sistem de operare în timp real RTOS – OS in Real Time Interfața cu utilizatorul User Interface Management Modulul de control al poziției 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 comunicații ș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 aplicații 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 Interfața cu utilizatorul User Interface Management Modul servicii instalare dispozitive Service Modul compatibilitate/portabilitate Intermediate Machine Control pentru caracteristici hardware Native Machine Controlul magistralei de comunicație 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 interfața cu utilizatorul care integrează şi prezintă

facilitățile oferite de către componentele modulului servicii în afişajul Infotainment; Service este modulul servicii care permite adăugarea ș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 conține mecanismul de control pentru caracteristicile hardware ale echipamentelor folosite;

Network Control este modulul de control al magistralei de comunicație; 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 comunicație folosite în diagnosticarea autovehiculului. Pe baza acestui set de protocoale de comunicație 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 către sistemul ECU şi primește răspunsul 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 interacţionează cu toate modulele sistemului ECU de la care colectează şi raportează eventualele stări de avarie stocate în memoria internă. Interfaţa 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 primește 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 către

testerul de diagnosticare extern; CAN Bus Data Link este magistrala de legătură 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 Interfața 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 Legătură sistem diagnosticare CAN Bus Data Link Adaptor conexiune radio Wireless Adaptor

3. CONCLUZII

Autovehiculele moderne integrează un număr tot mai mare de dispozitive electronice fapt care duce la creșterea complexității şi a costurilor în dezvoltarea și producerea de autovehicule. Pentru a reduce costurile de producție a autovehiculelor marile consorții 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 producție.

În Japonia există organizația JASPAR (Japan Automotive Software Platform and Architecture), organizaţie fondată în anul 2004 de către corporațiile Nissan şi Toyota în calitate de membri fondatori [8], iar în Europa există organizația AUTOSAR (Automotive Open System Architecture) [5], organizaţie fondată în anul 2003, organizații care gestionează dezvoltarea și implementarea acestor standarde.

4. NOTĂ:

Această lucrare a beneficiat de suport financiar prin proiectul "Creșterea calității studiilor doctorale în științe inginerești pentru sprijinirea dezvoltării societății bazate pe cunoaștere", contract: POSDRU/107/1.5/S/ 78534, proiect cofinanțat din Fondul Social European prin Programul Operațional 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] Schäuffele, 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).