2008R0482 — NL — 07.11.2011 — 001.001

Dit document vormt slechts een documentatiehulpmiddel en verschĳnt buiten de verantwoordelĳkheid van de instellingen

►B VERORDENING (EG) Nr. 482/2008 VAN DE COMMISSIE van 30 mei 2008 betreffende de invoering van een systeem ter verzekering van de softwareveiligheid door verleners van luchtvaartnavigatiediensten en tot wijziging van bijlage II bij Verordening (EG) nr. 2096/2005 (Voor de EER relevante tekst) (PB L 141, 31.5.2008, p.5)

Gewĳzigd bĳ:









▼B

VERORDENING (EG) Nr. 482/2008 VAN DE COMMISSIE

van 30 mei 2008

betreffende de invoering van een systeem ter verzekering van de softwareveiligheid door verleners van luchtvaartnavigatiediensten en tot wijziging van bijlage II bij Verordening (EG) nr. 2096/2005

(Voor de EER relevante tekst)







DE COMMISSIE VAN DE EUROPESE GEMEENSCHAPPEN, Gelet op het Verdrag tot oprichting van de Europese Gemeenschap, Gelet op Verordening (EG) nr. 550/2004 van het Europees Parlement en de Raad van 10 maart 2004 betreffende de verlening van luchtvaartnavigatiediensten in het gemeenschappelijk Europees luchtruim („de luchtvaartnavigatiedienstenverordening”) ( 1 ), en met name artikel 4, Overwegende hetgeen volgt: (1) Overeenkomstig Verordening (EG) nr. 550/2004 dient de Commissie de relevante Eurocontrol Safety Regulatory Requirements (ESARR’s) vast te stellen en goed te keuren met inachtneming van de bestaande communautaire regelgeving. ESARR 6, getiteld „Software in ATM systems”, omvat een aantal veiligheidsvoorschriften met betrekking tot de invoering van een systeem ter verzekering van de softwareveiligheid. (2) In de laatste zin van overweging 12 van Verordening (EG) nr. 2096/2005 van de Commissie van 20 december 2005 tot vaststelling van gemeenschappelijke eisen voor de verlening van luchtvaartnavigatiediensten ( 2 ) wordt gesteld dat „de relevante bepalingen van ESARR 1 betreffende veiligheidstoezicht bij de luchtverkeersbeveiliging en van ESARR 6 betreffende software in luchtverkeersbeveiligingssystemen in afzonderlijke Gemeenschapsbesluiten moeten worden vastgesteld en goedgekeurd.”. (3) Op grond van bijlage II bij Verordening (EG) nr. 2096/2005 dienen verleners van luchtvaartnavigatiediensten een veiligheidsbeheersysteem toe te passen, alsmede veiligheidseisen betreffende risicobeoordeling en -beperking bij wijzigingen. Binnen het kader van hun veiligheidsbeheersysteem en als onderdeel van hun procedure voor risicobeoordeling en -beperking bij wijzigingen dienen verleners van luchtvaartnavigatiediensten specifiek voor softwaregerelateerde aspecten een systeem ter verzekering van de softwareveiligheid te ontwikkelen en in te voeren. (4) De belangrijkste doelstelling inzake softwareveiligheid waaraan functionele systemen die software bevatten, dienen te voldoen, is de risico’s die zijn verbonden aan het gebruik van de software binnen het Europese netwerk voor luchtverkeersbeheer („EATMN-software”), tot een aanvaardbaar niveau te reduceren. (5) Deze verordening dient geen betrekking te hebben op militaire operaties en trainingen als bedoeld in artikel 1, lid 2, van Verordening (EG) nr. 549/2004 van het Europees Parlement en de Raad van 10 maart 2004 tot vaststelling van het kader voor de totstandbrenging van het gemeenschappelijke Europese luchtruim („de kaderverordening”) ( 3 ). (6) Bijlage II bij Verordening (EG) nr. 2096/2005 moet derhalve dienovereenkomstig worden gewijzigd. (7) De in deze verordening vervatte maatregelen zijn in overeenstemming met het advies van het Comité voor het gemeenschappelijke luchtruim, Overwegende hetgeen volgt: HEEFT DE VOLGENDE VERORDENING VASTGESTELD:







