31.5.2008   

RO

Jurnalul Oficial al Uniunii Europene

L 141/5

(1)

În conformitate cu Regulamentul (CE) nr. 550/2004, Comisia trebuie să identifice și să adopte dispozițiile relevante ale cerințelor Eurocontrol pentru reglementarea siguranței („ESARR”), luând în considerare legislația comunitară existentă. ESARR 6 denumit „Sistemele software ale sistemelor ATM” prevede un set de cerințe pentru reglementarea siguranței în vederea punerii în aplicare a unui sistem de asigurare a siguranței software.

(2)

În Regulamentul (CE) nr. 2096/2005 al Comisiei din 20 decembrie 2005 de stabilire a unor cerințe comune pentru furnizarea de servicii de navigație aeriană (2) se menționează, la ultima propoziție la considerentul 12, următoarele: „Dispozițiile relevante ale ESARR 1 privind controlul siguranței în domeniul ATM și ale ESARR 6 privind sistemele software ale sistemelor ATM ar trebui identificate și adoptate prin acte comunitare separate.”

(3)

Anexa II la Regulamentul (CE) nr. 2096/2005 solicită furnizorilor de servicii de navigație aeriană să pună în aplicare un sistem de management al siguranței, precum și cerințele de siguranță pentru o strategie de evaluare și reducere a riscurilor în ceea ce privește modificările. În cadrul sistemului de management al siguranței, și ca parte a activităților de evaluare și reducere a riscurilor în ceea ce privește modificările, un furnizor de servicii de trafic aerian ar trebui să definească și să pună în aplicare un sistem de asigurare a siguranței software care să vizeze, în mod specific, aspectele legate de software.

(4)

În ceea ce privește siguranța software, principalul obiectiv de îndeplinit în cazul sistemelor funcționale care conțin software este acela de a garanta reducerea la un nivel tolerabil a riscurilor aferente Аutilizării software în cadrul sistemelor privind rețeaua europeană de management al traficului aerian („software EATMN”).

(5)

Prezentul regulament nu ar trebui să vizeze operațiunile și pregătirea militară menționate la articolul 1 alineatul (2) din Regulamentul (CE) nr. 549/2004 al Parlamentului European și al Consiliului din 10 martie 2004 de stabilire a cadrului pentru crearea Cerului Unic European (regulamentul-cadru) (3).

(6)

Prin urmare, anexa II la Regulamentul (CE) nr. 2096/2005 ar trebui modificată în consecință.

(7)

Măsurile prevăzute de prezentul regulament sunt conforme cu avizul Comitetului pentru Cerul Unic,

1.

„software” înseamnă programe pentru calculator, precum și date de configurare corespunzătoare, inclusiv software comercial, dar excluzând elementele electronice cum ar fi circuitele integrate specifice unei aplicații, rețelele circuit-poartă programabile sau controlerele logice pentru semiconductoare;

2.

„date de configurare” înseamnă date care configurează un software generic pentru un caz particular de utilizare;

3.

„software comercial” înseamnă software care nu a fost creat pentru actualul contract;

4.

„asigurarea siguranței” înseamnă toate acțiunile, planificate și sistematice, necesare pentru a genera încrederea corespunzătoare că un produs, un serviciu, o organizație sau un sistem funcțional atinge un nivel de siguranță acceptabil sau tolerabil;

5.

„organizație” înseamnă fie un furnizor de servicii de trafic aerian (ATS), fie un furnizor de comunicare, navigație și supraveghere (CNS), fie o entitate care asigură (ATFM sau ASM);

6.

„sistem funcțional” înseamnă o combinație de sisteme, proceduri și resurse umane organizate în scopul îndeplinirii unei funcții în cadrul ATM;

7.

„risc” înseamnă combinația între probabilitatea generală sau frecvența de apariție a unui efect dăunător provocat de un pericol și gravitatea acelui efect;

8.

„pericol” înseamnă orice situație, eveniment sau circumstanță care ar putea determina un accident;

9.

„software nou” înseamnă un software care a fost comandat sau pentru care au fost încheiate contracte ferme după intrarea în vigoare a prezentului regulament;

10.

„obiectiv privind siguranța” înseamnă o declarație calitativă sau cantitativă care definește frecvența maximă sau probabilitatea maximă la care poate apărea un pericol;

11.

„cerință de siguranță” înseamnă un mijloc de reducere a unui risc, definit în cadrul unei strategii de reducere a riscurilor care permite atingerea unui obiectiv de siguranță specific, incluzând cerințele organizaționale, operaționale, procedurale, funcționale, de performanță, precum și cerințele de interoperabilitate sau caracteristicile de mediu;

12.

„tranziție sau transfer în regim operațional” înseamnă modalitatea de înlocuire a componentelor sistemului privind rețeaua europeană de management al traficului aerian (EATMN) sau a software-ului în timp ce sistemul este operațional;

13.

„cerință de siguranță software” înseamnă o descriere a ceea ce trebuie să producă software-ul, ținând cont de inputuri și de constrângeri, astfel încât să fie asigurată funcționarea în siguranță a software-ului EATMN și în conformitate cu nevoile operaționale;

