EUR-Lex Access to European Union law

Back to EUR-Lex homepage

This document is an excerpt from the EUR-Lex website

Document 32008R0482

Regulamento (CE) n. o  482/2008 da Comissão, de 30 de Maio de 2008 , que estabelece um sistema de garantia de segurança do software , a aplicar pelos prestadores de serviços de navegação aérea, e que altera o anexo II do Regulamento (CE) n. o  2096/2005 Texto relevante para efeitos do EEE

OJ L 141, 31.5.2008, p. 5–10 (BG, ES, CS, DA, DE, ET, EL, EN, FR, IT, LV, LT, HU, MT, NL, PL, PT, RO, SK, SL, FI, SV)
Special edition in Croatian: Chapter 07 Volume 016 P. 88 - 93

No longer in force, Date of end of validity: 01/01/2020; revogado por 32017R0373 . Latest consolidated version: 07/11/2011

ELI: http://data.europa.eu/eli/reg/2008/482/oj

31.5.2008   

PT

Jornal Oficial da União Europeia

L 141/5


REGULAMENTO (CE) N.o 482/2008 DA COMISSÃO

de 30 de Maio de 2008

que estabelece um sistema de garantia de segurança do software, a aplicar pelos prestadores de serviços de navegação aérea, e que altera o anexo II do Regulamento (CE) n.o 2096/2005

(Texto relevante para efeitos do EEE)

A COMISSÃO DAS COMUNIDADES EUROPEIAS,

Tendo em conta o Tratado que institui a Comunidade Europeia,

Tendo em conta o Regulamento (CE) n.o 550/2004 do Parlamento Europeu e do Conselho, de 10 de Março de 2004, relativo à prestação de serviços de navegação aérea no céu único europeu («regulamento relativo à prestação de serviços») (1), nomeadamente o artigo 4.o,

Considerando o seguinte:

(1)

Nos termos do Regulamento (CE) n.o 550/2004, a Comissão deve identificar e adoptar as especificações regulamentares Eurocontrol sobre segurança (ESARR), tendo em conta a legislação comunitária vigente. As ESARR 6, denominadas «Software dos sistemas de gestão do tráfego aéreo», contêm uma série de especificações regulamentares sobre segurança, para a aplicação de um sistema de garantia de segurança do software.

(2)

O Regulamento (CE) n.o 2096/2005 da Comissão, de 20 de Dezembro de 2005, que estabelece requisitos comuns para a prestação de serviços de navegação aérea (2), declara, na última frase do considerando 12, que «(as) disposições relevantes das ESARR 1, relativas à supervisão da segurança na gestão do tráfego aéreo, e das ESARR 6, relativas ao software dos sistemas de gestão do tráfego aéreo, devem ser identificadas e adoptadas por actos comunitários separados».

(3)

O anexo II do Regulamento (CE) n.o 2096/2005 impõe que os prestadores de serviços de navegação aérea apliquem um sistema de gestão da segurança, bem como requisitos de segurança para a avaliação e redução de riscos relativamente a alterações. No âmbito do seu sistema de gestão da segurança e das suas actividades de avaliação e redução de riscos relativamente a alterações, os prestadores de serviços de navegação aérea devem definir e aplicar um sistema de garantia de segurança do software que trate especificamente das questões relativas ao software.

(4)

Em termos de segurança do software, o principal objectivo a atingir pelos sistemas funcionais que o contêm consiste em assegurar que os riscos associados à utilização de software nos sistemas da Rede Europeia de Gestão do Tráfego Aéreo («software da REGTA») tenham sido reduzidos a um nível tolerável.

(5)

O presente regulamento não abrange as operações e treinos militares referidos no n.o 2 do artigo 1.o do Regulamento (CE) n.o 549/2004 do Parlamento Europeu e do Conselho, de 10 de Março de 2004, que estabelece o quadro para a realização do céu único europeu («regulamento quadro») (3).

(6)

O anexo do Regulamento (CE) n.o 2096/2005 deve, por conseguinte, ser alterado em conformidade.

(7)

As medidas previstas no presente regulamento estão em conformidade com o parecer do Comité do Céu Único,

