31.5.2008   

DA

Den Europæiske Unions Tidende

L 141/5

(1)

I henhold til forordning (EF) nr. 550/2004 skal Kommissionen identificere og vedtage de relevante bestemmelser blandt Eurocontrols sikkerhedskrav (Eurocontrol Safety Regulatory Requirements — ESARR) under hensyn til gældende fællesskabsret. ESARR 6 med overskriften »software i lufttrafikstyringssystemer« indeholder et sæt sikkerhedskrav til indførelsen af et softwaresikringssystem.

(2)

Kommissionens forordning (EF) nr. 2096/2005 af 20. december 2005 om fælles krav til udøvelse af luftfartstjenester (2) angiver i betragtning 12, sidste punktum, at »de relevante bestemmelser i ESARR 1 om kontrol med flyvesikkerheden i ATM og i ESARR 6 om software i ATM-systemer bør fastlægges og vedtages ved separate fællesskabsretsakter«.

(3)

Bilag II til forordning (EF) nr. 2096/2005 pålægger udøvere af lufttrafiktjeneste at indføre et flyvesikkerhedsstyringssystem og flyvesikkerhedsmæssige krav til risikovurdering og -reduktion ved ændringer. Udøvere af lufttrafiktjeneste bør inden for rammerne af deres sikkerhedsstyringssystemer og som led i deres risikovurdering og risikoreduktion ved ændringer fastlægge og indføre et softwaresikringssystem særligt for forhold vedrørende software.

(4)

Det vigtigste mål med hensyn til softwaresikkerhed, som skal opfyldes af funktionelle systemer, der indeholder software, er at sikre, at risiciene i forbindelse med brugen af software i systemer i det europæiske lufttrafikstyringsnet (EATMN-software) nedbringes til et tolerabelt niveau.

(5)

Denne forordning bør ikke omfatte militære operationer og militær træningsflyvning som omhandlet i artikel 1, stk. 2, i Europa-Parlamentets og Rådets forordning (EF) nr. 549/2004 af 10. marts 2004 om rammerne for oprettelse af et fælles europæisk luftrum (rammeforordningen) (3).

(6)

Bilag II til forordning (EF) nr. 2096/2005 bør derfor ændres i overensstemmelse hermed.

(7)

Foranstaltningerne i denne forordning er i overensstemmelse med udtalelse fra Udvalget for det Fælles Luftrum —

1)

»software«: edbprogrammer og tilhørende konfigurationsdata, inklusive tidligere udviklet software, men undtagen elektroniske dele som f.eks. applikationsspecifikke integrerede kredsløb, programmerbare gate arrays eller solid-state logiske controllere

2)

»konfigurationsdata«: data, som konfigurerer et generisk softwaresystem til et særligt anvendelsesformål

3)

»tidligere udviklet software«: software, der ikke er udviklet inden for den nugældende kontrakt

4)

»sikring«: alle planlagte og systematisk udførte handlinger, som er nødvendige for at skabe tilstrækkelig tillid til, at et produkt, en tjeneste, en virksomhed eller et funktionssystem opnår acceptabel eller tolerabel sikkerhed

5)

»organisation«: en ATS-udøver, en CNS-udøver eller en enhed, der leverer ATFM eller ASM

6)

»funktionssystem«: en kombination af systemer, procedurer og menneskelige ressourcer, der er organiseret med henblik på at udfylde en funktion i lufttrafikstyringen

7)

»risiko«: kombinationen af den overordnede sandsynlighed for eller hyppighed af en skadelig virkning, der er forårsaget af en fare, og alvoren af en sådan virkning

8)

»fare«: ethvert forhold og enhver begivenhed eller omstændighed, som kan føre til et havari

9)

»ny software«: software, som er bestilt efter denne forordnings ikrafttræden, eller som der er underskrevet en bindende kontrakt om efter denne forordnings ikrafttræden

10)

»sikkerhedsmål«: en kvalitativ eller kvantitativ opgørelse, som fastlægger den maksimale hyppighed eller sandsynlighed for, at en fare kan forventes at indtræde

11)

»sikkerhedskrav«: et middel til risikoreduktion, der er fastlagt på grundlag af strategien for risikoreduktion, og hvorved der opfyldes et særligt sikkerhedsmål, herunder krav, der vedrører organisation, drift, procedurer, funktion, resultater, interoperabilitet eller miljøegenskaber

12)

»cutover eller hot swapping«: det at udskifte systemkomponenter eller software i det europæiske lufttrafikstyringsnet (EATMN), medens systemet er i drift

13)

»sikkerhedskrav til software«: en beskrivelse af, hvad softwaren skal frembringe på grundlag af input og begrænsninger, og opfyldelsen af disse sikrer, at EATMN-softwaren fungerer sikkert og opfylder det operationelle behov