14.

„software EATMN” înseamnă software utilizat în cadrul sistemelor EATMN menționat la articolul 1;

15.

„validarea cerințelor” înseamnă confirmarea prin examinare și furnizare de dovezi obiective că cerințele specifice pentru o anumită utilizare sunt așa cum au fost prevăzute;

16.

„realizare în mod independent” înseamnă desfășurarea activităților corespunzătoare procesului de verificare a software-ului de către o persoană (persoane), alta decât cea care a dezvoltat elementul verificat;

17.

„defecțiune de software” înseamnă incapacitatea unui program de a efectua, în mod corect, o funcție cerută;

18.

„cădere software” înseamnă incapacitatea unui program de a efectua o funcție cerută;

19.

„COTS” înseamnă o aplicație disponibilă pe piață, comercializată prin intermediul unor cataloage publice și care nu poate fi personalizată sau îmbunătățită;

20.

„componente software” înseamnă un modul care poate fi instalat sau conectat împreună cu alte module software reutilizabile în scopul combinării și al creării unei aplicații software specifice;

21.

„componente independente software” înseamnă acele componente software care nu sunt scoase din operare de către defecțiunea care a determinat apariția pericolului;

22.

„performanțele privind timpul de răspuns al software-ului” înseamnă timpul necesar software-ului de a răspunde unor inputuri date sau unor evenimente periodice, și/sau performanța software în ceea ce privește tranzacțiile sau mesajele prelucrate în unitatea de timp;

23.

„capacitate software” înseamnă abilitatea software-ului de a prelucra un anumit volum de flux de date;

24.

„acuratețe” înseamnă gradul necesar de precizie pentru rezultatele calculate;

25.

„utilizarea resurselor software” înseamnă cantitatea de resurse din cadrul unui sistem de calcul care poate fi utilizată de către aplicația software;

26.

„robustețea software” înseamnă comportamentul software-ului în cazul apariției unor inputuri neașteptate, al cedării componentelor hardware și al penelor de curent, fie în cadrul sistemului de calcul, fie în cadrul dispozitivelor conectate la acesta;

27.

„toleranță la supraîncărcare” înseamnă comportamentul unui sistem și, în special, toleranța acestuia, atunci când inputurile au loc cu o frecvență mai mare decât cea prevăzută pentru exploatarea normală a sistemului;

28.

„verificare completă și corectă a software-ului EATMN” înseamnă că toate cerințele de siguranță software definesc în mod corect exigențele privind componenta software ca urmare a procesului de evaluare și reducere a riscurilor, iar punerea lor în aplicare este dovedită la nivelul cerut de către nivelul de asigurare software;

29.

„date privind ciclul de viață software” înseamnă date produse pe perioada ciclului de viață software pentru a planifica, conduce, explica, defini, înregistra sau pentru a furniza dovezi privind activitățile desfășurate; aceste date permit desfășurarea proceselor aferente ciclului de viață software, autorizarea sistemelor sau a echipamentelor și modificarea post-autorizare a produsului software;

30.

„ciclu de viață software” înseamnă:

31.

„cerință de siguranță” înseamnă o cerință de siguranță aplicabilă unui sistem funcțional.

(a)

cerințele de siguranță software precizează în mod corect criteriile necesare pentru ca software-ul să îndeplinească obiectivele și cerințele privind siguranța definite în cadrul procesului de evaluare și reducere a riscurilor;

(b)

trasabilitatea este avută în vedere în ceea ce privește toate cerințele de siguranță software;

(c)

implementarea software-ului nu include funcții care să afecteze grav siguranța;

(d)

software-ul EATMN satisface cerințele aplicabile în cazul său, la un nivel de încredere corespunzător nivelului de risc al software-ului;

(e)

sunt prevăzute garanții care confirmă respectarea cerințelor generale de siguranță menționate la literele (a)-(d), iar argumentele care demonstrează că garanțiile necesare în acest sens derivă întotdeauna:

1.

este documentat, în mod specific ca parte a documentației generale de evaluare și reducere a riscurilor;

2.

alocă niveluri de asigurare software tuturor aplicațiilor software EATMN operaționale, în conformitate cu cerințele prevăzute în anexa I;

3.

include asigurări privind:

4.

determină gradul de rigoare pentru stabilirea garanțiilor; gradul de rigoare trebuie definit pentru fiecare nivel de asigurare software și crește pe măsură ce crește nivelul de risc al software-ului, în acel sens:

5.

utilizează rezultatele experienței utilizării software-ului EATMN pentru a confirma faptul că sistemul de asigurare a siguranței software și alocarea nivelurilor de asigurare software sunt corespunzătoare. În acel scop, efectele unei căderi sau ale unei defecțiuni a software-ului, notificate în conformitate cu cerințele relevante privind notificarea și evaluarea evenimentelor legate de siguranță, se evaluează în comparație cu efectele asupra sistemului în cauză identificate conform schemei de clasificare a gravității prevăzută în anexa II secțiunea 3.2.4 la Regulamentul (CE) nr. 2096/2005.