ADOPTOU O PRESENTE REGULAMENTO:

Artigo 1.o

Objecto e âmbito de aplicação

1.   O presente regulamento estabelece os requisitos relativos à definição e à aplicação de um sistema de garantia de segurança do software por parte de prestadores de serviços de tráfego aéreo (ATS), entidades prestadoras de serviços de gestão de fluxos de tráfego aéreo (ATFM) e de serviços de gestão do espaço aéreo (ASM) e prestadores de serviços de comunicação, navegação e vigilância (CNS), para o tráfego aéreo geral.

Identifica e adopta as disposições vinculativas das especificações regulamentares do Eurocontrol sobre segurança — ESARR 6 –, denominadas «Software dos sistemas de gestão do tráfego aéreo», emitidas em 6 de Novembro de 2003.

2.   O presente regulamento aplica-se ao novo software e a quaisquer alterações do software utilizado nos sistemas de ATS, ASM, ATFM e CNS.

O presente regulamento não se aplica ao software de elementos aerotransportados ou ao equipamento espacial.

Artigo 2.o

Definições

Para efeitos do presente regulamento, são aplicáveis as definições do artigo 2.o do Regulamento (CE) n.o 549/2004.

São também aplicáveis as seguintes definições:

1.

«Software»: programas informáticos e correspondentes dados de configuração, incluindo software extrínseco, mas excluindo elementos electrónicos, nomeadamente circuitos integrados de aplicação específica, matrizes de portas lógicas programáveis ou controladores lógicos de estado sólido;

2.

«Dados de configuração»: dados que configuram um sistema de software genérico para uma determinada utilização;

3.

«Software extrínseco»: software não desenvolvido para o contrato actual;

4.

«Garantia de segurança»: o conjunto de acções planeadas e sistemáticas necessárias para proporcionar a confiança adequada na obtenção de um nível de segurança aceitável ou tolerável para um produto, serviço, organização ou sistema funcional;

5.

«Organização»: um prestador de ATS, um prestador de serviços CNS ou uma entidade prestadora de serviços ATFM ou ASM;

6.

«Sistema funcional»: uma combinação de sistemas, procedimentos e recursos humanos organizados para desempenhar uma função no contexto da gestão do tráfego aéreo (ATM);

7.

«Risco»: a combinação da probabilidade global ou da frequência de ocorrência de um efeito nocivo induzido por uma situação de perigo e a gravidade desse efeito;

8.

«Situação de perigo»: qualquer situação, acontecimento ou circunstância susceptível de causar um acidente;

9.

«Novo software»: um software encomendado ou relativamente ao qual foram assinados contratos vinculativos após a entrada em vigor do presente regulamento;

10.

«Objectivo de segurança»: uma declaração qualitativa ou quantitativa que define a frequência ou a probabilidade máximas previsíveis de ocorrência de uma situação de perigo;

11.

«Requisito de segurança»: um meio de redução do risco, definido no contexto de uma estratégia de redução do risco, que permite atingir um objectivo de segurança específico, incluindo requisitos organizacionais, operacionais, processuais, funcionais, de desempenho e de interoperabilidade e/ou características ambientais;

12.

«Transferência (cutover) ou permuta a quente (hot swapping)»: substituição de componentes ou de software de um sistema da Rede Europeia de Gestão do Tráfego Aéreo (REGTA) enquanto o sistema está operacional;

13.

«Requisito de segurança do software»: descrição do que deve ser produzido pelo software em função dos inputs (dados introduzidos) e dos condicionalismos e que, se for de facto produzido, assegurará que o software da REGTA funcionará em segurança e de acordo com as necessidades operacionais;

14.

«Software da REGTA»: software utilizado nos sistemas da rede europeia de gestão do tráfego aéreo a que se refere o artigo 1.o;

15.

«Validade dos requisitos»: confirmação, mediante exame e fornecimento de prova objectiva, de que os requisitos relativos a uma utilização específica correspondem ao pretendido;

16.

«Execução com independência»: execução das actividades do processo de verificação do software por pessoas distintas daquelas que desenvolveram o produto sujeito a verificação;

17.

