ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 140
Numărul 139 Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 135
Abonament PDF

Vehicule electrice pe hidrogen – Verificare și validare în medii virtuale

Teofil Zaharia
Technical Expert @ Bosch Engineering Center Cluj



PROGRAMARE


Piața autovehiculelor este într-o schimbare majoră, numărul vânzărilor de modele electrice fiind într-o creștere fără precedent (iea.org, 2023). Acestea sunt reprezentate de vehicule ce folosesc bateria ca sursă unică de energie (BEV) și de cele hibride (PHEV/HEV). Printre ultimele se numără cele ce folosesc arderea combustibililor fosili în sinergie cu bateria, dar și o categorie mai puțin cunoscută, anume a vehiculelor electrice cu pile de combustie (FCEV, Fuel Cell Electric Vehicle). Fiecare dintre aceste categorii a adus noi provocări tehnice, în domeniul HW precum și SW. Scopul acestui articol este să prezinte metodologii și soluții pentru testarea SW în automotive, cu exemple specifice pentru FCEV-uri pe hidrogen.

Hydrogen FCEV - Sistemul fizic

Molecule de hidrogen sunt separate în protoni și electroni, recombinându-se cu atomii de oxigen să formeze apă

FCEV-urile sunt vehicule ce obțin energia electrică din pile de combustie (fuel cells), dispozitive ce induc o reacție chimică într-un mod foarte similar cu cel al bateriilor. Rezultatul acestei reacții este un flux de electroni în circuitul extern (conectat la bornele celulelor) și un flux de ioni pozitivi în interiorul celulei ce trece printr-un separator. Separarea sarcinilor produce o tensiune la bornele celulei și, cu ajutorul curentului electric extern, furnizează putere electrică la o sarcină conectată. Acest proces este ilustrat pentru o celulă de hidrogen într-un videoclip de pe site-ul Bosch (bosch.com, 2023), de unde a fost luată diagrama alăturată. Marea diferență față de baterii o reprezintă locul de stocare a reactanților. În contrast cu bateriile ce stochează reactanții în interiorul carcasei, pilele de combustie iau reactanții din exterior. Combustibilul în sine (metan, metanol sau ca în cazul de față, hidrogen) este stocat în rezervoare. Agentul oxidant (oxigenul molecular în cazul nostru) este luat din aer. Se observă că situația de alimentare este foarte similară cu aceea a vehiculelor cu ardere internă (IC, Internal Combustion). Următoarea diagramă de sistem sublinează și mai mult această asemănare (bosch.com, 2023):

Figura 1 prezintă un sistem FC pe hidrogen comandat complet electronic, similar cu cel al unui vehicul modern IC. Putem identifica sistemul de alimentare cu aer, unde compresorul (Fig. 1/5 Electric Air Compressor) alimentează stiva de pile de combustie (Fig. 1/4 Fuel Cell Stack) cu aer bogat în oxigen (înainte de reacție se consideră bogat). Similar și pentru sistemele de stocare, alimentare și injecție de combustibil, Figura 1 prezintă rezervoarele de hidrogen (Fig. 1/cei doi cilindri verzi din dreapta), conductele de hidrogen și injectorul (Fig1/3 Hydrogen gas injector).

Figura 1: Diagramă sistem FC complet, cu componente Bosch

Controlul electronic al tuturor componentelor din Figura 1 este făcut dintr-un ECU (Electronic Control Unit) specializat pentru această aplicație. Acesta primește semnale de la toți senzorii (de exemplu, senzori de presiune, temperatură) și comandă toți actuatorii (de exemplu, compresor, valve, injector). Datorită domeniul foarte specific de aplicație, ECU-ul a fost denumit FCCU (Fig1/Fuel Cell Control Unit).

Toate acestea luate la un loc ne dau un indiciu despre complexitatea sistemului, și implicit a software-ului de comandă.

Software Embedded în Automotive - Arhitectură generală

Operația oricărui soft-embedded se poate împărți în următorul set de pași (repetați ciclic):

  1. Achiziția de date: citirea datelor de senzori de la pinii microcontrollerului;

  2. Modelarea stării sistemului: calcularea unei reprezentări abstracte, adică un rezumat, al factorilor fizici importanți pentru sistem (de exemplu, sistem-oprit, sistem-pornit, sistem-supraîncălzit);

  3. Luarea deciziilor: calculul punctelor de referință fizice ce reflectă intenția curentă pentru sistem (de exemplu, pornește sau oprește sistemul, crește puterea furnizată), luând în considerare starea actuală a acestuia (determinată la pasul anterior);

  4. Transformarea punctelor de referință anterioare high-level, în semnale mai low-level de reglaj pentru actuatori (de exemplu, PWM pentru reglaj de motor), și transmiterea lor, cu speranța că acestea vor face ca sistemul să evolueze în starea dorită.

Putem observa o suprapunere cu modelul sense-think-act folosit în robotică (roboticsbook.org, 2022).

Având în vedere principiile de proiectare software, mai ales cel al separării pe componente software diferite a funcționalităților diferite (Martin, 2005), obținem o arhitectură de tip layered (stratificată). Cea mai cunoscută arhitectură din domeniu ce urmează acest model este AUTOSAR (autosar.org, 2023), o diagramă simplificată fiind prezentată în Figura 2 (embitel.com, 2018).

Figura 2: Categoriile majore de componente SW în arhitectura AUTOSAR (embitel.org, 2018)