Artikel 1

Onderwerp en toepassingsgebied

1. In deze verordening worden de eisen vastgesteld voor de definiëring en implementatie van een systeem ter verzekering van de softwareveiligheid door verleners van luchtverkeersdiensten (ATS), instanties die zorg dragen voor het beheer van de luchtverkeersstromen (ATFM) en luchtruimbeheer (ASM) voor het algemene luchtverkeer en verleners van communicatie-, navigatie en plaatsbepalingsdiensten (CNS).

Voorts worden de bindende bepalingen van de Eurocontrol Safety Regulatory Requirement — ESARR 6 — getiteld „Software in ATM systems” van 6 november 2003 vastgesteld en goedgekeurd.

2. Deze verordening is van toepassing op nieuwe software en op elke wijziging van de software van ATS, ASM, ATFM en CNS-systemen.

Zij is niet van toepassing op software van onderdelen die zich aan boord van luchtvaartuigen of in de ruimte bevinden.

Artikel 2

Definities

Voor de toepassing van deze verordening gelden de definities van artikel 2 van Verordening (EG) nr. 549/2004.

Voorts wordt verstaan onder:

1. „software”: computerprogramma’s en bijbehorende configuratiegegevens, met inbegrip van standaardsoftware, doch met uitzondering van elektronische elementen zoals toepassingsspecifieke geïntegreerde schakelingen, programmeerbare „gate arrays” of vaste logische regeleenheden;

2. „configuratiegegevens”: gegevens om de algemene software af te stemmen op een specifieke toepassing;

3. „standaardsoftware”: software die niet specifiek met het oog op het lopende contract is ontwikkeld;

4. „verzekering van de veiligheid”: alle geplande en systematische handelingen die nodig zijn om voldoende zekerheid te verschaffen dat een product, een dienst, een organisatie of een functioneel systeem een aanvaardbaar of toelaatbaar veiligheidsniveau bereikt;

5. „organisatie”: een verlener van ATS of CNS of een instantie die zorg draagt voor ATFM of ASM;

6. „functioneel systeem”: een combinatie van systemen, procedures en personeel die zijn georganiseerd om een taak op het gebied van luchtverkeersbeheer te verrichten;

7. „risico”: de combinatie van de algemene waarschijnlijkheid of de frequentie waarmee een schadelijk gevolg van een gevaar zich zal voordoen, en de ernst van dat gevolg;

8. „gevaar”: omstandigheid of gebeurtenis die een ongeval kan veroorzaken;

9. „nieuwe software”: software die is besteld of het voorwerp uitmaakt van een bindende overeenkomst die is ondertekend na de inwerkintreding van deze verordening;

10. „veiligheidsdoelstelling”: een kwalitatieve of kwantitatieve vaststelling van de maximale frequentie of waarschijnlijkheid waarmee een gevaar zich naar verwachting zal voordoen;

11. „veiligheidseis”: een op basis van de risicobeperkingsstrategie vastgesteld middel tot risicobeperking waarmee een specifieke veiligheidsdoelstelling wordt bereikt, met inbegrip van organisatorische, operationele, procedurele, functionele, prestatie- en interoperabiliteitseisen en omgevingskenmerken;

12. „omschakeling of hot swapping”: de vervanging van systeemcomponenten of software van het Europese netwerk voor luchtverkeersbeheer (EATMN) terwijl het systeem operationeel is;

13. „softwareveiligheidseis”: een omschrijving van de door de software op basis van een bepaalde input en randvoorwaarden te leveren output waardoor, indien aan de eis wordt voldaan, wordt gewaarborgd dat de EATMN-software veilig functioneert en voldoet aan de operationele behoeften;

14. „EATMN-software”: software die wordt gebruikt in de in artikel 1 bedoelde EATMN-systemen;

15. „validering van de eisen”: de bevestiging na onderzoek en het verstrekken van objectief bewijsmateriaal dat aan specifieke vereisten is voldaan;

16. „onafhankelijk te voldoen”: de omstandigheid in een softwareverificatieprocedure dat het proces wordt uitgevoerd door een andere persoon dan de ontwikkelaar van het geverifieerde onderdeel;

17. „softwarestoring”: wanneer een vereiste functie door een programma niet correct kan worden uitgevoerd;

