Introducere
C şi C++ sunt de la distanţă cel mai larg utilizate limbaje pentru dezvoltare de software integrat. Cercetări recente efectuate de VDC arată că C este utilizat de 70% din companiile intervievate, iar C++ de 42%. C a fost implementat pentru orice procesor virtual. El oferă o plajă largă de resurse şi biblioteci şi este suportat de o mulţime de unelte.
Limbajul C, în particular, permite ca dezvoltatorii să facă multe lucruri care în esenţă sunt incorecte. Este foarte simplu să scrii un program care să fie conform standardului limbajului, dar care să conducă la erori de program (de exemplu blocare) sau la comportament nedefinit. Exemplele uzuale sunt programele care duc la accesarea memoriei în afara limitelor unei matrice sau o operaţie aritmetică ce conduce la fenomenul de depăşire (integer overflow).
Filozofia standardelor de programare
Calea acceptată de industrie pentru abordarea acestor situaţii tip hazard este de a adopta un standard de programare. În forma lor cea mai simplă, aceste standarde definesc un set consistent de practici de programare. Deşi uniformitatea stilului poate fi valoroasă în cadrul unui proiect software, ele nu se adresează atributelor importante ce definesc un software de calitate, precum: siguranţă în funcţionare, portabilitate sau întreţinere.
Rolul fundamental al standardelor de programare este de a defini un sub-set mai sigur al limbajului de programare prin încadrarea într-un set de reguli ce elimină construcţii de program cunoscute ca producătoare de situaţii hazard.
Ghidurile de programare MISRA, îmbrăţişând acest principiu al creării unui sub-set sigur, sunt acceptate pe plan mondial ca referinţe pentru dezvoltarea de software în C şi C++, acolo unde siguranţa în funcţionare este critică. Ele au fost acceptate pe scară largă deoarece sunt concise şi uşor de urmărit şi pentru că se concentrează pe probleme esenţiale. Un sondaj efectuat recent (Ganssle, 2014) asupra a 500 respondenţi, a relevat date interesante asupra vitezei de adoptare a standardelor de programare. Cea mai importantă descoperire este aceea că aproape 60% dintre toate standardele de programare în uz sunt bazate pe MISRA. Stricteţea adoptării a fost o altă descoperire importantă. Setul de reguli de programare bazat pe MISRA acoperă 75% din utilizarea consistentă a echipei de dezvoltare, în timp ce alte seturi de reguli ocupă mai puţin de 50%.
Principiul abaterii
Standardele de programare MISRA conţin ghiduri respectate pe scară largă pentru dezvoltarea în limbajele C şi C++. Aceste ghiduri se concentrează pe probleme importante la dezvoltarea de sisteme software critice. MISRA recunoaşte de asemenea că, în anumite situaţii, este nerezonabil sau chiar imposibil să te conformezi cu ghidul de programare şi de aceea este necesară abaterea de la unele reguli. O abatere stipulează motivul pentru neconformarea la o regulă de programare particulară într-o circumstanţă clară. Ea oferă de asemenea logica şi descrierea măsurii prin care regula particulară este relaxată şi furnizează un caz de siguranţă ce include diminuarea efectelor neconformării.
Totuşi, în absenţa domeniului de aplicare a neconformităţii stabilit cu atenţie, facilitatea unei abateri de bază ar putea fi înţeleasă greşit sau abuziv, subminând în cele din urmă eficienţa ghidurilor.
Constrângeri asupra utilizării abaterilor
În acelaşi fel în care însăşi standardele de programare au nevoie de creare de obiective şi logici bine înţelese, motivele pentru abaterea de la regulile de programare au nevoie de o expresie comună şi o interpretare agreată, precum şi un scop clar al aplicării lor. Industria auto, domeniul de aplicare original şi încă aflat în frunte pentru MISRA, s-a confruntat cu aceste cerinţe. Atât MISRA în sine, cât şi un organism naţional, Asociaţia Producătorilor Auto din Japonia (JAMA), au început procesul de stabilire a condiţiilor în care se permit abateri specifice de la conformitatea MISRA. Scopul acestei munci este de a defini un set de reguli cu domeniu de aplicare bine limitat. O primă şi importantă etapă este de a clasifica motivele abaterii de la reguli.
Categorisirea motivelor de abatere
Prin împărţirea abaterilor în următoarele categorii, dificultăţile practice cu conformarea sunt mai evidente. Suplimentar, această categorisire protejează împotriva abaterilor nepotrivite şi slăbirii standardului de programare.
a) Performanţa: Poate părea ciudat şi neintuitiv să fie sugerată performanţa ca motiv de a nu urmări bunele practici de programare, dar următoarea situaţie din viaţa reală demonstrează necesitatea:
Ca parte a sistemului de control al vehiculului, o variabilă de timp trebuie să fie acumulată la intervale regulate. Programul, corect formulat pentru a răspunde MISRA-C:2012 Regula 10.6 (valoarea să nu fie atribuită unui tip de variabilă mai larg), este:
extern uint16_t qty, time_step;
uint32_t prod = ( uint32_t ) qty * ( uint32_t ) time_step;
Aceasta asigură că operanzii pe 16 biţi nu vor depăşi în multiplicare 32 de biţi pentru acest compilator. Totuşi, compilatorul realizează această operaţie utilizând modul “shift and add” pentru multiplicare mai degrabă decât modul IMUL (multiplicare cu semn) cu care este echipat. Distribuitorul compilatorului a clarificat că modul IMUL apare numai în conversii implicite, necesitând expresii ca:
uint32_t prod = qty * time_step; // deviate from Rule 10.6
Prin permiterea în acest caz a conversiei implicite, se garantează operarea IMUL pe un singur ciclu, mai degrabă decât cele aproximativ 100 de cicluri de ceas pentru execuţia în cazul cel mai rău din modul anterior, justificând abaterea controlată pe bază de performanţă.
b) Program extern (terţ): Această categorie include biblioteci comune, programe auto-generate, module de programe interne moştenite sau chiar şi numai o funcţie complexă cuprinzând un algoritm cheie al aplicaţiei. Cei care întreţin biblioteci cu caracter public, datorită domeniului lor de aplicaţie larg, au foarte rar motive de a se conforma MISRA sau alte standarde de programare. Programele auto-generate, în afară de cazul în care respectă standarde de siguranţă funcţională precum ISO 26262, este foarte posibil să conţină violări inerente ale MISRA. Programele moştenite pot data dinaintea adoptării MISRA. Analiza impactului refacerii programelor pentru a se conforma regulilor MISRA poate reprezenta o problemă. Cazul de siguranţă în funcţionare se bazează pe ideea de “calificare prin utilizare” în combinaţie cu alte măsuri de calitate.
c) Construire de configuraţii: O caracteristică particulară a aplicaţiilor furnizorilor auto este de a oferi mai multe variante unui singur program de bază, conform necesităţilor clienţilor. Mai degrabă decât controlul la nivelul de construcţie, programele implementează mecanisme de configurare pentru controlul furnizării fiecărei variante. Ca rezultat, conformitatea MISRA poate avea de suferit în termeni de redundanţă în program, invarianţă în expresii şi probleme globale de legătură.
d) Acces la hardware: Cu scopul de a accesa registrele, de a se adresa memoriei absolute şi de a controla întreruperile, dezvoltatorii embedded au nevoie să acceseze extensii specifice compilatorului în limbajul C, conducând la o neconformitate MISRA. Cazul sigur va necesita tipic o atentă acoperire a testului unităţii.
e) Programare defensivă: fiind dată absenţa manipulării robuste a excepţiilor în C, practicile de programare defensivă pot implica, de exemplu, protecţii împotriva comportamentului neprevăzut. O unealtă de analiză completă va detecta corect condiţiile invariante şi programele inaccesibile ca rezultat. Cazul de siguranţă trebuie să implice executarea forţată a testului unităţii pentru aceste căi şi condiţii.
f) Caracteristici de limbaj: există motive valabile legate de calitatea programului pentru a utiliza construcţii de limbaj “recente”, cum ar fi de exemplu tipuri Boolean sau “long long” sau funcţii în linie. Totuşi, acestea pot necesita abateri de la versiunile mai vechi de MISRA. Problema de siguranţă este aceea că nu se garantează suportul pentru toate compilatoarele chiar şi pentru o construcţie C99 veche de 15 ani.
Structura abaterilor controlate
Categorisirea după diferite logici este un prim pas în crearea unei structuri de abatere corect constrânsă. Acest lucru conduce natural la o evidenţiere a tuturor cazurilor cunoscute de abateri specifice, după regulă şi după categorie. MISRA şi JAMA se documentează, cu participarea industriei, elaborând un set de reguli cu constrângeri legate de domeniul de aplicare, fiecare cu o justificare detaliată și cazul de siguranță.
Chiar şi în afara contextului auto, aceste iniţiative sunt importante. Standardul de programare MISRA a fost original proiectat pentru sectorul auto, dar încă din primii ani şi-a găsit locul şi în multe alte medii embedded, de la produse de larg consum până la dispozitive medicale, de la control industrial la EDA. În mod egal, stabilirea unei structuri de abatere controlată este importantă în orice industrie sau organizaţie ce lucrează cu standarde de programare.
Suport automat al uneltelor
Un standard de programare fără mijloace automate de executare şi audit puternic, precum şi capabilităţi de raportare, va deveni curând un obiect de bibliotecă, rareori aplicat. Punctul de pornire pentru o unealtă automată de analiză statică trebuie să fie precizia de diagnosticare, claritatea înţelegerii şi explicării fiecărei probleme ridicate, precum şi raportarea detaliată a fiecărei versiuni a proiectului software.
Dar chiar şi un mediu de unealtă automată necesită atenţie şi aplicarea unor politici agreate de abatere, în special când aceasta elimină un impediment la conformarea completă. Atât regulile de programare, cât şi politica de abatere trebuie să fie convenabile pentru dezvoltatori, de încredere pentru conducere şi management şi să faciliteze un raport detaliat QA.
Un sistem de abatere de bază va cupla fiecare instanţă a suprimării regulii cu abaterea sa şi va păstra această legătură pe toată durata de viaţă a programului sursă relevant. Cerinţele sunt mai complexe când avem de-a face cu abateri controlate. Orice suprimare a regulilor de programare relevante trebuie să se supună unor limitări strânse în forţă, şi nicio suprimare nu poate avea loc în afara setului controlat de abateri. Când se alege locul programului specific unde diagnosticul raportat este de suprimare, dezvoltatorii trebuie să fie constrânşi să suprime numai în conformitate cu gamele de abateri controlate.
Concluzie
Standardele de programare MISRA C sunt sinonime cu utilizarea sigură şi defensivă a C în numeroase medii embedded şi dincolo de acestea. Fiind cuprinzător, dar oferind în același timp un spațiu larg pentru utilizarea restrictivă a limbajului C, un sistem de abateri controlate este recunoscut acum ca o necesitate, după cum se observă din eforturile industriei şi ale diferitelor comunităţi de a defini aceste restricţionări. În acest articol, au fost explorate categoriile de abateri şi s-a observat cum motive legitime specifice pentru abateri sunt acum conturate pentru uz industrial. Astăzi este disponibil şi suportul uneltelor automate complexe pentru iniţiativa controlului abaterilor însoţit de rapoarte şi alte elemente de conformitate ￭
Programming Research Ltd
www.prqa.com
Despre autor
Fergus Bolger este CTO la Programming Research Ltd. El a primit B.E. şi diploma de Master în Inginerie la University College Dublin. Poate fi găsit la adresa fergus_bolger@programmingresearch.com
Relaţia dintre PRQA şi MISRA se întinde încă din urmă cu 20 de ani. Elementele majore ale ghidurilor MISRA-C şi MISRA-C++ au derivat din propriile noastre standarde de programare, iar experţii noştri tehnici rămân membri cheie ai grupurilor de lucru MISRA-C şi MISRA-C++.
Uneltele de analiză statică ale PRQA, QA·C şi QA·C++, sunt pe primele locuri în verificarea conformităţii MISRA-C şi MISRA-C++, precum şi ca gazdă pentru alte capabilităţi valoroase de analiză.
Pentru mai multe informaţii accesaţi www.prqa.com
Bibliografie
Ganssle, J. (2014, August 4). Retrieved from The Ganssle Group: www.ganssle.com/tem/tem266.html