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

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

Î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