«Anomalia do software»: incapacidade de um programa para executar correctamente uma função requerida;

18.

«Falha do software»: incapacidade de um programa para executar uma função requerida;

19.

«COTS»: aplicação comercializada publicamente por catálogo e que não se destina a ser adaptada ao utilizador ou aperfeiçoada;

20.

«Componentes de software»: bloco constituinte que pode ser adaptado ou ligado a outros constituintes reutilizáveis do software, para combinar e criar uma aplicação de software adaptada ao utilizador;

21.

«Componentes de software independentes»: componentes de software que não ficam inoperacionais pela mesma situação de falha que causa a situação de perigo;

22.

«Desempenho do software em termos de tempo»: tempo concedido ao software para responder aos dados introduzidos ou a ocorrências periódicas e/ou desempenho do software em termos de transacções ou mensagens tratadas por unidade de tempo;

23.

«Capacidade do software»: aptidão do software para processar um determinado fluxo de dados;

24.

«Precisão»: exactidão requerida para os resultados calculados;

25.

«Utilização dos recursos de software»: quantidade de recursos do sistema informático que podem ser utilizados pelo software da aplicação;

26.

«Robustez do software»: comportamento do software na eventualidade de introdução de dados inesperados, falhas do equipamento e interrupções da alimentação energética, quer no próprio sistema informático quer em dispositivos a ele ligados;

27.

«Tolerância à sobrecarga»: comportamento do sistema na eventualidade de uma introdução de dados a ritmo superior ao esperado durante o seu funcionamento normal e, em especial, tolerância do sistema a essa eventualidade;

28.

«Verificação correcta e completa do software da REGTA»: todos os requisitos de segurança do software especificam correctamente o que o processo de avaliação e redução de riscos requer do componente de software e o seu cumprimento é demonstrado ao nível que o sistema de garantia requer;

29.

«Dados do ciclo de vida do software»: dados produzidos durante o ciclo de vida do software para planear, dirigir, explicar, definir, registar ou comprovar actividades; estes dados possibilitam os processos do ciclo de vida do software, a aprovação do sistema ou equipamento e a modificação pós-aprovação do produto de software;

30.

«Ciclo de vida do software»:

a)

Série ordenada de processos que uma organização determina como suficientes e adequados para produzir um produto de software;

b)

Intervalo de tempo que se inicia com a decisão de produzir ou modificar um produto de softwaree e termina quando o produto é retirado do serviço;

31.

«Requisito de segurança do sistema»: requisito de segurança derivado para um sistema funcional.

Artigo 3.o

Requisitos gerais de segurança

1.   Se a uma organização for requerida a execução de um processo de avaliação e redução de riscos em conformidade com as disposições comunitárias ou nacionais aplicáveis, a organização definirá e porá em prática um sistema de garantia de segurança do software, dedicado especificamente a questões relacionadas com o software da REGTA, incluindo todas as alterações operacionais em linha do software, em particular a transferência ou a permuta a quente.

2.   A organização assegurará, no mínimo, que o seu sistema de garantia de segurança do software forneça provas e argumentos que demonstrem o seguinte:

a)

Os requisitos de segurança do software especificam correctamente o que o software requer para se cumprirem os objectivos e requisitos de segurança identificados pelo processo de avaliação e redução de riscos;

b)

A rastreabilidade aplica-se a todos os requisitos de segurança do software;

c)

A implementação do software não contém funções que afectem adversamente a segurança;

d)

O software da REGTA satisfaz os seus requisitos com um nível de confiança coerente com a importância crítica do software;

e)

São fornecidas garantias assegurando que os requisitos gerais de segurança estabelecidos nas alíneas a) a d) são satisfeitos, e os argumentos para demonstrar a garantias requeridas são sempre derivados de:

i)

uma versão do software conhecida e executável,

ii)

uma gama conhecida de dados de configuração,

iii)

um conjunto conhecido de produtos e descrições de software, incluindo especificações, utilizados na produção daquela versão.

3.   A organização disponibilizará à autoridade supervisora nacional as garantias requeridas, demonstrando que os requisitos referidos no n.o 2 foram satisfeitos.

Artigo 4.o

