ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 150 Numărul 149 Numărul 148 Numărul 147 Numărul 146 Numărul 145 Numărul 144 Numărul 143 Numărul 142 Numărul 141 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 84
Abonament PDF

Importanța conceptului „Functional Safety” în dezvoltarea de produse SW automotive

Radu Ivănuș
Head of Advanced Embedded Technologies Business Unit @ NTT DATA Romania


PROGRAMARE

Încep povestea noastră prin a vă descrie ceea ce înseamnă un "ECU", un termen utilizat de regulă, în corelație cu zona automotive. Denumirea ECU provine din engleză: Electronic Control Unit, desemnând un echipament electronic, care conține mai multe componente electronice și cel puțin un microcontroler pe care rulează un software, fie scris în ASM sau C. Cu alte cuvinte, ECU-urile sunt calculatoarele din mașini.

Dacă la început mașinile nu erau echipate cu ECU-uri (Electronic Control Unit), începând cu anii 1970, acestea au devenit un echipament standard de echipare. Primul ECU introdus pe piață în anul 1968, a fost dedicat sistemului de alimentare cu combustibil al motorului și a fost produs de firma Bosch pentru mașini Volkswagen.

Mașinile actuale conțin sute de ECU-uri si milioane de linii de cod, ajungând la o putere de calcul și la o complexitate foarte mare. Odată cu extinderea mașinilor moderne care funcționează și sunt controlate de acestea, nevoia de funcționalități de siguranță a devenit "Functional Safety", de asemenea, inevitabilă.

ECU-urile au evoluat foarte mult de-a lungul anilor, atașându-li-se la ora actuală, alături de microcontrolere și microprocesoare. Pentru cei curioși în legătură cu sumarul evoluției ECU-ului de-a lungul anilor, expunem mai jos următoarele date:

Sursa imaginii: freightliner.com

Ca proces, siguranța funcțională ("funtional safety") a devenit o componentă esențială a ciclului de dezvoltare de soft pentru ECU. Aceste scheme de siguranță pentru automobile ajută la detectarea disfuncționalităților (electrice și electronice), și specifică acțiuni, tehnici și metode pentru a atenua riscurile și pagubele cauzate de erori la nivel de software și hardware.

Lipsa sau aplicarea incorectă a normelor de siguranță, poate avea consecințe grave: rănirea pasagerilor sau chiar pierderea de vieți omenești, care aduc după sine pierderi financiare și de imagine / brand pentru producătorii de mașini.

De aceea, în ziua de astăzi, automobilele moderne trebuie să respecte standardele internaționale de siguranță definite de ISO 26262: "Road vehicles - Functional safety"

Automotive Safety Integrity Level (ASIL) este o schemă de clasificare a riscurilor în cadrul standardului ISO 26262. Există definite patru nivele de siguranță în cadrul standardului: ASIL A, ASIL B, ASIL C și ASIL D. ASIL D dictează cel mai strict nivel de cerință safety asupra produsului , ASIL A fiind cel mai permisiv. Riscurile identificate ca QM ( "quality managed") nu implică nici o măsură separată de protecție.

Împărțirea nivelelor ASIL se face pe baza a trei considerente: frecvența de apariție (F), controlabilitate (C) și severitate (S) asupra erorii HW sau SW, unde Frecvența = Expunere * λ

Mai sus am descris care sunt nivelele de safety aplicate sistemelor, dar în cazul când nivelul ASIL maxim nu poate fi asigurat direct în sistem, standardul ISO26262 permite așa numita decompoziție a lor după cum este prezentată în imaginea de mai jos. Cu cât sistemul este cotat cu un nivel de safety ridicat, cu atât costurile de implementare HW si SW cresc. Când este aplicată decompoziția, ne ajută să împărțim sistemul în elemente redundante cu un nivel de siguranță mai redus, ceea ce duce la îndeplinirea cerințelor sistemului fără a afecta prea mult costurile.

În cele ce urmează, vă voi descrie modalități/exemple de metode aplicate în SW pentru a monitoriza și detecta erori în sistem.

Detecția, controlul și indicarea erorilor din sistem pe următoarele componente HW:

A. Erori la nivel de microcontroller:

Testarea și monitorizarea memoriei RAM (inclusiv CSA - Context Switch Area) și stiva de date (stack underflow/overflow), ROM și EEPROM.

typedef enum { 
  uint32 value; 
  uint32 complement; 
}Asil_Var32biti; 

Asil_Var32biti Modulel_Varl; 

