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