Requisitos aplicáveis ao sistema de garantia de segurança do software

A organização assegurará, no mínimo, que o sistema de garantia de segurança do software:

1.

Seja documentado, como parte específica da documentação relativa ao processo geral de avaliação e redução de riscos;

2.

Atribua níveis de garantia a todo o software operacional da REGTA, em conformidade com os requisitos constantes do anexo I;

3.

Inclua garantias de:

a)

validade dos requisitos de segurança do software, em conformidade com o anexo II, parte A;

b)

Verificação do software, em conformidade com o anexo II, parte B;

c)

Gestão da configuração do software, em conformidade com o anexo II, parte C,

d)

Rastreabilidade dos requisitos de segurança do software, em conformidade com o anexo II, parte D;

4.

Determine o rigor com o qual as garantias são estabelecidas. O rigor será definido para cada nível de garantia do software e aumentará na medida em que a importância do software se tornar mais crítica. Para este efeito:

a)

A variação no rigor das garantias por cada nível de garantia do software corresponderá aos seguintes critérios:

i)

deve ser conseguida com independência,

ii)

deve ser conseguida,

iii)

não é requerida;

b)

As garantias correspondentes a cada nível de garantia do software darão suficiente confiança de que o software da REGTA pode ser utilizado com segurança tolerável;

5.

Aproveite a experiência do software da REGTA para confirmar que o sistema de garantia de segurança do software e os níveis de garantia atribuídos são adequados. Para isso, os efeitos de qualquer anomalia ou falha do software, comunicada de acordo com os pertinentes requisitos em matéria de comunicação e avaliação de ocorrências relacionadas com a segurança, serão avaliados em comparação com os efeitos identificados para o sistema em causa segundo a grelha de classificação da gravidade estabelecida no Regulamento (CE) n.o 2096/2005 da Comissão, anexo II, ponto 3.2.4.

Artigo 5.o

Requisitos aplicáveis a alterações do software e a software específico

1.   No caso de alterações do software ou de tipos específicos de software, como uma COTS, um software extrínseco ou um software previamente utilizado ao qual não podem ser aplicados alguns dos requisitos constantes do n.o 2, alíneas d) ou e), do artigo 3.o ou dos n.os 2, 3, 4 ou 5 do artigo 4.o, a organização assegurará que o sistema de garantia de segurança do software proporcione, por outros meios escolhidos e acordados com a autoridade supervisora nacional, o mesmo nível de confiança que o nível de garantia eventualmente definido para o software.

Estes meios darão suficiente confiança de que o software cumpre os objectivos e requisitos de segurança identificados pelo processo de avaliação e redução de riscos.

2.   Na avaliação dos meios referidos no n.o 1, a autoridade supervisora nacional poderá recorrer a uma organização reconhecida ou a um organismo notificado.

Artigo 6.o

Alteração do Regulamento (CE) n.o 2096/2005

Ao anexo II do Regulamento (CE) n.o 2096/2005 é aditado o seguinte ponto:

«3.2.5.   Secção 5

Sistema de garantia de segurança do software

No âmbito do funcionamento do sistema de gestão da segurança, os prestadores de serviços de tráfego aéreo devem aplicar um sistema de garantia de segurança do software em conformidade com o Regulamento (CE) n.o 482/2008 da Comissão, de 30 de Maio de 2008, [que estabelece um sistema de garantia de segurança do software, a aplicar pelos prestadores de serviços de navegação aérea, e que altera o Regulamento (CE) n.o 2096/2005 (4)].

Artigo 7.o

Entrada em vigor

O presente regulamento entra em vigor no vigésimo dia seguinte ao da sua publicação no Jornal Oficial da União Europeia.

É aplicável a partir de 1 de Janeiro de 2009 ao novo software dos sistemas da REGTA referidos no n.o 2 do artigo 1.o

É aplicável a partir de 1 de Julho de 2010 a todas as alterações do software utilizado nos sistemas da REGTA aos quais se refere o n.o 2 do artigo 1.o e que àquela data estejam em funcionamento.

O presente regulamento é obrigatório em todos os seus elementos e directamente aplicável em todos os Estados-Membros.