/• function example to write safety variable */
void Modulel_WriteAsil32(Asil_Var32biti *var
   , uint32 val) 
{ 
  SuspendAlllnterrupts(); 
  #if (USE_COMPLEMENT != ON) /*redundant write */
  var->value = val; 
  var->complement = val; 
  #else /* or with complement */ 
  var->value = val; 
  var->complement = ~val; 
  #endif 
  ResumeAlllnterrupts(); 
}

/* function example to read safety variable */ 
uint32 Modulel_ReadAsil32(Asil_Var32biti* var) 
{ 
  uint32 loc_var = (uint32)0;
  SuspendAlllnterrupts(); 
  #if (USE_COMPLEMENT != ON) /*redundant read */
  if(var->value == var->complement) 
  #else /* or with complement */ 
  if(var->value == ~var->complement) 
  #endif 
  { 
    loc_var = var->value; 
    ResumeAlllnterrupts(); 
  } 
  else 
  {
    ResumeAlllnterrupts(); 
    /* RAM fault detected */ 
    ERROR_REACTION(); 
  }
  return loc_var; 
 }
 void main () 
 {
  /* ... */ 
  unit32 loc_var; 

  Modulel_WriteAsil32(&Modulel_Varl, 0xBEBEBEBE);
  /* code .... */ 
  loc_var = Modulel_ReadAsil32(&Modulel_Varl); 
    /* code .... */ 
}

B. Testarea și monitorizarea perifericelor: ADC (convertorul analogic), SPI, CAN și altele.

Convertorul ADC al microcontrolerului poate fi testat pentru a detecta următoarele erori:

C. Monitorizarea și detecția de erori la nivelul HW-ului/ sistemului ECU:

D. Monitorizarea execuției SW prin (PFM - Program Flow Monitor)

void Functionl(void) { 
  PfmStart(Threadl, 1) ; 
  /* function body, part 1 */
  FunctionX() ; 
  /* function body, part 2 */
  PfmEntry(Threadl, 2);
  /* function body, part 3 *I 
  FunctionY(); 
  /* function body, part 4 */
  PfmEntry(Threadl, 3) ; 
  /* function body, part 5 */
  FunctionZ(); 
  /* function body, part 6 */
  PfmEnd(Threadl); 
} 
main(void) {
  PfmStart(Thread2, 1);
  /* main body, part 1 */
  Functionl();
  /* main body, part 2 */
  PfmEnd(Thread2); 
}

E. Monitorizarea sistemului de operare - "OS tasks":

TASK(TASK_lOMS) 
{
  /* task's local variable definitions */
  StartTaskMon(TASK_lOMS); 
  ...
  /* task implementation */ 
  ...
  EndTaskMon(TASK_lOMS); 
  (void)TerminateTask(); 
}

e.g. Pentru un task de 2 milisecunde pe care îl dorim să-l monitorizam într-un interval de 10 milisecunde, ne vom aștepta să avem un număr de cinci execuții ale taskului de 2 mil în caz ideal; în mod normal, putem să calculăm și o toleranță de ±1 task, rezultând un interval corect de execuție, care poate fi cuprins între [4-6] execuții.

F. Monitorizarea și comunicarea cu Watchdogul extern (WDT). Acesta este un chip electronic care comunică cu microcontrolerul pe bază de SPI. Rolul lui este de a monitoriza corecta funcționare a microcontrolerului, fundamentat pe jocul QA (question and answer game) și generarea unui reset, în caz contrar.

Jocul QA funcționează pe baza generării aleatorii a unui set de 15 întrebări ( în funcție de un algoritm fixat dinainte) care sunt trimise către microcontroler pe linia de SPI în intervale de timp prestabilite.

Fiecărei întrebări îi corespunde un răspuns fix, prestabilit pe care WDT-ul îl așteaptă via SPI, în interval de timp configurat.

Pentru obține un nivel ridicat de siguranță, trebuie să efectuăm următoarele teste:

Nivelul ASIL dat sistemului este influențat de aplicabilitatea lui în vehicul: ce tip de ECU este și ce controlează (e.g. suspensie, transmisie, motor, scaune, system infotainment, etc.).

Important de menționat câțiva termeni care țin de zona de safety în automotive:

Fault Tolerant Time

Închei acest articol prin a vă prezenta, mai jos, un exemplu de arhitectură ECU control electrovalve sau motoare electrice, cu aplicabilitate în zona de transmisie automată, suspensie controlată sau control direcție. Componentele marcate cu buline roșii reprezintă zonele safety din sistem care trebuie monitorizate și controlate de SW pentru a atinge nivelul ASIL cerut. Exemplu de ECU generic ASIL C

NUMĂRUL 149 - Development with AI

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • P3 group
  • Ing Hubs
  • Cognizant Softvision
  • Colors in projects