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.
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ă.
Operația oricărui soft-embedded se poate împărți în următorul set de pași (repetați ciclic):
Achiziția de date: citirea datelor de senzori de la pinii microcontrollerului;
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);
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);
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.
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ă:
Asigurarea cantității necesare de oxigen pentru reacție;
Asigurarea valorilor potrivite pentru mărimi fizice semnificative pentru sistemul de aer (precum, presiune, temperatură);
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.
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:
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;
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;
Testare concomitentă cu implementarea: pe măsură ce o componentă devine testabilă, se și face validarea ei;
Ca în dezvoltarea oricărui produs software, este nevoie de:
Prototipare în timpul dezvoltării: developerul își testează continuu codul în timp ce încă-l dezvoltă, pentru a primi feedback instant;
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.
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:
Distrugerea sistemului;
Daune colaterale la aparatura implicată în test;
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
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:
Emularea codului embedded într-un mediu desktop. Acest lucru se poate întâmpla de la nivel de instrucțiuni de procesor în sus;
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:
Software-ul nu este emulat într-un mediu desktop, ci rulează nativ pe hardware-ul target (microcontroller-ul de pe ECU);
O parte din simulare încă rulează pe PC, în cazul HIL-ului acesta fiind obligatoriu de tipul RTCP (real-time PC), deoarce trebuie să ofere comportament temporal fidel sistemului real;
Totul este conectat printr-un ham de cabluri (wiring harness):
Semnalele simulate sunt conectate la generatoarea de semnale electrice, conectate la RTPC-ul ce rulează modelele;