Feito em Bruxelas, em 30 de Maio de 2008.

Pela Comissão

Antonio TAJANI

Membro da Comissão


(1)  JO L 96 de 31.3.2004, p. 10.

(2)  JO L 335 de 21.12.2005, p. 13. Regulamento alterado pelo Regulamento (CE) n.o 1315/2007 (JO L 291 de 9.11.2007, p. 16).

(3)  JO L 96 de 31.3.2004, p. 1.

(4)  JO L 141 de 31.5.2008, p. 5.».


ANEXO I

Requisitos aplicáveis ao nível de garantia do software referido no n.o 2 do artigo 4.o

1.

O nível de garantia do software associará o rigor das garantias do software à importância crítica do software da REGTA, utilizando a grelha de classificação da gravidade constante estabelecidos na secção 4 do ponto 3.2.4 do anexo II do Regulamento (CE) n.o 2096/2005 da Comissão, de 20 de Dezembro de 2005, em combinação com a probabilidade de ocorrência de um determinado efeito grave. Identificar-se-ão, pelo menos, quatro níveis de garantia do software, sendo o nível 1 o mais crítico.

2.

O nível de garantia atribuído ao software será proporcional ao efeito mais grave que as anomalias ou falhas do software possam causar, tal como referido na secção 4 do ponto 3.2.4 do anexo II do Regulamento (CE) n.o 2096/2005. Serão tidos em conta, nomeadamente, os riscos associados a anomalias ou falhas do software e as medidas de defesa arquitecturais e/ou processuais identificadas.

3.

Aos componentes do software da REGTA cuja independência mútua não puder ser demonstrada será atribuído o nível de garantia dos componentes dependentes mais críticos.


ANEXO II

Parte A:   Requisitos aplicáveis à validade dos requisitos de segurança do software a que se refere o n.o 3, alínea a), do artigo 4.o

1.

Os requisitos de segurança do software especificarão o comportamento funcional, nos modos nominal e degradado, do software da REGTA, o desempenho em termos de tempo, a capacidade, a precisão, a utilização dos recursos de software no equipamento-alvo, a robustez em condições de funcionamento anormais e a tolerância à sobrecarga, conforme o caso.

2.

Os requisitos de segurança do software serão completos e correctos e cumprirão os requisitos de segurança do sistema.

Parte B:   Requisitos aplicáveis às garantias de verificação do software a que se refere o n.o 3, alínea b), do artigo 4.o

1.

O comportamento funcional do software da REGTA, o desempenho em termos de tempo, a capacidade, a precisão, a utilização dos recursos de software no equipamento-alvo, a robustez em condições de funcionamento anormais e a tolerância à sobrecarga cumprirão os requisitos do software.

2.

O software da REGTA será adequadamente verificado por análise e/ou ensaio e/ou meios equivalentes, conforme acordado com a autoridade supervisora nacional.

3.

A verificação do software da REGTA será correcta e completa.

Parte C:   Requisitos aplicáveis às garantias de gestão da configuração do software a que se refere o n.o 3, alínea c), do artigo 4.o

1.

Haverá identificação, rastreabilidade e tomada em conta do estatuto da configuração, de modo a poder demonstrar que a configuração dos dados relativos ao ciclo de vida do software está sob controlo ao longo de todo o ciclo de vida do software da REGTA.

2.

Haverá comunicação e rastreio de problemas e correspondentes acções correctivas, de modo a poder demonstrar a redução dos problemas de segurança associados ao software.

3.

Haverá procedimentos de restauração e disponibilização que permitam regenerar e apresentar os dados relativos ao ciclo de vida do software ao longo de todo o ciclo de vida do software da REGTA.

Parte D:   Requisitos aplicáveis às garantias de rastreabilidade dos requisitos de segurança do software a que se refere o n.o 3, alínea d), do artigo 4.o

1.

Cada um dos requisitos de segurança do software será rastreado de acordo com o nível de concepção cujo cumprimento seja demonstrado.

2.

Cada um dos requisitos de segurança do software, a cada nível de concepção cujo cumprimento seja demonstrado, será rastreado de acordo com um requisito de segurança do sistema.


Top