Ideea din spatele arhitecturii layered în domeniul embedded este de a permite aplicațiilor software (de exemplu, buclele de reglaj pentru diversele sisteme mecanice) să ruleze și să fie dezvoltate independent de interfețe-software specifice pentru un anumit hardware. Astfel, aplicațiile pot fi proiectate pentru interfețe standardizate (AUTOSAR este un astfel de standard) și abstracte, ce ascund detalii specifice hardware-ului. Din această privință, mediul devine conceptual similar cu cel desktop, unde se apelează la funcționalități low-level prin OS și prin drivere implicite.

Ierarhia de cerințe și de componente software

Aplicațiile embedded sunt componente software ce implementeză un set de funcții. Putem lua ca exemplu funcția de aprovizionare cu aer a stivei de pile de combustie (Figura 3):

Figura 3: Sistemul de aprovizionare cu aer al stivei, constând în principal din compresor și valve

Funcția de aprovizionare constă dintr-un set de funcții de un nivel inferior (lower-level), fiecare rezolvând o subproblemă:

Aceste subprobleme (și altele care nu sunt menționate) sunt rezolvate în subcomponente software ce alcătuiesc componenta principală de aprovizionare cu aer (aplicația), formând o ierarhie. În interiorul acesteia, ele fac schimb de date și implementează cerințe specifice, contribuind la realizarea sarcinii principale.

Metodologii software de dezvoltare și testare - Modelul V

Având în vedere natura ierarhică a sistemelor, procesul de dezvoltare și testare va reflecta aceeași structură. Standardul din industrie este Modelul V, care are la bază următoarele principii:

  1. Proiectare top-down: cerințe abstracte și cuprinzătoare (la nivel de sistem) se rafinează în cerințe tot mai atomice, dând naștere de la arhitectură la sub-module;

  2. Implementare bottom-up: cerințele cele mai atomizate se implementează primele, sub-modulele rezultate fiind integrate (compuse) în module ce îndeplinesc cerințe de un nivel de abstractizare tot mai înalt;

  3. Testare concomitentă cu implementarea: pe măsură ce o componentă devine testabilă, se și face validarea ei;

  4. Reproiectare (cu reimplementare și retestare): pe măsură ce apar rezultatele testelor, în cazul în care se descoperă o nepotrivire dintre cerințe și funcționalitatea sistemului propriu-zis, se repetă acest ciclu de dezvoltare și testare pentru componentele afectate;

Simulare și evaluare - Tehnici de testare

Testare SW în general - particularități embedded

Ca în dezvoltarea oricărui produs software, este nevoie de:

  1. Prototipare în timpul dezvoltării: developerul își testează continuu codul în timp ce încă-l dezvoltă, pentru a primi feedback instant;

  2. Testare pentru verificare și validare: se rulează teste automate pentru a determina câte dintre cerințe sunt acoperite de software în momentul respectiv. În domeniul automotive se generează și stochează rapoartele de test, având valoare legală pe termen lung.

Scopul oricărui proces de verificare și validare este să se evalueze dacă sistemul este potrivit pentru sarcina pentru care a fost dezvoltat. În lumea embedded, cerințele implică de obicei un sistem electro-mecanic, ceea ce se reflectă și în evaluarea lui. Aici se poate găsi și cea mai mare diferență față de testarea software-ului clasic, unde este suficientă simularea(folosirea) exclusivă a hardware-ului de calcul.

Nevoia simulării sistemelor în dezvoltarea software-ului embedded

Dacă cerințele descriu funcționarea unui sistem fizic ce constă din senzori și actuatori ( de pildă, o mașină autonomă), și testarea ar trebui să implice rularea softului pe sistemul țintit. Riscurile majore ale acestei abordări sunt:

Pentru a reduce aceste riscuri, a devenit standard dezvoltarea unui model matematic pentru partea fizică/chimică, care este folosit în simulări, înainte să se facă testele finale pe sistemul propriu-zis.

Figura 5: Mediu SIL pentru testarea sistemului software

Modelare și simulare - Testare SIL și HIL

Modelul unui sistem este valoros numai dacă poate fi folosit pentru testarea cerințelor sistemului iar costul dezvoltării lui nu-l depășește pe cel al sistemelor fizice simulabile cu acesta.

Luând ca exemplu sistemul de aprovizionare cu aer la Fuel Cell, putem vedea că este un sistem pneumatic. Simularea lui va presupune modelarea unui sistem pneumatic uzual, cu compresor, valve, ducte etc.

Din punctul de vedere al testării software, valoarea modelului constă în conectarea senzorilor și a actuatorilor simulați la o instanță a programului testat. Acest lucru se întâmplă în doi pași:

  1. Emularea codului embedded într-un mediu desktop. Acest lucru se poate întâmpla de la nivel de instrucțiuni de procesor în sus;

  2. Conectarea emulării la semnale din model, care reprezintă senzori (SW-input, Model-output) și actuatori (SW-output, Model-input), simulând situația când softul primește aceste valori de la hardware. Acest tip de set-up se numește Software-in-the-Loop (SIL), datorită faptului că închide bucla dintre proces (modelul din simulare) și regulator (implementat în codul embedded). Precum s-a menționat, softul va citi valori de la senzorii simulați, va face calcule interne și va scrie valori de comandă pentru a aduce sistemul simulat în starea dorită.

O tehnică mai elaborată ce acoperă testarea și a părții hardware (i.e. a ECU-ului), se numește Hardware-in-the-Loop (HIL). Este similară cu SIL, cu câteva diferențe cheie:

Referințe

  1. autosar.org. (2023).
  2. bosch.com. (2023).
  3. embitel.com. (2018).
  4. iea.org. (2023).
  5. Martin, R. C. (2005).
  6. roboticsbook.org. (2022).

NUMĂRUL 138 - Maps & AI

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • Connatix
  • BoatyardX
  • .msg systems
  • Yardi
  • Colors in projects

INTERVIURI VIDEO