18. „softwarefalen”: wanneer een vereiste functie door een programma niet kan worden uitgevoerd;

19. „COTS”: een in de handel verkrijgbare toepassing die is opgenomen in de publieke catalogus van een leverancier en niet bedoeld is om te worden aangepast of uitgebreid;

20. „softwarecomponenten”: modules die kunnen worden toegevoegd of gekoppeld aan andere herbruikbare softwaremodules om een softwaretoepassing op maat van de klant samen te stellen;

21. „onafhankelijke softwarecomponenten”: softwarecomponenten waarvan de werking niet wordt verstoord door dezelfde omstandigheden als die waardoor het gevaar wordt veroorzaakt;

22. „responstijd”: de tijd die de software krijgt om te reageren op geleverde input of periodieke gebeurtenissen, en/of de prestaties van de software, uitgedrukt in aantal transacties of boodschappen per tijdseenheid;

23. „softwarecapaciteit”: de capaciteit van de software om een bepaalde gegevensstroom te verwerken;

24. „nauwkeurigheid”: de vereiste nauwkeurigheid van de berekende resultaten;

25. „vereist geheugen”: het binnen een computersysteem beschikbare geheugen dat door de softwaretoepassing kan worden gebruikt;

26. „stabiliteit van de software”: het gedrag van de software bij onverwachte gebeurtenissen, hardwaredefecten en stroomonderbrekingen, hetzij binnen het computersysteem, hetzij in daaraan gekoppelde apparatuur;

27. „overbelastingstolerantie”: het gedrag van het systeem en met name zijn tolerantie bij een grotere input dan bij een normale werking van het systeem kan worden verwacht;

28. „correcte en volledige verificatie van de EATMN-software”: situatie waarin alle softwareveiligheidseisen correct de eisen weergeven die in het kader van het risicobeoordelings- en -beperkingsproces aan de softwarecomponent worden gesteld en waarin de toepassing van die eisen overeenkomstig het vereiste softwarezekerheidsniveau is aangetoond;

29. „gegevens betreffende de levenscyclus van de software”: de gegevens die gedurende de levenscyclus van de software worden gegenereerd om de activiteiten te plannen, te sturen, te verklaren, te definiëren, te registreren of aan te tonen; deze gegevens maken de goedkeuring van de softwarelevenscyclusprocessen, van het systeem of van de uitrusting en van wijzigingen van het softwareproduct na de goedkeuring mogelijk;

30. „levenscyclus van de software”: a) een door een organisatie als toereikend en passend gedefinieerde geordende reeks processen om een softwareproduct te ontwikkelen; b) de periode tussen het moment waarop wordt beslist een softwareproduct te ontwikkelen of te wijzigen en het moment waarop dat product buiten dienst wordt gesteld;

31. „systeemveiligheidseis”: een veiligheidseis die van toepassing is op een functioneel systeem.

Artikel 3

Algemene veiligheidseisen

1. Wanneer een organisatie op grond van de toepasselijke communautaire of nationale wetgeving verplicht is een risicobeoordelings- en -beperkingsproces uit te voeren, dient zij een specifiek systeem ter verzekering van de softwareveiligheid te definiëren en te implementeren voor alle EATMN-softwaregerelateerde aspecten, waaronder alle online operationele aanpassingen en met name omschakeling of hot swapping.

2. De organisatie zorgt ervoor dat haar systeem ter verzekering van de softwareveiligheid ten minste de volgende elementen aantoont en signaleert:

a) de softwareveiligheidseisen geven correct weer waaraan de software dient te beantwoorden om aan de door middel van het risicobeoordelings- en -beperkingsproces vastgestelde veiligheidsdoelstellingen en -eisen te voldoen;

b) de traceerbaarheid van alle softwareveiligheidseisen wordt verzekerd;

c) de invoering van de software creëert geen functies die een negatieve invloed hebben op de veiligheid;

d) de EATMN-software voldoet aan de toepasselijke eisen met een betrouwbaarheidsgraad die overeenstemt met de kritische factor van de software;