14)

»EATMN-software«: software, som anvendes i EATMN-systemerne i artikel 1

15)

»kravvalidering«: en bekræftelse efter undersøgelse og tilvejebringelse af objektiv dokumentation for, at de særlige krav til et specifikt anvendelsesformål følger hensigten

16)

»opnå ved uafhængig verifikation«: ved verifikation af software den omstændighed, at verifikationsprocesaktiviteterne udføres af en eller flere personer, som ikke har deltaget i udviklingen af det verificerede objekt

17)

»softwarefunktionsfejl«: et programs manglende evne til at udføre en påkrævet funktion korrekt

18)

»softwaresvigt«: et programs manglende evne til at udføre en påkrævet funktion

19)

»COTS«: (Commercial Off The Shelf) en applikation, som sælges af forhandlere via offentligt tilgængelige katalogvarer, og som normalt ikke skal tilpasses eller forbedres

20)

»softwarekomponenter«: moduler, der kan indbygges eller forbindes med andre genanvendelige softwaremoduler for at kombinere og skabe en brugerdefineret softwareapplikation

21)

»uafhængige softwarekomponenter«: softwarekomponenter, der ikke sættes ud af drift som følge af den svigttilstand, der forårsager faren

22)

»softwarens responstid«: den tid, softwaren må bruge på at reagere på et givet input eller på periodiske hændelser, og/eller softwarens præstationer målt på antal behandlede transaktioner eller beskeder pr. tidsenhed

23)

»softwarekapacitet«: softwarens evne til at håndtere en given datastrøm

24)

»nøjagtighed«: kravet til de databeregnede resultaters præcision

25)

»softwareressourceudnyttelse«: den mængde ressourcer i computersystemet, som softwareapplikationen kan udnytte

26)

»softwarestabilitet«: softwarens respons på uventede input, hardwaresvigt og strømafbrydelser enten i selve computersystemet eller i tilsluttede enheder

27)

»overload tolerance«: systemets respons, og særlig dets tolerance, over for input, der forekommer med større intensitet, end det forventes under systemets normale drift

28)

»korrekt og komplet verifikation af EATMN-software«: alle sikkerhedskrav til software, som på korrekt vis angiver, hvad der kræves af softwarekomponenten i overensstemmelse med risikovurderings- og risikoreduktionsprocessen, og opfyldelsen af sikkerhedskravene er dokumenteret i henhold til det niveau, der kræves ifølge softwaresikringsniveauet

29)

»softwarelivscyklusdata«: data, der frembringes i løbet af softwarens livscyklus for at planlægge, styre, forklare, definere, registrere eller dokumentere aktiviteter. Disse data letter softwarelivscyklusprocesserne og godkendelsen af systemet eller udstyret samt ændringer af softwareproduktet efter godkendelsen

30)

»softwarelivscyklus«:

31)

»sikkerhedskrav til systemet«: et sikkerhedskrav, der gælder for et funktionssystem.

a)

sikkerhedskravene til softwaren angiver på korrekt vis, hvad der kræves af softwaren for at opfylde sikkerhedsmålene og -kravene fastlagt i risikovurderings- og risikoreduktionsprocessen

b)

der tages højde for sporbarhed i alle sikkerhedskrav til softwaren

c)

softwareimplementeringen indeholder ingen funktioner, som indvirker negativt på sikkerheden

d)

EATMN-software opfylder kravene med en pålidelighedsgrad, der modsvarer softwarens kritikalitet

e)

det er sikret, at de almene sikkerhedskrav i litra a) til d) er opfyldt, og argumenter til støtte for den påkrævede sikkerhed kan til enhver tid udledes af:

1)

er dokumenteret, især som en del af dokumentationen vedrørende den overordnede risikovurdering og -reduktion

2)

tildeler softwaresikringsniveauer til al operationel EATMN-software i overensstemmelse med kravene i bilag I

3)

omfatter godtgørelse af, at:

4)

fastsætter, med hvilken grad af strenghed sikringen er godtgjort; strengheden af kravene, der stilles til godtgørelsen, defineres for hvert softwaresikringsniveau og skærpes, når softwarens kritikalitet øges; i den forbindelse gælder følgende:

5)

anvender feedback fra erfaringer med EATMN-software til at bekræfte, at softwaresikringssystemet og tildelingen af sikringsniveauer er hensigtsmæssige. Virkningerne af en softwarefunktionsfejl eller et softwaresvigt, der indberettes i henhold til de relevante krav om indberetning og vurdering af sikkerhedsmæssige hændelser, skal vurderes til dette formål sammenholdt med de virkninger, der er påpeget for det pågældende system i henhold til alvorsklassifikationsskemaet i afsnit 3.2.4 i bilag II til forordning (EF) nr. 2096/2005.