e) zekerheden worden verschaft die bevestigen dat is voldaan aan de onder a) tot en met d) genoemde algemene veiligheidseisen; het bewijs dat de vereiste zekerheid wordt geboden, wordt steeds geleverd op basis van: i) een bekende operationele versie van de software, ii) een bekende reeks configuratiegegevens, en iii) bekende softwareproducten en -omschrijvingen, met inbegrip van de specificaties, die gebruikt zijn voor de productie van de betrokken versie.

3. De organisatie stelt de vereiste zekerheden die aantonen dat aan de in lid 2 genoemde eisen is voldaan ter beschikking van de nationale toezichthoudende instantie.

Artikel 4

Voorschriften met betrekking tot het systeem ter verzekering van de softwareveiligheid

De organisatie zorgt ervoor dat het systeem ter verzekering van de softwareveiligheid ten minste:

1. gedocumenteerd is als onderdeel van de algemene documentatie inzake risicobeoordeling en -beperking;

2. een softwarezekerheidsniveau toewijst aan alle operationele EATMN-software overeenkomstig de in bijlage I genoemde eisen;

3. zekerheid biedt met betrekking tot: a) de validering van softwareveiligheidseisen overeenkomstig de in bijlage II, deel A, genoemde eisen; b) verificatie van de software overeenkomstig de in bijlage II, deel B, genoemde eisen; c) het beheer van de softwareconfiguratie overeenkomstig de in bijlage II, deel C, genoemde eisen, en d) de traceerbaarheid van softwareveiligheidseisen overeenkomstig de in bijlage II, deel D, genoemde eisen;

4. bepaalt met welke striktheidsgraad de zekerheid wordt vastgesteld; voor elk softwarezekerheidsniveau wordt de striktheidsgraad vastgesteld; deze stijgt evenredig met de kritische factor van de software; daartoe: a) moet de striktheidsgraad van de zekerheid per softwarezekerheidsniveau variëren overeenkomstig de volgende criteria: i) onafhankelijk te voldoen, ii) te voldoen, iii) niet vereist. b) dienen de met elk softwarezekerheidsniveau overeenstemmende zekerheden voldoende waarborgen te bieden dat de EATMN-software voldoet aan de geldende veiligheidsnormen.

5. de feedback van de EATMN-software gebruikt om te bevestigen dat het systeem ter verzekering van de softwareveiligheid en de toegewezen zekerheidsniveaus passend zijn. De overeenkomstig de relevante eisen inzake rapportage en evaluatie van veiligheidsincidenten gerapporteerde effecten van een softwarestoring of -falen worden getoetst aan de voor het betrokken systeem vastgestelde effecten per in punt 3.2.4 van bijlage II bij ►M1 Uitvoeringsverordening (EU) nr. 1035/2011 van de Commissie ( 4 ) ◄ bepaalde ernstcategorie.

Artikel 5

Eisen inzake wijzigingen van de software en specifieke software

1. Wanneer bij een wijziging in de software of in specifieke soorten software zoals COTS, standaardsoftware of reeds gebruikte software een aantal eisen van artikel 3, lid 2, onder d) of e), of van artikel 4, punten 2, 3, 4 of 5, niet kunnen worden toegepast, zorgt de organisatie ervoor dat het systeem ter verzekering van de softwareveiligheid op een andere in overleg met de toezichthoudende instantie bepaalde manier dezelfde betrouwbaarheid waarborgt als het voor vergelijkbare software vastgestelde softwarezekerheidsniveau.

Die middelen dienen voldoende te waarborgen dat de software voldoet aan de in het risicobeoordelings- en -beperkingsproces vastgestelde veiligheidsdoelstellingen en -eisen.

2. Voor de beoordeling van de in lid 1 bedoelde middelen kan de nationale toezichthoudende instantie een beroep doen op een erkende organisatie of een aangemelde instantie.

▼M1 —————

▼B

Artikel 7

Inwerkingtreding

Deze verordening treedt in werking op de twintigste dag volgende op die van haar bekendmaking in het Publicatieblad van de Europese Unie.

Zij is vanaf 1 januari 2009 van toepassing op de nieuwe software van de in artikel 1, lid 2, bedoelde EATMN-systemen.

Zij is vanaf 1 juli 2010 van toepassing op elke wijziging van de software van de in artikel 1, lid 2, bedoelde EATMN-systemen die op die datum in gebruik zijn.

Deze verordening is verbindend in al haar onderdelen en is rechtstreeks toepasselijk in elke lidstaat.









BIJLAGE I

Eisen met betrekking tot het softwarezekerheidsniveau als bedoeld in artikel 4, punt 2

1. Het softwarezekerheidsniveau is de relatie tussen de striktheid van de softwarezekerheid en de kritische factor van EATMN-software op basis van de in punt 3.2.4, deel 4, van bijlage II bij ►M1 Uitvoeringsverordening (EU) nr. 1035/2011 ◄ vastgestelde ernstcategorieën in combinatie met de waarschijnlijkheid dat een incident zich voordoet. Er worden ten minste vier softwarezekerheidsniveaus gedefinieerd, waarbij softwarezekerheidsniveau 1 het meest kritische niveau is.

2. Het toegewezen softwarezekerheidsniveau wordt afgestemd op het ernstigste gevolg dat door een softwarestoring of -falen kan worden veroorzaakt, als bedoeld in punt 3.2.4, deel 4, van bijlage II bij ►M1 Uitvoeringsverordening (EU) nr. 1035/2011 ◄ . Hierbij wordt met name rekening gehouden met de risico’s die een softwarestoring of -falen met zich brengt en de aanwezige architecturale en/of procedurele veiligheidsmaatregelen.

3. Aan EATMN-softwarecomponenten waarvan niet kan worden aangetoond dat zij onafhankelijk van elkaar kunnen functioneren, wordt het softwarezekerheidsniveau van de meest kritische afhankelijke component toegewezen.









BIJLAGE II

Deel A: Eisen met betrekking tot de zekerheid betreffende de validering van de softwareveiligheidseisen als bedoeld in artikel 4, punt 3, onder a)

1. In de softwareveiligheidseisen wordt het functionele gedrag van de EATMN-software bij normaal en gestoord bedrijf alsmede de passende responstijd, capaciteit, nauwkeurigheid, het vereiste geheugen op de doelhardware, de stabiliteit in uitzonderlijke omstandigheden en overbelastingstolerantie omschreven.

2. De softwareveiligheidseisen dienen volledig en correct te zijn en te beantwoorden aan de systeemveiligheidseisen.

Deel B: Eisen met betrekking tot de zekerheid betreffende de verificatie van de software als bedoeld in artikel 4, punt 3, onder b)

1. Het functionele gedrag van de EATMN-software, de responstijd, capaciteit, nauwkeurigheid, het vereiste geheugen op de doelhardware, de stabiliteit in uitzonderlijke omstandigheden en overbelastingstolerantie dienen te voldoen aan de software-eisen.

2. De EATMN-software dient op passende wijze te worden gecontroleerd door middel van analyse en/of tests en/of gelijkwaardige middelen en overeenkomstig de afspraken met de nationale toezichthoudende instantie.

3. De verificatie van de EATMN-software dient correct en volledig te gebeuren.

Deel C: Eisen met betrekking tot de zekerheid betreffende het beheer van de softwareconfiguratie als bedoeld in artikel 4, punt 3, onder c)

1. Er wordt voorzien in procedures voor de identificatie, traceerbaarheid en status van de configuratie zodat kan worden aangetoond dat de gegevens betreffende de levenscyclus van de software tijdens de volledige levenscyclus van de EATMN-software aan een configuratiecontrole worden onderworpen.

2. Procedures voor de rapportage van storingen, tracking en de vaststelling van corrigerende maatregelen zodat kan worden aangetoond dat veiligheidsproblemen die met de software te maken hebben, worden opgevangen.

3. Opzoekings- en releaseprotocollen waardoor gegevens betreffende de levenscyclus van de software gedurende de gehele levenscyclus van de EATMN-software kunnen worden gegenereerd en geproduceerd.

Deel D: Eisen met betrekking tot de zekerheid betreffende de traceerbaarheid van de softwareveiligheidseisen als bedoeld in artikel 4, punt 3, onder d)

1. Elke softwareveiligheidseis moet kunnen worden gekoppeld aan het ontwerpniveau waarop de conformiteit is aangetoond.

2. Elke softwareveiligheidseis moet op elk ontwerpniveau waarop zijn conformiteit is aangetoond, kunnen worden gekoppeld aan een systeemveiligheidseis.