Escolha as funcionalidades experimentais que pretende experimentar

Este documento é um excerto do sítio EUR-Lex

Documento C(2019)1789

REGULAMENTO DELEGADO (UE) …/... DA COMISSÃO que complementa a Diretiva 2010/40/UE do Parlamento Europeu e do Conselho no que diz respeito à implantação e à utilização operacional de sistemas cooperativos de transporte inteligentes

C/2019/1789 final

EXPOSIÇÃO DE MOTIVOS

1.Contexto político

O volume crescente do transporte rodoviário na União Europeia coloca vários desafios. O transporte rodoviário é responsável pela maior parte das emissões de gases com efeito de estufa e de poluentes atmosféricos provenientes do setor dos transportes no seu conjunto. Embora a segurança rodoviária tenha melhorado na UE nas últimas décadas, esta tendência abrandou recentemente e é pouco provável que a UE atinja o seu objetivo de reduzir em 50 % o número de vítimas mortais entre 2010 e 2020. Além disso, as estradas congestionadas geram custos consideráveis para a economia da UE. É necessária uma ação coordenada em várias frentes para fazer face a estes problemas e evitar danos graves para as populações, a economia, o ambiente e o clima da Europa.

As novas tecnologias destinadas a melhorar a eficiência, a segurança e o desempenho ambiental dos transportes rodoviários desempenham um papel significativo na consecução dos objetivos da Comissão neste domínio. Um domínio emergente é o dos sistemas cooperativos de transporte inteligentes (STIC), que permitem uma interação direta entre veículos, e entre estes e as infraestruturas rodoviárias circundantes. No setor do transporte rodoviário, os STIC implicam normalmente a comunicação veículoveículo («V2V»), veículoinfraestrutura («V2I») e/ou infraestruturainfraestrutura («I2I»), bem como a comunicação entre veículos e peões ou ciclistas («veículomeio circundante» ou «V2X»). Tal possibilita uma vasta gama de serviços de informação e cooperação.

Os STIC são uma categoria de serviços STI, com base numa rede aberta que permite a existência de uma relação «todos para todos» (manytomany) ou interpares entre estações STIC. Tal significa que todas as estações STIC, tal como definidas no presente regulamento, podem trocar mensagens de forma segura entre si, não estando limitadas ao intercâmbio de mensagens com uma ou mais estações predefinidas. Os serviços STI que fornecem informações semelhantes, por exemplo, via radiodifusão digital, redes celulares ou rádio FM, mas que não têm as características de uma rede aberta que permita uma relação «todos para todos» ou interpares entre estações STIC, estão fora do âmbito de aplicação do presente regulamento.

Os benefícios dos STIC fazemse sentir numa série de domínios, nomeadamente maior segurança rodoviária, menos congestionamento, maior eficiência dos transportes, mobilidade e fiabilidade dos serviços, redução do consumo de energia, menos impactos ambientais negativos e apoio ao desenvolvimento económico. Ao mesmo tempo, há que ter o cuidado de evitar potenciais efeitos negativos, como, por exemplo, o aumento da procura de tráfego decorrente destas melhorias, uma sobrecarga de informação aos condutores ou um maior número de riscos em matéria de cibersegurança ou de privacidade gerado pelo aumento da partilha de dados.

Na última década, registaramse novos desenvolvimentos notáveis no que respeita às tecnologias que facilitam os STIC. No entanto, apesar dos potenciais benefícios, estes ainda não se traduziram numa implantação em grande escala. Em 2011, os fabricantes de veículos da UE reunidos no Consórcio para a Comunicação Car2Car emitiram um memorando de entendimento comum, declarando a sua intenção de iniciar até 2015 a implantação em grande escala, uma vez que os sistemas estariam tecnologicamente prontos até essa data. No entanto, tornouse claro que tal seria impossível, a menos que as principais partes interessadas adotassem uma abordagem comum dos aspetos técnicos e não técnicos.

Em 2014, a Comissão respondeu criando uma plataforma para a implantação de sistemas cooperativos de transporte inteligentes na UE (plataforma STIC), um grupo de peritos, no âmbito do qual as autoridades nacionais, as partes interessadas nos STIC e a Comissão poderiam trabalhar em conjunto numa visão partilhada e em soluções concretas para a implantação interoperável de STIC na UE. Os resultados do extenso trabalho da plataforma e dos seus grupos de trabalho foram resumidos nos relatórios finais 1 para a fase I (20142016) e para a fase II (20162017).

Através da plataforma CRoads 2 , uma iniciativa conjunta dos EstadosMembros e dos operadores rodoviários para ensaiar e implementar serviços STIC à luz da harmonização e interoperabilidade transfronteiras, e de investimentos significativos a nível nacional e da UE (199 milhões de EUR, dos quais 107 milhões de EUR foram cofinanciados através do Mecanismo Interligar a Europa), 16 EstadosMembros trabalharam em conjunto com a indústria, a fim de harmonizar os serviços STIC V2I e tornálos interoperáveis, de modo a que, por exemplo, as mensagens sobre obras rodoviárias sejam interpretadas de forma coerente em diferentes ambientes geográficos e por fabricantes de veículos diferentes. Tratase do resultado da cooperação entre a plataforma CRoads e o Consórcio para a Comunicação Car2Car, que veio melhorar a coerência das mensagens e dos sistemas V2V e V2I.

Em 2016, um grupo de empresas do setor automóvel e das telecomunicações criou a Associação Automóvel 5G no domínio da tecnologia para a mobilidade conectada e automatizada, incluindo para os serviços STIC. Criouse, assim, uma situação em que existem duas tecnologias para a comunicação de pequeno alcance, com níveis de maturidade e de comercialização diferentes, que não são interoperáveis ao nível do acesso rádio.

O trabalho desenvolvido pela plataforma STIC prestou um contributo essencial no contexto da estratégia europeia para os STIC 3 , que visava facilitar a convergência dos investimentos e dos quadros regulamentares em toda a UE, para que a implantação pudesse começar o mais rapidamente possível e, em especial, para permitir a implantação, a partir de 2019, dos serviços STIC consolidados relacionados com segurança. A estratégia identificou a necessidade de adotar um quadro jurídico adequado a nível da UE até 2018, eventualmente através de atos delegados ao abrigo da Diretiva 2010/40/UE [Diretiva Sistemas de Transporte Inteligentes (STI)] 4 ou de outros instrumentos jurídicos.

O objetivo do presente regulamento delegado, que complementa a Diretiva 2010/40/UE do Parlamento Europeu e do Conselho, é criar os requisitos jurídicos mínimos para a interoperabilidade dos STIC e permitir a implantação em grande escala de sistemas e serviços STIC a partir de 2019. A Diretiva 2010/40/UE («Diretiva STI») constitui um quadro político e jurídico para acelerar a implantação de soluções de transporte inovadoras em toda a Europa. A diretiva centrase nos sistemas de transporte inteligentes para o transporte rodoviário e na sua interface com outros modos de transporte e habilita a Comissão a adotar atos delegados em quatro domínios prioritários. A definição de especificações para os STIC faz parte do domínio prioritário IV da diretiva.

O presente regulamento delegado centrase nos serviços «Day 1», ou seja, os serviços STIC a implantar a curto prazo, que contribuirão especialmente para a segurança rodoviária e a eficiência do tráfego. Estão agora disponíveis especificações e normas para os serviços «Day 1» prioritários interoperáveis, bem como uma solução comum de segurança, graças à cooperação entre um vasto grupo de partes interessadas da indústria e as autoridades dos EstadosMembros.

2.BASE JURÍDICA, SUBSIDIARIEDADE E PROPORCIONALIDADE

2.1.Base jurídica

O presente ato delegado complementa a Diretiva 2010/40/UE em conformidade com o seu artigo 7.º. O regulamento é o instrumento jurídico mais adequado, uma vez que não exige medidas nacionais de transposição e, por conseguinte, garante um maior grau de harmonização, menos encargos administrativos para os EstadosMembros, maior segurança jurídica para as partes interessadas públicas e privadas e uma rápida entrada em vigor.

2.2.Subsidiariedade e proporcionalidade

De acordo com o princípio da subsidiariedade (artigo 5.º, n.º 3, do Tratado da União Europeia), a União intervém apenas se e na medida em que os objetivos da ação considerada não possam ser suficientemente alcançados pelos EstadosMembros, podendo contudo, devido às dimensões ou aos efeitos da ação considerada, ser mais bem alcançados ao nível da União.

Embora os serviços STIC já estejam a ser implantados através de projetos em toda a UE e em vários EstadosMembros, e muitos fabricantes de veículos tenham indicado a sua intenção de passarem à implantação em grande escala, muitos argumentaram que é necessário um quadro jurídico a nível da UE. A normalização liderada pela indústria, através dos Organismos Europeus de Normalização («OEN»), contribui para a interoperabilidade mas é voluntária e permite eventualmente formas de implementação divergentes e não interoperáveis. Uma vez que existem muitas partes interessadas e fortes efeitos de rede, nenhuma das partes interessadas pode, por si só, adotar uma solução interoperável. Do mesmo modo, o estabelecimento de regras a nível nacional constituiria provavelmente um obstáculo à prestação de serviços STIC contínuos no Espaço Único Europeu dos Transportes.

A compatibilidade entre as soluções relativas a infraestruturas e veículos terá de ser assegurada em toda a UE, a fim de colher todos os benefícios dos STIC. Além disso, é necessária uma abordagem mais harmonizada a nível da UE, a fim de assegurar sinergias eficazes com a implantação de novas tecnologias de segurança e a introdução de uma mobilidade cooperativa, conectada e automatizada («MCCA») em toda a UE. Sem um quadro inclusivo e orientado para o futuro a nível da UE, a implantação continuará provavelmente a ser fragmentada, descoordenada e incapaz de assegurar a continuidade geográfica dos serviços STIC em toda a UE e nas suas fronteiras externas.

O cumprimento do presente regulamento delegado apenas seria obrigatório se os serviços ou estações STIC fossem implantados. Embora as especificações vinculativas da UE exijam, de facto, que as atuais estações STIC e as novas soluções tecnológicas se adaptem a elas, são essenciais para garantir a interoperabilidade dos serviços STIC em toda a UE, e a revisão prevista permite flexibilidade no desenvolvimento de soluções tecnológicas. Um regulamento é mais rigoroso do que uma orientação ou recomendação, mas os benefícios diretos e indiretos esperados são também proporcionalmente mais elevados. Nesse sentido, o presente ato delegado é proporcional.

Outro efeito importante do presente regulamento delegado é garantir a autenticidade e a integridade das mensagens trocadas entre estações STIC. Tal deverá permitir avaliar a fiabilidade dessas informações. Ao mesmo tempo, o impacto na privacidade dos utentes da estrada deve ser reduzido ao mínimo. Assim, a plataforma STIC desenvolveu uma arquitetura de segurança apoiada por uma infraestrutura de chave pública (Public Key Infrastructure, «PKI»), que utiliza certificados com pseudónimo alterados com frequência. A política comum de segurança e certificação daí resultante foi objeto de ampla consulta e foi acordada por todas as partes interessadas envolvidas.

2.3.Direitos fundamentais

O direito à proteção dos dados pessoais é garantido ao abrigo do artigo 8.º da Carta dos Direitos Fundamentais da União Europeia. Sempre que as medidas previstas no presente regulamento implicarem o processamento de dados pessoais, tal deve ser efetuado em conformidade com a legislação da UE sobre a proteção dos dados pessoais, em especial, com o Regulamento Geral sobre a Proteção de Dados («RGPD») 5 e a Diretiva Privacidade Eletrónica 6 .

Em 10 de julho de 2017, no âmbito dos seus trabalhos preparatórios, os serviços da Comissão consultaram o subgrupo «Tecnologia» do Grupo de Trabalho do Artigo 29.º, instituído nos termos da Diretiva Proteção de Dados 7 . O parecer do subgrupo (outubro de 2017) chamou a atenção para uma série de ações necessárias para apoiar o tratamento lícito de dados pessoais no domínio dos STIC. Foi ainda esclarecido que, uma vez que o presente regulamento abrange apenas o intercâmbio de mensagens entre estações STIC, não é, por si só, suscetível de criar uma base jurídica para o tratamento lícito de dados. Em consequência, as obrigações impostas aos responsáveis pelo tratamento de dados e aos subcontratantes continuam a ser plenamente aplicáveis. No entanto, o presente regulamento esclarece que, sem uma base jurídica adequada e específica, os dados pessoais recolhidos não devem ser (re)utilizados nem para fins comerciais, nem como novos recursos para efeitos de aplicação da lei. Acresce que as informações relativas a uma pessoa singular identificada ou identificável devem ser tratadas no pleno respeito do princípio da minimização de dados e unicamente para os efeitos citados no presente regulamento, e armazenadas apenas durante o tempo que for necessário. Por último, os utilizadores finais devem ser informados de forma clara e exaustiva sobre a recolha de dados e as disposições relativas aos períodos durante os quais são conservados.

3.Resultados das avaliações ex post e das avaliações de impacto

   Avaliações ex post/balanços de qualidade da legislação existente

Uma vez que não existe legislação neste domínio, não foi necessário realizar uma avaliação ex post.

   Recolha e utilização de conhecimentos especializados

A Comissão utilizou os relatórios finais da fase I e da fase II da plataforma STIC. A Comissão recorreu também a peritos externos através de um contrato para um estudo de apoio à avaliação de impacto celebrado com a empresa RICARDO Energy & Environment, apoiada pela TRT e pela TEPR, que foi lançado em setembro de 2017 e concluído em dezembro de 2018.

   Avaliação de impacto

A iniciativa é apoiada por uma avaliação de impacto que obteve um parecer positivo com reservas após análise, em 10 de outubro de 2018, pelo Comité de Controlo da Regulamentação («CCR»). As reservas do CCR incidiram, essencialmente, em dois aspetos:

·o CCR considerou que o relatório não tinha esclarecido suficientemente a necessidade de uma abordagem faseada para atingir os objetivos da iniciativa. Consequentemente, não foi possível inferir claramente a escolha da opção preferida, a partir da análise e da apresentação do relatório,

·o CCR considerou igualmente que o relatório não explicou por que motivo (ainda) não tinha dado resposta às preocupações das partes interessadas relativamente à segurança dos utilizadores vulneráveis das vias rodoviárias e aos impactos ambientais.

Em resposta a estas reservas, foram acrescentadas na avaliação de impacto final as seguintes precisões:

·a distinção entre as diferentes opções políticas e as considerações subjacentes foram analisadas e clarificadas ao longo de toda a avaliação de impacto, em especial nos pontos 5.3, 7 e 8. É explicitamente debatida a necessidade de uma avaliação de impacto separada para eventuais medidas legislativas de acompanhamento, incluindo um mandato V2V,

·o impacto dos STIC nos utilizadores vulneráveis das vias rodoviárias («UVV») foi clarificado em maior profundidade nas secções 6.1 e 6.5. Foi sublinhado que os serviços STIC específicos dos UVV ainda não estavam suficientemente consolidados para serem incluídos nas especificações e, por conseguinte, nas opções políticas consideradas na referida avaliação de impacto. As preocupações das partes interessadas foram descritas mais pormenorizadamente no anexo 2,

·relativamente aos impactos, a análise de sensibilidade descrita na secção 6.5 foi alargada a todas as opções políticas, tendo sido feitos ajustamentos em todo o relatório, a fim de melhor diferenciar as opções políticas. A secção 2 do anexo 4 foi atualizada, de modo a refletir o facto de os serviços «Day 1» incidirem fortemente na segurança e a clarificar as limitações da análise,

·a secção 6.4 foi acrescentada para debater os impactos das diferentes opções políticas em termos de proteção de dados. O anexo 6 também foi atualizado a este respeito.

A avaliação de impacto examinou três grandes opções estratégicas:

OP1:    Intervenção ligeira baseada em medidas não legislativas, incluindo orientações não vinculativas sobre a interoperabilidade dos serviços «Day 1», a comunicação segura, a proteção de dados e a avaliação da conformidade.

OP2:    Intervenção moderada baseada em especificações nos termos da Diretiva STI. Tal incluiria elementos semelhantes aos da OP1, mas estes seriam juridicamente vinculativos mediante um regulamento delegado. No entanto, os EstadosMembros e a indústria continuariam a ter a liberdade de decidir sobre a implantação de STIC.

OP3: Intervenção forte com base num mandato veículoveículo («V2V») e na criação de organismos de governação. Esta opção baseiase nas especificações juridicamente vinculativas de uma abordagem faseada, garantindo que todos os veículos novos estão equipados com estações STIC e aumentando drasticamente a taxa de utilização, dessa forma atingindo muito mais rapidamente o limiar de eficácia da prestação de serviços (relacionado com o efeito de rede). A OP3 inclui medidas adicionais que apoiam a implantação de STIC e não podem ser introduzidas apenas através de um ato delegado:

·uma medida legislativa pode fornecer uma base jurídica para o tratamento lícito dos dados pessoais relacionados com os STIC. Tal aumentaria a segurança jurídica e teria provavelmente como resultado a prestação de mais serviços STIC, e

·a atribuição de funções de governação a organismos jurídicos asseguraria igualmente a coordenação e a supervisão da implantação de STIC, garantindo assim a redução ao mínimo dos entraves à sua utilização.

A opção preferida é a OP3 uma abordagem faseada, tal como previsto na Diretiva STI, em que, após a adoção de especificações, se considerará uma iniciativa separada para a implantação, que analise em maior profundidade a eficiência e a proporcionalidade de um mandato baseado no desenvolvimento contínuo do setor dos STIC. Esta opção política é considerada a mais coerente e eficaz, permitindo as maiores reduções em termos de número de acidentes, congestionamento e emissões de CO2.

Os impactos esperados são os seguintes:

·os principais benefícios são a redução do número de acidentes e dos custos de combustíveis, e as economias de tempo de viagem. Verificase ainda uma ligeira redução dos custos externos das emissões de CO2 e de poluentes atmosféricos. Os benefícios monetários totais ascendem a 78,9 mil milhões de EUR para o período de 20202035. Este valor aumentaria para 128,9 mil milhões de EUR com a introdução de um mandato V2V,

·os principais custos dizem respeito ao equipamento STIC nos veículos e nas infraestruturas rodoviárias. Avaliaramse outros custos da conformidade e administrativos, mas foram considerados menores em comparação com os custos globais. Os custos monetários totais ascendem a 19,1 mil milhões de EUR para o período de 20202035 ou 32,3 mil milhões de EUR, com a introdução de um mandato V2V. Por conseguinte, os benefícios esperados compensam largamente os custos previstos,

·embora 90 % dos custos estejam relacionados com o equipamento das frotas, os custos de equipamento das infraestruturas ficarão, em grande medida, a cargo do setor público. No entanto, os EstadosMembros continuam a ser livres de decidir se devem ou não proceder à implantação.

4.RESULTADOS DAS CONSULTAS

4.1.Reuniões com peritos nomeados pelos EstadosMembros

O desenvolvimento de regras e requisitos a nível da UE para apoiar a implantação de sistemas e serviços STIC, em especial a interoperabilidade e a continuidade dos serviços V2V e V2I em toda a UE, exigiu uma estreita cooperação entre as partes interessadas (fabricantes, prestadores de serviços e autoridades competentes). Os EstadosMembros da UE e os países da EFTA foram convidados a nomear peritos para participarem numa série de 13 reuniões com os serviços da Comissão em Bruxelas, entre 23 de maio de 2017 e 3 de outubro de 2018, e ajudarem na elaboração do projeto de regulamento. Os peritos do Parlamento Europeu foram igualmente convidados a participar e a Comissão organizou uma série de reuniões bilaterais com os EstadosMembros.

4.2.Consulta das partes interessadas

Foi aberta uma consulta pública no sítio Web da Comissão, que decorreu entre 10 de outubro de 2017 e 12 de janeiro de 2018 (13 semanas), que recebeu 139 respostas. A consulta pública baseouse num questionário que analisava as opiniões das partes interessadas sobre os principais elementos da avaliação de impacto: o problema principal, os seus fatores determinantes, as eventuais medidas políticas e seus impactos prováveis, bem como a pertinência da ação a nível da UE.

Foram realizados diversos estudos de caso no âmbito de um estudo de apoio:

·nove sobre projetos de implantação de STIC na UE, e

·três sobre a implantação de STIC noutros países (Estados Unidos, Austrália e Japão), que incluíram entrevistas com representantes de alto nível, entre outubro de 2017 e fevereiro de 2018.

Todos os estudos de caso incidiram nos seguintes aspetos da implantação de STIC: objetivos, progressos, obstáculos, recolha de dados e custos na zona em causa. Nos estudos de caso da UE, os inquiridos foram igualmente convidados a dar a sua opinião sobre a definição do problema, as medidas e as opções políticas, bem como sobre a monitorização e a avaliação desta iniciativa política.

Em 9 de fevereiro de 2018, realizouse um seminário com as partes interessadas para recolher informações/dados específicos e os pontos de vista e as sugestões dos peritos e das partes interessadas. O seminário contou com inúmeras presenças, totalizando mais de 140 participantes.

Em 6 de setembro de 2018 e 29 de janeiro de 2019, a Comissão apresentou o objetivo e o âmbito de aplicação do regulamento aos membros da Comissão dos Transportes e do Turismo.

O projeto de regulamento foi objeto de uma consulta pública através do portal «Legislar Melhor», de 11 de janeiro de 2019 a 8 de fevereiro de 2019, tendo sido recebidas 100 respostas.

4.3.Tecnologias da comunicação STIC

Uma questão particularmente importante para os STIC diz respeito às tecnologias da comunicação que podem ser utilizadas no intercâmbio de mensagens entre estações STIC. Tal está diretamente relacionado com a necessidade de garantir que todos podem falar com todos (interoperabilidade) e que todos continuam a poder falar com todos (compatibilidade).

A maximização dos benefícios implica a mobilização das diferentes vantagens de várias tecnologias complementares. A abordagem da «comunicação híbrida» combina dois tipos de tecnologias:

·tecnologias das comunicações de curto alcance, que funcionam numa faixa de frequência dedicada de 5,9 GHz e são as mais pertinentes para os serviços urgentes. O STIG5 foi desenvolvido especificamente para este fim, estando agora consolidado, ensaiado e já implantado, e

·tecnologias das comunicações de maior alcance, que tiram partido da cobertura das redes existentes e interligam grandes áreas, embora se apliquem a serviços V2I, menos urgentes. As tecnologias celulares 3G/4G são tecnologias consolidadas, que já oferecem uma boa cobertura em grandes partes da UE.

A implementação prática da abordagem da comunicação híbrida, combinada com a necessidade de assegurar a interoperabilidade e a continuidade dos serviços, impõe determinadas opções tecnológicas que se refletem num conjunto mínimo de requisitos funcionais e técnicos para o intercâmbio interoperável de mensagens entre estações STIC. Uma vez que tal não deve prejudicar o prosseguimento da inovação, o presente regulamento garante que as futuras tecnologias podem ser integradas na combinação «comunicação híbrida».

Uma cláusula de revisão facilitará a integração dos vários candidatos existentes, como a LTEV2X (uma tecnologia celular de comunicação de curto alcance) e a tecnologia 5G, o grupo de tecnologias para as redes celulares da próxima geração. A Comissão debaterá possíveis alterações ao presente regulamento delegado com um grupo de peritos de forma aberta e transparente, e informáloá regularmente sobre os progressos e as eventuais medidas a adotar. As partes interessadas que já colocaram em serviço as estações STIC devem cooperar de boafé, em consonância com a legislação da União e as legislações nacionais em matéria de concorrência, a fim de assegurar condições de concorrência equitativas entre as diferentes tecnologias, sem prejudicar o desenvolvimento de novas tecnologias. A fim de permitir desenvolvimentos futuros neste domínio, as partes interessadas mencionadas deverão também preparar os seus produtos para a integração de tecnologias futuras.

5.INCIDÊNCIA ORÇAMENTAL

O presente regulamento tem algumas incidências no orçamento da UE.

Para assegurar o bom funcionamento da rede STIC, é necessário que determinadas tarefas sejam executadas por entidades centrais, antes de se poder estabelecer o quadro de governação completo. Enquanto se aguarda a criação dessas entidades, a Comissão executará algumas das tarefas — principalmente as relacionadas com o sistema de gestão de credenciais de segurança dos STIC da UE, o quadro STIC da UE para o fornecimento de comunicações seguras e de confiança com base numa PKI.

É importante assegurar que as estações STIC podem ser incluídas no sistema de gestão das credenciais de segurança, antes de serem colocadas em serviço e se tornarem operacionais. Para o efeito, a Comissão assumirá as tarefas de ponto de contacto central, gestor da lista de confiança e autoridade responsável pela política de certificação dos STIC, enquanto tarefa partilhada entre o Centro Comum de Investigação («CCI») e a DG MOVE.

Tal não terá qualquer impacto em termos de recursos humanos, uma vez que o CCI e a DG MOVE irão utilizar ou reafetar o pessoal em função das necessidades. O CCI beneficia também da medida de apoio «Arquitetura de Segurança para Infraestruturas Conectadas e Veículos na Europa» no contexto da Decisão de Execução C(2016)1966 da Comissão 8 , que atribui 4 milhões de EUR à execução da fase I do sistema de gestão de credenciais de segurança (20182021). Se forem necessárias medidas adicionais de apoio, estas poderão ser financiadas no âmbito do Mecanismo Interligar a Europa.

REGULAMENTO DELEGADO (UE) …/... DA COMISSÃO

de 13.3.2019

que complementa a Diretiva 2010/40/UE do Parlamento Europeu e do Conselho no que diz respeito à implantação e à utilização operacional de sistemas cooperativos de transporte inteligentes

(Texto relevante para efeitos do EEE)

A COMISSÃO EUROPEIA,

Tendo em conta o Tratado sobre o Funcionamento da União Europeia,

Tendo em conta a Diretiva 2010/40/UE do Parlamento Europeu e do Conselho, de 7 de julho de 2010, que estabelece um quadro para a implantação de sistemas de transporte inteligentes no transporte rodoviário, inclusive nas interfaces com outros modos de transporte 9 , nomeadamente o artigo 6.º, n.º 3, em conjugação com o artigo 7.º,

Considerando o seguinte:

(1)O artigo 2.º, n.º 1, da Diretiva 2010/40/UE identifica a ligação entre os veículos e as infraestruturas de transporte como domínio prioritário IV, para a elaboração e utilização de especificações e normas. Tal envolve, entre outros, o desenvolvimento e a implementação de sistemas cooperativos (veículoveículo, veículoinfraestrutura, em que as mensagens podem ter origem tanto no veículo como nas infraestruturas, e infraestruturainfraestrutura) com base na: facilitação do intercâmbio de dados ou informações entre veículos, entre infraestruturas, e entre veículos e infraestruturas, utilização de um formato de mensagem normalizado para esse intercâmbio de dados ou informações entre veículos e infraestruturas, e na definição de uma infraestrutura de comunicação para o intercâmbio de dados ou informações entre veículos, entre infraestruturas, e entre veículos e infraestrutura.

(2)Os sistemas cooperativos de transporte inteligentes («STIC») utilizam tecnologias que permitem aos veículos rodoviários comunicar entre si e com as infraestruturas rodoviárias, incluindo a sinalização rodoviária. Os serviços STIC são uma categoria de serviços STI baseada numa rede aberta, que permite a existência de uma relação «todos para todos» ou interpares entre estações STIC. Tal significa que todas as estações STIC, tal como definidas no presente regulamento, podem trocar mensagens de forma segura entre si, não estando limitadas ao intercâmbio de mensagens com uma ou mais estações predefinidas. As estações STIC não necessitam de requisitos adicionais, tais como: utilizar o mesmo software ou ter uma conta ou relação contratual com a mesma entidade (por exemplo, o fabricante do veículo, a autoridade rodoviária ou o prestador de serviços).

(3)A estratégia europeia relativa aos STI 10 identificou um risco de fragmentação do mercado interno no domínio dos STIC, bem como a necessidade de definir requisitos mínimos para os serviços STIC, a fim de assegurar a sua implantação coordenada e coerente. Neste contexto, a Comissão anunciou a sua intenção de, quando adequado, fazer uso do seu mandato ao abrigo da Diretiva 2010/40/UE para adotar o(s) ato(s) delegado(s) até 2018, a fim de assegurar a compatibilidade, a interoperabilidade e a continuidade dos serviços STIC aquando da implantação e utilização operacional dos serviços STIC à escala da União, com base numa comunicação de confiança e segura.

(4)A fim de promover e maximizar todos os benefícios em termos de segurança rodoviária e eficiência do tráfego dos serviços STIC, as especificações estabelecidas no presente regulamento devem aplicarse a toda a rede de transporte rodoviário. Incluemse as suas interfaces com outros modos de transporte pertinentes para a segurança rodoviária ou a eficiência do tráfego, como as passagens de nível, as zonas portuárias, etc.

(5)As especificações estabelecidas no presente regulamento devem aplicarse a todos os serviços STIC, sem prejuízo das especificações específicas adotadas noutros atos ao abrigo da Diretiva 2010/40/UE, em especial os Regulamentos Delegados (UE) n.º 886/2013 11 e (UE) 2015/962 12 da Comissão.

(6)A Diretiva (UE) 2016/1148 do Parlamento Europeu e do Conselho, de 6 de julho de 2016 13 , relativa a medidas destinadas a garantir um elevado nível comum de segurança das redes e da informação em toda a União («Diretiva SRI») estabelece requisitos relativos às capacidades nacionais no domínio da cibersegurança, estabelece mecanismos para reforçar a cooperação estratégica e operacional entre os EstadosMembros e introduz obrigações relativas às medidas de segurança e às notificações de incidentes em todos os setores. Uma vez que a Diretiva SRI inscreveu numa lista os operadores de sistemas de transporte inteligentes na aceção do artigo 4.º, ponto 1, da Diretiva 2010/40/UE enquanto potenciais operadores de serviços essenciais, a aplicação da Diretiva SRI e os requisitos impostos por força do presente regulamento podem, em certos casos, ser complementares.

(7)A Decisão 2008/671/CE da Comissão 14 harmoniza as condições aplicáveis à disponibilidade e à utilização eficiente da faixa de frequências de 5 8755 905 MHz para as aplicações relacionadas com a segurança dos STI na União.

(8)Em resposta ao mandato de normalização M/453 15 , os Organismos Europeus de Normalização («OEN») — o Instituto Europeu de Normalização das Telecomunicações («ETSI») e o Comité Europeu de Normalização («CEN») — elaboraram normas comuns para a implantação de serviços STIC, a que o presente regulamento faz referência. Essas normas constituem a base para a prestação efetiva de serviços STIC prioritários, permitindo que os gestores de tráfego rodoviário tomem as medidas adequadas e preparem o terreno para uma maior segurança na automatização da rede rodoviária da UE. O trabalho de normalização prosseguirá, nomeadamente para integrar outras tecnologias e reforçar mais ainda os STIC. Os organismos de normalização pertinentes e todas as partes interessadas deverão, por conseguinte, prosseguir os trabalhos desenvolvidos no âmbito do mandato de normalização M/453 e desenvolver em conjunto soluções que apoiem a interoperabilidade e permitam que todas as tecnologias desempenhem o seu papel.

(9)Para garantir a interoperabilidade, cada estação STIC exige uma configuração específica de normas («perfil do sistema»), que determina a aplicação de várias normas facultativas. O perfil do sistema descreve as interfaces externas necessárias para a comunicação entre estações STIC. Cada estação STIC deve cumprir o disposto na Diretiva 2014/53/UE do Parlamento Europeu e do Conselho 16 . A cooperação entre a indústria e as autoridades dos EstadosMembros permitiu o desenvolvimento de perfis de sistema harmonizados para as estações STIC de bordo e para as estações STIC rodoviárias que comunicam na banda de frequências de 5 8555 925 MHz. Para que todos os serviços STIC possam ser recebidos uniformemente em toda a União, é necessária uma abordagem de «comunicação híbrida», isto é, que combine tecnologias das comunicações complementares. Tendo em conta o ritmo do progresso tecnológico, tanto a indústria como os EstadosMembros são incentivados a desenvolver — e a harmonizar em toda a União — perfis de sistema adicionais, complementares e compatíveis, para outros tipos de estações e tecnologias STIC. Antes de utilizarem esses novos perfis ou tecnologias, devem informar a Comissão para que possa ser considerada, sem demora, uma atualização do presente regulamento. Estas atualizações devem ser preparadas em estreita cooperação com os EstadosMembros.

(10)A natureza cooperativa dos STIC exige que cada estação STIC contribua com informações para a rede STIC. As estações STIC não devem interferir nem na prestação dos serviços STIC prioritários, dos serviços eletrónicos de portagem europeus e no funcionamento do tacógrafo inteligente, e nem no funcionamento de outras estações STIC.

(11)É importante que a indústria e os EstadosMembros apliquem soluções técnicas comuns para a prestação de serviços STIC. Estas devem ser desenvolvidas, em especial, através dos OEN, a fim de facilitar a introdução de serviços STIC, assegurar a interoperabilidade e a continuidade dos serviços em toda a União, e reduzir os custos de implementação. A fim de assegurar a compatibilidade, a interoperabilidade e a continuidade dos serviços STIC à escala da União, as normas e os perfis de sistema a que se refere o presente regulamento deverão ser utilizados, se for caso disso, como referência para o desenvolvimento de futuros serviços e tecnologias STIC.

(12)No que diz respeito à implantação, deve ser dada prioridade aos serviços STIC que contribuem para a segurança rodoviária e a eficiência do tráfego. Os serviços que constituem serviços de informações mínimas universais sobre tráfego relacionadas com a segurança rodoviária na aceção do Regulamento Delegado (UE) n.º 886/2013, devem, sempre que possível, ser fornecidos como um serviço universal gratuito aos utilizadores finais no ponto de utilização, em conformidade com o referido regulamento.

(13)Para garantir a interoperabilidade, cada serviço STIC exige uma configuração específica de normas, designada por perfil de serviço, que define a aplicação de várias normas facultativas. Os serviços STIC não devem interferir com a prestação de serviços STIC prioritários. Os atuais perfis de serviço veículoveículo foram desenvolvidos principalmente para os automóveis de passageiros. A fim de permitir a implantação destes serviços ou de serviços similares para outras categorias de veículos, poderá ser necessário desenvolver perfis de serviço adicionais ou atualizar os perfis de serviço no presente regulamento.

(14)A Decisão n.º 768/2008/CE do Parlamento Europeu e do Conselho 17 estabelece princípios comuns e disposições de referência que se pretende de aplicação transversal em legislação setorial. Constitui, por conseguinte, um quadro horizontal geral para qualquer nova legislação que harmonize as condições para a comercialização de produtos. As suas disposições de referência preveem definições e deveres gerais dos operadores económicos e uma série de procedimentos de avaliação da conformidade de entre os quais o legislador pode escolher em função das necessidades; No intuito de garantir a segurança do mercado, também estabelece regras de marcação CE e disposições de referência para procedimentos relacionados com produtos que apresentem um risco. Uma vez que o presente regulamento abrange a colocação no mercado de estações STIC, é adequado utilizar as disposições de referência constantes do anexo I dessa decisão que tornam o fabricante responsável por assegurar, nomeadamente, a conformidade com toda a legislação aplicável; pela elaboração de uma declaração UE de conformidade; pela aposição da marcação de conformidade e pela preparação da documentação técnica adequada. As funções e responsabilidades de outras entidades, tais como o mandatário, o importador e o distribuidor, devem também ser regulamentadas.

(15)No presente regulamento, as estações STIC instaladas em veículos, portáteis ou situadas na infraestrutura rodoviária são consideradas como produtos que podem ser colocados no mercado como módulos autónomos ou como partes de módulos de maior dimensão. Pode ensaiarse até que ponto as estações STIC a instalar em veículos cumprem os requisitos aplicáveis, antes ou depois da instalação. No caso das estações STIC rodoviárias, estas podem ser ensaiadas antes da instalação, de modo a poderem ser colocadas no mercado como produtos autónomos. Quanto às estações STIC centrais, a situação pode ser diferente, uma vez que estarão frequentemente integradas em centros de controlo do tráfego que não estão normalizados. Uma vez que estes centros de controlo do tráfego são construídos gradualmente, de acordo com a evolução das zonas de trânsito que gerem, poderá ser impossível ensaiálas integralmente, antes de serem colocadas no mercado. Em qualquer caso, o nível de segurança e confiança deve ser o mesmo para todas as estações STIC, incluindo as centrais.

(16)Antes que qualquer estação STIC entre em serviço e se torne operacional, é necessário identificar a entidade que verificará que esta é acompanhada de uma declaração UE de conformidade e, quando aplicável, que a marcação de conformidade foi aposta. A referida entidade deverá registar a estação no sistema de gestão de credenciais de segurança dos STIC da UE e assegurar que esta continua a cumprir os requisitos técnicos durante todo o período da sua utilização. A entidade será o operador da estação STIC e será responsável pelas relações com o utilizador.

(17)Para muitos serviços STIC, é essencial garantir a autenticidade e a integridade das mensagens STIC que contêm informações, como a posição, a velocidade e o rumo. Por conseguinte, deve ser estabelecido um modelo de confiança STIC comum europeu para todas as estações STIC (para todas as estações STIC móveis, os mesmos requisitos para as de bordo e pessoais, e para todas as estações STIC fixas, os mesmos requisitos para as centrais e rodoviárias), independentemente das tecnologias das comunicações utilizadas. As regras e os requisitos deste modelo de confiança constam do certificado e da política de segurança. O nível mais elevado da infraestrutura de chave pública («PKI») é a lista de confiança de certificados europeus, que contém as entradas de todas as autoridades responsáveis pela certificação de raiz de confiança na Europa.

(18)No passado, foram feitos alguns esforços no sentido de um reconhecimento mútuo dos certificados de segurança dos produtos na Europa. O exemplo mais importante a este respeito é o Acordo de Reconhecimento mútuo («ARM») do Grupo de Altos Funcionários para a Segurança dos Sistemas de Informação («SOGIS»). Embora constitua o modelo mais importante de cooperação e reconhecimento mútuo no domínio da certificação da segurança, o SOGIS apenas inclui uma parte dos EstadosMembros da União. Dado que a certificação da segurança das estações STIC é um elemento importante da política de certificação e segurança dos STIC, o ARM do SOGIS é aplicado na ausência de outros sistemas europeus de certificação da cibersegurança equivalentes, ao abrigo do quadro europeu aplicável em matéria de cibersegurança.

(19)Certas estações STIC colocadas no mercado antes da data de aplicação do presente regulamento podem não cumprir integralmente os requisitos do presente regulamento em matéria de segurança dos STIC, uma vez que as decisões de implantação técnica podem já ter sido tomadas num momento anterior. A fim de permitir que essas estações STIC integrem a rede STIC após a data de aplicação do presente regulamento, deve ser previsto um procedimento que considere a possibilidade de inscrever essas estações STIC no modelo de confiança STIC.

(20)Nos termos do artigo 6.º, n.º 6, da Diretiva 2010/40/UE, a Comissão deve adotar especificações que respeitem um conjunto de princípios, incluindo a utilização de infraestruturas de satélite ou de qualquer tecnologia que ofereça níveis de precisão equivalentes, para efeitos das aplicações e dos serviços STI que exijam serviços de cronometria e de posicionamento globais, contínuos, precisos e garantidos. Por conseguinte, é conveniente assegurar a compatibilidade das estações STIC com os serviços de valor acrescentado prestados pelos programas Galileo e Serviço Europeu Complementar de Navegação Geoestacionária («EGNOS»), tal como estabelecido no Regulamento (UE) n.º 1285/2013 do Parlamento Europeu e do Conselho, a fim de melhorar a fiabilidade das estações STIC.

(21)A plataforma para a implantação de STIC na União («plataforma STIC»), criada em novembro de 2014 e presidida por departamentos da Comissão, desenvolveu uma política comum em matéria de segurança e certificação, aprovada por todas as partes interessadas. Uma vez que a política comum de segurança e certificação deve ser atualizada em função do progresso técnico e do desenvolvimento do quadro de governação, a Comissão deve rever o presente regulamento de forma contínua, a fim de manter a coerência e a consistência.

(22)Para assegurar o bom funcionamento da rede STIC, é necessário que certas tarefas sejam executadas por entidades centrais, antes de se poder estabelecer integralmente o quadro de governação. Enquanto se aguarda a criação de entidades centrais, a Comissão deve ser responsável por essas tarefas, incluindo as relacionadas com a autoridade responsável pela política de certificação dos STIC, o gestor da lista de confiança e o ponto de contacto dos STIC.

(23)Sempre que as medidas previstas no presente regulamento impliquem o tratamento de dados pessoais, este deve ser efetuado em conformidade com o direito da União em matéria de proteção dos dados pessoais, em especial o Regulamento (UE) 2016/679 18 e, quando aplicável, a Diretiva 2002/58/CE 19 . Esse tratamento deve ter um fundamento jurídico adequado, que conste da lista do artigo 6.º do Regulamento (UE) 2016/679, que não esteja previsto no presente regulamento delegado.

(24)Sem um fundamento jurídico adequado, os dados pessoais recolhidos não devem ser reutilizados para quaisquer outros fins, tais como fins comerciais ou como novos recursos para fins de aplicação da lei, exceto com base numa lei.

(25)As informações relativas a uma pessoa singular identificada ou identificável devem ser tratadas no pleno respeito do princípio da minimização de dados e unicamente para os efeitos especificados no presente regulamento, e armazenadas apenas durante o tempo que for necessário. Os requisitos de segurança relativos à pseudonimização previstos no presente regulamento contribuem para reduzir o risco de utilização abusiva dos dados.

(26)Os utilizadores finais devem ser informados de forma clara e exaustiva de todas as informações pertinentes sobre o tratamento dos seus dados pessoais, em conformidade com o Regulamento (UE) 2016/679.

(27)Tal como referido na política comum de segurança e certificação, desenvolvida no contexto da plataforma STIC, no âmbito da governação são exigidos organismos sob a forma de comités diretores comuns das partes interessadas, incluindo Comissão, EstadosMembros, operadores de infraestruturas rodoviárias, e fabricantes e operadores de estações STIC. Enquanto se aguarda a criação de tais organismos, a Comissão, assistida por um grupo de peritos em que estão representadas todas as partes interessadas pertinentes, deverá ser responsável pelas tarefas pertinentes, incluindo as relacionadas com a governação, a supervisão e a autoridade responsável pela política de certificação dos STIC. Este grupo de peritos deve incluir, em especial, representantes dos fabricantes de estações STIC e operadores da rede STIC, bem como outras partes interessadas e autoridades competentes dos EstadosMembros envolvidas.

(28)O processo de consulta amplo e inclusivo que conduziu ao desenvolvimento da política de segurança e do quadro de governação, e da política de certificação (com o apoio de todas as partes interessadas públicas e privadas pertinentes) deve igualmente aplicarse à atualização do presente regulamento em função do progresso técnico e, se for caso disso, do desenvolvimento do quadro de governação.

(29)Os EstadosMembros e as autoridades de certificação de raiz devem fornecer regularmente à Comissão informações que lhe permitam acompanhar a aplicação do presente regulamento.

(30)A fim de ter em conta o rápido desenvolvimento de novos mercados, tecnologias e serviços, tal como já anunciado no programa de trabalho atualizado da Diretiva STI, esperase que o presente regulamento seja alterado antes da revisão da aplicação do presente regulamento, que deverá ser efetuada três anos após a sua entrada em vigor.

O principal candidato, entre as eventuais alterações, é inclusão de redes 3G/4G existentes para prestação de serviços prioritários STIC. Além disso, foram finalizadas as especificações para as tecnologias TLEV2X no projeto de parceria para a terceira geração («3GPP»), estando atualmente a ser validadas as implementações do protótipo. Estas tecnologias estão atualmente a ser integradas nas normas e especificações técnicas europeias, tanto para os serviços prioritários STIC como para os novos serviços emergentes. Por último, as novas tecnologias em rápida evolução, como a tecnologia 5G, poderão também servir de base aos serviços STIC.

Alguns destes desenvolvimentos podem desencadear uma ou mais alterações ao presente regulamento, uma vez que seja transmitido à Comissão um dossiê com especificações consolidadas do ponto de vista técnico. Tais alterações devem assegurar uma abordagem aberta e orientada para o futuro das normas e na legislação. A Comissão deverá consultar um grupo de peritos sobre possíveis alterações ao presente regulamento de forma aberta e transparente e informálo regularmente sobre os progressos e as eventuais medidas a tomar. A fim de manter a continuidade dos serviços prioritários STIC, deverá também assegurarse a compatibilidade e a interoperabilidade com as estações STIC existentes, já colocadas em serviço em conformidade com o presente regulamento, ou especificar uma trajetória de migração adequada, tendo igualmente em conta a evolução do mercado e das tecnologias.

A Comissão deve analisar o dossiê e debatêlo no âmbito do grupo de peritos sem demora injustificada, tendo em vista uma possível alteração ao presente regulamento, analisando se é necessária uma alteração dos requisitos existentes. As partes interessadas que já colocaram em serviço estações STIC devem cooperar de boafé, em consonância com a legislação da União e as legislações nacionais em matéria de concorrência, a fim de assegurar condições de concorrência equitativas entre as diferentes tecnologias, sem prejudicar o desenvolvimento de novas tecnologias. A fim de permitir desenvolvimentos futuros neste domínio, as partes interessadas mencionadas deverão também preparar os seus produtos para a integração de tecnologias futuras.

(31)A Autoridade Europeia para a Proteção de Dados foi consultada em conformidade com o disposto no artigo 28.º, n.º 2, do Regulamento (CE) n.º 45/2001 do Parlamento Europeu e do Conselho 20 e emitiu parecer em …,

ADOTOU O PRESENTE REGULAMENTO:

Capítulo I

Disposições gerais

Artigo 1.º

Objeto e âmbito de aplicação

1.O presente regulamento estabelece as especificações necessárias para garantir a compatibilidade, a interoperabilidade e a continuidade da implantação e utilização operacional dos serviços STIC à escala da União, com base numa comunicação de confiança e segura.

Estabelece o modo como a comunicação veículoveículo, veículoinfraestrutura e infraestruturainfraestrutura deve ser realizada através de estações STIC e como as estações STIC devem ser colocadas no mercado e em serviço, a fim de permitir a prestação de serviços STIC aos utilizadores dos STI.

2.O presente regulamento é aplicável a todas as estações STIC no domínio do transporte rodoviário e às suas interfaces com outros modos de transporte.

3.A implantação de estações STIC é realizada em conformidade com o artigo 5.º da Diretiva 2010/40/UE. Os EstadosMembros devem designar a parte da sua infraestrutura de rede de transporte equipada com estações STIC.

Artigo 2.º

Definições

Para os efeitos do presente regulamento, aplicamse as seguintes definições:

(1)«Sistemas cooperativos de transporte inteligentes» ou «STIC», sistemas de transporte inteligentes que permitem a cooperação entre utilizadores de STI através do intercâmbio de mensagens seguras e de confiança, utilizando o sistema de gestão de credenciais de segurança dos STIC da UE;

(2)«Serviço STIC», um serviço STI prestado através de STIC;

(3)«Estação STIC», o conjunto de componentes de hardware e software necessários para recolher, armazenar, processar, receber e transmitir mensagens seguras e de confiança, a fim de permitir a prestação de um serviço STIC. Incluemse as estações de STI pessoais, centrais, de bordo e rodoviárias, conforme definido na norma EN 302 665 v 1.1.1;

(4)«Estação STIC móvel», uma estação STIC instalada num veículo ou sob a forma de um dispositivo pessoal portátil;

(5)«Estação STIC fixa», uma estação STIC instalada num sistema central ou numa infraestrutura rodoviária;

(6)«Estação STIC central», um servidor central com capacidades de estação STIC integradas como, por exemplo, num centro de gestão de tráfego;

(7)«Disponibilização no mercado», o fornecimento de uma estação STIC para distribuição ou utilização no mercado da União, no âmbito de atividades comerciais, a título oneroso ou gratuito;

(8)«Colocação no mercado», a primeira disponibilização de uma estação STIC no mercado da União;

(9)«Colocação em serviço» de uma estação STIC, a sua primeira utilização na União para os fins a que se destina;

(10)«Comunicação de pequeno alcance», a comunicação na faixa de frequências de 5 855 MHz 5 925 MHz;

(11)«Serviço STIC prioritário», um serviço STIC que contribui para a segurança rodoviária ou a eficiência do tráfego e que está incluído no anexo I;

(12)«Perfil do sistema», um conjunto mínimo de requisitos funcionais e técnicos para o intercâmbio interoperável de mensagens entre estações STIC;

(13)«Perfil de serviço», um conjunto de especificações funcionais para mensagens interoperáveis, que permite a prestação de um serviço STIC;

(14)«Sistema global de navegação por satélite» («GNSS»), uma infraestrutura constituída por uma constelação de satélites e uma rede de estações terrestres, que fornece informações exatas de geolocalização e tempo aos utilizadores que disponham de um recetor adequado;

(15)«Fabricante», uma pessoa singular ou coletiva que concebe ou fabrica uma estação STIC ou que mandou conceber ou fabricar uma estação STIC e comercializa essa estação STIC sob o seu nome ou marca comercial;

(16)«Operador de estação STIC», qualquer pessoa singular ou coletiva responsável pela colocação em serviço e pelo funcionamento de estações STIC em conformidade com o presente regulamento;

(17)«Mandatário», uma pessoa singular ou coletiva estabelecida na União mandatada por escrito por um fabricante para praticar determinados atos em nome deste;

(18)«Importador», uma pessoa singular ou coletiva estabelecida na União que coloca uma estação STIC proveniente de um país terceiro no mercado da União;

(19)«Distribuidor», uma pessoa singular ou coletiva presente na cadeia de abastecimento, com exceção do fabricante ou do importador, que disponibiliza uma estação STIC no mercado;

(20)«Operador económico», o fabricante, mandatário, importador ou distribuidor;

(21)«Recolha», qualquer medida destinada a obter o retorno de uma estação STIC que já tenha sido disponibilizada ao utilizador final;

(22)«Retirada», a medida destinada a impedir que uma estação STIC presente na cadeia de abastecimento seja disponibilizada no mercado;

(23)«Marcação CE», a marcação através da qual o fabricante indica que o produto está em conformidade com os requisitos aplicáveis previstos na legislação da União que prevê a sua aposição;

(24)«Utilizador final», uma pessoa singular ou coletiva que utiliza, por último, ou que se pretende utilize, por último, uma estação STIC;

(25)«Autoridade de fiscalização do mercado», a autoridade de um EstadoMembro responsável pela fiscalização do mercado no respetivo território;

(26)«Autoridade nacional competente», qualquer autoridade habilitada a verificar a conformidade de uma estação STIC com a legislação aplicável;

(27)«Sistema de gestão de credenciais de segurança dos STIC da UE», o quadro STIC da União Europeia para o fornecimento de comunicações de confiança e seguras, utilizando uma infraestrutura de chave pública (Public Key Infrastructure, «PKI»);

(28)«Autoridade responsável pela inscrição», a entidade jurídica e/ou operacional que autentica uma estação STIC e lhe concede o acesso ao STIC;

(29)«Rede STIC», todas as estações STIC operacionais da União.

Artigo 3.º

Disponibilização no mercado e/ou colocação em serviço

Uma estação STIC só pode ser disponibilizada no mercado e/ou colocada em serviço se, além de adequadamente mantida e utilizada de acordo com o fim a que se destina, cumprir o disposto no presente regulamento.

Artigo 4.º

Livre circulação

Os EstadosMembros não podem proibir, restringir ou dificultar, pelas razões abrangidas pelo presente regulamento, a disponibilização no mercado ou a colocação em serviço no seu território de estações STIC que cumpram o disposto no presente regulamento.

Capítulo II

Requisitos técnicos

Artigo 5.º

Requisitos aplicáveis às estações STIC

1.As estações STIC de bordo concebidas para comunicações de pequeno alcance devem cumprir os requisitos estabelecidos no perfil do sistema constante do anexo II, secção 2.

2.As estações STIC rodoviárias concebidas para comunicações de curto alcance devem cumprir os requisitos estabelecidos no perfil do sistema constante do anexo II, secção 3.

3.As estações STIC devem enviar mensagens que permitam a prestação de, pelo menos, um dos serviços STIC prioritários constantes da lista do anexo I.

4.As estações STIC devem ser compatíveis com as estações STIC que enviam mensagens para todos os serviços STIC prioritários constantes da lista do anexo I.

5.As estações STIC não devem interferir com o funcionamento do serviço eletrónico europeu de portagem, tal como referido na Diretiva 2004/52/CE do Parlamento Europeu e do Conselho 21 , na Decisão 2009/750/CE da Comissão 22 e no funcionamento do tacógrafo inteligente a que se refere o Regulamento (UE) n.º 165/2014 do Parlamento Europeu e do Conselho 23 .

6.As estações STIC devem ser compatíveis com as estações STIC conformes aos perfis de sistema estabelecidos no anexo II.

7.Quando as estações STIC operarem com GNSS, devem ser compatíveis com os serviços de localização e cronometria fornecidos pelos sistemas Galileo e EGNOS. Além disso, as estações STIC podem ser compatíveis com outros sistemas de navegação por satélite.

Artigo 6.º

Requisitos aplicáveis aos serviços STIC

1.Os serviços STIC prioritários constantes da lista do anexo I devem cumprir os requisitos do perfil de serviço STIC correspondente.

2.Cada serviço STIC deve funcionar sem qualquer alteração com todos os perfis de serviço, tal como estabelecido no anexo I.

Capítulo III

Colocação no mercado de estações STIC

Artigo 7.º

Obrigações dos fabricantes de estações STIC

1.Ao colocar estações STIC no mercado, os fabricantes devem garantir que estas foram concebidas e fabricadas em conformidade com os requisitos constantes do artigo 5.º.

2.Os fabricantes devem elaborar a documentação técnica referida no anexo V, parte A, e efetuar ou mandar efetuar o procedimento de avaliação da conformidade referido no anexo V, parte A.

3.Se, através do procedimento a que se refere o anexo V, parte A, tiver sido demonstrada a conformidade de uma estação STIC com os requisitos aplicáveis, os fabricantes devem elaborar uma declaração UE de conformidade e apor a marcação CE.

4.Os fabricantes devem conservar a documentação técnica referida no anexo V, parte A, e a declaração UE de conformidade durante 10 anos a contar da data de colocação da estação STIC no mercado.

5.Os fabricantes asseguram a existência de procedimentos para manter a conformidade das produções em série com o presente regulamento.

6.A fim de proteger a saúde e a segurança dos consumidores, sempre que adequado tendo em conta os riscos apresentados pelas estações STIC, os fabricantes devem:

a)Realizar ensaios por amostragem das estações STIC comercializadas;

b)Investigar e, se necessário, conservar um registo das reclamações, de estações STIC não conformes e das recolhas de estações STIC;

c)Informar os distribuidores de todas essas ações de monitorização.

7.Os fabricantes devem assegurar que as estações STIC que colocaram no mercado têm apostos o tipo, o número do lote ou da série, ou quaisquer outros elementos que permitam a sua identificação.

8.Na estação STIC ou, se tal não for possível, na embalagem ou num documento que acompanhe a estação STIC, os fabricantes devem indicar:

a)O nome;

b)A firma ou marca registada;

c)O endereço postal, indicando um único ponto de contacto no qual podem ser contactados.

Os dados de contacto são apresentados numa língua que possa ser facilmente compreendida tanto pelos utilizadores finais como pelas autoridades de fiscalização do mercado.

9.Os fabricantes devem assegurar que a estação STIC é acompanhada de instruções e informações de segurança numa língua que possa ser facilmente compreensível pelos utilizadores finais, de acordo com o que o EstadoMembro em causa determinar. Essas instruções e informações de segurança e a rotulagem devem ser claras, compreensíveis e inteligíveis.

10.Os fabricantes que considerem que uma estação STIC que colocaram no mercado não é conforme ao presente regulamento devem adotar imediatamente as medidas corretivas necessárias para assegurar a sua conformidade, para a retirar ou para a recolher, consoante o caso. Sempre que a estação STIC apresentar um risco, os fabricantes devem informar imediatamente as autoridades de fiscalização do mercado dos EstadosMembros em que a disponibilizaram, fornecendolhes informações pormenorizadas, em especial, no que se refere à não conformidade e a quaisquer medidas corretivas adotadas.

11.Mediante pedido fundamentado de uma autoridade nacional competente, os fabricantes devem facultar todas as informações e documentação necessárias, em papel ou em suporte eletrónico e numa língua que possa ser facilmente compreensível por essa autoridade, para demonstrar a conformidade da estação STIC. Os fabricantes devem cooperar com a referida autoridade, a pedido desta, em todas as ações adotadas com vista à eliminação dos riscos decorrentes de estações STIC que tenham colocado no mercado.

Artigo 8.º

Mandatários

1.Um fabricante pode designar um mandatário por mandato escrito.

2.Os mandatários praticam os atos definidos no mandato conferido pelo fabricante. O mandato deve permitir, no mínimo, ao mandatário:

a)Manter à disposição das autoridades nacionais de fiscalização do mercado a declaração UE de conformidade e a documentação técnica, durante 10 anos a contar da data de colocação da estação STIC no mercado;

b)Facultar, mediante pedido fundamentado de uma autoridade nacional competente, todas as informações e documentação necessárias para demonstrar a conformidade da estação STIC;

c)Cooperar com as autoridades nacionais competentes, a pedido destas, em qualquer ação de eliminação dos riscos decorrentes de estações STIC abrangidas pelo seu mandato.

As obrigações previstas no artigo 7.º, n.º 1, e a elaboração da documentação técnica referida no artigo 7.º, n.º 2, não fazem parte do mandato.

Artigo 9.º

Obrigações dos importadores

1.Os importadores colocam no mercado da União apenas estações STIC conformes.

2.Antes de colocar uma estação STIC no mercado da União, os importadores devem assegurar que:

a)O fabricante efetuou o procedimento de avaliação da conformidade referido no artigo 7.º, n.º 2;

b)O fabricante elaborou a documentação técnica;

c)A estação STIC tem aposta a marcação CE exigida;

d)O fabricante respeitou os requisitos previstos no artigo 7.º, n.º 7, e no artigo 8.º.

3.Sempre que um importador considere que uma estação STIC não é conforme aos requisitos referidos no artigo 5.º, não deve colocar o produto no mercado até que este seja posto em conformidade. Sempre que uma estação STIC apresente um risco, o importador deve informar desse facto o fabricante e as autoridades de fiscalização do mercado.

4.Na estação STIC ou, se tal não for possível, na embalagem ou num documento que acompanhe a estação STIC, os importadores devem indicar:

a)O seu nome;

b)A sua firma ou marca registada;

c)O endereço no qual podem ser contactados.

Os dados de contacto devem ser apresentados numa língua facilmente compreendida pelos utilizadores finais e pelas autoridades nacionais competentes.

5.Os importadores devem assegurar que a estação STIC é acompanhada de instruções e informações de segurança numa língua que possa ser facilmente compreensível pelos utilizadores finais, de acordo com o que o EstadoMembro em causa determinar.

6.Enquanto uma estação STIC estiver sob a responsabilidade do importador, este garante que as condições de armazenagem ou transporte não prejudicam a sua conformidade com os requisitos previstos no artigo 5.º.

7.A fim de proteger a saúde e a segurança dos consumidores, sempre que adequado tendo em conta os riscos apresentados pelas estações STIC, os importadores devem:

a)Realizar ensaios por amostragem da estação STIC comercializada;

b)Investigar e, se necessário, conservar um registo das reclamações, de estações STIC não conformes e das recolhas de estações STIC;

c)Informar os distribuidores dessas ações de monitorização.

8.Os importadores que considerem que uma estação STIC que colocaram no mercado não é conforme ao presente regulamento devem adotar imediatamente as medidas corretivas necessárias para assegurar a conformidade dessa estação STIC ou para a retirar ou para a recolher, consoante o caso. Sempre que a estação STIC apresentar um risco, os importadores devem informar imediatamente as autoridades nacionais competentes dos EstadosMembros em que a disponibilizaram, fornecendolhes informações pormenorizadas, em especial, no que se refere à não conformidade e a quaisquer medidas corretivas adotadas.

9.Durante 10 anos após a data de colocação da estação STIC no mercado, os importadores mantêm um exemplar da declaração UE de conformidade à disposição das autoridades de fiscalização do mercado e asseguram que a documentação técnica lhes possa ser facultada, a pedido.

10.Mediante pedido fundamentado de uma autoridade nacional competente, os importadores devem facultar todas as informações e documentação necessárias, em papel ou em suporte eletrónico e numa língua que possa ser facilmente compreensível por essa autoridade, para demonstrar a conformidade da estação STIC. Os importadores devem cooperar com a referida autoridade, a pedido desta, em todas as ações de eliminação dos riscos decorrentes de estações STIC que tenham colocado no mercado.

Artigo 10.º

Obrigações dos distribuidores

1.Ao disponibilizarem uma estação STIC no mercado, os distribuidores agem com a devida diligência em relação aos requisitos previstos no presente regulamento.

2.Antes de disponibilizarem uma estação STIC no mercado, os distribuidores devem certificarse de que:

a)Esta tem aposta a marcação CE;

b)É acompanhada das instruções e informações de segurança referidas no artigo 7.º, n.º 9, numa língua que possa ser facilmente compreendida pelos utilizadores finais no EstadoMembro em que deve ser disponibilizada no mercado;

c)O fabricante e o importador cumpriram os requisitos estabelecidos no artigo 7.º, n.os 7 e 8, e no artigo 9.º, n.º 4.

3.Sempre que um distribuidor considere que uma estação STIC não é conforme ao artigo 5.º, não deve disponibilizála no mercado até que esta seja posta em conformidade. Sempre que uma estação STIC apresente um risco, o distribuidor deve informar desse facto o fabricante ou o importador e as autoridades de fiscalização do mercado.

4.Enquanto uma estação STIC estiver sob a responsabilidade do distribuidor, este garante que as condições de armazenagem ou transporte não prejudicam a sua conformidade com os requisitos previstos no artigo 5.º.

5.Os distribuidores que considerem que uma estação STIC que disponibilizaram no mercado não é conforme ao presente regulamento ou a qualquer outra legislação aplicável da União devem assegurar que são adotadas medidas corretivas para assegurar a sua conformidade, ou para a retirar ou recolher, consoante o caso. Sempre que a estação STIC apresentar um risco, os distribuidores devem informar imediatamente as autoridades de fiscalização do mercado dos EstadosMembros em que a disponibilizaram, fornecendolhes informações pormenorizadas, em especial, no que se refere à não conformidade e a quaisquer medidas corretivas adotadas.

6.Mediante pedido fundamentado de uma autoridade nacional competente, os distribuidores devem facultar todas as informações e documentação necessárias para demonstrar a conformidade da estação STIC. Os distribuidores devem cooperar com as referidas autoridades, a pedido desta, em todas as ações de eliminação dos riscos decorrentes das estações STIC que tenham disponibilizado no mercado.

Artigo 11.º

Casos em que as obrigações dos fabricantes se aplicam aos importadores e distribuidores

Sempre que um importador ou distribuidor colocar no mercado uma estação STIC sob o seu nome ou a sua marca comercial, ou alterar uma estação STIC já colocada no mercado, de tal modo que a conformidade com o presente regulamento possa ser afetada, deve ser considerado como um fabricante para efeitos do presente regulamento e estar sujeito às obrigações dos fabricantes nos termos do artigo 7.º.

Artigo 12.º

Identificação dos operadores económicos

A pedido das autoridades de fiscalização do mercado, os operadores económicos identificam:

a)Os operadores económicos que lhes tenham fornecido uma estação STIC;

b)Os operadores económicos a quem forneceram uma estação STIC.

Os operadores económicos devem estar em condições de apresentar as informações referidas no primeiro parágrafo durante um pelo período de 15 anos após lhes ter sido fornecida a estação STIC, e de 15 anos após terem fornecido a estação STIC.

Artigo 13.º

Declaração UE de conformidade

1.A declaração UE de conformidade deve indicar que foi demonstrado o cumprimento dos requisitos especificados no artigo 5.º.

2.A declaração UE de conformidade deve ser estruturada de acordo com o modelo constante do anexo V, parte B, conter os elementos especificados no anexo V, parte A, e ser mantida atualizada. A referida declaração deve ser traduzida para a língua ou línguas exigidas pelo EstadoMembro no qual a estação STIC é disponibilizada no mercado.

3.Ao elaborar a declaração UE de conformidade, o fabricante assume a responsabilidade pela conformidade da estação STIC com os requisitos previstos no presente regulamento.

4.Sempre que uma estação STIC estiver sujeita a mais do que um ato da União que exija uma declaração UE de conformidade, deve elaborarse uma única declaração referente a todos esses atos. Essa declaração deve identificar os atos em causa, incluindo as respetivas referências de publicação.

Artigo 14.º

Princípios gerais da marcação CE

A marcação CE está sujeita aos princípios gerais enunciados no artigo 30.º do Regulamento (CE) n.º 765/2008 do Parlamento Europeu e do Conselho 24 .

Artigo 15.º

Regras e condições para a aposição da marcação CE

1.A marcação CE deve ser aposta de modo visível, legível e indelével na estação STIC ou na respetiva placa de identificação.

2.A marcação CE deve ser aposta antes de a estação STIC ser colocada no mercado. Pode ser seguida de um pictograma ou de qualquer outra marca indicando um risco ou uma utilização especiais.

Artigo 16.º

Fiscalização do mercado da União e controlo das estações STIC que entram no mercado da União

O artigo 15.º, n.º 3, e os artigos 16.º a 29.º do Regulamento (CE) n.º 765/2008 aplicamse às estações STIC.

Artigo 17.º

Procedimento aplicável às estações STIC que apresentam um risco a nível nacional

1.Sempre que as autoridades de fiscalização do mercado de um EstadoMembro tiverem agido em conformidade com o artigo 20.º do Regulamento (CE) n.º 765/2008 ou existam motivos suficientes para crerem que uma estação STIC apresenta um risco para a saúde ou a segurança das pessoas ou para segurança e a eficiência do tráfego, devem proceder a uma avaliação da estação STIC em causa, abrangendo todos os requisitos aplicáveis do presente regulamento. Os operadores económicos pertinentes devem cooperar na medida do necessário.

Sempre que, no decurso da avaliação, as autoridades de fiscalização do mercado verificarem que a estação STIC não cumpre os requisitos do presente regulamento, devem exigir, sem demora, ao operador económico em causa que adote todas as medidas corretivas adequadas para assegurar a sua conformidade com esses requisitos ou para a retirar do mercado ou recolher num prazo razoável e proporcional à natureza do risco.

O artigo 21.º do Regulamento (CE) n.º 765/2008 aplicase às medidas referidas no segundo parágrafo do presente número.

2.Sempre que as autoridades de fiscalização do mercado considerarem que a não conformidade não se restringe ao território nacional, devem informar, sem demora, a Comissão e os demais EstadosMembros dos resultados da avaliação e das medidas que exigiram fossem adotadas pelo operador económico.

3.O operador económico deve assegurar a aplicação, em toda a União, da totalidade das medidas corretivas adequadas, no que respeita a todas as estações STIC em causa que tenha disponibilizado no mercado da União.

4.Sempre que o operador económico não tome as medidas corretivas adequadas no prazo referido no n.º 1, segundo parágrafo, as autoridades de fiscalização do mercado devem tomar todas as medidas provisórias adequadas para proibir ou restringir a disponibilização da estação STIC nos seus mercados nacionais, para a retirar desses mercados ou para a recolher.

5.As autoridades de fiscalização do mercado devem informar, sem demora, a Comissão e os demais EstadosMembros das medidas provisórias a que se refere o n.º 4. Essas informações incluem todos os elementos disponíveis, incluindo:

a)Os dados necessários para identificar a estação STIC não conforme;

b)A origem da estação STIC;

c)O risco envolvido e a natureza da alegada não conformidade do STIC com os requisitos estabelecidos no presente regulamento;

d)A natureza e a duração das medidas provisórias adotadas;

e)Os argumentos apresentados pelo operador económico.

6.Os EstadosMembros, com exceção do EstadoMembro que deu início ao procedimento, devem informar, sem demora, a Comissão e os demais EstadosMembros de:

a)Quaisquer medidas que tenham adotado;

b)Todas as informações adicionais de que disponham relativas à não conformidade da estação STIC em causa;

c)Quaisquer objeções que tenham às medidas provisórias adotadas pelo EstadoMembro que deu início ao procedimento.

7.Se, no prazo de três meses a contar da receção das informações a que se refere o n.º 5, os demais EstadosMembros ou a Comissão não tiverem levantado objeções a uma medida provisória adotada por um EstadoMembro, essa medida é considerada justificada. Caso a medida provisória seja considerada justificada, os EstadosMembros devem assegurar a aplicação imediata de medidas restritivas adequadas em relação à estação STIC em causa, nomeadamente a sua retirada, sem demora, do mercado. 

Artigo 18.º

Procedimento de salvaguarda da União

1.Sempre que, no termo do procedimento previsto no artigo 17.º, n.os 3 e 4, tiverem sido levantadas objeções a uma medida provisória adotada por um EstadoMembro ou sempre que a Comissão considerar que uma medida provisória é contrária à legislação da União, a Comissão deve iniciar, sem demora, consultas com os EstadosMembros e os operadores económicos pertinentes, e avaliar a medida provisória. Em função dos resultados dessa avaliação, a Comissão deve decidir se a medida nacional é ou não justificada. 

Os EstadosMembros são os destinatários dessa decisão, a qual é, sem demora, comunicada pela Comissão aos operadores económicos pertinentes.

2.Se a medida provisória for considerada justificada numa decisão da Comissão, os EstadosMembros devem adotar as medidas necessárias para assegurar que a estação STIC não conforme é retirada dos respetivos mercados e informar desse facto a Comissão. Se a medida provisória for considerada injustificada, o EstadoMembro em causa deve revogála.

Artigo 19.º

Estações STIC conformes que apresentam um risco para a saúde e a segurança a nível nacional

1.Sempre que, após uma avaliação nos termos do artigo 17.º, n.º 1, as autoridades de fiscalização do mercado de um EstadoMembro verificarem que, embora em conformidade com o presente regulamento, uma estação STIC apresenta um risco para a saúde ou segurança das pessoas ou para outros aspetos da proteção do interesse público, essas autoridades devem ordenar ao operador económico em causa que adote uma ou mais das seguintes medidas corretivas proporcionais à natureza do risco:

a)Adotar todas as medidas adequadas para que a estação STIC, quando colocada no mercado, deixe de apresentar esse risco;

b)Retirar a estação STIC do mercado;

c)Recolher a estação STIC.

As autoridades de fiscalização do mercado devem fixar um período razoável, proporcional à natureza do risco, até ao final do qual o operador económico deve adotar as medidas referidas no primeiro parágrafo.

2.O operador económico deve assegurar que a medida corretiva é adotada em toda a União, no que respeita a todas as estações STIC que disponibilizou no mercado da União.

3.As autoridades de fiscalização do mercado devem informar imediatamente a Comissão e os demais EstadosMembros das medidas corretivas que tenham ordenado nos termos do n.º 1, bem como comunicar todas as informações disponíveis, incluindo:

a)Os dados necessários para identificar a estação STIC em causa;

b)A origem e a cadeia de abastecimento da estação STIC;

c)A natureza do risco;

d)A natureza e a duração das medidas corretivas.

4.A Comissão deve iniciar, sem demora, consultas com os EstadosMembros e os operadores económicos pertinentes e avaliar as medidas corretivas adotadas pelas autoridades de fiscalização do mercado. Com base nos resultados da avaliação, decide se a medida é ou não justificada e, se necessário, propõe medidas adequadas.

5.Os EstadosMembros são os destinatários dessa decisão, a qual é imediatamente comunicada pela Comissão ao operador ou operadores económicos pertinentes.

Artigo 20.º

Não conformidade formal

1.Sem prejuízo do disposto no artigo 17.º, o EstadoMembro deve exigir que o operador económico pertinente ponha termo à não conformidade, sempre que fizer uma das seguintes constatações:

a)A marcação CE foi aposta em violação do disposto no artigo 14.º ou no artigo 15.º;

b)A marcação CE não foi aposta;

c)A declaração UE de conformidade não foi elaborada;

d)A declaração UE de conformidade não foi corretamente elaborada;

e)A documentação técnica não está disponível ou não está completa;

f)As informações referidas no artigo 5.º, n.º 6, ou no artigo 7.º, n.º 3, estão ausentes ou são falsas ou incompletas;

g)Os demais requisitos administrativos previstos no artigo 5.º ou no artigo 7.º não estão cumpridos.

2.Sempre que a não conformidade referida no n.º 1 persistir, o EstadoMembro em causa deve adotar as medidas adequadas para restringir ou proibir a disponibilização da estação STIC no mercado, ou para garantir que esta é recolhida ou retirada do mercado.

Capítulo IV

Colocação em serviço e funcionamento de estações STIC centrais

Artigo 21.º

Colocação em serviço de estações STIC centrais

1.Antes de colocar em serviço estações STIC centrais, o operador da estação STIC deve assegurar que estas foram concebidas e fabricadas em conformidade com os requisitos estabelecidos no artigo 5.º. Para o efeito, deve adotar uma das seguintes medidas:

a)Adquirir uma estação STIC colocada no mercado em conformidade com o capítulo III. Nesse caso, os n.os 2 e 3 do presente artigo não são aplicáveis;

b)Integrar as capacidades da estação STIC num centro de controlo de tráfego ou servidor central. Nesse caso, os n.os 2 e 3 do presente artigo são aplicáveis e os artigos 7.º a 20.º não são aplicáveis à estação STIC central.

2.Os operadores de estações STIC devem elaborar a documentação técnica exigida referida no anexo V, parte C, e efetuar o procedimento de avaliação da conformidade referido no anexo V, parte C. Sempre que a conformidade de uma estação STIC central com os requisitos estabelecidos no artigo 5.º tiver sido demonstrada através desse procedimento, os operadores de estações STIC devem elaborar uma declaração UE de conformidade nos termos do anexo V, parte D.

3.Os operadores de estações STIC devem conservar a documentação técnica e a declaração UE de conformidade enquanto a estação STIC central estiver em funcionamento.

Artigo 22.º

Obrigações dos operadores de estações STIC

1.Os operadores de estações STIC devem assegurar que todas as estações STIC são colocadas em serviço e operadas em conformidade com o presente regulamento.

2.Antes de colocar em serviço uma estação STIC, o operador da estação STIC deve certificarse de que:

a)Esta tem aposta a marcação CE;

b)A documentação técnica referida no artigo 7.º está disponível;

c)A estação STIC é certificada de acordo com os requisitos do anexo IV, ponto 1.6.2.

As obrigações previstas no primeiro parágrafo, alíneas a) e b), do presente número não se aplicam às estações STIC centrais colocadas em serviço nos termos do artigo 21.º, n.º 1, alínea b).

Além disso, antes da colocação em serviço de uma estação STIC, o operador da estação STIC deve inscrevêla no sistema de gestão de credenciais de segurança dos STIC da UE, em conformidade com o artigo 23.º, n.º 3.

3.Antes de colocar em serviço uma estação STIC, o operador da estação STIC deve acordar com o proprietário da estação STIC os direitos e obrigações no que respeita ao funcionamento, à manutenção e à atualização da estação STIC, incluindo a forma de informar o utilizador final.

4.Sempre que uma estação STIC for inscrita no sistema de gestão de credenciais de segurança dos STIC da UE, deve ser inscrita no registo de estações STIC da autoridade responsável pela sua inscrição, juntamente com a identificação do seu operador. O ponto de contacto STIC deve manter uma lista de registos de estações STIC.

5.O operador da estação STIC deve assegurar que, enquanto a estação STIC estiver a ser utilizada, continua a cumprir os requisitos do artigo 5.º, conforme aplicável no momento da sua colocação em serviço.

6.Sempre que uma estação STIC for adaptada por iniciativa do seu operador ou tenha de ser adaptada devido a uma alteração ao presente regulamento, o operador deve assegurar que a estação STIC é conforme com a versão mais recente das especificações pertinentes referidas no artigo 5.º.

7.Sempre que uma estação STIC seja modernizada por iniciativa do fabricante ou do seu mandatário, o fabricante ou o seu mandatário e os operadores da estação STIC devem cooperar com vista a garantir que a estação STIC é conforme à versão mais recente das especificações pertinentes referidas no artigo 5.º.

Capítulo V

Segurança

Artigo 23.º

Inscrição das estações STIC no sistema de gestão de credenciais de segurança dos STIC da UE

1.O sistema de gestão de credenciais de segurança dos STIC da UE foi criado para fornecer comunicações seguras e de confiança entre estações STIC.

2.O funcionamento do sistema de gestão de credenciais de segurança dos STIC da UE deve cumprir os requisitos constantes do:

a)Anexo III (política de certificação), que estabelece os requisitos de gestão dos certificados de chave pública para serviços STIC, por parte das entidades emissoras, e para a sua utilização pelas entidades finais;

b)Anexo IV (política de segurança), que estabelece os requisitos para a gestão da segurança da informação nos STIC.

3.Todas as estações STIC devem estar inscritas no sistema de gestão de credenciais de segurança dos STIC da UE e cumprir as respetivas regras, em conformidade com as especificações estabelecidas nos anexos III e IV.

Artigo 24.º

Autoridade responsável pela política de certificação dos STIC

1.A autoridade responsável pela política de certificação dos STIC é responsável pela gestão da política de certificação e de autorizações PKI, em conformidade com a política de certificação estabelecida no anexo III.

2.A Comissão atua como autoridade responsável pela política de certificação dos STIC até que seja criada uma entidade específica. 

Artigo 25.º

Gestor da lista de confiança

1.O gestor da lista de confiança é responsável pela criação e atualização da Lista de Confiança de Certificados Europeus (European Certificate Trust List, «ECTL») em conformidade com a política de certificação estabelecida no anexo III, bem como pela apresentação regular de relatórios de atividade à autoridade responsável pela política de certificação dos STIC, no que diz respeito ao funcionamento geral seguro do modelo de confiança dos STIC.

2.A Comissão age na qualidade de gestor da lista de confiança até à criação de uma entidade específica.

Artigo 26.º

Ponto de contacto STIC

1.O ponto de contacto STIC é responsável pelo tratamento de toda a comunicação com os gestores das autoridades de certificação de raiz e pela publicação do certificado de chave pública do gestor da lista de confiança e da ECTL, em conformidade com a política de certificação constante do anexo III.

2.A Comissão atua como ponto de contacto STIC até à criação de uma entidade específica.

Artigo 27.º

Sistema de gestão da segurança das informações

Cada operador de estação STIC deve operar um sistema de gestão da segurança da informação em conformidade com a norma ISO/IEC 27001 e os requisitos adicionais constantes do anexo IV, ponto 1.3.1. 

Artigo 28.º

Cumprimento da política de segurança

Os operadores de estações STIC devem solicitar e obter certificação periódica em conformidade com os requisitos do anexo IV, secção 1.7. 

Capítulo VI

Implementação

Artigo 29.º

Implementação da rede STIC

1.A Comissão terá as seguintes funções na implementação da rede STIC:

a)Tarefas de governação:

1)Preparar atualizações do quadro de governação dos STIC;

2)Apoiar o desenvolvimento de princípios comuns para o tratamento lícito de dados pessoais por parte dos responsáveis pelo tratamento de dados e pelos subcontratantes na rede STIC;

3)Agir como ponto de contacto, no que respeita à implementação da rede STIC, para os operadores e fabricantes de estações STIC, os grupos de utilizadores de STI e as partes interessadas de países terceiros;

4)Rever o seguinte:

a)Critérios de avaliação dos STIC, a utilizar pelos laboratórios de ensaio e outros organismos de avaliação durante o processo de avaliação da conformidade;

b)Especificações de referência STIC, incluindo as normas de base e de ensaio a utilizar nas várias fases do processo de avaliação;

b)Tarefas de supervisão: supervisionar a gestão de incidentes de segurança em grande escala e de grande gravidade com impacto em toda a rede STIC (incluindo situações de recuperação em caso de catástrofe, em que o algoritmo criptográfico está comprometido);

c)As funções da autoridade responsável pela política de certificação dos STIC são as seguintes:

1)Gestão da política de certificação;

2)Gestão de autorizações PKI.

2.No desempenho das funções referidas no n.º 1, a Comissão é assistida por um grupo de peritos com representantes das partes interessadas públicas e privadas, em especial, fabricantes de estações STIC e operadores da rede STIC.

Capítulo VII

Disposições finais

Artigo 30.º

Medidas intercalares

Em caso de uma situação de emergência que comprometa o bom funcionamento da rede STIC e que tenha um grave impacto direto na segurança rodoviária, na cibersegurança ou na disponibilidade e integridade dos serviços STIC, a Comissão pode adotar uma decisão que introduza medidas provisórias para obviar a essa situação. Essa decisão deve limitarse estritamente à análise das causas e consequências dessa situação. A referida decisão é aplicável até que o presente regulamento seja alterado para remediar essa situação.

Artigo 31.º

Relatórios

1.Os EstadosMembros devem monitorizar a aplicação do presente regulamento no seu território e informar sobre os progressos realizados na sua aplicação no relatório periódico a que se refere o artigo 17.º, n.º 3, da Diretiva 2010/40/UE. Os relatórios devem abranger, em especial:

a)Uma descrição das iniciativas públicas e públicoprivadas pertinentes para a implantação de STIC, incluindo os respetivos objetivo, calendário, etapas, recursos, principal(ais) parte(s) interessada(s) e estatuto;

b)A cobertura da rede rodoviária por tipo de estrada para cada serviço STIC prioritário veículoinfraestrutura constante da lista do anexo I;

c)O número de estações STIC rodoviárias e centrais instaladas no seu território.

Os EstadosMembros devem apresentar um relatório, pela primeira vez, até 27 de agosto de 2020.

2.As autoridades de certificação de raiz constantes da lista de confiança de certificados especificada no anexo III devem comunicar à Comissão, até 31 de dezembro de 2020, e até 31 de dezembro de cada ano, o número de estações STIC móveis e fixas inscritas e operacionais sob a sua autoridade.

Artigo 32.º

Estações STIC colocadas no mercado antes de 31 de dezembro de 2019

1.A autoridade responsável pela política de certificação dos STIC pode permitir, numa base casuística, a inscrição das estações STIC colocadas no mercado, o mais tardar, em 31 de dezembro de 2019, que não cumpram integralmente os requisitos do presente regulamento em matéria de segurança dos STIC, e das estações STIC do mesmo tipo/modelo colocadas no mercado, o mais tardar, em 30 de junho de 2021 no modelo de confiança dos STIC, desde que estejam preenchidas as condições estabelecidas no n.º 2. As estações STIC do mesmo tipo/modelo utilizadas para a substituição de estações STIC defeituosas ou avariadas a que se refere a primeira frase poderão também ser inscritas, nas mesmas condições.

2.A autoridade responsável pela política de certificação dos STIC pode inscrever as estações STIC referidas no n.º 1 no modelo de confiança dos STIC, nas seguintes condições:

a)É estabelecido o mesmo nível de segurança e de confiança exigido pelo presente regulamento;

b)Ficou demonstrado que as respetivas estações STIC, bem como o procedimento previsto de inscrição, não representam riscos adicionais para a rede STIC.

3.A autoridade responsável pela política de certificação dos STIC toma a sua decisão com base no relatório de um auditor PKI acreditado e numa avaliação da vulnerabilidade em termos de segurança efetuada por um organismo de avaliação da conformidade.

Artigo 33.º

Revisão

1.Até [SP: Inserir a data: três anos após a entrada em vigor do presente regulamento], a Comissão deve rever a aplicação do presente regulamento e, se for caso disso, adotar novas especificações comuns no âmbito do presente regulamento.

2.Sempre que as partes interessadas pretendam utilizar um método ou serviço de comunicação novo ou atualizado, ou outras soluções inovadoras, incluindo tecnologias para as quais os protótipos estão a ser atualmente ensaiados, na rede STIC, devem primeiro apresentar à Comissão um ficheiro com as especificações técnicas e informações sobre o grau de maturidade e a compatibilidade da solução inovadora com o presente regulamento. Essas especificações técnicas devem ser desenvolvidas em conformidade com os princípios da abertura, do consenso e da transparência, tal como definidos no anexo II do Regulamento (UE) n.º 1025/2012.

A Comissão deve analisar o processo sem demora injustificada e começar a debater o processo no grupo de peritos, tal como definido no artigo 29.º, n.º 2, no prazo de dois meses, tendo em vista uma possível alteração do presente regulamento. O grupo de peritos avalia a necessidade de especificações comuns que integrem as novas soluções na rede STIC e emite um parecer, o mais tardar seis meses após a receção do processo. Se for caso disso, o Centro Comum de Investigação da Comissão apoiará os debates pertinentes com uma avaliação técnica independente.

A apresentação de soluções inovadoras à Comissão e, se for caso disso, a subsequente alteração do presente regulamento podem ocorrer a qualquer momento após a entrada em vigor do presente regulamento.

3.A fim de manter a continuidade dos serviços STIC prioritários constantes da lista do anexo I, quaisquer alterações futuras devem assegurar a compatibilidade e a interoperabilidade com as estações STIC existentes colocadas em serviço em conformidade com o presente regulamento, ou especificar uma trajetória de migração adequada.

Artigo 34.º

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.

O presente regulamento é aplicável a partir de 31 de dezembro de 2019.

O presente regulamento é obrigatório em todos os seus elementos e diretamente aplicável em todos os EstadosMembros.

Feito em Bruxelas, em 13.3.2019

   Pela Comissão

   O Presidente
   Jean-Claude JUNCKER

(1)    https://ec.europa.eu/transport/themes/its/cits_en
(2)     https://www.croads.eu
(3)    Comunicação da Comissão ao Parlamento Europeu, ao Conselho, ao Comité Económico e Social Europeu e ao Comité das Regiões, Uma estratégia europeia relativa aos sistemas cooperativos de transporte inteligentes, uma etapa rumo a uma mobilidade cooperativa, conectada e automatizada, [COM(2016) 766 final].
(4)    Diretiva 2010/40/UE do Parlamento Europeu e do Conselho, de 7 de julho de 2010, que estabelece um quadro para a implantação de sistemas de transporte inteligentes no transporte rodoviário, inclusive nas interfaces com outros modos de transporte (JO L 207 de 6.8.2010, p. 1).
(5)    Regulamento (UE) 2016/679 do Parlamento Europeu e do Conselho, de 27 de abril de 2016, relativo à proteção das pessoas singulares no que diz respeito ao tratamento de dados pessoais e à livre circulação desses dados e que revoga a Diretiva 95/46/CE (Regulamento Geral sobre Proteção de Dados) (JO L 119 de 4.5.2016, p. 1).
(6)    Diretiva 2002/58/CE do Parlamento Europeu e do Conselho, de 12 de julho de 2002, relativa ao tratamento de dados pessoais e à proteção da privacidade no setor das comunicações eletrónicas (Diretiva relativa à privacidade e às comunicações eletrónicas) (JO L 201 de 31.7.2002, p. 37).
(7)    Diretiva 95/46/CE do Parlamento Europeu e do Conselho, de 24 de outubro de 1995, relativa à proteção das pessoas singulares no que diz respeito ao tratamento de dados pessoais e à livre circulação desses dados (Diretiva relativa à Proteção de Dados) (JO L 281 de 23.11.1995, p. 31).
(8)    Decisão de Execução da Comissão, de 7 de abril de 2016, que altera a Decisão de Execução C(2014)1921 da Comissão que estabelece um programa de trabalho plurianual 20142020 para a concessão de assistência financeira no âmbito do Mecanismo Interligar a Europa (MIE) — setor dos transportes no período 20142020.
(9)    JO L 207 de 6.8.2010, p. 1.
(10)    Comunicação da Comissão ao Parlamento Europeu, ao Conselho, ao Comité Económico e Social Europeu e ao Comité das Regiões, Uma estratégia europeia relativa aos sistemas cooperativos de transporte inteligentes, uma etapa rumo a uma mobilidade cooperativa, conectada e automatizada [COM(2016) 766 final].
(11)    Regulamento Delegado (UE) n.º 886/2013 da Comissão, de 15 de maio de 2013, que complementa a Diretiva 2010/40/UE do Parlamento Europeu e do Conselho no respeitante aos dados e procedimentos para a prestação, se possível, de informações mínimas universais sobre o tráfego relacionadas com a segurança rodoviária, gratuitas para os utilizadores (JO L 247 de 18.9.2013, p. 6).
(12)    Regulamento Delegado (UE) 2015/962 da Comissão, de 18 de dezembro de 2014, que complementa a Diretiva 2010/40/UE do Parlamento Europeu e do Conselho no respeitante à prestação de serviços de informação de tráfego em tempo real à escala da UE (JO L 157 de 23.6.2015, p. 21).
(13)    JO L 194 de 19.7.2016, p. 1.
(14)    Decisão 2008/671/CE da Comissão, de 5 de agosto de 2008, relativa à utilização harmonizada do espetro radioelétrico na faixa de frequências de 5875 5905 MHz para aplicações relacionadas com a segurança no domínio dos sistemas de transporte inteligentes (STI) (JO L 220 de 15.8.2008, p. 24).
(15)    M/453: Mandato de normalização dirigido ao CEN, ao CENELEC e ao ETSI no domínio das tecnologias da informação e da comunicação, para apoiar a interoperabilidade de sistemas cooperativos de transporte inteligentes na Comunidade Europeia.
(16)    Diretiva 2014/53/UE do Parlamento Europeu e do Conselho, de 16 de abril de 2014, relativa à harmonização da legislação dos EstadosMembros respeitante à disponibilização de equipamentos de rádio no mercado e que revoga a Diretiva 1999/5/CE (JO L 153 de 22.5.2014, p. 62).
(17)    Decisão n.º 768/2008/CE do Parlamento Europeu e do Conselho, de 9 de julho de 2008, relativa a um quadro comum para a comercialização de produtos, e que revoga a Decisão 93/465/CEE (JO L 218 de 13.8.2008, p. 82).
(18)    Regulamento (UE) 2016/679 do Parlamento Europeu e do Conselho, de 27 de abril de 2016, relativo à proteção das pessoas singulares no que diz respeito ao tratamento de dados pessoais e à livre circulação desses dados e que revoga a Diretiva 95/46/CE (Regulamento Geral sobre a Proteção de Dados) (JO L 119 de 4.5.2016, p. 1).
(19)    Diretiva 2002/58/CE do Parlamento Europeu e do Conselho, de 12 de julho de 2002, relativa ao tratamento de dados pessoais e à proteção da privacidade no setor das comunicações eletrónicas (Diretiva relativa à privacidade e às comunicações eletrónicas) (JO L 201 de 31.7.2002, p. 37).
(20)    Regulamento (CE) n.º 45/2001 do Parlamento Europeu e do Conselho, de 18 de Dezembro de 2000, relativo à proteção das pessoas singulares no que diz respeito ao tratamento de dados pessoais pelas instituições e pelos órgãos comunitários e à livre circulação desses dados (JO L 8 de 12.1.2001, p. 1).
(21)    Diretiva 2004/52/CE do Parlamento Europeu e do Conselho, de 29 de abril de 2004, relativa à interoperabilidade dos sistemas eletrónicos de portagem rodoviária na Comunidade (JO L 166 de 30.4.2004, p. 124).
(22)    Decisão 2009/750/CE da Comissão, de 6 de outubro de 2009, relativa à definição do serviço eletrónico europeu de portagem e seus elementos técnicos (JO L 268 de 13.10.2009, p. 11).
(23)    Regulamento (UE) n.º 165/2014 do Parlamento Europeu e do Conselho, de 4 de fevereiro de 2014, relativo à utilização de tacógrafos nos transportes rodoviários, que revoga o Regulamento (CEE) n.º 3821/85 do Conselho relativo à introdução de um aparelho de controlo no domínio dos transportes rodoviários e que altera o Regulamento (CE) n.º 561/2006 do Parlamento Europeu e do Conselho relativo à harmonização de determinadas disposições em matéria social no domínio dos transportes rodoviários (JO L 60 de 28.2.2014, p. 1).
(24)    Regulamento (CE) n.º 765/2008 do Parlamento Europeu e do Conselho, de 9 de julho de 2008, que estabelece os requisitos de acreditação e fiscalização do mercado relativos à comercialização de produtos, e que revoga o Regulamento (CEE) n.º 339/93 (JO L 218 de 13.8.2008, p. 30).
Início

ANEXO I

1.Introdução

O presente anexo contém os perfis de serviço para os serviços de prioridade STI-C. Um perfil de serviço é uma configuração específica de normas que define a implementação de várias opções de normas.

1.1.Referências

No presente anexo, utilizam-se as seguintes referências:

TS 102 894-2    ETSI TS 102 894-2, Sistemas de Transporte Inteligentes (STI); Requisitos de utilizadores e aplicações; Parte 2: Dicionário de dados comuns da camada de aplicações e instalações, V1.3.1 (2018-08)

EN 302 637-2    ETSI EN 302 637-2, Sistemas de Transporte Inteligentes (STI); Comunicações em veículos; Conjunto básico de aplicações; Parte 2: Especificação do Serviço Básico de Perceção Cooperativa, V1.4.0 (2018-08); esta referência deve ser lida como referência à versão 1.4.1 a partir da data de publicação daquela versão.

ETSI EN 302 637-3    ETSI EN 302 637-3, Sistemas de Transporte Inteligentes (STI); Comunicações em veículos; Conjunto básico de aplicações; Parte 3: Especificações do Serviço Básico de Notificação Ambiental Descentralizada, V1.4.0 (201808)

ECE 13    Regulamento n.º 13 da Comissão Económica das Nações Unidas para a Europa (UNECE) — Disposições uniformes relativas à homologação de veículos das categorias M, N e O no que se refere à travagem [2016/194]

ECE 13H    Regulamento n.º 13H da Comissão Económica das Nações Unidas para a Europa (UNECE) — Prescrições uniformes relativas à homologação dos automóveis de passageiros no que diz respeito ao sistema de travagem [2015/2364]

ECE 48    Regulamento n.º 48 da Comissão Económica das Nações Unidas para a Europa (UNECE) — Prescrições uniformes relativas à homologação de veículos no que diz respeito à instalação de dispositivos de iluminação e sinalização luminosa [2016/1723]

ECE 121    Regulamento n.º 121 da Comissão Económica das Nações Unidas para a Europa (UNECE) — Prescrições uniformes relativas à homologação de veículos no que diz respeito à localização e identificação de comandos manuais, avisadores e indicadores [2016/18]

ISO/TS 19321    ISO/TS 19321, Sistemas de transporte inteligentes — STI cooperativos — Dicionário de estruturas de dados de informação em veículos (IVI) (15 de abril de 2015)

ISO 639-1    Códigos para a representação dos nomes dos países e suas subdivisões – Parte 1: Código alfa-2

ISO/TS 14823    ISO 14823:2017. Sistemas de transporte inteligentes – Dicionário de dados gráficos

1.2.Notações e abreviaturas

No presente anexo, utilizam-se as seguintes notações e abreviaturas:

ABS                Anti-lock Braking System (Sistema de travagem antibloqueio)

ASR                Anti-Slip Regulation (Sistema de controlo antipatinagem)

CA                Certificado de Autorização

CAM                Cooperative Awareness Message (Mensagem de Perceção Cooperativa

STI-C            Sistemas Cooperativos de Transporte Inteligentes

DCC                Decentralized Congestion Control (Controlo de Congestionamento Descentralizado)

DEN                Decentralized Environmental Notification (Notificação Ambiental Descentralizada

DENM            Decentralized Environmental Notification Message (Mensagem de Notificação Ambiental Descentralizada)

GNSS            Global Navigation Satellite System (Sistema Global de Navegação por Satélite)

I2V                infraestrutura-veículo

IRC                Impact Reduction Container (Contenção de Redução de Impacto)

IVI                informações veículo-infraestrutura

MAP                Informações topológicas para a interseção

SPAT                Signal Phase and Timing (Fase e Temporização de Sinal)

SREM            Signal Request Extended Message (Mensagem Alargada de Pedido de Sinal)

SSEM            Signal Request Status Extended Message (Mensagem Alargada de Estado de Pedido de Sinal)

TC                Classe de Tráfego

SGT                Sistema de Gestão do Tráfego

TOC                Centro Operacional Rodoviário

TRCO            Condição de acionamento

TTC                Time to Collision (tempo até à colisão)

V2V                Veículo-veículo

1.3.Definições

No presente anexo, utilizam-se as seguintes definições:

(a)«veículo imobilizado»: um veículo com uma velocidade absoluta <= 8 centímetros por segundo. Este estado deve ser determinado por sensores internos do veículo;

(b)«veículo de emergência»: um veículo designado e autorizado para responder a uma emergência. Geralmente, os veículos de emergência podem, por lei, violar as regras convencionais de trânsito, a fim de alcançar os seus destinos no menor espaço de tempo possível, nomeadamente (mas não apenas) atravessar um cruzamento quando os semáforos estão vermelhos ou exceder o limite de velocidade.

2.Lista de serviços prioritários

Categoria de serviços

Serviço

Perfil de serviço

Serviços veículo-veículo

Engarrafamento

Fim de fila perigoso

Ponto 3

Engarrafamento

Engarrafamento à frente

Ponto 4

Aviso de veículo imobilizado

Veículo parado

Ponto 5

Aviso de veículo imobilizado

Veículo avariado

Ponto 6

Aviso de veículo imobilizado

Pós-colisão

Ponto 7

Aviso de veículo especial

Veículo de emergência em operação

Ponto 8

Aviso de veículo especial

Veículo de emergência de salvaguarda imobilizado

Ponto 9

Aviso de veículo especial

Aviso de serviço de pronto-socorro imobilizado

Ponto 10

Intercâmbio de IRC

IRC de pedido

Ponto 11

Intercâmbio de IRC

IRC de resposta

Ponto 12

Situação perigosa

Luz de travagem de emergência eletrónica

Ponto 13

Situação perigosa

Intervenção do travão automático

Ponto 14

Situação perigosa

Intervenção do sistema reversível de retenção de ocupantes

Ponto 15

Condições meteorológicas adversas

Nevoeiro

Ponto 16

Condições meteorológicas adversas

Precipitação

Ponto 17

Condições meteorológicas adversas

Perda de tração

Ponto 18

Serviços infraestrutura-veículo

Sinalização de bordo

Informações de limite de velocidade dinâmico

Ponto 19

Sinalização de bordo

«Texto livre» de VMS incorporado

Ponto 20

Sinalização de bordo

Outras informações de sinalização

Ponto 21

Notificação relativa a localizações perigosas

Zona de acidentes

Ponto 22

Notificação relativa a localizações perigosas

Engarrafamento à frente

Ponto 23

Notificação relativa a localizações perigosas

Veículo imobilizado

Ponto 24

Notificação relativa a localizações perigosas

Aviso de condições meteorológicas

Ponto 25

Notificação relativa a localizações perigosas

Via com pavimento temporariamente escorregadio

Ponto 26

Notificação relativa a localizações perigosas

Animal ou pessoa na via

Ponto 27

Notificação relativa a localizações perigosas

Obstáculo na via

Ponto 28

Aviso de obras na estrada

Faixa fechada ao trânsito (e outras restrições)

Ponto 29

Aviso de obras na estrada

Via fechada ao trânsito

Ponto 30

Aviso de obras na estrada

Obras na estrada — móveis

Ponto 31

Cruzamentos sinalizados

Velocidade ótima recomendada na proximidade da passagem para a luz verde

Ponto 32

Cruzamentos sinalizados

Priorização dos transportes públicos

Ponto 33

3.Engarrafamento — fim de fila perigoso

3.1.Descrição do serviço de sistemas cooperativos de transporte inteligentes (STI-C)

O serviço STI-C transmite informações de veículo para veículo (V2V) numa situação em que um veículo ego deteta o fim de um engarrafamento («fim de fila perigoso»). Essa situação ocorre quando a faixa de tráfego do veículo ego se encontra bloqueada e o veículo não pode prosseguir na sua faixa. Este serviço não contempla ambientes urbanos.

Os seguintes serviços STI-C estão relacionados com este serviço, pois partilham condições de acionamento semelhantes:

·«situações perigosas — luz de travagem de emergência eletrónica»;

3.2.Condições de acionamento

3.2.1.Condições prévias

(1)Sempre que um serviço STI-C é acionado, devem estar reunidas as seguintes condições prévias:

(a)o veículo ego está localizado num ambiente não urbano, conforme determinado através de pelo menos uma das seguintes formas:

·a velocidade é superior a 80 km/h para um bloco temporal de pelo menos 30 s nos 60 s que antecedem cada deteção e o valor absoluto do ângulo de viragem do volante é inferior a 90 ° para um bloco temporal de pelo menos 30 s nos 60 s que antecedem cada deteção (um «final de fila perigoso» não deve ser detetado em ambientes não destinados a veículos a motor);

·um sensor de câmara de bordo indica um ambiente não urbano;

·um mapa digital de bordo indica um ambiente não urbano.

(2)A velocidade e a desaceleração do veículo devem ser determinadas pelo sinal de barramento do veículo e não por um sistema global de navegação por satélite (GNSS). Deve ser utilizada a velocidade filtrada do veículo (no que se refere ao ruído do sensor). Este requisito deve ser aplicado a todas as subsequentes ocorrências da análise de velocidade e desaceleração do veículo.

(3)Os valores de velocidade e ângulo devem ser medidos de forma contínua. As condições devem estar reunidas durante todo o período de medição. O processo deve recomeçar se as condições não estiverem reunidas durante o período de medição.

3.2.2.Condições específicas do serviço

(4)Se estiverem reunidas as condições prévias indicadas no ponto (1) e, pelo menos, uma das seguintes condições, consideram-se reunidas as condições de acionamento deste serviço STI-C e deve ser acionada a geração de uma Mensagem de Notificação Ambiental Descentralizada (DENM):

·TRCO_0 E (TRCO _2 OU TRCO _3 OU TRCO _4 OU TRCO _5 OU TRCO _6)

·TRCO _1 E TRCO _2.

Quadro 1: Condições específicas do serviço «Engarrafamento — fim de fila perigoso»

Contagem

Condição de acionamento (CdA)

Estado

TRCO_0;

O veículo ego está a mover-se a uma velocidade inicial superior a 80 km/h e a desaceleração inicial é igual ou inferior a 0,1 m/s². O condutor reage ao fim de fila perigoso reduzindo a velocidade da velocidade inicial para a velocidade-alvo de 30 km/h ou menos. A duração entre a velocidade inicial e a velocidade-alvo deve ser de 10 s ou menos. É detetada uma desaceleração instantânea entre a velocidade inicial e a velocidade-alvo superior a 3,5 m/s².

reação do condutor

TRCO _1

Os passageiros do veículo ego reagem ao engarrafamento acionando as luzes de perigo durante pelo menos 3 s

reação do condutor

TRCO _2

Pelo menos três outros veículos com uma velocidade de pelo menos 7 km/h acionam as luzes de perigo durante pelo menos 3 s, conforme indicado por:

·um sensor de câmara de bordo; ou

·CAM.

sensores de ambiente ou de bordo

TRCO _3

Foi recebida pelo menos uma DENM correspondente ao serviço «Engarrafamento - Fim de fila perigoso».

ambiente

TRCO _4

Foram recebidas pelo menos cinco DENM diferentes (ou seja, com valores de actionIDs diferentes) correspondentes ao serviço STI-C de «engarrafamento - engarrafamento à frente» do tráfego a jusante.

ambiente

TRCO _5

Foi recebida pelo menos uma DENM correspondente ao serviço STI-C «Aviso de veículo especial - Veículo de salvaguarda de emergência estático», com a linkedCause igual à Traffic Condition ou Dangerous End of Queue.

ambiente

TRCO _6

Os sensores de bordo do veículo ego reconhecem que o veículo está perante um fim de fila perigoso.

sensores de bordo

(5)Não deve ser solicitada uma DENM nova dentro do Detection Blocking Time. O Detection Blocking Time é iniciado após o evento ser detetado e ter sido solicitada uma DENM para esse efeito. Desta forma, um único evento não poderá inundar o canal de transmissão. O Detection Blocking Time deve ser de 60 s, seja qual for a forma de deteção do evento. O período de deteção entre dois eventos detetados deve ser pelo menos igual ao Detection Blocking Time. O algoritmo de deteção pode ser executado durante o Detection Blocking Time.

Nota: não é apresentado qualquer período para as manobras de travagem, pois a velocidade inicial do veículo ego não tem qualquer restrição superior.

(6)Uma condição deve ser válida enquanto estiver ativa e por um período extra de 5 s (o período aumenta o determinismo do algoritmo de deteção). A validade diminuirá a partir do momento em que a condição deixar de ser satisfeita, facilitando, assim, a combinação de condições de acionamento.

(7)As CAM e DENM de veículos remotos utilizados para avaliar as condições específicas do serviço, conforme descrito acima, devem ser relevantes para o veículo ego. A relevância deve ser determinada através de um dos seguintes meios:

(a)um mapa digital indica que o evento e o veículo ego estão separados por uma distância inferior a 500 m e partilham o mesmo sentido de circulação;

(b)um histórico de correlações de trajeto indica que o evento e o veículo ego estão separados por uma distância inferior a 500 m e partilham o mesmo sentido de circulação;

(c)a distância euclidiana entre o evento e o veículo ego é inferior a 500 m e o valor absoluto da diferença de rumo é inferior a 10°. As posições de referência de engarrafamento de acordo com as DENM estão localizadas numa área que vai de -45° a +45°, começando no eixo longitudinal do veículo ego.

Nota: ao contabilizar veículos ou eventos, a mudança do Certificado de Autorização (CA) deve ser considerada de forma que nenhum veículo ou evento seja contabilizado várias vezes.

3.2.3.Qualidade das informações

(8)O valor do elemento de dados informationQuality na DENM depende da forma como a situação é detetada. As TRCO (ver ponto (4)) dividem-se em dois grupos: reação do condutor, dinâmica do veículo, ambiente e sensores de bordo. O valor informationQuality deve ser definido de acordo com o seguinte quadro. Deve ser utilizado o valor mais alto possível.

Quadro 2: Qualidade das informações de «engarrafamento — fim de fila perigoso»

Deteção de evento

Valor da InformationQuality

Sem implementação em conformidade com as TRCO

desconhecido(0)

Está reunida pelo menos uma TRCO da reação do condutor E do grupo ambiental.

1

Está reunida pelo menos uma TRCO da reação do condutor E do grupo dos sensores de bordo.

2

Está reunida pelo menos uma TRCO da reação do condutor E de ambiente E do grupo dos sensores de bordo.

3

3.3.Condições de terminação

(9)Não será considerada a terminação do serviço STI-C.

3.3.1.Cancelamento

(10)Não deve ser utilizada uma DENM de cancelamento para este serviço STI-C.

3.3.2.Negação

(11)Não deve ser utilizada uma DENM de negação para este serviço STI-C.

3.4.Atualização

(12)Não deve ser utilizada uma DENM de atualização para este serviço STI-C.

3.5.Duração de repetição e intervalo de repetição

(13)Devem ser repetidas novas DENM para uma repetitionDuration de 20 s com um repetitionInterval de 0,5 s. Consequentemente, os parâmetros da interface repetitionDuration e repetitionInterval entre a aplicação e o serviço básico de Notificação Ambiental Descentralizada (DEN) devem ser definidos de acordo com os valores acima.

Nota: quando duas DENM com o mesmo causeCode provêm da mesma estação STI-C, o caso deve ser gerido pela estação STI-C recetora.

3.6.Classe de tráfego

(14)Devem ser definidas DENM novas para a traffic class 1.

3.7.Parâmetros de mensagem

3.7.1.DENM

(15)O quadro a seguir especifica os elementos de dados de DENM que devem ser definidos.

Quadro 3: Elementos de dados de DENM de «engarrafamento — fim de fila perigoso»

Campo de dados

Valor

Contentor de gestão

actionID

Identificador de uma DENM. Deve ser definido nos termos da [TS 102 894-2].

detectionTime

TimestampIts - Selo temporal em que o evento é detetado pela estação STI-C de origem. Deve ser definido em conformidade com a norma [TS 102 894-2].

referenceTime

TimestampIts - selo temporal em que é gerada uma DENM nova. Deve ser definido em conformidade com a norma [TS 102 894-2].

terminação

Não deve ser definido, pois nem a negação nem o cancelamento devem ser utilizados neste serviço STI-C.

eventPosition

ReferencePosition. Deve ser definido em conformidade com a norma [TS 102 894-2].

relevanceDistance

menosDe1000 m(4)

relevanceTrafficDirection

upstreamTraffic(1)

validityDuration

20 s (prevê-se que os veículos enfrentem uma situação de tráfego diferente 20 s após a deteção)

stationType

O tipo de estação STI-C de origem. Deve ser definido em conformidade com a norma [TS 102 894-2].

Contenção de situação

informationQuality

Ver ponto (8)

causeCode

dangerousEndOfQueue(27)

subCauseCode

unavailable(0)

Contenção de localização

eventSpeed

Velocidade da estação STI-C de origem. Deve ser definido em conformidade com a norma [TS 102 8942].

eventPositionHeading

Rumo da estação STI-C de origem. Deve ser definido em conformidade com a norma [TS 102 8942].

traces

PathHistory da estação STI-C de origem. Deve ser definido em conformidade com a norma [TS 102 894-2].

roadType

RoadType da estrada em que a estação STI-C de deteção está situada.

Deve ser definido em conformidade com a norma [TS 102 894-2] em conjugação com as seguintes regras:

Urbano / não urbano

Separação estrutural

Elemento de dados

Urbano

Não

urbano-NoStructuralSeparation ToOppositeLanes(0)

Urbano

Sim

urbano-WithStructuralSeparation ToOppositeLanes(1)

Urbano

Desconhecido

urbano-NoStructuralSeparation ToOppositeLanes(0)

Não urbano

Não

nonUrban-NoStructuralSeparation ToOppositeLanes(2)

Não urbano

Sim

nonUrban-WithStructuralSeparation ToOppositeLanes(3)

Não urbano

Desconhecido

nonUrban-NoStructuralSeparation ToOppositeLanes(2)

Se não for possível determinar as informações sobre o estatuto urbano/não urbano, deve ser omitido o elemento de dados.

Contenção a la carte

lanePosition

Se a lanePosition for fornecida por um sensor de bordo (por exemplo, radar, câmara), o valor deve ser definido de acordo com a norma [TS 102 894-2]. A utilização de um sistema GNSS e um mapa digital para estimar o número da faixa não é permitido para esta versão da condição de acionamento.

Se a lanePosition for desconhecida, o elemento de dados deve ser omitido.

3.7.2.Mensagem de Perceção Cooperativa (CAM)

(16)Não deve ser utilizada a CAM de adaptação para este serviço STI-C.

3.8.Rede e camada de transporte

(17)O parâmetro de interface DENM destination area entre o serviço básico DEN e a rede e a camada de transporte devem ser iguais a uma forma circular com raio igual a relevanceDistance.

3.9.Camada de segurança

(18)Se as condições de acionamento estiverem reunidas conforme descrito no ponto (4), qualquer alteração de CA será bloqueada para os novos DENM, desde que a validityDuration não tenha expirado. Devem ser enviadas novas DENM correspondentes com o mesmo CA.

4.Engarrafamento — engarrafamento à frente

4.1.Descrição do serviço STI-C

O serviço STI-C transmite informações V2V numa situação em que um veículo ego deteta um engarrafamento. Essa situação ocorre se o veículo ego estiver rodeado por tráfego imobilizado ou um grande volume de tráfego. O serviço não se aplica a ambientes urbanos.

Os seguintes serviços STI-C estão relacionados com este serviço, pois partilham condições de acionamento semelhantes:

   «aviso de veículo imobilizado — veículo parado»;

   «aviso de veículo imobilizado — veículo avariado»;

   «aviso de veículo imobilizado — veículo em pós-colisão»;

   «aviso de veículo especial — aviso de serviço de pronto-socorro imobilizado»;

4.2.Condições de acionamento

4.2.1.Condições prévias

(19)Antes de um serviço STI-C ser acionado, devem estar reunidas as seguintes condições prévias:

(a)não é detetado qualquer serviço de «aviso de veículo imobilizado» (ver pontos 4 a 6);

(b)não é detetado qualquer serviço de «aviso de veículo especial» (ver pontos 7 a 9);

(c)o veículo ego está localizado num ambiente não urbano. A localização deve ser determinada através de pelo menos um dos seguintes meios:

(a)a velocidade é superior a 80 km/h para um bloco temporal de pelo menos 30 s nos 180 s que antecedem cada deteção e o valor absoluto do ângulo do volante é inferior a 90° para um bloco temporal de pelo menos 30 s nos 60 s que antecedem cada deteção (não devem ser detetados congestionamentos rodoviários em ambientes não destinados a veículos a motor);

(b)um sensor de câmara de bordo indica um ambiente não urbano;

(c)um mapa digital de bordo indica um ambiente não urbano.

(20)A velocidade do veículo deve ser determinada pelo sinal de barramento do veículo e não por um sistema GNSS. Deve ser utilizada a velocidade filtrada do veículo (no que se refere ao ruído do sensor). Este requisito deve ser aplicado a todas as subsequentes ocorrências da análise de velocidade.

(21)Os valores de velocidade e ângulo devem ser medidos de forma contínua. As condições devem estar reunidas durante todo o período de medição. O processo deve recomeçar se as condições não estiverem reunidas durante o período de medição.

4.2.2.Condições específicas do serviço

(22)Se estiverem reunidas as condições prévias indicadas no ponto (19) e, pelo menos, uma das seguintes condições, consideram-se reunidas as condições de acionamento deste serviço STI-C e deve ser acionada a geração de uma DENM:

·TRCO_0;

·TRCO _1 E (TRCO _2 OU TRCO _3 OU TRCO _4 OU TRCO _5)

Quadro 4: Condições específicas do serviço «Engarrafamento — engarrafamento à frente»

Contagem

Condição de acionamento

Estatuto

TRCO_0;

O veículo ego desloca-se a uma velocidade média de 30 km/h ou inferior e superior a 0 km/h (este limiar é introduzido para evitar a sobreposição e distinguir TRCO_0 de TRCO_1). A velocidade média deve ser calculada ao longo de um período de 120 segundos (a condição de duração exclui os estados de tráfego que mudam frequentemente do acionamento).

Nota: Esta TRCO abrange o cenário em que o veículo ego é rodeado de tráfego de «para-arranca».

dinâmica dos veículos

TRCO_1

A velocidade do veículo ego é igual a 0 km/h durante pelo menos 30 s.

Nota: esta TRCO abrange o cenário em que o veículo ego se encontra imobilizado e rodeado de outros utilizadores da via.

dinâmica dos veículos

TRCO_2

Foi recebida pelo menos uma DENM correspondente ao serviço STI-C «engarrafamento - engarrafamento à frente» com o mesmo sentido de circulação.

ambiente

TRCO_3

Foi recebida pelo menos uma notificação de engarrafamento no mesmo sentido do tráfego por meio de rádio móvel.

ambiente

TRCO_4

As CAM indicam uma velocidade de 30 km/h, ou inferior, de pelo menos cinco outros veículos a 100 m no mesmo sentido do tráfego.

ambiente

TRCO_5

Os sensores de bordo indicam uma velocidade de 30 km/h, ou inferior, de pelo menos cinco outros veículos a 100 m e no mesmo sentido do tráfego.

sensor de bordo

(23)Não deve ser solicitada uma nova DENM no Detection Blocking Time. O Detection Blocking Time é iniciado após o evento ser detetado e ter sido solicitada uma DENM para esse efeito. Desta forma, um único evento não poderá inundar o canal de transmissão. O Detection Blocking Time deve ser de 180 s, seja qual for a forma de deteção do evento. O período de deteção entre dois eventos detetados deve ser pelo menos igual ao Detection Blocking Time. O algoritmo de deteção pode ser executado durante o Detection Blocking Time.

(24)Uma condição deve ser válida enquanto estiver ativa e por um período extra de 5 s (o período aumenta o determinismo do algoritmo de deteção). A validade diminui a partir do momento em que a condição deixar de ser satisfeita, facilitando, assim, a combinação de condições de acionamento.

(25)As CAM e DENM de veículos remotos utilizados para avaliar as condições específicas do serviço, conforme descrito acima, devem ser relevantes para o veículo ego. A relevância deve ser determinada através de um dos seguintes meios:

(a)um mapa digital indica que o evento e o veículo ego estão separados por uma distância inferior a 500 m e partilham o mesmo sentido de tráfego;

(b)um histórico de correlações de trajeto indica que o evento e o veículo ego estão separados por uma distância inferior a 500 m e partilham o mesmo sentido de tráfego;

(c)a distância euclidiana entre o evento e o veículo ego é inferior a 500 m e o valor absoluto da diferença de rumo é inferior a 10°. As posições de referência de engarrafamento de acordo com as DENM estão localizadas numa área que vai de -45° a +45°, começando no eixo longitudinal do veículo ego.

Nota: ao contabilizar veículos ou eventos, a mudança do CA deve ser considerada de forma que nenhum veículo ou evento seja contabilizado várias vezes.

4.2.3.Qualidade das informações

(26)O valor do elemento de dados informationQuality na DENM depende da forma como a situação é detetada. As TRCO (ver ponto (22)) dividem-se em dois grupos: reação do condutor, dinâmica do veículo, ambiente e sensores de bordo. O valor informationQuality deve ser definido de acordo com o seguinte quadro. Deve ser utilizado o valor mais alto possível.

Quadro 5: Qualidade das informações de «engarrafamento - engarrafamento à frente»

Deteção de evento

Valor da InformationQuality

Sem implementação em conformidade com asTRCO

desconhecido(0)

Está reunida pelo menos uma condição do grupo de dinâmica do veículo, ou seja, a condição TRCO_0 está reunida.

1

Está reunida pelo menos uma condição da dinâmica do veículo E do grupo ambiental.

2

Está reunida pelo menos uma condição da dinâmica do veículo E do grupo de sensor de bordo.

3

Está reunida pelo menos uma condição da dinâmica do veículo E do grupo de ambiente E do grupo de sensor de bordo.

4

4.3.Condições de terminação

(27)Não será considerada a terminação do serviço STI-C.

4.3.1.Cancelamento

(28)Não deve ser utilizada uma DENM de cancelamento para este serviço STI-C.

4.3.2.Negação

(29)Não deve ser utilizada uma DENM de negação para este serviço STI-C.

4.4.Atualização

(30)Não deve ser utilizada uma DENM de atualização para este serviço STI-C.

4.5.Duração de repetição e intervalo de repetição

(31)Devem ser repetidas novas DENM para uma repetitionDuration de 60 s com um repetitionInterval de 1 s. Consequentemente, os parâmetros de interface Repetition duration e repetitionInterval entre a aplicação e o serviço básico de DEN devem ser definidos de acordo com os valores acima.

Nota: Quando duas DENM com o mesmo causeCode provêm da mesma estação STI-C, o caso deve ser gerido pela estação STI-C recetora.

4.6.Classe de tráfego

(32)Devem ser definidas DENM novas para a traffic class 1.

4.7.Parâmetros de mensagem

4.7.1.DENM

(33)O quadro a seguir especifica os elementos de dados de DENM que devem ser definidos.

Quadro 6: Elementos de dados de DENM de «engarrafamento - engarrafamento à frente»

Campo de dados

Valor

Contentor de gestão

actionID

Identificador de uma DENM. Deve ser definido em conformidade com a norma [TS 102 894-2].

detectionTime

TimestampIts - selo temporal em que o evento é detetado pela estação STI-C de origem. Deve ser definido em conformidade com a norma [TS 102 894-2].

referenceTime

TimestampIts - selo temporal em que é gerada uma DENM nova. Deve ser definido em conformidade com a norma [TS 102 894-2].

terminação

Não deve ser definido, pois nem a negação nem o cancelamento devem ser utilizados neste serviço STI-C.

eventPosition

ReferencePosition. Deve ser definido em conformidade com a norma [TS 102 894-2].

relevanceDistance

lessThan1000m(4)

relevanceTrafficDirection

upstreamTraffic(1)

validityDuration

60 s (prevê-se que uma situação de engarrafamento dure pelo menos 60 s)

stationType

O tipo de estação STI-C de origem. Deve ser definido em conformidade com a norma [TS 102 894-2].

Contenção de situação

informationQuality

Ver ponto (26).

causeCode

trafficCondition(1)

subCauseCode

unavailable(0)

Contenção de localização

eventSpeed

Velocidade da estação STI-C de origem. Deve ser definido em conformidade com a norma [TS 102 8942].

eventPositionHeading

Rumo da estação STI-C de origem. Deve ser definido em conformidade com a norma [TS 102 8942].

traces

PathHistory da estação STI-C de origem. Deve ser definido em conformidade com a norma [TS 102 894-2].

roadType

RoadType da estrada em que a estação STI-C de deteção está situada.

Deve ser definido em conformidade com a norma [TS 102 894-2] em conjugação com as seguintes regras:

Urbano / não urbano

Separação estrutural

Elemento de dados

Urbano

Não

urbano-NoStructuralSeparation ToOppositeLanes(0)

Urbano

Sim

urbano-WithStructuralSeparation ToOppositeLanes(1)

Urbano

Desconhecido

urbano-NoStructuralSeparation ToOppositeLanes(0)

Não urbano

Não

nãoUrbano-NoStructuralSeparation ToOppositeLanes(2)

Não urbano

Sim

nãoUrbano-WithStructuralSeparation ToOppositeLanes(3)

Não urbano

Desconhecido

nãoUrbano-NoStructuralSeparation ToOppositeLanes(2)

Se não for possível determinar as informações sobre o estatuto urbano/não urbano, deve ser omitido o elemento de dados.

Contenção a la carte

lanePosition

Se a lanePosition for fornecida por um sensor de bordo (por exemplo, radar ou câmara), o valor deve ser definido de acordo com a norma [TS 102 894-2]. A utilização de um sistema GNSS e um mapa digital para estimar o número da faixa não é permitido para esta versão da condição de acionamento.

Se a lanePosition for desconhecida, o elemento de dados deve ser omitido.

4.7.2.CAM

(34)Não deve ser utilizada a CAM de adaptação para este serviço STI-C.

4.8.Rede e camada de transporte

(35)O parâmetro de interface DENM destination area entre o serviço básico DEN e a rede e a camada de transporte devem ser iguais a uma forma circular com raio igual à relevanceDistance.

4.9.Camada de segurança

(36)Se as condições de acionamento estiverem reunidas conforme descrito no ponto (22), qualquer alteração de CA será bloqueada para as novas DENM, desde que a validityDuration não tenha expirado. Devem ser enviadas novas DENM correspondentes com o mesmo CA.

5.Aviso de veículo imobilizado — veículo parado

5.1.Descrição do serviço STI-C

Este serviço STI-C transmite informações V2V sobre uma situação em que um veículo parou, sem informações específicas sobre o motivo.

Os seguintes serviços STI-C estão relacionados com este serviço, pois partilham condições de acionamento semelhantes:

·«aviso de veículo especial — aviso de serviço de pronto-socorro imobilizado»;

·«aviso de veículo imobilizado — veículo avariado»;

·«aviso de veículo imobilizado — pós-colisão».

(37)Deve ser enviado um sinal de DENM para a pilha apenas no caso de se considerarem reunidas as condições de acionamento descritas no presente ponto. Esse sinal induz a pilha a gerar uma DENM nova, de atualização ou de cancelamento. Se não estiverem reunidas as condições de acionamento, não deve ser gerado um sinal de DENM.

5.2.Condições de acionamento

5.2.1.Condições prévias

(38)Antes de um serviço STI-C ser acionado, devem estar reunidas as seguintes condições prévias:

(a)não é exibida no painel de instrumentos qualquer mensagem de aviso de avaria que impeça que o motorista continue a conduzir [por exemplo, símbolos de aviso vermelhos em conformidade com a norma (ECE 121)].

Nota: este serviço não é necessário para verificar o estado do terminal de ignição 15 para o acionamento (pode estar ativado ou desativado). A operação do serviço é facultativa quando o terminal de ignição 15 está desligado.

(39)Deve ser evitada a ativação paralela com os outros serviços STI-C relacionados. Nos casos em que os serviços STI-C «veículo avariado» e/ou «pós-colisão» são acionados em simultâneo, os serviços STI-C devem seguir a seguinte ordem de prioridades:

(a)«pós-colisão» (prioridade mais alta);

(b)«veículo avariado»;

(c)«veículo parado» (prioridade mais baixa).

5.2.2.Condições específicas do serviço

(40)Se estiverem reunidas as condições prévias indicadas no ponto (38) e todas as seguintes condições, consideram-se reunidas as condições de acionamento deste serviço STI-C e deve ser acionada a geração de uma DENM:

(a)o veículo ego ativou as luzes de perigo;

(b)o veículo encontra-se imobilizado;

(c)o Triggering Timer expirou.

(41)A velocidade do veículo deve ser determinada pelo sinal de barramento do veículo e não por um sistema GNSS. Deve ser utilizada a velocidade filtrada do veículo (no que se refere ao ruído do sensor). Este requisito deve ser aplicado a todas as subsequentes ocorrências da análise de velocidade do veículo.

(42)Se o veículo tiver ativado as luzes de perigo e estiver imobilizado, o Triggering Timer deve ser regulado para 30 s e iniciado. O Triggering Timer deve ser reduzido se ocorrerem seguintes situações:

(a)o temporizador deve ser reduzido em 10 s se a transmissão automática (AUT) estiver definida para «estacionar» durante pelo menos 3 s;

(b)o temporizador deve ser reduzido em 10 s se a caixa de velocidades estiver definida para marcha lenta sem carga durante pelo menos 3 s;

(c)o temporizador deve ser reduzido em 10 s se o travão de estacionamento estiver acionado durante pelo menos 3 s;

(d)o temporizador deve ser reduzido em 10 s se um número arbitrário de fivelas de cintos de segurança passar de «ligado» para «desligado» durante pelo menos 3 s;

(e)o temporizador deve ser regulado para 0 se um número arbitrário de portas estiver aberto durante pelo menos 3 s;

(f)o temporizador deve ser regulado para 0 se o terminal de ignição passar da posição «ligado» para «desligado» durante pelo menos 3 s;

(g)o temporizador deve ser regulado para 0 se o porta-bagagens estiver aberto durante pelo menos 3 s;

(h)o temporizador deve ser regulado para 0 se o capô estiver aberto durante pelo menos 3 s.

(43)Todos os procedimentos acima indicados para a redução do temporizador devem ser aplicados apenas uma vez durante a deteção inicial. Se o Triggering Timer tiver iniciado uma contagem decrescente até 0, não será necessária qualquer redução adicional no ciclo de deteção atual.

(44)Durante o tempo de funcionamento do Triggering Timer, as luzes de perigo devem estar ativadas e o veículo deve estar imobilizado. Caso contrário, a deteção deve ser cancelada.

5.2.3.Qualidade das informações

(45)O valor do elemento de dados informationQuality na DENM depende da forma como o evento é detetado (ver ponto (42)). O valor informationQuality deve ser definido de acordo com o seguinte quadro (deve ser utilizado o valor mais alto possível):

Quadro 7: Qualidade das informações de «veículo imobilizado — veículo parado»

Deteção de evento

Valor da informationQuality

Sem implementação em conformidade com as TRCO

desconhecido(0)

Não está reunida nenhuma das condições a) a h).

1

Está reunida pelo menos uma condição de a) a d).

2

Está reunida pelo menos uma condição de e) a h).

3

(46)Se as condições de acionamento se alterarem entre duas atualizações, a informationQualitynão deve ser alterada até à próxima atualização. Se as condições alteradas ainda estiverem reunidas enquanto a DENM é atualizada, a informationQuality deve ser atualizada. Na fase de atualização, apenas devem ser avaliadas as condições que levariam a uma redução do temporizador, mas não o próprio temporizador.

5.3.Condições de terminação

(47)Este serviço STI-C é terminado através do cancelamento da estação STI-C de origem. Aquando da terminação do serviço STI-C, o pedido de atualização da DENM deve ser terminado.

5.3.1.Cancelamento

(48)Se pelo menos uma das seguintes condições estiver reunida antes de o período definido no elemento de dados validityDuration expirar, deve ser acionada a geração de uma DENM de cancelamento:

(a)o veículo já não está imobilizado por um período de 5 s;

(b)as luzes de perigo estão desativadas;

(c)a posição do veículo alterou-se em mais de 500 m (por exemplo, porque o veículo foi rebocado).

Nota: a condição de cancelamento não implica que a estação STI-C necessite de estar permanentemente operacional ou de estender a sua operação durante essa condição de cancelamento.

5.3.2.Negação

(49)Não deve ser utilizada uma DENM de negação para este serviço STI-C.

5.4.Atualização

(50)Se a DENM anteriormente acionada para um Stopped Vehicle detetado não foi cancelada, deve ser acionada a geração de uma DENM de atualização a cada 15 s.

(51)Na fase de atualização, apenas devem ser verificadas as condições de acionamento (não deve ser efetuada uma avaliação adicional dos temporizadores).

(52)Devem ser atribuídos novos valores a campos ou elementos de dados na DENM de acordo com o evento alterado (por exemplo, detectionTime ou informationQuality).

Nota: a condição de atualização não implica que a estação STI-C necessite de estar permanentemente operacional ou de estender a sua operação durante essa condição de atualização.

5.5.Duração de repetição e intervalo de repetição

(53)As DENM novas que foram atualizadas ou canceladas devem ser repetidas para uma repetitionDuration de 15 s com um repetitionInterval de 1 s. Consequentemente, os parâmetros de interface repetitionDuration e repetitionInterval entre a aplicação e o serviço básico de DEN devem ser definidos de acordo com os valores acima.

Nota: a validityDuration está regulada para 30 s. Desta forma, é possível evitar uma lacuna de DENM se a repetitionDuration da DENM original tiver expirado e a atualização ainda não tiver sido recebida.

Nota: Quando duas DENM com o mesmo causeCode provêm da mesma estação STI-C, o caso deve ser gerido pela estação STI-C recetora.

5.6.Classe de tráfego

(54)Devem ser definidas DENM novas, de atualização e de cancelamento para a traffic class 1.

5.7.Parâmetros de mensagem

5.7.1.DENM

(55)O quadro a seguir especifica os elementos de dados de DENM que devem ser definidos.

Quadro 8: Elementos de dados de DENM de «aviso de veículo imobilizado — veículo parado»

Campo de dados

Valor

Contentor de gestão

actionID

Identificador de uma DENM. Deve ser definido em conformidade com a norma [TS 102 894-2].

detectionTime

TimestampIts - selo temporal em que o evento é detetado pela estação STI-C de origem. Deve ser definido em conformidade com a norma [TS 102 894-2].

Deve ser renovado para uma DENM de atualização.

referenceTime

TimestampIts - selo temporal em que é gerada uma DENM nova, de atualização ou de cancelamento. Deve ser definido em conformidade com a norma [TS 102 894-2].

terminação

Não deve ser definido no caso de DENM novas ou de atualização. Deve ser definido como isCancellation(0) no caso de uma DENM de cancelamento.

eventPosition

ReferencePosition. Deve ser definido em conformidade com a norma [TS 102 894-2].

Deve ser renovado para uma DENM de atualização.

relevanceDistance

lessThan1000m(4)

relevanceTrafficDirection

Se o roadType for conhecido, o valor deve ser definido da seguinte forma:

roadType

Sentido

 

0

allTrafficDirections(0)

 

1

upstreamTraffic(1)

 

2

allTrafficDirections(0)

 

3

upstreamTraffic(1)

 

Caso contrário, o valor deve ser definido para allTrafficDirections(0)

validityDuration

30 s

stationType

O tipo de estação STI-C de origem. Deve ser definido em conformidade com a norma [TS 102 894-2].

Contenção de situação

informationQuality

Ver ponto (45). Deve ser renovado a cada DENM de atualização.

causeCode

stationaryVehicle(94)

subCauseCode

unavailable(0)

Contenção de localização

eventSpeed

Velocidade da estação STI-C de origem. Deve ser definido em conformidade com a norma [TS 102 8942].

Deve ser renovado para uma DENM de atualização.

eventPositionHeading

Rumo da estação STI-C de origem. Deve ser definido em conformidade com a norma [TS 102 894-2].

Deve ser renovado para uma DENM de atualização.

traces

PathHistory da estação STI-C de origem. Deve ser definido em conformidade com a norma [TS 102 894-2].

roadType

RoadType da estrada em que a estação STI-C de deteção está situada.

Deve ser renovado para uma DENM de atualização.

Deve ser definido em conformidade com a norma [TS 102 894-2] em conjugação com as seguintes regras:

Urbano / não urbano

Separação estrutural

Elemento de dados

Urbano

Não

urbano-NoStructuralSeparation ToOppositeLanes(0)

Urbano

Sim

urbano-WithStructuralSeparation ToOppositeLanes(1)

Urbano

Desconhecido

urbano-NoStructuralSeparation ToOppositeLanes(0)

Não urbano

Não

nãoUrbano-NoStructuralSeparation ToOppositeLanes(2)

Não urbano

Sim

nãoUrbano-WithStructuralSeparation ToOppositeLanes(3)

Não urbano

Desconhecido

nãoUrbano-NoStructuralSeparation ToOppositeLanes(2)

Se não for possível determinar as informações sobre o estatuto urbano/não urbano, deve ser omitido o elemento de dados.

Contenção a la carte

lanePosition

Se a lanePosition for fornecida por um sensor de bordo (por exemplo, radar ou câmara), o valor deve ser definido de acordo com a norma [TS 102 894-2]. A utilização de um sistema GNSS e um mapa digital para estimar o número da faixa não é permitido para esta versão da condição de acionamento.

Se a lanePosition for desconhecida, o elemento de dados deve ser omitido.

Deve ser renovado para uma DENM de atualização.

Contenção a la carte: StationaryVehicleContainer

stationarySince

Deve ser definido de acordo com a duração em minutos da estação STI-C de deteção em estado imobilizado. Deve ser definido em conformidade com a norma [TS 102 894-2].

Deve ser renovado para uma DENM de atualização.

5.7.2.CAM

(56)Não deve ser utilizada a CAM de adaptação para este serviço STI-C.

5.8.Rede e camada de transporte

(57)O parâmetro de interface DENM destination area entre o serviço básico DEN e a rede e a camada de transporte devem ser iguais a uma forma circular com raio igual à relevanceDistance.

5.9.Camada de segurança

(58)No caso de se aplicarem as condições de acionamento conforme descrito no ponto (40), será bloqueada uma alteração de CA para DENM novas, de atualização e de cancelamento, desde que a validityDuration não tenha expirado. Devem ser enviadas DENM novas, de atualização e de cancelamento correspondentes com o mesmo CA.

6.Aviso de veículo imobilizado — veículo avariado

6.1.Descrição do serviço STI-C

Este serviço STI-C transmite informações V2V sobre um veículo avariado. Embora possam existir vários motivos para a avaria de um veículo, como furos nos pneus, a falta de combustível ou uma falha no motor, o presente ponto centra-se nos motivos indicados pelas mensagens de aviso de avaria no painel de instrumentos.

Os seguintes serviços STI-C estão relacionados com este serviço, pois partilham condições de acionamento semelhantes:

·«aviso de veículo especial — aviso de serviço de pronto-socorro imobilizado»;

·«aviso de veículo imobilizado — veículo parado»;

·«aviso de veículo imobilizado — pós-colisão».

(59)Apenas deve ser enviado um sinal de DENM para a pilha se as condições de acionamento descritas no presente ponto forem consideradas válidas. Esse sinal induz a pilha a gerar uma DENM nova, de atualização ou de cancelamento. Se não estiverem reunidas as condições de acionamento, não deve ser gerado um sinal de DENM.

6.2.Condições de acionamento

6.2.1.Condições prévias

(60)Antes de um serviço STI-C ser acionado, deve estar reunida a seguinte condição prévia:

(a)uma mensagem de aviso de avaria que impede que o condutor continue a conduzir [por exemplo, símbolos de aviso vermelhos, nos termos da norma (ECE 121)] é exibida no painel de instrumentos.

Nota: este serviço não é necessário para verificar o estado do terminal de ignição 15 para o acionamento (pode estar ativado ou desativado). A operação do serviço é facultativa quando o terminal de ignição 15 está desligado.

(61)Deve ser evitada a ativação paralela com os outros serviços STI-C relacionados. Nos casos em que os serviços STI-C «veículo parado» e/ou «pós-colisão» são acionados em simultâneo, os serviços STI-C devem seguir a seguinte ordem de prioridades:

(a)«pós-colisão» (prioridade mais alta);

(b)«veículo avariado»;

(c)«veículo parado» (prioridade mais baixa).

6.2.2.Condições específicas do serviço

(62)Se estiver reunida a condição prévia indicada no ponto (60) e todas as seguintes condições, consideram-se reunidas as condições de acionamento deste serviço STI-C e deve ser acionada a geração de uma DENM:

(a)o veículo ego ativou as luzes de perigo;

(b)o veículo encontra-se imobilizado;

(c)o Triggering Timer expirou.

(63)A velocidade do veículo deve ser determinada pelo sinal de barramento do veículo e não por um sistema GNSS. Deve ser utilizada a velocidade filtrada do veículo (no que se refere ao ruído do sensor). Este requisito deve ser aplicado a todas as subsequentes ocorrências da análise de velocidade do veículo.

(64)Se o veículo tiver ativado as luzes de perigo e estiver imobilizado, o Triggering Timer deve ser regulado para 30 s e iniciado. O Temporizador de Acionamento deve ser reduzido se ocorrerem seguintes situações:

(a)o temporizador deve ser reduzido em 10 s se a transmissão automática (AUT) estiver definida para «estacionar» durante pelo menos 3 s;

(b)o temporizador deve ser reduzido em 10 s se a caixa de velocidades estiver definida para marcha lenta sem carga durante pelo menos 3 s;

(c)o temporizador deve ser reduzido em 10 s se o travão de estacionamento estiver acionado durante pelo menos 3 s;

(d)o temporizador deve ser reduzido em 10 s se um número arbitrário de fivelas dos cintos de segurança passar de «ligado» para «desligado» durante pelo menos 3 s;

(e)o temporizador deve ser regulado para 0 se um número arbitrário de portas estiver aberto durante pelo menos 3 s;

(f)o temporizador deve ser regulado para 0 se o terminal de ignição passar da posição «ligado» para «desligado» durante pelo menos 3 s;

(g)o temporizador deve ser regulado para 0 se o porta-bagagens estiver aberto durante pelo menos 3 s;

(h)o temporizador deve ser regulado para 0 se o capô estiver aberto durante pelo menos 3 s.

(65)Todos os procedimentos acima indicados para a redução do temporizador devem ser aplicados apenas uma vez durante a deteção inicial. Se o Triggering Timer tiver iniciado uma contagem decrescente até 0, não será necessária qualquer redução adicional no ciclo de deteção atual.

(66)Durante o tempo de funcionamento do Triggering Timer, as luzes de perigo devem estar ativadas e o veículo deve estar sempre imobilizado. Caso contrário, a deteção deve ser cancelada.

6.2.3.Qualidade das informações

(67)O valor do elemento de dados informationQuality na DENM depende da forma como o evento é detetado (ver ponto (64)). O valor informationQuality deve ser definido de acordo com o seguinte quadro (deve ser utilizado o valor mais alto possível):

Quadro 9: Qualidade das informações de «veículo imobilizado — veículo avariado»

Deteção de evento

Valor da informationQuality

Sem implementação em conformidade com as TRCO

desconhecido(0)

Não está reunida nenhuma das condições a) a h).

1

Está reunida pelo menos uma condição de a) a d).

2

Está reunida pelo menos uma condição de e) a h).

3

(68)Se as condições de acionamento se alterarem entre duas atualizações, a informationQualitynão deve ser alterada até à próxima atualização. Se as condições alteradas ainda estiverem reunidas enquanto a DENM é atualizada, a informationQuality deve ser atualizada. Na fase de atualização, apenas devem ser avaliadas as condições que levariam a uma redução do temporizador, mas não o próprio temporizador.

6.3.Condições de terminação

(69)Este serviço STI-C é terminado através do cancelamento da estação STI-C de origem. Aquando da terminação do serviço STI-C, o pedido de atualização da DENM deve ser terminado.

6.3.1.Cancelamento

(70)Se pelo menos uma das seguintes condições estiver reunida antes de o período definido no elemento de dados validityDuration expirar, deve ser acionada a geração de uma DENM de cancelamento:

(a)o veículo já não está imobilizado por um período de 5 s;

(b)as luzes de perigo estão desativadas;

(c)a posição do veículo alterou-se em mais de 500 m (por exemplo, porque o veículo foi rebocado).

Nota: a condição de cancelamento não implica que a estação STI-C necessite de estar permanentemente operacional ou de estender a sua operação durante essa condição de cancelamento.

6.3.2.Negação

(71)Não deve ser utilizada uma DENM de negação para este serviço STI-C.

6.4.Atualização

(72)Se a DENM anteriormente acionada para um Broken-down Vehicle detetado não foi cancelada, deve ser acionada a geração de uma DENM de atualização a cada 15 s.

(73)Na fase de atualização, apenas devem ser verificadas as condições de acionamento (não deve haver uma avaliação adicional dos temporizadores).

(74)Se o terminal de ignição 15 passar da posição «ligado» para «desligado», deve ser acionada uma DENM de atualização de imediato.

(75)Devem ser atribuídos novos valores a campos ou elementos de dados na DENM de acordo com o evento alterado (por exemplo, detectionTime ou informationQuality).

Nota: a condição de atualização não implica que a estação STI-C necessite de estar permanentemente operacional ou de estender a sua operação durante essa condição de atualização.

6.5.Duração de repetição e intervalo de repetição

(76)As DENM novas que foram atualizadas ou canceladas devem ser repetidas para uma repetitionDuration de 15 s com um repetitionInterval de 1 s. Consequentemente, os parâmetros de interface Repetition duration e Repetition interval entre a aplicação e o serviço básico de DEN devem ser definidos de acordo com os valores acima.

(77)Em caso de ativação do terminal de ignição 15, a validityDuration deve ser regulada para 30 s. Desta forma, é possível evitar uma lacuna de DENM se a repetitionDuration da DENM original tiver expirado e a atualização ainda não tiver sido recebida.

Nota: a validityDuration é definida para um valor mais alto no caso de um terminal de ignição 15 desativado do que no caso de um terminal de ignição15 ativado. Tal deve-se ao facto de não poder ser acionada uma DENM de atualização, deixando de poder ser enviada. Por esse motivo, a última DENM deve ser mantida ativa por mais tempo.

Nota: quando duas DENM com o mesmo causeCode provêm da mesma estação STI-C, o caso deve ser gerido pela estação STI-C recetora.

6.6.Classe de tráfego

(78)Devem ser definidas DENM novas, de atualização e de cancelamento para a traffic class 1.

6.7.Parâmetros de mensagem

6.7.1.DENM

(79)O quadro a seguir especifica os elementos de dados de DENM que devem ser definidos.

Quadro 10: Elementos de dados de DENM de «aviso de veículo imobilizado — veículo avariado»

Campo de dados

Valor

Contentor de gestão

actionID

Identificador de uma DENM. Deve ser definido em conformidade com a norma [TS 102 894-2].

detectionTime

TimestampIts- selo temporal em que o evento é detetado pela estação STI-C de origem. Deve ser definido em conformidade com a norma [TS 102 894-2].

Deve ser renovado para uma DENM de atualização.

referenceTime

TimestampIts - selo temporal em que é gerada uma DENM nova, de atualização ou de cancelamento. Deve ser definido em conformidade com a norma [TS 102 894-2].

terminação

Não deve ser definido no caso de uma DENM nova ou de atualização. Deve ser definido como cancelamentoSI (0) no caso de uma DENM de cancelamento.

eventPosition

ReferencePosition. Deve ser definido em conformidade com a norma [TS 102 894-2].

Deve ser renovado para uma DENM de atualização.

relevanceDistance

menosDe1000m(4)

relevanceTrafficDirection

Se o roadType for conhecido, o valor deve ser definido da seguinte forma:

roadType

Sentido

 

0

allTrafficDirections(0)

 

1

upstreamTraffic(1)

 

2

allTrafficDirections(0)

 

3

upstreamTraffic(1)

 

Caso contrário, o valor deve ser definido para allTrafficDirections(0)

validityDuration

·Terminal de ignição 15 ativado: 30 s

·Terminal de ignição 15 desativado: 900 s

stationType

O tipo de estação STI-C de origem. Deve ser definido em conformidade com a norma [TS 102 894-2].

Contenção de situação

informationQuality

Ver ponto (67). Deve ser renovado a cada DENM de atualização.

causeCode

stationaryVehicle(94)

subCauseCode

vehicleBreakdown(2)

Contenção de localização

eventSpeed

Velocidade da estação STI-C de origem. Deve ser definido em conformidade com a norma [TS 102 8942].

Deve ser renovado para uma DENM de atualização.

eventPositionHeading

Rumo da estação STI-C de origem. Deve ser definido em conformidade com a norma [TS 102 894-2].

Deve ser renovado para uma DENM de atualização.

traces

PathHistory da estação STI-C de origem. Deve ser definido em conformidade com a norma [TS 102 894-2].

roadType

RoadType da estrada em que a estação STI-C de deteção está situada.

Deve ser renovado para uma DENM de atualização.

Deve ser definido em conformidade com a norma [TS 102 894-2] em conjugação com as seguintes regras:

Urbano / não urbano

Separação estrutural

Elemento de dados

Urbano

Não

urbano-NoStructuralSeparation ToOppositeLanes(0)

Urbano

Sim

urbano-WithStructuralSeparation ToOppositeLanes(1)

Urbano

Desconhecido

urbano-NoStructuralSeparation ToOppositeLanes(0)

Não urbano

Não

nonUrban-NoStructuralSeparation ToOppositeLanes(2)

Não urbano

Sim

nonUrban-WithStructuralSeparation ToOppositeLanes(3)

Não urbano

Desconhecido

nonUrban-NoStructuralSeparation ToOppositeLanes(2)

Se não for possível determinar as informações sobre o estatuto urbano/não urbano, deve ser omitido o elemento de dados.

Contenção a la carte

lanePosition

Se a lanePosition for fornecida por um sensor de bordo (por exemplo, radar ou câmara), o valor deve ser definido de acordo com a norma [TS 102 894-2]. A utilização de um sistema GNSS e um mapa digital para estimar o número da faixa não é permitido para esta versão da condição de acionamento.

Se a lanePosition for desconhecida, o elemento de dados deve ser omitido.

Deve ser renovado para uma DENM de atualização.

Contenção a la carte: StationaryVehicleContainer

stationarySince

Deve ser definido de acordo com a duração em minutos da estação STI-C de deteção em estado imobilizado. Deve ser definido em conformidade com a norma [TS 102 894-2].

Deve ser renovado para uma DENM de atualização.

6.7.2.CAM

(80)Não deve ser utilizada a CAM de adaptação para este serviço STI-C.

6.8.Rede e camada de transporte

(81)O parâmetro de interface DENM destination area entre o serviço básico DEN e a rede e a camada de transporte devem ser iguais a uma forma circular com raio igual à relevanceDistance.

6.9.Camada de segurança

(82)No caso de se aplicarem as condições de acionamento conforme descrito no ponto (62), será bloqueada uma alteração de CA para DENM novas, de atualização e de cancelamento, desde que a validityDuration não tenha expirado. Devem ser enviadas DENM novas, de atualização e de cancelamento correspondentes com o mesmo CA.

7.Aviso de veículo imobilizado — pós-colisão

7.1.Descrição do serviço STI-C

Este serviço STI-C transmite informações V2V sobre um veículo imobilizado na sequência de um acidente rodoviário.

Os seguintes serviços STI-C estão relacionados com este serviço, pois partilham condições de acionamento semelhantes:

   «aviso de veículo imobilizado — veículo parado»;

   «aviso de veículo imobilizado — veículo avariado».

(83)Apenas deve ser enviado um sinal de DENM para a pilha se as condições de acionamento descritas no presente ponto forem consideradas válidas. Esse sinal induz a pilha a gerar uma DENM nova, de atualização ou de cancelamento. Se não estiverem reunidas as condições de acionamento, não deve ser gerado um sinal de DENM.

7.2.Condições de acionamento

7.2.1.Condições prévias

(84)Não se aplicam condições prévias específicas a este serviço STI-C.

(85)Deve ser evitada a ativação paralela com os outros serviços STI-C relacionados. Nos casos em que os serviços STI-C de «veículo parado» e/ou «veículo avariado» são acionados em simultâneo, os serviços STI-C devem seguir a seguinte ordem de prioridades:

(a)«pós-colisão» (prioridade mais alta);

(b)«veículo avariado»;

(c)«veículo parado» (prioridade mais baixa).

7.2.2.Condições específicas do serviço

(86)Se estiverem reunidas as condições prévias indicadas no ponto (84) e, pelo menos, uma das seguintes condições, consideram-se reunidas as condições de acionamento deste serviço STI-C e deve ser acionada a geração de uma DENM:

(a)foi manualmente acionada uma eCall por um ocupante do veículo através do botão de eCall e o veículo fica imobilizado dentro de 15 s. Se o veículo já estiver imobilizado, a condição é satisfeita de imediato;

(b)é detetada uma colisão de pouca gravidade sem a ativação de um sistema irreversível de retenção de ocupantes (por exemplo, corte de bateria de alta tensão, porta destrancada) e o veículo fica imobilizado dentro de 15 s. Se o veículo já estiver imobilizado, a condição é satisfeita de imediato;

(c)é detetada uma colisão com um peão com ativação de pelo menos um sistema irreversível de proteção de peões (por exemplo, capô de acionamento automático, airbag exterior) e o veículo é imobilizado dentro de 15 s. Se o veículo já tiver sido imobilizado, a condição é satisfeita de imediato;

(d)é detetada uma colisão grave com a ativação de pelo menos um sistema irreversível de retenção de ocupantes (por exemplo, tensor pirotécnico de cintos de segurança, airbag).

(87)A velocidade do veículo deve ser determinada pelo sinal de barramento do veículo e não por um sistema GNSS. Deve ser utilizada a velocidade filtrada do veículo (no que se refere ao ruído do sensor). Este requisito deve ser aplicado a todas as subsequentes ocorrências da análise de velocidade do veículo.

Nota: apenas é necessário verificar as condições na presença da fonte de alimentação necessária. Desta forma, não é necessária a implementação do sistema com proteção contra colisões.

7.2.3.Qualidade das informações

(88)O valor do elemento de dados informationQuality na DENM depende da forma como o evento é detetado (ver ponto (86)). O valor informationQuality deve ser definido de acordo com o seguinte quadro (deve ser utilizado o valor mais alto possível):

Quadro 11: Qualidade das informações de «veículo imobilizado — pós-colisão»

Deteção de evento

Valor da informationQuality

Sem implementação em conformidade com as TRCO

desconhecido(0)

A condição a) está reunida.

1

A condição b) ou c) está reunida.

2

A condição d) está reunida.

3

(89)Se as condições de acionamento se alterarem entre duas atualizações, a informationQualitynão deve ser alterada até à próxima atualização. Se as condições alteradas ainda estiverem reunidas enquanto a DENM é atualizada, a informationQuality deve ser atualizada.

7.3.Condições de terminação

(90)Este serviço STI-C é terminado através do cancelamento da estação STI-C de origem. Aquando da terminação do serviço STI-C, o pedido de atualização da DENM deve ser terminado.

7.3.1.Cancelamento

(91)Quando pelo menos uma das seguintes condições estiver reunida antes de o período definido no elemento de dados validityDuration expirar, deve ser acionada a geração de uma DENM de cancelamento:

(a)o veículo ego não está imobilizado por um período de 15 s;

(b)a posição do veículo alterou-se em mais de 500 m (por exemplo, porque o veículo foi rebocado).

Nota: a condição de cancelamento não implica que a estação STI-C necessite de estar permanentemente operacional ou de estender a sua operação durante essa condição de cancelamento.

7.3.2.Negação

(92)Não deve ser utilizada uma DENM de negação para este serviço STI-C.

7.4.Atualização

(93)Deve ser acionada uma DENM de atualização a cada 60 s se o serviço STI-C não tiver sido cancelado.

(94)Se o terminal de ignição 15 passar da posição «ligado» para «desligado», deve ser acionada uma DENM de atualização de imediato.

(95)Devem ser atribuídos novos valores a campos ou elementos de dados na DENM de acordo com o evento alterado (por exemplo, detectionTime ou informationQuality).

Nota: a condição de atualização não implica que a estação STI-C necessite de estar permanentemente operacional ou de estender a sua operação durante essa condição de atualização.

7.5.Duração de repetição e intervalo de repetição

(96)As DENM novas que foram atualizadas ou canceladas devem ser repetidas para uma Repetition duration de 60 s com um repetitionInterval de 1 s. Consequentemente, os parâmetros de interface Repetition duration e repetitionInterval entre a aplicação e o serviço básico de DEN devem ser definidos de acordo com os valores acima.

(97)Em caso de ativação do terminal de ignição 15, a validityDuration deve ser regulada para 180 s. Desta forma, é possível evitar uma lacuna de DENM se a Repetition duration da DENM original tiver expirado e a atualização ainda não tiver sido recebida.

Nota: a validityDuration é definida para um valor mais alto no caso de um terminal de ignição 15 desativado do que no caso de um terminal de ignição15 ativado. Tal deve-se ao facto de não poder ser acionada uma DENM de atualização, deixando de poder ser enviada. Por esse motivo, a última DENM deve ser mantida ativa por mais tempo.

Nota: Quando duas DENM com o mesmo causeCode provêm da mesma estação STI-C, o caso deve ser gerido pela estação STI-C recetora.

7.6.Classe de tráfego

(98)Devem ser definidas DENM novas, de atualização e de cancelamento para a traffic class 1.

7.7.Parâmetros de mensagem

7.7.1.DENM

(99)O quadro a seguir especifica os elementos de dados de DENM que devem ser definidos.

Quadro 12: Elementos de dados de DENM de «Aviso de Veículo Imobilizado — Pós-Colisão»

Campo de dados

Valor

Contenção de gestão

actionID

Identificador de uma DENM. Deve ser definido em conformidade com a norma [TS 102 894-2].

detectionTime

TimestampIts- em que o evento é detetado pela estação STI-C de origem. Deve ser definido em conformidade com a norma [TS 102 894-2].

Deve ser renovado para uma DENM de atualização.

referenceTime

TimestampIts - timestamp em que é gerada uma DENM nova, de atualização ou de cancelamento. Deve ser definido em conformidade com a norma [TS 102 894-2].

terminação

Não deve ser definido no caso de DENM novas ou de atualização. Deve ser definido como isCancellation(0) no caso de uma DENM de cancelamento.

eventPosition

. Deve ser definido em conformidade com a norma [TS 102 894-2].

Deve ser renovado para uma DENM de atualização.

relevanceDistance

lessThan5km(5)

relevanceTrafficDirection

Se o roadType for conhecido, o valor deve ser definido da seguinte forma:

RoadType

Sentido

 

0

allTrafficDirections(0)

 

1

upstreamTraffic(1)

 

2

allTrafficDirections(0)

 

3

upstreamTraffic(1)

 

Caso contrário, o valor deve ser definido para allTrafficDirections(0)

validityDuration

·Terminal de ignição 15 ativado: 180 s

·Terminal de ignição 15 desativado: 1 800 s

stationType

O tipo de estação STI-C de origem. Deve ser definido em conformidade com a norma [TS 102 894-2].

Contenção de situação

informationQuality

Ver ponto (88). Deve ser renovado a cada DENM de atualização.

causeCode

stationaryVehicle(94)

subCauseCode

postCrash(3)

Contenção de localização

eventSpeed

Velocidade da estação STI-C de origem. Deve ser definido em conformidade com a norma [TS 102 8942].

Deve ser renovado para uma DENM de atualização.

eventPositionHeading

Rumo da estação STI-C de origem. Deve ser definido em conformidade com a norma [TS 102 894-2].

Deve ser renovado para uma DENM de atualização.

traces

PathHistory da estação STI-C de origem. Deve ser definido em conformidade com a norma [TS 102 894-2].

roadType

RoadType da estrada em que a estação STI-C de deteção está situada.

Deve ser renovado para uma DENM de atualização.

Deve ser definido em conformidade com a norma [TS 102 894-2] em conjugação com as seguintes regras:

Urbano / não urbano

Separação estrutural

Elemento de dados

Urbano

Não

urbano-NoStructuralSeparation ToOppositeLanes(0)

Urbano

Sim

urbano-WithStructuralSeparation ToOppositeLanes(1)

Urbano

Desconhecido

urbano-NoStructuralSeparation ToOppositeLanes(0)

Não urbano

Não

nãoUrbano-NoStructuralSeparation ToOppositeLanes(2)

Não urbano

Sim

nãoUrbano-WithStructuralSeparation ToOppositeLanes(3)

Não urbano

Desconhecido

nãoUrbano-NoStructuralSeparation ToOppositeLanes(2)

Se não for possível determinar as informações sobre o estatuto urbano/não urbano, deve ser omitido o elemento de dados.

Contenção a la carte

lanePosition

Se a lanePosition for fornecida por um sensor de bordo (por exemplo, radar ou câmara), o valor deve ser definido de acordo com a norma [TS 102 894-2]. A utilização de um sistema GNSS e um mapa digital para estimar o número da faixa não é permitido para esta versão da condição de acionamento.

Se a lanePosition for desconhecida, o elemento de dados deve ser omitido.

Deve ser renovado para uma DENM de atualização.

Contenção a la carte: StationaryVehicleContainer

stationarySince

Deve ser definido de acordo com a duração em minutos da estação STI-C de deteção em estado imobilizado. Deve ser definido em conformidade com a norma [TS 102 894-2].

 

Deve ser renovado para uma DENM de atualização.

7.7.2.CAM

(100)Não deve ser utilizada a CAM de adaptação para este serviço STI-C.

7.8.Rede e camada de transporte

(101)O parâmetro de interface DENM destination area entre o serviço básico DEN e a rede e a camada de transporte devem ser iguais a uma forma circular com raio igual à relevanceDistance.

7.9.Camada de segurança

(102)No caso de se aplicarem as condições de acionamento conforme descrito no ponto (86), será bloqueada uma alteração de CA para DENM novas, de atualização e de cancelamento, desde que a validityDuration não tenha expirado. Devem ser enviadas DENM novas, de atualização e de cancelamento correspondentes com o mesmo CA.

8.Aviso de veículo especial — veículo de emergência em operação

8.1.Descrição do serviço STI-C

Este serviço STI-C transmite informações V2V sobre um veículo de emergência que se desloca para uma cena de operações, que é sinalizada pelo uso da barra de sinalização.

(103)Logo que o serviço STI-C é acionado, deve ser transmitida uma DENM pela estação STI-C rodoviária de emergência e partes dos campos de dados da CAM deverão ser definidas de acordo com o ponto 8.7.2.

Os seguintes serviços STI-C estão relacionados com este serviço, pois partilham condições de acionamento semelhantes:

·«aviso de veículo especial — veículo de salvaguarda de emergência imobilizado»;

·«aviso de veículo especial — aviso de serviço de pronto-socorro imobilizado»;

(104)O serviço STI-C predefinido para uma estação STI-C de um veículo de emergência é «veículo de emergência em operação». A mudança para o serviço STI-C de «veículo de salvaguarda de emergência imobilizado» só pode ser acionada nas condições estabelecidas no ponto 9.

8.2.Condições de acionamento

8.2.1.Condições prévias

(105)Antes de um serviço STI-C ser acionado, devem estar reunidas as seguintes condições prévias:

(a)o stationType é confirmado como um veículo especial [stationType de CAM é definido para specialVehicles(10)]. O serviço STI-C é reservado a veículos de emergência;

(b)as condições de acionamento relativas ao «veículo de salvaguarda de emergência imobilizado» não devem estar reunidas (ver ponto 9.2).

8.2.2.Condições específicas do serviço

(106)Se estiverem reunidas as condições prévias referidas no ponto (105) e as seguintes condições, deve ser acionada a geração de uma DENM:

(a)a barra de sinalização está em funcionamento.

(107)O nível de qualidade das informações pode ser melhorado pelas seguintes condições:

(b)a sirene está em funcionamento;

(c)o veículo não está imobilizado.

(108)A velocidade do veículo deve ser determinada pelo sinal de barramento do veículo e não por um sistema GNSS. Deve ser utilizada a velocidade filtrada do veículo (no que se refere ao ruído do sensor).

8.2.3.Qualidade das informações

(109)O valor do elemento de dados informationQuality na DENM depende da forma como o evento é detetado (ver pontos (106) e (107)). O valor informationQuality deve ser definido de acordo com o seguinte quadro (deve ser utilizado o valor mais alto possível):

Quadro 13: Qualidade das informações de «veículo de emergência em operação»

Deteção de evento

Valor da InformationQuality

Sem implementação em conformidade com as TRCO

desconhecido(0)

A condição a) está reunida.

1

As condições a) e b) estão reunidas.

2

As condições a) e c) estão reunidas.

3

As condições a), b) e c) estão reunidas.

4

(110)Se as condições de acionamento se alterarem entre duas atualizações, a informationQualitynão deve ser alterada até à próxima atualização. Se as condições alteradas ainda estiverem reunidas enquanto a DENM é atualizada, a informationQuality deve ser atualizada.

8.3.Condições de terminação

(111)O serviço STI-C deve terminar quando a barra de sinalização já não estiver em funcionamento. Aquando da terminação do serviço STI-C, devem ser terminadas as DENM de atualização. A vehicleRole deve ser definida para default(0) se a barra de sinalização já não estiver em funcionamento.

8.3.1.Cancelamento

(112)Não deve ser utilizada uma DENM de cancelamento para este serviço STI-C.

8.3.2.Negação

(113)Não deve ser utilizada uma DENM de negação para este serviço STI-C.

8.4.Atualização

(114)A DENM gerada deve ser atualizada a cada 250 ms se ainda estiverem reunidas as condições de acionamento. Os campos de dados que recebem novos valores são definidos no Quadro 14 abaixo.

8.5.Duração de repetição e intervalo de repetição

(115)Não deve ser utilizada uma DENM de repetição para este serviço STI-C.

8.6.Classe de tráfego

(116)Devem ser definidas DENM novas, de atualização e de cancelamento para a traffic class 1.

8.7.Parâmetros de mensagem

8.7.1.DENM

(117)O quadro a seguir especifica os elementos de dados de DENM que devem ser definidos.

Quadro 14: Elementos de dados de DENM de «veículo de emergência em operação»

Campo de dados

Valor

Contenção de gestão

actionID

Identificador de uma DENM. Deve ser definido em conformidade com a norma [TS 102 894-2].

detectionTime

TimestampIts - timestamp em que o evento é detetado pela estação STI-C de origem. Deve ser definido em conformidade com a norma [TS 102 894-2].

Deve ser renovado para uma DENM de atualização.

referenceTime

- timestamp em que é gerada uma DENM nova ou uma DENM de atualização. Deve ser definido em conformidade com a norma [TS 102 894-2].

terminação

Não deve ser definido, pois nem a negação nem o cancelamento devem ser utilizados neste serviço STI-C.

eventPosition

ReferencePosition. Deve ser definido em conformidade com a norma [TS 102 894-2].

Deve ser renovado para uma DENM de atualização.

relevanceDistance

lessThan1000m(4)

relevanceTrafficDirection

Se o roadType for conhecido, o valor deve ser definido da seguinte forma:

RoadType

Sentido

 

0

allTrafficDirections(0)

 

1

upstreamTraffic(1)

 

2

allTrafficDirections(0)

 

3

upstreamTraffic(1)

 

Caso contrário, o valor deve ser definido para allTrafficDirections(0)

validityDuration

2 s

stationType

specialVehicles(10)

Contenção de situação

informationQuality

Ver ponto (109). Deve ser renovado a cada DENM de atualização.

causeCode

emergencyVehicleApproaching (95)

subCauseCode

emergencyVehicleApproaching(1)

Contenção de localização

eventSpeed

Velocidade da estação STI-C de origem. Deve ser definido em conformidade com a norma [TS 102 8942].

Deve ser renovado para uma DENM de atualização.

eventPositionHeading

Rumo da estação STI-C de origem. Deve ser definido em conformidade com a norma [TS 102 894-2].

Deve ser renovado para uma DENM de atualização.

traces

PathHistory da estação STI-C de origem. Deve ser definido em conformidade com a norma [TS 102 894-2].

Deve ser renovado para uma DENM de atualização.

roadType

RoadType da estrada em que a estação STI-C de deteção está situada.

Deve ser renovado para uma DENM de atualização.

Deve ser definido em conformidade com a norma [TS 102 894-2] em conjugação com as seguintes regras:

Urbano / não urbano

Separação estrutural

Elemento de dados

Urbano

Não

urbano-NoStructuralSeparation ToOppositeLanes(0)

Urbano

Sim

urbano-WithStructuralSeparation ToOppositeLanes(1)

Urbano

Desconhecido

urbano-NoStructuralSeparation ToOppositeLanes(0)

Non-urban

Não

Non-urban-NoStructuralSeparation ToOppositeLanes(2)

Non-urban

Sim

Non-urban-WithStructuralSeparation ToOppositeLanes(3)

Non-urban

Desconhecido

Non-urban-NoStructuralSeparation ToOppositeLanes(2)

Se não for possível determinar as informações sobre o estatuto urbano/não urbano, deve ser omitido o elemento de dados.

Contenção a la carte

lanePosition

Se a lanePosition for fornecida por um sensor de bordo (por exemplo, radar ou câmara), o valor deve ser definido de acordo com a norma [TS 102 894-2]. Não é permitida a utilização de um sistema GNSS e de um mapa digital para estimar o número da faixa para esta versão da condição de acionamento.

Se a lanePosition for desconhecida, o elemento de dados deve ser omitido.

Deve ser renovado para uma DENM de atualização.

Contenção a la carte: StationaryVehicleContainer

stationarySince

Deve ser definido de acordo com a duração em minutos da estação STI-C de deteção em estado imobilizado. Deve ser definido em conformidade com a norma [TS 102 894-2].

 

Deve ser renovado para uma DENM de atualização.

8.7.2.CAM

(118)A vehicleRole deve ser iniciada numa configuração de «predefinição» [vehicleRole da CAM definida para default(0)]. Se pelo menos uma das condições de acionamento do ponto (106) estiver reunida, a vehicleRole deve ser definida para emergency(6).

(119)O quadro a seguir especifica os elementos de dados da DENM que devem ser definidos se o serviço STI-C for acionado.

Quadro 15: Elementos de dados de CAM de «veículo de emergência em operação»

Campo de dados

Valor

CoopAwareness

generationDeltaTime

Tempo correspondente ao tempo da posição de referência na CAM, considerado como tempo da CAM de geração.

Deve ser definido em conformidade com a norma [EN 302 637-2].

BasicContainer

stationType

specialVehicles(10)

referencePosition

Posição e precisão da posição medidas no ponto de referência da estação STIC de origem.

Deve ser definido em conformidade com a norma [TS 102 894-2].

O HighFrequencyContainer deve ser definido para BasicVehicleContainerHighFrequency

rumo

O rumo da estação STI-C de origem em relação ao norte geográfico.

Deve ser definido em conformidade com a norma [TS 102 894-2].

velocidade

Velocidade de condução da estação STI-C de origem.

Deve ser definido em conformidade com a norma [TS 102 894-2].

driveDirection

O sentido de marcha do veículo (para a frente ou para trás) da estação STI-C de origem.

Deve ser definido em conformidade com a norma [TS 102 894-2].

vehicleLength

O comprimento do veículo.

Deve ser definido em conformidade com a norma [TS 102 894-2].

vehicleWidth

A largura do veículo.

Deve ser definido em conformidade com a norma [TS 102 894-2].

longitudinalAcceleration

Aceleração longitudinal da estação STI-C de origem.

Deve ser definido em conformidade com a norma [TS 102 894-2].

curvatura

Curvatura da trajetória do veículo e de precisão

Deve ser definido em conformidade com a norma [TS 102 894-2].

curvatureCalcMode

Descreve se o valor da velocidade de guinada é utilizado para calcular a curvatura de um valor de curvatura comunicado.

Deve ser definido em conformidade com a norma [TS 102 894-2].

yawRate

A velocidade de guinada de um veículo num dado ponto no tempo.

Deve ser definida em conformidade com a norma [TS 102 894-2].

LowFrequencyContainer deve ser definido para BasicVehicleContainerLowFrequency

vehicleRole

emergência(6)

exteriorLights

Descreve o estado dos interruptores de luz exterior de um veículo.

Deve ser definido em conformidade com a norma [TS 102 894-2].

pathHistory

Representa o movimento do veículo ao longo de um período recente e/ou distância.

Deve ser definido em conformidade com a norma [TS 102 894-2].

SpecialVehicleContainer deve ser definido para EmergencyContainer

lightBarSirenInUse

o bit lightBarActivated deve ser regulado para 1(onChange) se for detetada a utilização da barra de sinalização; caso contrário, deve ser regulado para 0.

o bit sirenActivated deve ser regulado para 1, se for detetada a utilização da sirene; caso contrário, deve ser regulado para 0.

emergencyPriority

Não exigido.

causeCode

Conforme especificado no ponto (117)

subCauseCode

Conforme especificado no ponto (117)

8.8.Rede e camada de transporte

(120)O parâmetro de interface DENM destination area entre o serviço básico DEN e a rede e a camada de transporte devem ser iguais a uma forma circular com raio igual à relevanceDistance.

8.9.Camada de segurança

(121)No caso de se aplicarem as condições de acionamento conforme descrito no ponto (106), será bloqueada uma alteração de CA para DENM novas e de atualização, desde que a validityDuration não tenha expirado. Devem ser enviadas DENM novas e de atualização correspondentes com o mesmo CA.

9.Aviso de veículo especial — veículo de salvaguarda de emergência imobilizado

9.1.Descrição do serviço STI-C

Este serviço STI-C transmite informações V2V sobre um veículo de salvaguarda de emergência imobilizado a proteger uma área de risco.

(122)Logo que o serviço STI-C é acionado, deve ser transmitida uma DENM pela estação STI-C rodoviária de emergência e partes dos campos de dados da CAM deverão ser definidas de acordo com o ponto 9.7.2.

Os seguintes serviços STI-C estão relacionados com este serviço, pois partilham condições de acionamento semelhantes:

·«aviso de veículo especial — veículo de emergência em operação»;

·«aviso de veículo especial — aviso de serviço de pronto-socorro imobilizado»;

9.2.Condições de acionamento

9.2.1.Condições prévias

(123)Antes de um serviço STI-C ser acionado, devem estar reunidas as seguintes condições prévias:

·o stationType é confirmado como um veículo de emergência [stationType de CAM é definido para specialVehicles(10)]. O serviço STI-C é reservado a veículos de emergência;

·o Standstill Timer deve ser iniciado no zero.

(124)O serviço STI-C predefinido para uma estação STI-C de um veículo de emergência é «veículo de emergência em operação». A mudança para o serviço STI-C de «veículo de salvaguarda de emergência imobilizado» só pode ser acionada nas condições estabelecidas no ponto 9.2.2.

9.2.2.Condições específicas do serviço

(125)Se o veículo estiver imobilizado e a barra de luz estiver em funcionamento, deve ser regulado para zero e iniciado umStandstill Timer. Se a barra de sinalização já não estiver em funcionamento ou o veículo já não estiver imobilizado, o Standstill Timerdeverá ser interrompido e reposto a zero.

(126)Se estiverem reunidas as condições prévias indicadas no ponto (123) e, pelo menos, uma das seguintes condições, consideram-se reunidas as condições de acionamento deste serviço STI-C e deve ser acionada a geração de uma DENM:

(a)a barra de sinalização está em funcionamento e o relé do motor está ativado;

(b)a barra de sinalização está em funcionamento, as luzes de perigo estão ativadas e o travão de estacionamento está ativado ou (em caso de transmissão automática) o «estacionamento» está selecionado;

(c)a barra de sinalização está em funcionamento, as luzes de perigo estão ativadas e o Standstill Timer é de 60 s ou mais.

(127)O nível de qualidade das informações pode ser melhorado pelas seguintes condições:

(d)o estado de pelo menos uma porta, ou do porta-bagagens, é «aberto»;

(e)o banco do condutor é detetado, por uma das seguintes técnicas, como «não ocupado»:

(1)câmara no habitáculo;

(2)utilização de uma técnica mais avançada para a ocupação dos bancos no avisador de cinto de segurança.

(128)A velocidade do veículo deve ser determinada pelo sinal de barramento do veículo e não por um sistema GNSS. Deve ser utilizada a velocidade filtrada do veículo (no que se refere ao ruído do sensor). Este requisito deve ser aplicado a todas as subsequentes ocorrências da análise de velocidade do veículo.

(129)Se o serviço STI-C for acionado devido à satisfação da condição a) ou b) do ponto 126, o Standstill Timerdeverá ser interrompido e regulado para 60 s. Na fase de atualização, apenas devem ser verificadas as condições, não se devendo iniciar um temporizador.

9.2.3.Qualidade das informações

(130)O valor do elemento de dados informationQuality na DENM depende da forma como o evento é detetado (ver pontos (126) e (127)). O valor informationQuality deve ser definido de acordo com o seguinte quadro (deve ser utilizado o valor mais alto possível):

Quadro 16: Qualidade das informações de «veículo de salvaguarda de emergência imobilizado»

Deteção de evento

Valor da InformationQuality

Sem implementação em conformidade com as TRCO

desconhecido(0)

A condição c) não está reunida

1

A condição d) não está reunida

2

Está reunida pelo menos uma das condições b) ou c) e está reunida a condição d)

3

Está reunida pelo menos uma das condições b) ou c) e está reunida a condição e)

4

A condição a) está reunida

5

(131)Se as condições de acionamento se alterarem entre duas atualizações, a informationQualitynão deve ser alterada até à próxima atualização. Se as condições alteradas ainda estiverem reunidas enquanto a DENM é atualizada, a informationQuality deve ser atualizada.

9.3.Condições de terminação

(132)Este serviço STI-C é terminado através do cancelamento da estação STI-C de origem. Aquando da terminação do serviço STI-C, o pedido de atualização da DENM deve ser terminado.

9.3.1.Cancelamento

(133)Se a seguinte condição estiver reunida antes de o período definido no elemento de dados validityDuration expirar, deve ser acionada a geração de uma DENM de cancelamento:

(a)já não está reunida nenhuma das condições específicas do sistema STI-C a) a c) do ponto 9.2.2.

A vehicleRole deve ser definida para predefinição(0) se a barra de sinalização já não estiver em funcionamento.

9.3.2.Negação

(134)Não deve ser utilizada uma DENM de negação para este serviço STI-C.    

9.4.Atualização

(135)A DENM gerada deve ser atualizada a cada 60 s se ainda estiverem reunidas as condições de acionamento. Todos os campos de dados que recebem novos valores são definidos no Quadro 17 abaixo.

9.5.Duração de repetição e intervalo de repetição

(136)As DENM novas que foram atualizadas ou canceladas devem ser repetidas para uma repetitionDuration de 60 s com um repetitionInterval de 1 s. Consequentemente, os parâmetros de interface repetitionDuration e repetitionInterval entre a aplicação e o serviço básico de DEN devem ser definidos de acordo com os valores acima.

Nota: a validityDuration está regulada para 180 s. Desta forma, é possível evitar uma lacuna de DENM se a repetitionDuration da DENM original tiver expirado e a atualização ainda não tiver sido recebida.

Nota: quando duas DENM com o mesmo causeCode provêm da mesma estação STI-C, o caso deve ser gerido pela estação STI-C recetora.

9.6.Classe de tráfego

(137)Devem ser definidas DENM novas, de atualização e de cancelamento para a traffic class 1.

9.7.Parâmetros de mensagem

9.7.1.DENM

(138)O quadro a seguir especifica os elementos de dados de DENM que devem ser definidos.

Quadro 17: Elementos de dados de DENM de «veículo de salvaguarda de emergência imobilizado»

Campo de dados

Valor

Contentor de gestão

actionID

Identificador de uma DENM. Deve ser definido em conformidade com a norma [TS 102 894-2].

detectionTime

TimestampIts- timestamp em que o evento é detetado pela estação STI-C de origem. Deve ser definido em conformidade com a norma [TS 102 894-2].

Deve ser renovado para uma DENM de atualização.

referenceTime

TimestampIts - timestamp em que é gerada uma DENM nova, de atualização ou de cancelamento. Deve ser definido em conformidade com a norma [TS 102 894-2].

termination

Não deve ser definido no caso de DENM novas ou de atualização. Deve ser definido como cancelamentoIS(0) no caso de estarem reunidas as condições de cancelamento; ver ponto (133).

eventPosition

ReferencePosition. Deve ser definido em conformidade com a norma [TS 102 894-2].

Deve ser renovado para uma DENM de atualização.

relevanceDistance

lessThan5km(5)

relevanceTrafficDirection

Se o roadType for conhecido, o valor deve ser definido da seguinte forma:

roadType

Sentido

 

0

allTrafficDirections(0)

 

1

upstreamTraffic(1)

 

2

allTrafficDirections(0)

 

3

upstreamTraffic(1)

 

Caso contrário, o valor deve ser definido para allTrafficDirections(0)

validityDuration

180 s

stationType

specialVehicles(10)

Contenção de situação

informationQuality

Ver ponto (130). Deve ser renovado a cada DENM de atualização.

causeCode

rescueAndRecoveryWorkInProgress(15)

subCauseCode

emergencyVehicles(1)

Contenção de localização

eventSpeed

Velocidade da estação STI-C de origem. Deve ser definido em conformidade com a norma [TS 102 8942].

Deve ser renovado para uma DENM de atualização.

eventPositionHeading

Rumo da estação STI-C de origem. Deve ser definido em conformidade com a norma [TS 102 894-2].

Deve ser renovado para uma DENM de atualização.

traces

PathHistory da estação STI-C de origem. Deve ser definido em conformidade com a norma [TS 102 894-2].

Deve ser renovado para uma DENM de atualização.

roadType

RoadType da estrada em que a estação STI-C de deteção está situada.

Deve ser renovado para uma DENM de atualização.

Deve ser definido em conformidade com a norma [TS 102 894-2] em conjugação com as seguintes regras:

Urbano / não urbano

Separação estrutural

Elemento de dados

Urbano

Não

urbano-NoStructuralSeparation ToOppositeLanes(0)

Urbano

Sim

urbano-WithStructuralSeparation ToOppositeLanes(1)

Urbano

Desconhecido

urbano-NoStructuralSeparation ToOppositeLanes(0)

Não urbano

Não

nãoUrbano-NoStructuralSeparation ToOppositeLanes(2)

Não urbano

Sim

nãoUrbano-WithStructuralSeparation ToOppositeLanes(3)

Não urbano

Desconhecido

nãoUrbano-NoStructuralSeparation ToOppositeLanes(2)

Se não for possível determinar as informações sobre o estatuto urbano/não urbano, deve ser omitido o elemento de dados.

Contenção a la carte

lanePosition

Se a lanePosition for fornecida por um sensor de bordo (por exemplo, radar ou câmara), o valor deve ser definido de acordo com a norma [TS 102 894-2]. Não é permitida a utilização de um sistema GNSS e de um mapa digital para estimar o número da faixa para esta versão da condição de acionamento.

Se a lanePosition for desconhecida, o elemento de dados deve ser omitido.

Deve ser renovado para uma DENM de atualização.

Contenção a la carte: StationaryVehicleContainer

stationarySince

Deve ser definido de acordo com a duração em minutos da estação STI-C de deteção em estado imobilizado. Deve ser definido em conformidade com a norma [TS 102 894-2].

 

Deve ser renovado para uma DENM de atualização.

9.7.2.CAM

(139)A vehicleRole deve ser iniciada numa configuração de «predefinição» [vehicleRole da CAM definida para default((0)]. Se pelo menos uma das condições de acionamento especificada no ponto (126) estiver reunida, a vehicleRole deve ser definida para emergency(6).

(140)O quadro a seguir especifica os elementos de dados da DENM que devem ser definidos se o serviço STI-C for acionado.

Quadro 18: Elementos de dados de CAM de «veículo de salvaguarda de emergência imobilizado»

Campo de dados

Valor

CoopAwareness

generationDeltaTime

Tempo correspondente ao tempo da posição de referência na CAM, considerado como tempo da CAM de geração.

Deve ser definido em conformidade com a norma [EN 302 637-2].

BasicContainer

stationType

specialVehicles(10)

referencePosition

Posição e precisão da posição medidas no ponto de referência da estação STIC de origem.

Deve ser definido em conformidade com a norma [TS 102 894-2].

O HighFrequencyContainer deve ser definido para BasicVehicleContainerHighFrequency

heading

O rumo da estação STI-C de origem em relação ao norte geográfico.

Deve ser definido em conformidade com a norma [TS 102 894-2].

velocidade

Velocidade de condução da estação STI-C de origem.

Deve ser definida em conformidade com a norma [TS 102 894-2].

driveDirection

O sentido de marcha do veículo (para a frente ou para trás) da estação STI-C de origem.

Deve ser definido em conformidade com a norma [TS 102 894-2].

vehicleLength

O comprimento do veículo.

Deve ser definido em conformidade com a norma [TS 102 894-2].

vehicleWidth

A largura do veículo.

Deve ser definida em conformidade com a norma [TS 102 894-2].

longitudinalAcceleration

Aceleração longitudinal da estação STI-C de origem.

Deve ser definida em conformidade com a norma [TS 102 894-2].

curvatura

Curvatura da trajetória do veículo e de precisão.

Deve ser definida em conformidade com a norma [TS 102 894-2].

curvatureCalcMode

Descreve se o valor da velocidade de guinada é utilizado para calcular a curvatura de um valor de curvatura comunicado.

Deve ser definido em conformidade com a norma [TS 102 894-2].

yawRate

A velocidade de guinada num dado ponto no tempo.

Deve ser definida em conformidade com a norma [TS 102 894-2].

LowFrequencyContainer deve ser definido para BasicVehicleContainerLowFrequency

vehicleRole

emergência(6)

exteriorLights

Descreve o estado dos interruptores de luz exterior de um veículo.

Deve ser definido em conformidade com a norma [TS 102 894-2].

pathHistory

Representa o movimento do veículo ao longo de um período recente e/ou distância.

Deve ser definido em conformidade com a norma [TS 102 894-2].

SpecialVehicleContainer deve ser definido para EmergencyContainer

lightBarSirenInUse

O bit lightBarActivated deve ser regulado para 1(onChange) se for detetada a utilização da barra de sinalização; caso contrário, deve ser regulado para 0.

O bit sirenActivated deve ser regulado para 1, se for detetada a utilização da sirene; caso contrário, deve ser regulado para 0.

emergencyPriority

Não exigido

causeCode

Conforme especificado no ponto (138)

subCauseCode

Conforme especificado no ponto (138)

9.8.Rede e camada de transporte

(141)O parâmetro de interface DENM destination area entre o serviço básico DEN e a rede e a camada de transporte devem ser iguais a uma forma circular com raio igual à relevanceDistance.

9.9.Camada de segurança

(142)No caso de se aplicarem as condições de acionamento conforme descrito no ponto (126), será bloqueada uma alteração de CA para DENM novas, de atualização e de cancelamento, desde que a validityDuration não tenha expirado. Devem ser enviadas DENM novas, de atualização e de cancelamento correspondentes com o mesmo CA.

10.Aviso de veículo especial — aviso de serviço de pronto-socorro imobilizado

10.1.Descrição do serviço STI-C

Este serviço STI-C transmite informações V2V sobre um serviço de pronto-socorro em assistência a um veículo avariado. O serviço STI-C do serviço de pronto-socorro em movimento, por exemplo, transportando um veículo avariado, é abrangido pela CAM comum.

Os seguintes serviços STI-C estão relacionados com este serviço, pois partilham condições de acionamento semelhantes:

·«aviso de veículo especial — veículo de emergência em operação»;

·«aviso de veículo especial — veículo de salvaguarda de emergência imobilizado».

10.2.Condições de acionamento

10.2.1.Condições prévias

(143)Antes de um serviço STI-C ser acionado, devem estar reunidas as seguintes condições prévias:

·o stationType é confirmado como um veículo de emergência [stationType de CAM é definido para specialVehicles(10)]. O serviço STI-C é reservado a veículos de pronto-socorro;

·o Standstill Timer deve ser iniciado no zero.

10.2.2.Condições específicas do serviço

(144)Se o veículo estiver imobilizado e a barra de luz estiver em funcionamento, deve ser regulado para zero e iniciado umStandstill Timer. Se a barra de sinalização já não estiver em funcionamento ou o veículo já não estiver imobilizado, o Standstill Timerdeverá ser interrompido e reposto a zero.

(145)Se estiverem reunidas as condições prévias indicadas no ponto (143) e, pelo menos, uma das seguintes condições, consideram-se reunidas as condições de acionamento deste serviço STI-C e deve ser acionada a geração de uma DENM:

(a)a barra de sinalização está em funcionamento, as luzes de perigo estão ativadas e o travão de estacionamento está ativado ou (em caso de transmissão automática) o «estacionamento» está selecionado;

(b)a barra de sinalização está em funcionamento, as luzes de perigo estão ativadas e o Standstill Timer é de 60 s ou mais.

(146)O nível de qualidade das informações pode ser melhorado pelas seguintes condições:

(c)o estado da porta do condutor é «aberta»;

(d)o banco do condutor é detetado, por uma das seguintes técnicas, como «não ocupado»:

(1)câmara no habitáculo;

(2)é utilizada uma técnica mais avançada para a ocupação dos bancos no avisador de cinto de segurança.

(147)A velocidade do veículo deve ser determinada pelo sinal de barramento do veículo e não por um sistema GNSS. Deve ser utilizada a velocidade filtrada do veículo (no que se refere ao ruído do sensor). Este requisito deve ser aplicado a todas as subsequentes ocorrências da análise de velocidade do veículo.

(148)Se o serviço STI-C for acionado devido à satisfação da condição a) do ponto 145, o Standstill Timer deverá ser interrompido e regulado para 60 s. Na fase de atualização, apenas devem ser verificadas as condições, não se devendo iniciar um temporizador.

10.2.3.Qualidade das informações

(149)O valor do elemento de dados informationQuality na DENM depende da forma como o evento é detetado (ver pontos (145) e (146)). O valor informationQuality deve ser definido de acordo com o seguinte quadro (deve ser utilizado o valor mais alto possível):

Quadro 19: Qualidade das informações de «aviso de serviço de pronto-socorro imobilizado»

Deteção de evento

Valor da informationQuality

Sem implementação em conformidade com as TRCO

desconhecido(0)

A condição b) está reunida

1

A condição a) está reunida

2

Está reunida pelo menos uma das condições a) ou b) e está reunida a condição c)

3

Está reunida pelo menos uma das condições a) ou b) e está reunida a condição d)

4

(150)Se as condições de acionamento se alterarem entre duas atualizações, a informationQualitynão deve ser alterada até à próxima atualização. Se as condições alteradas ainda estiverem reunidas enquanto a DENM é atualizada, a informationQuality deve ser atualizada.

10.3.Condições de terminação

(151)Este serviço STI-C é terminado através do cancelamento da estação STI-C de origem. Aquando da terminação do serviço STI-C, o pedido de atualização da DENM deve ser terminado.

10.3.1.Cancelamento

(152)Se a seguinte condição estiver reunida antes de o período definido no elemento de dados validityDuration expirar, deve ser acionada a geração de uma DENM de cancelamento e a vehicleRole deve ser definida para predefinida(0):

(a)Não estão reunidas as condições a) e b) específicas do serviço STI-C indicadas no ponto (145).

10.3.2.Negação

(153)Não deve ser utilizada uma DENM de negação para este serviço STI-C.    

10.4.Atualização

(154)A DENM gerada deve ser atualizada a cada 60 s se ainda estiverem reunidas as condições de acionamento. Todos os campos de dados que recebem novos valores são definidos no Quadro 20 abaixo.

10.5.Duração de repetição e intervalo de repetição

(155)As DENM novas que foram atualizadas ou canceladas devem ser repetidas para uma repetitionDuration de 60 s com um repetitionInterval de 1 s. Consequentemente, os parâmetros de interface repetitionDuration e repetitionInterval entre a aplicação e o serviço básico de DEN devem ser definidos de acordo com os valores acima.

Nota: a validityDuration está regulada para 180 s. Desta forma, é possível evitar uma lacuna de DENM se a repetitionDuration da DENM original tiver expirado e a atualização ainda não tiver sido recebida.

Nota: Quando duas DENM com o mesmo causeCode provêm da mesma estação STI-C, o caso deve ser gerido pela estação STI-C recetora.

10.6.Classe de tráfego

(156)Devem ser definidas DENM novas, de atualização e de cancelamento para a traffic class 1.

10.7.Parâmetros de mensagem

10.7.1.DENM

(157)O quadro a seguir especifica os elementos de dados de DENM que devem ser definidos.

Quadro 20: Elementos de dados de DENM de «aviso de serviço de pronto-socorro imobilizado»

Campo de dados

Valor

Contentor de gestão

actionID

Identificador de uma DENM. Deve ser definido em conformidade com a norma [TS 102 894-2].

detectionTime

TimestampIts- timestamp em que o evento é detetado pela estação STI-C de origem. Deve ser definido em conformidade com a norma [TS 102 894-2].

Deve ser renovado para uma DENM de atualização.

referenceTime

TimestampIts - timestamp em que é gerada uma DENM nova, de atualização ou de cancelamento. Deve ser definido em conformidade com a norma [TS 102 894-2].

terminação

Não deve ser definido no caso de DENM novas ou de atualização. Deve ser definido como cancelamentoSI(0) no caso de estarem reunidas as condições de cancelamento (ver ponto (152)).

eventPosition

ReferencePosition. Deve ser definido em conformidade com a norma [TS 102 894-2].

Deve ser renovado para uma DENM de atualização.

relevanceDistance

lessThan5km(5)

relevanceTrafficDirection

Se o tipoDeEstrada for conhecido, o valor deve ser definido da seguinte forma:

RoadType

Sentido

 

0

allTrafficDirections(0)

 

1

upstreamTraffic(1)

 

2

allTrafficDirections(0)

 

3

upstreamTraffic(1)

 

Caso contrário, o valor deve ser definido para allTrafficDirections(0)

validityDuration

180 s

stationType

specialVehicles(10)

Contenção de situação

informationQuality

Ver ponto (149). Deve ser renovado a cada DENM de atualização.

causeCode

rescueAndRecoveryWorkInProgress(15)

subCauseCode

unavailable(0)

Contenção de localização

eventSpeed

Velocidade da estação STI-C de origem. Deve ser definido em conformidade com a norma [TS 102 8942].

Deve ser renovado para uma DENM de atualização.

eventPositionHeading

Rumo da estação STI-C de origem. Deve ser definido em conformidade com a norma [TS 102 894-2].

Deve ser renovado para uma DENM de atualização.

traces

PathHistory da estação STI-C de origem. Deve ser definido em conformidade com a norma [TS 102 894-2].

Deve ser renovado para uma DENM de atualização.

roadType

RoadType da estrada em que a estação STI-C de deteção está situada.

Deve ser renovado para uma DENM de atualização.

Deve ser definido em conformidade com a norma [TS 102 894-2] em conjugação com as seguintes regras:

Urbano / Não urbano

Separação estrutural

Elemento de dados

Urbano

Não

urbano-NoStructuralSeparation ToOppositeLanes(0)

Urbano

Sim

urbano-WithStructuralSeparation ToOppositeLanes(1)

Urbano

Desconhecido

urbano-NoStructuralSeparation ToOppositeLanes(0)

Não urbano

Não

nãoUrbano-NoStructuralSeparation ToOppositeLanes(2)

Não urbano

Sim

nãoUrbano-WithStructuralSeparation ToOppositeLanes(3)

Não urbano

Desconhecido

nãoUrbano-NoStructuralSeparation ToOppositeLanes(2)

Se não for possível determinar as informações sobre o estatuto urbano/não urbano, deve ser omitido o elemento de dados.

Contenção a la carte

lanePosition

Se a lanePosition for fornecida por um sensor de bordo (por exemplo, radar ou câmara), o valor deve ser definido de acordo com a norma [TS 102 894-2]. Não é permitida a utilização de um sistema GNSS e de um mapa digital para estimar o número da faixa para esta versão da condição de acionamento.

Se a lanePosition for desconhecida, o elemento de dados deve ser omitido.

Deve ser renovado para uma DENM de atualização.

Contenção a la carte: StationaryVehicleContainer

stationarySince

Deve ser definido de acordo com a duração em minutos da estação STI-C de deteção em estado imobilizado. Deve ser definido em conformidade com a norma [TS 102 894-2].

 

Deve ser renovado para uma DENM de atualização.

10.7.2.CAM

(158)A vehicleRole deve ser iniciada numa configuração de «predefinição» [vehicleRole da CAM definida para default(0)]. Se pelo menos uma das condições de acionamento especificada no ponto (145) estiver reunida, a vehicleRole deve ser definida para rescue(5).

(159)O quadro a seguir especifica os elementos de dados da DENM que devem ser definidos se o serviço STI-C for acionado.

Quadro 21: Elementos de dados de CAM de «aviso de serviço de pronto-socorro imobilizado»

Campo de dados

Valor

CoopAwareness

generationDeltaTime

Tempo correspondente ao tempo da posição de referência na CAM, considerado como tempo da CAM de geração.

Deve ser definido em conformidade com a norma [EN 302 637-2].

BasicContainer

stationType

specialVehicles(10)

referencePosition

Posição e precisão da posição medidas no ponto de referência da estação STIC de origem.

Deve ser definido em conformidade com a norma [TS 102 894-2].

HighFrequencyContainer deve ser definido para BasicVehicleContainerHighFrequency

heading

O rumo da estação STI-C de origem em relação ao norte geográfico.

Deve ser definido em conformidade com a norma [TS 102 894-2].

velocidade

Velocidade de condução da estação STI-C de origem.

Deve ser definida em conformidade com a norma [TS 102 894-2].

driveDirection

O sentido da marcha do veículo (para a frente ou para trás) da estação STI-C de origem.

Deve ser definido em conformidade com a norma [TS 102 894-2].

vehicleLength

O comprimento do veículo.

Deve ser definido em conformidade com a norma [TS 102 894-2].

vehicleWidth

A largura do veículo.

Deve ser definida em conformidade com a norma [TS 102 894-2].

longitudinalAcceleration

Aceleração longitudinal da estação STI-C de origem.

Deve ser definida em conformidade com a norma [TS 102 894-2].

curvatura

Curvatura da trajetória do veículo e de precisão.

Deve ser definida em conformidade com a norma [TS 102 894-2].

curvatureCalcMode

Descreve se o valor da velocidade de guinada é utilizado para calcular a curvatura de um valor de curvatura comunicado.

Deve ser definido em conformidade com a norma [TS 102 894-2].

yawRate

A velocidade de guinada num dado ponto no tempo.

Deve ser definida em conformidade com a norma [TS 102 894-2].

LowFrequencyContainer deve ser definido para BasicVehicleContainerLowFrequency

vehicleRole

rescue(5)

exteriorLights

Descreve o estado dos interruptores de luz exterior de um veículo.

Deve ser definido em conformidade com a norma [TS 102 894-2].

pathHistory

Representa o movimento do veículo ao longo de um período recente e/ou distância.

Deve ser definido em conformidade com a norma [TS 102 894-2].

O SpecialVehicleContainer deve ser definido para SafetyCarContainer

lightBarSirenInUse

O bit lightBarActivated deve ser regulado para 1 (onChange) se for detetada a utilização da barra de sinalização; caso contrário, deve ser regulado para 0.

O bit sirenActivated deve ser regulado para 1, se for detetada a utilização da sirene; caso contrário, deve ser regulado para 0.

causeCode

Conforme especificado no ponto (157)

subCauseCode

Conforme especificado no ponto (157)

10.8.Rede e camada de transporte

(160)O parâmetro de interface DENM destination area entre o serviço básico DEN e a rede e a camada de transporte devem ser iguais a uma forma circular com raio igual à relevanceDistance.

10.9.Camada de segurança

(161)No caso de se aplicarem as condições de acionamento conforme descrito no ponto (145), será bloqueada uma alteração de CA para DENM novas, de atualização e de cancelamento, desde que a validityDuration não tenha expirado. Devem ser enviadas DENM novas, de atualização e de cancelamento correspondentes com o mesmo CA.

11.Intercâmbio de IRC — pedido de IRC

11.1.Descrição do serviço STI-C

Este serviço STI-C transmite informações V2V sobre uma situação de condução crítica, em que uma colisão entre dois veículos é altamente provável ou inevitável. O veículo ego reconhece uma potencial colisão e envia o seu próprio IRC para obter o IRC do oponente de colisão em resposta.

Os seguintes serviços STI-C estão relacionados com este serviço, pois partilham condições de acionamento semelhantes:

·«intercâmbio de IRC — IRC de resposta»;

(162)Apenas deve ser enviado um sinal de DENM para a pilha se as condições de acionamento descritas no presente ponto forem consideradas válidas. Esse sinal induz a pilha a gerar uma DENM nova. Se não estiverem reunidas as condições de acionamento, não deve ser gerada uma DENM.

11.2.Condições de acionamento

11.2.1.Condições prévias

(163)Não se aplicam condições prévias específicas a este serviço STI-C.

11.2.2.Condições específicas do serviço

(164)Se estiverem reunidas ambas as seguintes condições, consideram-se reunidas as condições de acionamento deste serviço STI-C e deve ser acionada a geração de uma DENM:

(a)o «tempo até à colisão» (TTC) calculado por um algoritmo do dispositivo de medição de bordo é <1,5 s. A tolerância aceitável para o valor TTC calculado é de 10 %;

(b)a velocidade relativa entre dois potenciais oponentes de colisão é superior a 20 km/h.

Nota: o cálculo do TTC apenas com base na posição GNSS, como o que é fornecido pelos recetores de GNSS que utilizam técnicas mais avançadas, não oferece um grau de fiabilidade suficiente para este serviço.

11.2.3.Qualidade das informações

(165)O valor do elemento de dados informationQuality na DENM depende da forma como o evento é detetado. O valor informationQuality deve ser definido de acordo com o seguinte quadro (deve ser utilizado o valor mais alto possível):

Quadro 22: Qualidade das informações de «intercâmbio de IRC — pedido de IRC»

Deteção de evento

Valor da informationQuality

Sem implementação em conformidade com as TRCO

desconhecido(0)

De outra forma

1

11.3.Condições de terminação

(166)Não será considerada a terminação do serviço STI-C.

11.3.1.Cancelamento

(167)Não deve ser utilizada uma DENM de cancelamento para este serviço STI-C.

11.3.2.Negação

(168)Não deve ser utilizada uma DENM de negação para este serviço STI-C.

11.4.Atualização

(169)Não deve ser utilizada uma DENM de atualização para este serviço STI-C.

11.5.Duração de repetição e intervalo de repetição

(170)Devem ser repetidas novas DENM para uma repetitionDuration de 300 ms (100 ms três vezes consecutivas) com um repetitionInterval de 100 ms. Consequentemente, os parâmetros de interface repetitionDuration e repetitionInterval entre a aplicação e o serviço básico de DEN devem ser definidos de acordo com os valores acima.

Nota: uma vez que não é garantido que um IRC enviado chegue ao recetor (por exemplo, devido à carga do canal, temporariamente fora do intervalo, etc.), o remetente envia o IRC três vezes consecutivas. Esta situação é equivalente a uma repetitionDuration de 300 ms.

Nota: a duração estimada para a transmissão (de aplicação para aplicação) de um IRC (repetição não incluída) através de WLAN automóvel é de 200300 ms. Se apenas for recebida a terceira tentativa (pior das hipóteses), em ambos os casos (pedido e resposta), as informações estarão disponíveis para ambos os veículos após 1 segundo [2 * (300 ms + 100 ms (@10 Hz) + 100 ms (@10 Hz))]. Assim, o parâmetro de acionamento TTC < 1,5 s é suficiente. Considera-se que o envio de IRC três vezes consecutivas é um bom compromisso entre a carga do canal e a garantia de uma transmissão bem-sucedida.

Nota: apenas a primeira DENM será enviada sem restrições de Controlo de Congestionamento Descentralizado (CCD). A segunda e a terceira DENM podem ser afetadas pelo CCD (com base na carga atual do canal).

Nota: quando duas DENM com o mesmo causeCode provêm da mesma estação STI-C, o caso deve ser gerido pela estação STI-C recetora.

11.6.Classe de tráfego

(171)Devem ser definidas DENM novas para a traffic class 0.

11.7.Parâmetros de mensagem

11.7.1.DENM

(172)O quadro a seguir especifica os elementos de dados de DENM que devem ser definidos.

Quadro 23: Elementos de dados de DENM de «intercâmbio de IRC — pedido de IRC»

Campo de dados

Valor

Contenção de gestão

actionID

Identificador de uma DENM. Deve ser definido em conformidade com a norma [TS 102 894-2].

detectionTime

TimestampIts- timestamp em que o evento é detetado pela estação STI-C de origem. Deve ser definido em conformidade com a norma [TS 102 894-2].

tempoDeReferência

TimestampIts - timestamp em que é gerada uma DENM nova. Deve ser definido em conformidade com a norma [TS 102 894-2].

terminação

Não deve ser definido, pois nem a negação nem o cancelamento devem ser utilizados neste serviço STI-C.

eventPosition

. Deve ser definido em conformidade com a norma [TS 102 894-2].

relevanceDistance

lessThan100m(1)
Nota: esta situação deve também abranger o pior cenário possível, de condução a 250 km/h em direção a um fim de fila perigoso (s = v*t = 69,4 m/s * 1,5 s = 104,2 m).

rrelevanceTrafficDirection

allTrafficDirections(0)

validityDuration

2 s
Nota: deve ser superior ao TTC.

stationType

O tipo de estação STI-C de origem. Deve ser definido em conformidade com a norma [TS 102 894-2].

Contenção de situação

informationQuality

Ver ponto (164)

causeCode

collisionRisk(97)

subCauseCode

unavailable(0)

Contenção de localização

eventSpeed

Velocidade da estação STI-C de origem. Deve ser definido em conformidade com a norma [TS 102 894-2].

eventPositionHeading

Rumo da estação STI-C de origem. Deve ser definido em conformidade com a norma [TS 102 894-2].

traces

PathHistory da estação STI-C de origem. Deve ser definido em conformidade com a norma [TS 102 894-2].

roadType

Deve ser definido em conformidade com a norma [TS 102 894-2]. Se não for possível determinar as informações sobre o estatuto urbano/não urbano, deve ser omitido o elemento de dados.

Contenção a la carte: ImpactReductionContainer

heightLonCarrLeft

Altura da barra de tejadilho longitudinal esquerda do veículo, da base ao topo. Deve ser definido em conformidade com a norma [TS 102 894-2].

heightLonCarrRight

Altura da barra de tejadilho longitudinal direita do veículo, da base ao topo. Deve ser definido em conformidade com a norma [TS 102 894-2].

posLonCarrLeft

Distância longitudinal do centro do para-choques dianteiro do veículo até à parte dianteira da barra de tejadilho longitudinal esquerda do veículo. Deve ser definido em conformidade com a norma [TS 102 894-2].

posLonCarrRight

Distância longitudinal do centro do para-choques dianteiro do veículo até à parte dianteira da barra de tejadilho longitudinal direita do veículo. Deve ser definido em conformidade com a norma [TS 102 894-2].

positionOfPillars

Os pilares do veículo referem-se ao suporte vertical ou quase vertical do veículo, designados respetivamente como A, B, C ou D. Devem ser definidos de acordo com a norma [TS 102 894-2].

posCentMass

Distância perpendicular do centro de massa de um veículo de carga vazio até à linha dianteira do retângulo envolvente do veículo. Deve ser definido em conformidade com a norma [TS 102 894-2].

wheelBaseVehicle

Distância perpendicular entre o eixo dianteiro e traseiro da base da roda do veículo. Deve ser definido em conformidade com a norma [TS 102 894-2].

turningRadius

A menor rotação (ou seja, a rotação em U) que o veículo é capaz de fazer. Deve ser definido em conformidade com a norma [TS 102 894-2].

posFrontAx

Distância perpendicular entre a linha dianteira do retângulo envolvente do veículo e o eixo da roda dianteira. Deve ser definido em conformidade com a norma [TS 102 894-2].

positionOfOccupants

BitString que indica se um banco de passageiro está ocupado ou se o estado de ocupação é detetável. Deve ser definido em conformidade com a norma [TS 102 8942].

vehicleMass

Massa de um veículo de carga vazio. Deve ser definido em conformidade com a norma [TS 102 894-2].

requestResponseIndication

pedido(0)

11.7.2.CAM

(173)Não deve ser utilizada a CAM de adaptação para este serviço STI-C.

11.8.Rede e camada de transporte

(174)O parâmetro de interface entre o serviço básico DEN e a rede e a camada de transporte devem ser iguais a uma forma circular com raio igual à relevanceDistance.

11.9.Camada de segurança

(175)No caso de se aplicarem as condições de acionamento conforme descrito no ponto (164), será bloqueada uma alteração de CA, desde que a validityDuration não tenha expirado.

12.Intercâmbio de IRC — IRC de resposta

12.1.Descrição do serviço STI-C

Este serviço STI-C transmite informações V2V sobre uma situação de condução crítica, em que uma colisão entre dois veículos é altamente provável ou inevitável. O veículo ego recebeu um IRC de outro veículo e envia seu próprio IRC em resposta.

Os seguintes serviços STI-C estão relacionados com este serviço, pois partilham condições de acionamento semelhantes:

·«intercâmbio de IRC — pedido de IRC»

(176)Apenas deve ser enviado um sinal de DENM para a pilha se as condições de acionamento descritas no presente ponto forem consideradas válidas. Esse sinal induz a pilha a gerar uma DENM nova. Se não estiverem reunidas as condições de acionamento, não deve ser gerada uma DENM.

12.2.Condições de acionamento

12.2.1.Condições prévias

(177)Foi recebido um IRC conforme descrito no Quadro 23.

12.2.2.Condições específicas do serviço

(178)Se estiver reunida a condição prévia indicada no ponto (177) e ambas as seguintes condições, consideram-se reunidas as condições de acionamento deste serviço STI-C e deve ser acionada a geração de uma DENM:

(a)a requestResponseIndication no IRC recebido está definida para request(0);

(b)a distância perpendicular entre o veículo requerente (posição do evento no IRC) e o veículo ego (posição de referência conforme definida na CAM) é inferior a 100 m.

Nota: quando um IRC é recebido, o recetor tem de verificar se este foi realmente solicitado antes de responder com seu próprio IRC. Pode fazê-lo com base na requestResponseIndication. Para evitar uma carga desnecessária no canal de transmissão de vários IRC transmitidos, apenas os veículos nas imediações (a menos de 100 m) respondem ao pedido.

12.2.3.Qualidade das informações

(179)O valor do elemento de dados na DENM depende da forma como o evento é detetado. O valor deve ser definido de acordo com o seguinte quadro (deve ser utilizado o valor mais alto possível):

Quadro 24: Qualidade das informações de «intercâmbio de IRC — IRC de resposta»

Deteção de evento

Valor da InformationQuality

Sem implementação em conformidade com as TRCO

desconhecido(0)

De outra forma

1

12.3.Condições de terminação

(180)Não será considerada a terminação do serviço STI-C.

12.3.1.Cancelamento

(181)Não deve ser utilizada uma DENM de cancelamento para este serviço STI-C.

12.3.2.Negação

(182)Não deve ser utilizada uma DENM de negação para este serviço STI-C.

12.4.Atualização

(183)Não deve ser utilizada uma DENM de atualização para este serviço STI-C.

12.5.Duração de repetição e intervalo de repetição

(184)Devem ser repetidas novas DENM para uma repetitionDuration de 300 ms (100 ms três vezes consecutivas) com um repetitionInterval de 100 ms. Consequentemente, os parâmetros de interface repetitionDuration e repetitionInterval entre a aplicação e o serviço básico de DEN devem ser definidos de acordo com os valores acima.

Nota: uma vez que não é garantido que um IRC enviado chegue ao recetor (por exemplo, devido à carga do canal, temporariamente fora do intervalo, etc.), o remetente envia o IRC três vezes consecutivas. Esta situação é equivalente a uma repetitionDuration de 300 ms.

Nota: a duração estimada para a transmissão (de aplicação para aplicação) de um IRC (repetição não incluída) através de WLAN automóvel é de 200300 ms. Se apenas for recebida a terceira tentativa (pior das hipóteses), em ambos os casos (pedido e resposta), as informações estarão disponíveis para ambos os veículos após 1 segundo [2 * (300 ms + 100 ms (@10 Hz) + 100 ms (@10 Hz))]. Assim, o parâmetro de acionamento TTC < 1,5 s é suficiente. Considera-se que o envio de IRC três vezes consecutivas é um bom compromisso entre a carga do canal e a garantia de uma transmissão bem-sucedida.

Nota: apenas a primeira DENM será enviada sem restrições de DCC. A segunda e a terceira DENM podem ser afetadas pelo DCC (com base na carga atual do canal).

Nota: quando duas DENM com o mesmo causeCode provêm da mesma estação STI-C, o caso deve ser gerido pela estação STI-C recetora.

12.6.Classe de tráfego

(185)Devem ser definidas DENM novas para a traffic class 0.

12.7.Parâmetros de mensagem

12.7.1.DENM

(186)O quadro a seguir especifica os elementos de dados de DENM que devem ser definidos.

Quadro 25: Elementos de dados de DENM de «intercâmbio de IRC — IRC de resposta»

Campo de dados

Valor

Contenção de gestão

actionID

Identificador de uma DENM. Deve ser definido em conformidade com a norma [TS 102 894-2].

detectionTime

TimestampIts- timestamp em que o evento é detetado pela estação STI-C de origem. Deve ser definido em conformidade com a norma [TS 102 894-2].

tempoDeReferência

TimestampIts - timestamp em que é gerada uma DENM nova. Deve ser definido em conformidade com a norma [TS 102 894-2].

termination

Não deve ser definido, pois nem a negação nem o cancelamento devem ser utilizados neste serviço STI-C.

eventPosition

ReferencePosition. Deve ser definido em conformidade com a norma [TS 102 894-2].

relevanceDistance

lessThan100m(1)

relevanceTrafficDirection

allTrafficDirections(0)

validityDuration

2 s

stationType

O tipo de estação STI-C de origem. Deve ser definido em conformidade com a norma [TS 102 894-2].

Contenção de situação

informationQuality

Ver ponto (177).

causeCode

collisionRisk(97)

subCauseCode

unavailable(0)

Contenção de localização

eventSpeed

Velocidade da estação STI-C de origem. Deve ser definido em conformidade com a norma [TS 102 894-2].

eventPositionHeading

Rumo da estação STI-C de origem. Deve ser definido em conformidade com a norma [TS 102 894-2].

traces

da estação STI-C de origem. Deve ser definido em conformidade com a norma [TS 102 894-2].

roadType

Deve ser definido em conformidade com a norma [TS 102 894-2]. Se não for possível determinar as informações sobre o estatuto urbano/não urbano, deve ser omitido o elemento de dados.

Contenção a la carte: ImpactReductionContainer

heightLonCarrLeft

Altura da barra de tejadilho longitudinal esquerda do veículo, da base ao topo. Deve ser definido em conformidade com a norma [TS 102 894-2].

heightLonCarrRight

Altura da barra de tejadilho longitudinal direita do veículo, da base ao topo. Deve ser definido em conformidade com a norma [TS 102 894-2].

posLonCarrLeft

Distância longitudinal do centro do para-choques dianteiro do veículo até à parte dianteira da barra de tejadilho longitudinal esquerda do veículo. Deve ser definido em conformidade com a norma [TS 102 894-2].

posLonCarrRight

Distância longitudinal do centro do para-choques dianteiro do veículo até à parte dianteira da barra de tejadilho longitudinal direita do veículo. Deve ser definido em conformidade com a norma [TS 102 894-2].

positionOfPillars

Os pilares do veículo referem-se ao suporte vertical ou quase vertical do veículo, designados respetivamente como A, B, C ou D. Devem ser definidos de acordo com a norma [TS 102 894-2].

posCentMass

Distância perpendicular do centro de massa de um veículo de carga vazio até à linha dianteira do retângulo envolvente do veículo. Deve ser definido em conformidade com a norma [TS 102 894-2].

wheelBaseVehicle

Distância perpendicular entre o eixo dianteiro e traseiro da base da roda do veículo. Deve ser definido em conformidade com a norma [TS 102 894-2].

turningRadius

A menor rotação (ou seja, a rotação em U) que o veículo é capaz de fazer. Deve ser definido em conformidade com a norma [TS 102 894-2].

posFrontAx

Distância perpendicular entre a linha dianteira do retângulo envolvente do veículo e o eixo da roda dianteira. Deve ser definido em conformidade com a norma [TS 102 894-2].

positionOfOccupants

BitString que indica se um banco de passageiro está ocupado ou se o estado de ocupação é detetável. Deve ser definido em conformidade com a norma [TS 102 8942].

vehicleMass

Massa de um veículo de carga vazio. Deve ser definido em conformidade com a norma [TS 102 894-2].

requestResponseIndication

resposta(1)

12.7.2.CAM

(187)Não deve ser utilizada a CAM de adaptação para este serviço STI-C.

12.8.Rede e camada de transporte

(188)O parâmetro de interface DENM destination area entre o serviço básico DEN e a rede e a camada de transporte devem ser iguais a uma forma circular com raio igual à relevanceDistance.

12.9.Camada de segurança

(189)No caso de se aplicarem as condições de acionamento conforme descrito no ponto (178), será bloqueada uma alteração de CA, desde que a validityDuration não tenha expirado. Devem ser enviadas novas DENM correspondentes com o mesmo CA.

13.Situação perigosa — luz de travagem de emergência eletrónica

13.1.Descrição do serviço STI-C

Este serviço STI-C transmite informações V2V sobre a travagem de emergência acionada pelo condutor, por exemplo, em reação a um veículo imobilizado ou mais lento à frente. O próprio veículo ego passa a ser uma possível zona de perigo local.

Os seguintes serviços STI-C estão relacionados com este serviço, pois partilham condições de acionamento semelhantes:

·«situações perigosas — intervenção do travão automático»;

·«situações perigosas — intervenção do sistema reversível de retenção de ocupantes».

13.2.Condições de acionamento

13.2.1.Condições prévias

(190)Não se aplicam condições prévias específicas a este serviço STI-C.

(191)Deve ser evitada a ativação paralela com os outros serviços STI-C relacionados. Nos casos em que os serviços STI-C «intervenção do travão automático» e/ou «intervenção do sistema reversível de retenção de ocupantes» são acionados em simultâneo, os serviços STI-C devem seguir a seguinte ordem de prioridades:

(a)«luz de travagem de emergência eletrónica» (prioridade mais alta);

(b)«intervenção do travão automático»;

(c)«intervenção do sistema reversível de retenção de ocupantes» (prioridade mais baixa).

(192)Se um serviço STI-C de prioridade mais alta for acionado, qualquer transmissão relacionada de serviços STI-C de prioridade inferior que já tenha sido acionada e ainda esteja ativa em relação à atualização deverá ser abortada. Além disso, deve ser solicitada a geração de uma DENM nova para o serviço STI-C de prioridade mais alta.

13.2.2.Condições específicas do serviço

(193)Se estiver reunida a seguinte condição, consideram-se reunidas as condições de acionamento deste serviço STIC e deve ser acionada a geração de uma DENM:

(a)é detetado um sinal que representa o pedido de luz de travagem de emergência eletrónica. As condições para esses pedidos estão definidas nas normas [ECE 48], [ECE 13] e [ECE 13H].

Os veículos também podem utilizar as seguintes condições de acionamento alternativas:

(b)a velocidade atual do veículo é superior a 20 km/h e a aceleração atual é inferior a -7 m/s² por um mínimo de 500 ms.

(194)A aceleração do veículo deve ser determinada pelo sinal de barramento do veículo e não por um sistema GNSS. Deve ser utilizada a aceleração filtrada em relação ao ruído do sensor.

13.2.3.Qualidade das informações

(195)O valor do elemento de dados informationQuality na DENM depende da forma como o evento é detetado (ver ponto (193)). O valor informationQuality deve ser definido de acordo com o seguinte quadro (deve ser utilizado o valor mais alto possível):

Quadro 26: Qualidade das informações de «luz de travagem de emergência eletrónica»

Deteção de evento

Valor da informationQuality

Sem implementação em conformidade com as TRCO

0

A condição a) está reunida

1

Condição a) reunida e atual aceleração longitudinal filtrada do veículo <-4 m/s^2

2

A condição b) está reunida

3

(196)Se as condições de acionamento se alterarem entre duas atualizações, a informationQualitynão deve ser alterada até à próxima atualização. Se as condições alteradas ainda estiverem reunidas enquanto a DENM é atualizada, a informationQuality deve ser atualizada.

13.3.Condições de terminação

(197)O serviço STI-C deve ser terminado quando a condição a) ou b) já não for válida. Aquando da terminação do serviço STI-C, o pedido de atualização da DENM deve ser terminado.

13.3.1.Cancelamento

(198)Não deve ser utilizada uma DENM de cancelamento para este serviço STI-C.

13.3.2.Negação

(199)Não deve ser utilizada uma DENM de negação para este serviço STI-C.

13.4.Atualização

(200)A DENM gerada deve ser atualizada a cada 100 ms se ainda estiverem reunidas as condições de acionamento. Todos os campos de dados que recebem novos valores são definidos no Quadro 27 abaixo.

13.5.Duração de repetição e intervalo de repetição

(201)Não deve ser utilizada uma DENM de repetição para este serviço STI-C.

13.6.Classe de tráfego

(202)Devem ser definidas DENM novas e de atualização para a traffic class 0.

13.7.Parâmetros de mensagem

13.7.1.DENM

(203)O quadro a seguir especifica os elementos de dados de DENM que devem ser definidos.

Quadro 27: Elementos de dados de DENM de «luz de travagem de emergência eletrónica»

Campo de dados

Valor

Contenção de gestão

actionID

Identificador de uma DENM. Deve ser definido em conformidade com a norma [TS 102 894-2].

detectionTime

- timestamp em que o evento é detetado pela estação STI-C de origem. Deve ser definido em conformidade com a norma [TS 102 894-2].

Deve ser renovado para uma DENM de atualização.

referenceTime

TimestampIts - em que é gerada uma DENM nova ou uma DENM de atualização. Deve ser definido em conformidade com a norma [TS 102 894-2].

termination

Não deve ser definido, pois nem a negação nem o cancelamento devem ser utilizados neste serviço STI-C.

eventPosition

. Deve ser definido em conformidade com a norma [TS 102 894-2].

Deve ser renovado a cada DENM de atualização.

relevanceDistance

lessThan500m(3)

relevanceTrafficDirection

Se o roadType for conhecido, o valor deve ser definido da seguinte forma:

RoadType

Sentido 

0

allTrafficDirections(0) 

1

upstreamTraffic(1) 

2

allTrafficDirections(0) 

3

upstreamTraffic(1) 

Caso contrário, o valor deve ser definido para allTrafficDirections(0)

validityDuration

2 s

stationType

O tipo de estação STI-C de origem. Deve ser definido em conformidade com a norma [TS 102 894-2].

Contenção de situação

informationQuality

Ver ponto (193).

causeCode

dangerousSituation(99)

subCauseCode

emergencyElectronicBrakeEngaged(1)

Contenção de localização

eventSpeed

Velocidade da estação STI-C de origem. Deve ser definido em conformidade com a norma [TS 102 894-2].

Deve ser renovado para uma DENM de atualização.

eventPositionHeading

Rumo da estação STI-C de origem. Deve ser definido em conformidade com a norma [TS 102 894-2].

Deve ser renovado para uma DENM de atualização.

traces

da estação STI-C de origem. Deve ser definido em conformidade com a norma [TS 102 894-2].

Deve ser renovado para uma DENM de atualização.

roadType

RoadType da estrada em que a estação STI-C de deteção está situada.

Deve ser renovado para uma DENM de atualização.

Deve ser definido em conformidade com a norma [TS 102 894-2] em conjugação com as seguintes regras:

Urbano / Não urbano

Separação estrutural

Elemento de dados

Urbano

Não

urbano-NoStructuralSeparation ToOppositeLanes(0)

Urbano

Sim

urbano-WithStructuralSeparation ToOppositeLanes(1)

Urbano

Desconhecido

urbano-NoStructuralSeparation ToOppositeLanes(0)

Não urbano

Não

nãoUrbano-NoStructuralSeparation ToOppositeLanes(2)

Não urbano

Sim

nãoUrbano-WithStructuralSeparation ToOppositeLanes(3)

Não urbano

Desconhecido

nãoUrbano-NoStructuralSeparation ToOppositeLanes(2)

Se não for possível determinar as informações sobre o estatuto urbano/não urbano, deve ser omitido o elemento de dados.

Contenção a la carte

lanePosition

Se a lanePosition for fornecida por um sensor de bordo (por exemplo, radar ou câmara), o valor deve ser definido de acordo com a norma [TS 102 894-2]. Não é permitida a utilização de um sistema GNSS e de um mapa digital para estimar o número da faixa para esta versão da condição de acionamento.

Se a lanePosition for desconhecida, o elemento de dados deve ser omitido.

Deve ser renovado para uma DENM de atualização.

13.7.2.CAM

(204)Não deve ser utilizada a CAM de adaptação para este serviço STI-C.

13.8.Rede e camada de transporte

(205)O parâmetro de interface DENM destination area entre o serviço básico DEN e a rede e a camada de transporte devem ser iguais a uma forma circular com raio igual à relevanceDistance.

13.9.Camada de segurança

(206)No caso de se aplicarem as condições de acionamento conforme descrito no ponto (193), será bloqueada uma alteração de BA para DENM novas e de atualização, desde que a validityDuration não tenha expirado. Devem ser enviadas DENM novas e de atualização correspondentes com o mesmo CA.

14.Situação perigosa — intervenção do travão automático

14.1.Descrição do serviço STI-C

Este serviço STI-C transmite informações V2V sobre uma intervenção da travagem de emergência autónoma pelo veículo. O próprio veículo ego passa a ser uma possível zona de perigo local.

Os seguintes serviços STI-C estão relacionados com este serviço, pois partilham condições de acionamento semelhantes:

·«situações perigosas — luz de travagem de emergência eletrónica»;

·«situações perigosas — intervenção do sistema reversível de retenção de ocupantes».

14.2.Condições de acionamento

14.2.1.Condições prévias

(207)Não se aplicam condições prévias específicas a este serviço STI-C.

(208)Deve ser evitada a ativação paralela com os outros serviços STI-C relacionados. Nos casos em que os serviços STI-C «luz de travagem de emergência eletrónica» e/ou «intervenção do sistema reversível de retenção de ocupantes» são acionados em simultâneo, os serviços STI-C devem seguir a seguinte ordem de prioridades:

(a)«luz de travagem de emergência eletrónica» (prioridade mais alta);

(b)«intervenção do travão automático»;

(c)«intervenção do sistema reversível de retenção de ocupantes» (prioridade mais baixa).

(209)Se um serviço STI-C de prioridade mais alta for acionado, qualquer transmissão relacionada de serviços STI-C de prioridade inferior que já tenha sido acionada e ainda esteja ativa em relação à atualização deverá ser abortada. Além disso, deve ser solicitada a geração de uma DENM nova para o serviço STI-C de prioridade mais alta.

14.2.2.Condições específicas do serviço

(210)Se estiver reunida a seguinte condição, consideram-se reunidas as condições de acionamento deste serviço STI-C e deve ser acionada a geração de uma DENM:

(a)é detetado um sinal que representa um pedido de intervenção de um sistema de travagem de emergência autónoma.

(211)A aceleração do veículo deve ser determinada pelo sinal de barramento do veículo e não por um sistema GNSS. Deve ser utilizada a aceleração filtrada em relação ao ruído do sensor.

14.2.3.Qualidade das informações

(212)O valor do elemento de dados informationQuality na DENM depende da forma como o evento é detetado (ver ponto (210)). O valor informationQuality deve ser definido de acordo com o seguinte quadro (deve ser utilizado o valor mais alto possível):

Quadro 28: Qualidade das informações de «intervenção do travão automático»

Deteção de evento

Valor da informationQuality

Sem implementação em conformidade com as TRCO

0

A condição a) está reunida

1

Condição a) reunida e atual aceleração longitudinal filtrada do veículo <-4 m/s^2

2

(213)Se as condições de acionamento se alterarem entre duas atualizações, a informationQualitynão deve ser alterada até à próxima atualização. Se as condições alteradas ainda estiverem reunidas enquanto a DENM é atualizada, a informationQuality deve ser atualizada.

14.3.Condições de terminação

(214)O serviço STI-C deve ser terminado quando a condição a) já não for válida. Aquando da terminação do serviço STI-C, o pedido de atualização da DENM deve ser terminado.

14.3.1.Cancelamento

(215)Não deve ser utilizada uma DENM de cancelamento para este serviço STI-C.

14.3.2.Negação

(216)Não deve ser utilizada uma DENM de negação para este serviço STI-C.

14.4.Atualização

(217)A DENM gerada deve ser atualizada a cada 100 ms se ainda estiverem reunidas as condições de acionamento. Todos os campos de dados que recebem novos valores são definidos no Quadro 29.

14.5.Duração de repetição e intervalo de repetição

(218)Não deve ser utilizada uma DENM de repetição para este serviço STI-C.

14.6.Classe de tráfego

(219)Devem ser definidas DENM novas e de atualização para a traffic class 0.

14.7.Parâmetros de mensagem

14.7.1.DENM

(220)O quadro a seguir especifica os elementos de dados de DENM que devem ser definidos.

Quadro 29: Elementos de dados de DENM de «intervenção do travão automático»

Campo de dados

Valor

Contenção de gestão

actionID

Identificador de uma DENM. Deve ser definido em conformidade com a norma [TS 102 894-2].

detectionTime

TimestampIts- timestamp em que o evento é detetado pela estação STI-C de origem. Deve ser definido em conformidade com a norma [TS 102 894-2].

Deve ser renovado para uma DENM de atualização.

referenceTime

TimestampIts - timestamp em que é gerada uma DENM nova ou uma DENM de atualização. Deve ser definido em conformidade com a norma [TS 102 894-2].

termination

Não deve ser definido, pois nem a negação nem o cancelamento devem ser utilizados neste serviço STI-C.

eventPosition

ReferencePosition. Deve ser definido em conformidade com a norma [TS 102 894-2].

Deve ser renovado a cada DENM de atualização.

relevanceDistance

lessThan500m(3)

relevanceTrafficDirection

Se o roadType for conhecido, o valor deve ser definido da seguinte forma:

RoadType

Sentido 

0

allTrafficDirections(0) 

1

upstreamTraffic(1) 

2

allTrafficDirections(0) 

3

upstreamTraffic(1) 

Caso contrário, o valor deve ser definido para allTrafficDirections(0)

validityDuration

2 s

stationType

O tipo de estação STI-C de origem. Deve ser definido em conformidade com a norma [TS 102 894-2].

Contenção de situação

informationQuality

Ver ponto (210)

causeCode

dangerousSituation(99)

subCauseCode

aebEngaged(5)

Contenção de localização

eventSpeed

Velocidade da estação STI-C de origem. Deve ser definido em conformidade com a norma [TS 102 894-2].

Deve ser renovado para uma DENM de atualização.

eventPositionHeading

Rumo da estação STI-C de origem. Deve ser definido em conformidade com a norma [TS 102 894-2].

Deve ser renovado para uma DENM de atualização.

traces

PathHistory da estação STI-C de origem. Deve ser definido em conformidade com a norma [TS 102 894-2].

Deve ser renovado para uma DENM de atualização.

roadType

RoadType da estrada em que a estação STI-C de deteção está situada.

Deve ser renovado para uma DENM de atualização.

Deve ser definido em conformidade com a norma [TS 102 894-2] em conjugação com as seguintes regras:

Urbano / Não urbano

Separação estrutural

Elemento de dados

Urbano

Não

urbano-NoStructuralSeparation ToOppositeLanes(0)

Urbano

Sim

urbano-WithStructuralSeparation ToOppositeLanes(1)

Urbano

Desconhecido

urbano-NoStructuralSeparation ToOppositeLanes(0)

Não urbano

Não

nãoUrbano-NoStructuralSeparation ToOppositeLanes(2)

Não urbano

Sim

nãoUrbano-WithStructuralSeparation ToOppositeLanes(3)

Não urbano

Desconhecido

nãoUrbano-NoStructuralSeparation ToOppositeLanes(2)

Se não for possível determinar as informações sobre o estatuto urbano/não urbano, deve ser omitido o elemento de dados.

Contenção a la carte

lanePosition

Se a lanePosition for fornecida por um sensor de bordo (por exemplo, radar ou câmara), o valor deve ser definido de acordo com a norma [TS 102 894-2]. Não é permitida a utilização de um sistema GNSS e de um mapa digital para estimar o número da faixa para esta versão da condição de acionamento.

Se a lanePosition for desconhecida, o elemento de dados deve ser omitido.

Deve ser renovado para uma DENM de atualização.

14.7.2.CAM

(221)Não deve ser utilizada a CAM de adaptação para este serviço STI-C.

14.8.Rede e camada de transporte

(222)O parâmetro de interface DENM destination area entre o serviço básico DEN e a rede e a camada de transporte devem ser iguais a uma forma circular com raio igual à relevanceDistance.

14.9.Camada de segurança

(223)No caso de se aplicarem as condições de acionamento conforme descrito no ponto (210), será bloqueada uma alteração de CA para DENM novas e de atualização, desde que a validityDuration não tenha expirado. Devem ser enviadas DENM novas e de atualização correspondentes com o mesmo CA.

15.Situação perigosa — intervenção do sistema reversível de retenção de ocupantes

15.1.Descrição do serviço STI-C

Este serviço STI-C transmite informações V2V sobre uma intervenção ativa de um sistema reversível de retenção de ocupantes (por exemplo, tensor de cinto de segurança reversível) no veículo ego devido a uma situação de condução crítica.

Os seguintes serviços STI-C estão relacionados com este serviço, pois partilham condições de acionamento semelhantes:

·«situações perigosas — luz de travagem de emergência eletrónica»;

·«situações perigosas — intervenção do travão automático».

15.2.Condições de acionamento

15.2.1.Condições prévias

(224)Não se aplicam condições prévias específicas a este serviço STI-C.

(225)Deve ser evitada a ativação paralela com os outros serviços STI-C relacionados. Nos casos em que os serviços STI-C «luz de travagem de emergência eletrónica» e/ou «intervenção do travão automático» são acionados em simultâneo, os serviços STI-C devem seguir a seguinte ordem de prioridades:

(a)«luz de travagem de emergência eletrónica» (prioridade mais alta);

(b)«intervenção do travão automático»;

(c)«intervenção do sistema reversível de retenção de ocupantes» (prioridade mais baixa).

(226)Se um serviço STI-C de prioridade mais alta for acionado, qualquer transmissão relacionada de serviços STI-C de prioridade inferior que já tenha sido acionada e ainda esteja ativa em relação à atualização deverá ser abortada. Além disso, deve ser solicitada a geração de uma DENM nova para o serviço STI-C de prioridade mais alta.

15.2.2.Condições específicas do serviço

(227)Se estiver reunida a seguinte condição, será acionada a geração de uma DENM:

(a)é detetado um sinal que representa um pedido de intervenção ativa de um sistema reversível de retenção de ocupantes (por exemplo, tensor de cinto de segurança reversível) devido a uma situação crítica de condução.

15.2.3.Qualidade das informações

(228)O valor do elemento de dados informationQuality na DENM depende da forma como o evento é detetado (ver ponto (227)). O valor informationQuality deve ser definido de acordo com o seguinte quadro (deve ser utilizado o valor mais alto possível):

Quadro 30: Qualidade das informações de «intervenção do sistema reversível de retenção de ocupantes»

Deteção de evento

Valor da informationQuality

Sem implementação em conformidade com as TRCO

0

A condição a) está reunida

1

Condição a) reunida e atual aceleração longitudinal filtrada do veículo <-4 m/s^2

2

(229)Se as condições de acionamento se alterarem entre duas atualizações, a informationQualitynão deve ser alterada até à próxima atualização. Se as condições alteradas ainda estiverem reunidas enquanto a DENM é atualizada, a informationQuality deve ser atualizada.

15.3.Condições de terminação

(230)O serviço STI-C deve ser terminado quando a condição a) já não for válida. Aquando da terminação do serviço STI-C, o pedido de atualização da DENM deve ser terminado.

15.3.1.Cancelamento

(231)Não deve ser utilizada uma DENM de cancelamento para este serviço STI-C.

15.3.2.Negação

(232)Não deve ser utilizada uma DENM de negação para este serviço STI-C.

15.4.Atualização

(233)A DENM gerada deve ser atualizada a cada 100 ms se ainda estiverem reunidas as condições de acionamento. Todos os campos de dados que recebem novos valores são definidos no Quadro 31 abaixo.

15.5.Duração de repetição e intervalo de repetição

(234)Não deve ser utilizada uma DENM de repetição para este serviço STI-C.

15.6.Classe de tráfego

(235)Devem ser definidas DENM novas e de atualização para a traffic class 0.

15.7.Parâmetros de mensagem

15.7.1.DENM

(236)O quadro a seguir especifica os elementos de dados de DENM que devem ser definidos.

Quadro 31: Elementos de dados de DENM de «intervenção do sistema reversível de retenção de ocupantes»

Campo de dados

Valor

Contentor de gestão

actionID

Identificador de uma DENM. Deve ser definido em conformidade com a norma [TS 102 894-2].

detectionTime

SeloTemporalSTI - selo temporal em que o evento é detetado pela estação STI-C de origem. Deve ser definido em conformidade com a norma [TS 102 894-2].

Deve ser renovado para uma DENM de atualização.

referenceTime

TimestampIts - timestamp em que é gerada uma DENM nova ou uma DENM de atualização. Deve ser definido em conformidade com a norma [TS 102 894-2].

termination

Não deve ser definido, pois nem a negação nem o cancelamento devem ser utilizados neste serviço STI-C.

eventPosition

ReferencePosition. Deve ser definido em conformidade com a norma [TS 102 894-2].

Deve ser renovado a cada DENM de atualização.

relevanceDistance

lessThan500m(3)

relevanceTrafficDirection

Se o roadType for conhecido, o valor deve ser definido da seguinte forma:

RoadType

Sentido

0

allTrafficDirections(0)

1

upstreamTraffic(1)

2

allTrafficDirections(0)

3

upstreamTraffic(1)

Caso contrário, o valor deve ser definido para allTrafficDirections(0)

validityDuration

2 s

stationType

O tipo de estação STI-C de origem. Deve ser definido em conformidade com a norma [TS 102 894-2].

Contenção de situação

informationQuality

Ver ponto (226).

causeCode

dangerousSituation(99)

subCauseCode

preCrashSystemEngaged(2)

Contenção de localização

eventSpeed

Velocidade da estação STI-C de origem. Deve ser definido em conformidade com a norma [TS 102 894-2].

Deve ser renovado para uma DENM de atualização.

eventPositionHeading

Rumo da estação STI-C de origem. Deve ser definido em conformidade com a norma [TS 102 894-2].

Deve ser renovado para uma DENM de atualização.

traces

PathHistory da estação STI-C de origem. Deve ser definido em conformidade com a norma [TS 102 894-2].

Deve ser renovado para uma DENM de atualização.

roadType

RoadType da estrada em que a estação STI-C de deteção está situada.

Deve ser renovado para uma DENM de atualização.

Deve ser definido em conformidade com a norma [TS 102 894-2] em conjugação com as seguintes regras:

Urbano / Não urbano

Separação estrutural

Elemento de dados

Urbano

Não

urbano-NoStructuralSeparation ToOppositeLanes(0)

Urbano

Sim

urbano-WithStructuralSeparation ToOppositeLanes(1)

Urbano

Desconhecido

urbano-NoStructuralSeparation ToOppositeLanes(0)

Não urbano

Não

nãoUrbano-NoStructuralSeparation ToOppositeLanes(2)

Não urbano

Sim

nãoUrbano-WithStructuralSeparation ToOppositeLanes(3)

Não urbano

Desconhecido

nãoUrbano-NoStructuralSeparation ToOppositeLanes(2)

Se não for possível determinar as informações sobre o estatuto urbano/não urbano, deve ser omitido o elemento de dados.

Contenção a la carte

lanePosition

Se a lanePositionfor fornecida por um sensor de bordo (por exemplo, radar ou câmara), o valor deve ser definido de acordo com a norma [TS 102 894-2]. Não é permitida a utilização de um sistema GNSS e de um mapa digital para estimar o número da faixa para esta versão da condição de acionamento.

Se a lanePosition for desconhecida, o elemento de dados deve ser omitido.

Deve ser renovado para uma DENM de atualização.

15.7.2.CAM

(237)Não deve ser utilizada a CAM de adaptação para este serviço STI-C.

15.8.Rede e camada de transporte

(238)O parâmetro de interface DENM destination area entre o serviço básico DEN e a rede e a camada de transporte devem ser iguais a uma forma circular com raio igual à relevanceDistance.

15.9.Camada de segurança

(239)No caso de se aplicarem as condições de acionamento conforme descrito no ponto (227), será bloqueada uma alteração de CA para DENM novas e de atualização, desde que a validityDuration não tenha expirado. Devem ser enviadas DENM novas e de atualização correspondentes com o mesmo CA.

16.Condições meteorológicas adversas — nevoeiro

16.1.Descrição do serviço STI-C

Este serviço STI-C transmite informações de V2V sobre o nevoeiro que pode dificultar a visão do condutor.

Os seguintes serviços STI-C estão relacionados com este serviço, pois partilham condições de acionamento semelhantes:

·«condições meteorológicas adversas — precipitação».

(240)Apenas deve ser enviado um sinal de DENM para a pilha se as condições de acionamento descritas no presente ponto forem consideradas válidas. Esse sinal induz a pilha a gerar uma DENM nova ou de atualização. Se não estiverem reunidas as condições de acionamento, não deve ser gerado um sinal de DENM.

16.2.Condições de acionamento

16.2.1.Condições prévias

(241)Antes de um serviço STI-C ser acionado, devem estar reunidas as seguintes condições prévias:

(a)a velocidade do veículo é superior a 7 km/h;

(b)a velocidade do veículo é inferior a 80 km/h;

(242)A velocidade do veículo deve ser determinada pelo sinal de barramento do veículo e não por um sistema GNSS. Deve ser utilizada a velocidade filtrada do veículo (no que se refere ao ruído do sensor).

16.2.2.Condições específicas do serviço

(243)Se estiverem reunidas as condições prévias indicadas no ponto (241) e, pelo menos, uma das seguintes condições, consideram-se reunidas as condições de acionamento deste serviço STI-C e deve ser acionada a geração de uma DENM:

(1)reação do condutor e estado das luzes:

(a)o condutor ativa as luzes de nevoeiro da retaguarda e os faróis de médios. Todas essas condições devem ser válidas por mais de 20 s (para minimizar o risco de utilização indevida pelo condutor, as condições devem ser válidas por um período mais longo);

(b)o condutor ativa as luzes de nevoeiro da retaguarda, os faróis de médios e a velocidade do veículo é inferior a 60 km/h. Todas estas condições devem ser válidas por mais de 20 s;

(2)dispositivo de medição do campo de visibilidade;

(a)a visibilidade devido ao nevoeiro é inferior a 80 m +/- 40 m de tolerância por mais de 5 s (a visão obscurecida deve ser detetada por um período razoável. O período é mais curto do que para as condições a) e b), devido à maior fiabilidade das informações);

(b)a visibilidade devido ao nevoeiro é inferior a 80 m +/- 40 m de tolerância e a velocidade do veículo é inferior a 60 km/h (se o veículo estiver numa área não urbana, essa velocidade poderia ser uma indicação de visibilidade reduzida) por mais de 5 s.

(244)Não deve ser gerada uma DENM nova ou de atualização no Detection Blocking Time. O Detection Blocking Time é iniciado após o evento ser detetado e ter sido acionada uma DENM para esse efeito. Desta forma, não é possível que um único evento acione uma série de DENM. Para o dispositivo de medição do campo de visibilidade (condições c) e d)), o Detection Blocking Time deve ser de 15 s. Para as outras condições, não deve haver Detection Blocking Time.

(245)Para assegurar um comportamento funcional coerente para as diferentes condições de acionamento e o Detection Blocking Time, o Minimum Detection Interval entre dois eventos detetados deve ser de 20 s.

16.2.3.Qualidade das informações

(246)O valor do elemento de dados informationQuality na DENM depende da forma como o evento é detetado (ver ponto (243)). O valor informationQuality deve ser definido de acordo com o seguinte quadro (deve ser utilizado o valor mais alto possível):

Quadro 32: Qualidade das informações de «condições meteorológicas adversas — nevoeiro»

Deteção de evento

Valor da informationQuality

Sem implementação em conformidade com as TRCO

desconhecido(0)

A condição a) está reunida

1

A condição b) está reunida

2

A condição c) está reunida

3

A condição d) está reunida

4

(247)Se as condições de acionamento se alterarem entre duas atualizações, a informationQualitynão deve ser alterada até à próxima atualização. Se as condições alteradas ainda estiverem reunidas enquanto a DENM é atualizada, a informationQuality deve ser atualizada.

16.3.Condições de terminação

(248)Não será considerada a terminação do serviço STI-C.

16.3.1.Cancelamento

(249)Não deve ser utilizada uma DENM de cancelamento para este serviço STI-C.

16.3.2.Negação

(250)Não deve ser utilizada uma DENM de negação para este serviço STI-C.

16.4.Atualização

(251)O procedimento de atualização adequado da DENM deve ser determinado com base nas seguintes condições:

(a)está reunida pelo menos uma das condições do ponto (243) após o Minimum Detection Interval especificado no ponto 16.2.2;

(b)a validityDuration da DENM anterior não expirou;

(c)nem o valor do elemento de dados LatitudeDeltaDeltaLatitude nem o do elemento de dados LongitudeDeltaDeltaLongitude, que representam a distância entre o evento detetado atual e o evento detetado anterior, excedem o limite que pode ser abrangido pelos elementos de dados DeltaLatitude e DeltaLongitude.

(252)No caso de se reunirem as condições a), b) e c) especificadas no ponto (251), deve ser gerada uma DENM de atualização. As informações dos elementos de dados anteriores da DENM (eventPosition, eventDeltaTime, informationQuality) devem ser armazenadas no eventHistory enquanto eventPoint adicional.

Os pontos de evento devem seguir uma ordem ascendente em relação ao seu tempo de vida, com o eventPoint mais recente na primeira posição. Os pontos de evento no eventHistory com tempos de vida que excedem a validityDuration devem ser excluídos do eventHistory para a DENM de atualização. Se a distância abrangida pelo eventHistory exceder o limite permitido pela segurança, os pontos de evento mais antigos serão excluídos do mesmo.

As informações do evento atual detetado devem ser atribuídas aos campos de dados de DENM da DENM atualizada.

Nota: cabe ao recetor o tratamento dos pontos de evento com tempos de vida que excedem a validityDuration após a geração da DENM de atualização.

(253)Se as condições a) e b) estiverem reunidas, mas não a condição c), não deve ser gerada qualquer DENM de atualização. Em vez disso, deve ser gerada uma DENM nova. As informações do evento atual detetado devem ser atribuídas aos campos de dados de DENM da DENM nova adicional. A anterior DENM deve continuar a ser transmitida enquanto a repetitionDuration da anterior DENM não expirar.

(254)Se estiver reunida a condição a), mas não a condição b), não deve ser gerada qualquer DENM de atualização, mas sim uma DENM nova de acordo com o evento atualmente detetado.

Nota: nesse caso, a transmissão da antiga DENM já foi terminada, porque a repetitionDuration da antiga DENM expirou.

(255)Caso não se verifique a condição a), não é necessário gerar uma DENM de atualização.

16.5.Duração de repetição e intervalo de repetição

(256)As DENM novas ou que foram atualizadas devem ser repetidas para uma repetitionDuration de 180 s com um repetitionInterval de 4 s. Consequentemente, os parâmetros de interface repetitionDuration e repetitionInterval entre a aplicação e o serviço básico de DEN devem ser definidos de acordo com os valores acima indicados.

Nota: a validityDuration está regulada para 300 s. Desta forma, é possível evitar uma lacuna de DENM se a repetitionDuration da DENM original tiver expirado e a atualização ainda não tiver sido recebida.

Nota: quando duas DENM com o mesmo causeCode provêm da mesma estação STI-C, o caso deve ser gerido pela estação STI-C recetora.

16.6.Classe de tráfego

(257)Devem ser definidas DENM novas e de atualização para a traffic class 1.

16.7.Parâmetros de mensagem

16.7.1.DENM

(258)O quadro a seguir especifica os elementos de dados de DENM que devem ser definidos.

Quadro 33: Elementos de dados de DENM de «condições meteorológicas adversas — nevoeiro»

Campo de dados

Valor

Contenção de gestão

actionID

Identificador de uma DENM. Deve ser definido em conformidade com a norma [TS 102 894-2].

detectionTime

TimestampIts- timestamp em que o evento é detetado pela estação STI-C de origem. O selo temporal reflete o início da deteção do evento atual. Deve ser definido em conformidade com a norma [TS 102 894-2].

Deve ser renovado para uma DENM de atualização e definido para o tempo de deteção do atual evento.

referenceTime

TimestampIts - timestamp em que é gerada uma DENM nova ou uma DENM de atualização. Deve ser definido em conformidade com a norma [TS 102 894-2].

termination

Não deve ser definido, pois nem a negação nem o cancelamento devem ser utilizados neste serviço STI-C.

eventPosition

ReferencePosition. Deve ser definido em conformidade com a norma [TS 102 894-2].

Deve ser renovado para uma DENM de atualização.

relevanceDistance

·DENM nova: lessThan1000m(4)

·DENM de atualização: lessThan5km(5) (Ao utilizar atualizações, a distância abrangida pelo eventHistory torna-se mais longa. Para considerar todas as estações STI relevantes, a relevanceDistance é maior neste caso.

relevanceTrafficDirection

allTrafficDirections(0)

validityDuration

300 s

stationType

O tipo de estação STI-C de origem. Deve ser definido em conformidade com a norma [TS 102 894-2].

Contenção de situação

informationQuality

Ver ponto (246). Deve ser renovado para cada DENM de atualização e definido para a informationQuality do atual ponto de evento.

causeCode

adverseWeatherCondition-Visibility(18)

subCauseCode

indisponível(0) ou nevoeiro(1)

eventHistory

Este elemento apenas deve ser utilizado para DENM de atualização (ver ponto 16.4).

Contenção de localização

traces

PathHistory da estação STI-C de origem em relação ao ponto de evento atual.
Deve ser definido em conformidade com a norma [TS 102 894-2].
Deve ser renovado para uma DENM de atualização.

roadType

RoadType da estrada em que a estação STI-C de deteção está situada.

Deve ser renovado para uma DENM de atualização.

Deve ser definido em conformidade com a norma [TS 102 894-2] em conjugação com as seguintes regras:

Urbano / Não urbano

Separação estrutural

Elemento de dados

Urbano

Não

urbano-NoStructuralSeparation ToOppositeLanes(0)

Urbano

Sim

urbano-WithStructuralSeparation ToOppositeLanes(1)

Urbano

Desconhecido

urbano-NoStructuralSeparation ToOppositeLanes(0)

Não urbano

Não

nãoUrbano-NoStructuralSeparation ToOppositeLanes(2)

Não urbano

Sim

nãoUrbano-WithStructuralSeparation ToOppositeLanes(3)

Não urbano

Desconhecido

nãoUrbano-NoStructuralSeparation ToOppositeLanes(2)

Se não for possível determinar as informações sobre o estatuto urbano/não urbano, deve ser omitido o elemento de dados.

16.7.2.CAM

(259)Não deve ser utilizada a CAM de adaptação para este serviço STI-C.

16.8.Rede e camada de transporte

(260)O parâmetro de interface DENM destination area entre o serviço básico DEN e a rede e a camada de transporte devem ser iguais a uma forma circular com raio igual à relevanceDistance.

16.9.Camada de segurança

(261)No caso de se aplicarem as condições de acionamento conforme descrito no ponto (243), será bloqueada uma alteração de CA para DENM novas e de atualização durante 15 minutos (desde o momento em que a DENM nova foi gerada). Devem ser enviadas DENM novas e de atualização correspondentes com o mesmo CA.

(262)Se o CA mudar e houver uma transmissão de DENM ativa (DENM nova ou de atualização), a transmissão deve ser interrompida. Adicionalmente, o EventHistory e o PathHistory devem ser eliminados. O processo de geração regular de DENM deve então prosseguir.

17.Condições meteorológicas adversas — precipitação

17.1.Descrição do serviço STI-C

Este serviço STI-C transmite informações de V2V sobre a precipitação que pode dificultar a visão do condutor.

Os seguintes serviços STI-C estão relacionados com este serviço, pois partilham condições de acionamento semelhantes:

·«condições meteorológicas adversas — nevoeiro».

(263)Apenas deve ser enviado um sinal de DENM para a pilha se as condições de acionamento descritas no presente ponto forem consideradas válidas. Esse sinal induz a pilha a gerar uma DENM nova ou de atualização. Se não estiverem reunidas as condições de acionamento, não deve ser gerado um sinal de DENM.

17.2.Condições de acionamento

17.2.1.Condições prévias

(264)Antes de um serviço STI-C ser acionado, devem estar reunidas as seguintes condições prévias:

(a)a velocidade do veículo é superior a 7 km/h;

(b)a velocidade do veículo é inferior a 80 km/h;

(c)a função limpa para-brisas não está ativa.

(265)A velocidade do veículo deve ser determinada pelo sinal de barramento do veículo e não por um sistema GNSS. Deve ser utilizada a velocidade filtrada do veículo (no que se refere ao ruído do sensor).

17.2.2.Condições específicas do serviço

(266)Se estiverem reunidas as condições prévias indicadas no ponto (264) e, pelo menos, uma das seguintes condições, consideram-se reunidas as condições de acionamento deste serviço STI-C e deve ser acionada a geração de uma DENM.

(1)velocidade dos limpa-vidros e estado das luzes:

(a)os limpa-vidros funcionam à velocidade máxima. Estão ativados os faróis de médios. Todas estas condições devem ser válidas por mais de 20 s;

(b)os limpa-vidros funcionam à velocidade máxima e a velocidade do veículo é inferior a 60 km/h. Estão ativados os faróis de médios. Todas estas condições devem ser válidas por mais de 20 s;

(2)sensor de chuva, velocidade dos limpa-vidros e estado das luzes:

(a)a pluviosidade é igual a pelo menos 90 % da resposta do sensor e os limpa-vidros funcionam à velocidade máxima. Estão ativados os faróis de médios. Todas estas condições devem ser válidas por mais de 20 s;

(b)a pluviosidade é igual a pelo menos 90 % da resposta do sensor e os limpa-vidros funcionam à velocidade máxima. Os faróis de médios estão ativados e a velocidade do veículo é inferior a 60 km/h. Todas estas condições devem ser válidas por mais de 20 s.

(267)O Minimum Detection Interval entre dois eventos detetados deve ser de 20 s.

17.2.3.Qualidade das informações

(268)O valor do elemento de dados informationQuality na DENM depende da forma como o evento é detetado (ver ponto (266)). O valor informationQuality deve ser definido de acordo com o seguinte quadro (deve ser utilizado o valor mais alto possível):

Quadro 34: Qualidade das informações de «condições meteorológicas adversas — precipitação»

Deteção de evento

Valor da informationQuality

Sem implementação em conformidade com as TRCO

desconhecido(0)

A condição a) está reunida

1

A condição b) está reunida

2

A condição c) está reunida

3

A condição d) está reunida

4

(269)Se as condições de acionamento se alterarem entre duas atualizações, a informationQualitynão deve ser alterada até à próxima atualização. Se as condições alteradas ainda estiverem reunidas enquanto a DENM é atualizada, a informationQuality deve ser atualizada.

17.3.Condições de terminação

(270)Não será considerada a terminação do serviço STI-C.

17.3.1.Cancelamento

(271)Não deve ser utilizada uma DENM de cancelamento para este serviço STI-C.

17.3.2.Negação

(272)Não deve ser utilizada uma DENM de negação para este serviço STI-C.

17.4.Atualização

(273)O procedimento de atualização adequado da DENM deve ser determinado com base nas seguintes condições:

(a)está reunida pelo menos uma das condições do ponto (240) após o Minimum Detection Interval especificado no ponto 17.2.2;

(b)a validityDuration da DENM anterior não expirou;

(c)nem o valor do elemento de dados LatitudeDelta DeltaLongitudeDeltaLatitude nem o do elemento de dados DeltaLongitude, que representam a distância entre o evento detetado atual e o evento detetado anterior, excedem o limite que pode ser abrangido pelos elementos de dados DeltaLatitude e DeltaLongitude.

(274)No caso de se reunirem as condições a), b) e c) especificadas no ponto (273), deve ser gerada uma DENM de atualização. As informações dos elementos de dados anteriores da DENM (eventPosition, eventDeltaTime, informationQuality) devem ser armazenadas no eventHistory enquanto eventPoint adicional.

Os pontos de evento devem seguir uma ordem ascendente em relação ao seu tempo de vida, com o eventPoint mais recente na primeira posição. Os pontos de evento no eventHistory com tempos de vida que excedem a validityDuration devem ser eliminados do eventHistory para a DENM de atualização. Se a distância abrangida pelo eventHistory exceder o limite permitido pela segurança, os pontos de evento mais antigos serão eliminados do mesmo.

As informações do evento atual detetado terão de ser atribuídas aos campos de dados de DENM da DENM atualizada.

Nota: cabe ao recetor o tratamento dos pontos de evento com tempos de vida que excedem a validityDuration após a geração da DENM de atualização.

(275)Se as condições a) e b) estiverem reunidas, mas não a condição c), não deve ser gerada qualquer DENM de atualização. Em vez disso, deve ser gerada uma DENM nova. As informações do evento atual detetado terão de ser atribuídas aos campos de dados de DENM da DENM nova adicional. A anterior DENM deve continuar a ser transmitida enquanto a repetitionDuration da anterior DENM não expirar.

(276)Se estiver reunida a condição a), mas não a condição b), não deve ser gerada qualquer DENM de atualização, mas sim uma DENM nova de acordo com o evento atualmente detetado.

Nota: nesse caso, a transmissão da antiga DENM já foi terminada, porque a repetitionDuration da antiga DENM expirou.

(277)Caso não se verifique a condição a), não é necessário gerar uma DENM de atualização.

17.5.Duração de repetição e intervalo de repetição

(278)As DENM novas ou que foram atualizadas devem ser repetidas para uma repetitionDuration de 180 s com um repetitionInterval de 4 s. Consequentemente, os parâmetros de interface repetitionDuration e repetitionInterval entre a aplicação e o serviço básico de DEN devem ser definidos de acordo com os valores acima.

Nota: a validityDuration está regulada para 300 s. Desta forma, é possível evitar uma lacuna de DENM se a repetitionDuration da DENM original tiver expirado e a atualização ainda não tiver sido recebida.

Nota: Quando duas DENM com o mesmo causeCode provêm da mesma estação STI-C, o caso deve ser gerido pela estação STI-C recetora.

17.6.Classe de tráfego

(279)Devem ser definidas DENM novas e de atualização para a traffic class 1.

17.7.Parâmetros de mensagem

17.7.1.DENM

(280)O quadro a seguir especifica os elementos de dados de DENM que devem ser definidos.

Quadro 35: Elementos de dados de DENM de «condições meteorológicas adversas — precipitação»

Campo de dados

Valor

Contentor de gestão

actionID

Identificador de uma DENM. Deve ser definido em conformidade com a norma [TS 102 894-2].

detectionTime

TimestampIts- timestamp em que o evento é detetado pela estação STI-C de origem. O selo temporal reflete o início da deteção do ponto de evento atual. Deve ser definido em conformidade com a norma [TS 102 894-2].

Deve ser renovado para uma DENM de atualização e definido para o tempo de deteção do atual ponto de evento.

tempoDeReferência

TimestampIts - timestamp em que é gerada uma DENM nova ou uma DENM de atualização. Deve ser definido em conformidade com a norma [TS 102 894-2].

termination

Não deve ser definido, pois nem a negação nem o cancelamento devem ser utilizados neste serviço STI-C.

eventPosition

ReferencePosition. Deve ser definido em conformidade com a norma [TS 102 894-2].

Deve ser renovado para uma DENM de atualização e definido para a posição do atual ponto de evento.

relevanceDistance

·DENM nova: menosDe1000m(4)

·DENM de atualização: menosDe5km(5) (Ao utilizar atualizações, a distância abrangida pelo eventHistory torna-se mais longa. Para considerar todas as estações STI relevantes, a relevanceDistance é maior neste caso.)

relevanceTrafficDirection

allTrafficDirections(0)

validityDuration

300 s

stationType

O tipo de estação STI-C de origem. Deve ser definido em conformidade com a norma [TS 102 894-2].

Contenção de situação

informationQuality

Ver ponto (268). Deve ser renovado para cada DENM de atualização e definido para a informationQuality do atual ponto de evento.

causeCode

adverseWeatherCondition-Precipitation(19)

subCauseCode

unavailable(0), heavyRain(1) or heavySnowfall(2)

eventHistory

Este elemento apenas deve ser utilizado para DENM de atualização (ver ponto 17.4).

Contenção de localização

traces

PathHistory da estação STI-C de origem em relação ao ponto de evento atual.
Deve ser definido em conformidade com a norma [TS 102 894-2].
Deve ser renovado para uma DENM de atualização.

roadType

roadType da estrada em que a estação STI-C de deteção está situada.

Deve ser renovado para uma DENM de atualização e definido para o tipoDeEstrada do atual ponto de evento.

Deve ser definido em conformidade com a norma [TS 102 894-2] em conjugação com as seguintes regras:

Urbano / Não urbano

Separação estrutural

Elemento de dados

Urbano

Não

urbano-NoStructuralSeparation ToOppositeLanes(0)

Urbano

Sim

urbano-WithStructuralSeparation ToOppositeLanes(1)

Urbano

Desconhecido

urbano-NoStructuralSeparation ToOppositeLanes(0)

Não urbano

Não

nãoUrbano-NoStructuralSeparation ToOppositeLanes(2)

Não urbano

Sim

nãoUrbano-WithStructuralSeparation ToOppositeLanes(3)

Não urbano

Desconhecido

nãoUrbano-NoStructuralSeparation ToOppositeLanes(2)

Se não for possível determinar as informações sobre o estatuto urbano/não urbano, deve ser omitido o elemento de dados.

17.7.2.CAM

(281)Não deve ser utilizada a CAM de adaptação para este serviço STI-C.

17.8.Rede e camada de transporte

(282)O parâmetro de interface DENM destination area entre o serviço básico DEN e a rede e a camada de transporte devem ser iguais a uma forma circular com raio igual à relevanceDistance.

17.9.Camada de segurança

(283)No caso de se aplicarem as condições de acionamento conforme descrito no ponto (266), será bloqueada uma alteração de CA para DENM novas e de atualização durante 15 minutos (desde o momento em que a DENM nova foi gerada). Devem ser enviadas DENM novas e de atualização correspondentes com o mesmo CA.

(284)Se o CA mudar e houver uma transmissão ativa de uma DENM nova ou de atualização, a transmissão deve ser interrompida. Adicionalmente, o EventHistory e o PathHistory devem ser eliminados. O processo de geração regular de DENM deve então prosseguir.

18.Condições meteorológicas adversas — perda de tração

18.1.Descrição do serviço STI-C

Este serviço STI-C transmite informações de V2V sobre o estado escorregadio do piso, que pode afetar o comportamento de condução.

(285)Apenas deve ser enviado um sinal de DENM para a pilha se as condições de acionamento descritas no presente ponto forem consideradas válidas. Esse sinal induz a pilha a gerar uma DENM nova ou de atualização. Se não estiverem reunidas as condições de acionamento, não deve ser gerado um sinal de DENM.

18.2.Condições de acionamento

18.2.1.Condições prévias

(286)Antes de um serviço STI-C ser acionado, devem estar reunidas as seguintes condições prévias:

(a)a marcha-atrás não está ativada;

(b)não são comunicados erros no que respeita ao motor, à unidade de tração e ao sistema de travagem.

18.2.2.Condições específicas do serviço

(287)Se estiver reunida a condição prévia indicada no ponto (286) e, pelo menos, uma das seguintes condições, consideram-se reunidas as condições de acionamento deste serviço STI-C e deve ser acionada a geração de uma DENM:

(1)com base na aceleração positiva:

(a)com base no sistema de controlo de antipatinagem (ASR), no pedal de aceleração, na aceleração do veículo e na velocidade do veículo. Um pedido de ASR deve estar ativo durante pelo menos 200 ms (como para outras funções de segurança, dependendo do ASR). O pedal de aceleração é pressionado em média mais de 30 % quando a intervenção do ASR está ativa. A aceleração do veículo (aceleração de acordo com o sinal de barramento do veículo filtrado) é inferior a 40 % da aceleração do veículo em (uma superfície com um elevado coeficiente de atrito (tal como o piso seco (tipicamente µ = 0,85))) à mesma velocidade de arranque e manobra de condução. (Para abranger diferentes configurações de tração, por exemplo, duas rodas motrizes vs. quatro rodas motrizes, não foram definidos valores pormenorizados neste caso);

(b)com base no ASR, no pedal de aceleração, na aceleração do veículo e na velocidade do veículo. Um pedido de ASR deve estar ativo durante pelo menos 200 ms. O pedal de aceleração é pressionado em média mais de 30 % quando a intervenção do ASR está ativa. A aceleração do veículo (aceleração de acordo com o sinal de barramento do veículo filtrado) é inferior a 20 % da aceleração do veículo em (uma superfície com um elevado coeficiente de atrito (tal como o piso seco (tipicamente µ = 0,85))) com a mesma velocidade de arranque e manobra de condução;

(c)com base no ASR, no pedal de aceleração, na aceleração do veículo e na velocidade do veículo. Um pedido de ASR deve estar ativo durante pelo menos 200 ms. O pedal de aceleração é pressionado em média mais de 30 % quando a intervenção do ASR está ativa. A aceleração do veículo (aceleração de acordo com o sinal de barramento do veículo filtrado) é inferior a 10 % da aceleração do veículo em (uma superfície com um elevado coeficiente de atrito (tal como o piso seco (tipicamente µ = 0,85))) com a mesma velocidade de arranque e manobra de condução;

(d)com base no ASR e no pedal de aceleração. Um pedido de ASR deve estar ativo durante pelo menos 200 ms. O pedal de aceleração é pressionado em média menos de 30 % (de forma a não causar uma intervenção do ASR no solo com alto valor de atrito) quando a intervenção do ASR está ativa.

(2)com base na aceleração negativa (desaceleração):

(a)com base no sistema de travagem antibloqueio (ABS), na pressão de travagem e na desaceleração. A intervenção do ABS está ativa por mais de 200 ms (de acordo com outras funções de segurança, dependendo do ABS). A pressão de travagem é superior a 20 % da pressão máxima de travagem possível. A desaceleração do veículo (desaceleração de acordo com o sinal de barramento do veículo filtrado) é inferior a 50 % da desaceleração do veículo em (uma superfície com um elevado coeficiente de atrito (tal como o piso seco (tipicamente µ = 0,85))) com a mesma velocidade de arranque e manobra de condução;

(b)com base no ABS, na pressão de travagem e na desaceleração. A intervenção do ABS está ativa por mais de 200 ms. A pressão de travagem é superior a 20 % da pressão máxima de travagem possível. A desaceleração do veículo (desaceleração de acordo com o sinal de barramento do veículo filtrado) é inferior a 25 % da desaceleração do veículo em (uma superfície com um elevado coeficiente de atrito (tal como o piso seco (tipicamente µ = 0,85))) com a mesma velocidade de arranque e manobra de condução;

(c)com base no ABS, na pressão de travagem e na desaceleração. A intervenção do ABS está ativa por mais de 200 ms. A pressão de travagem é superior a 20 % (de forma a não causar uma intervenção do ABS no solo com alto valor de atrito) da pressão de travagem máxima possível. A desaceleração do veículo (desaceleração de acordo com o sinal de barramento do veículo filtrado) é inferior a 10 % da desaceleração do veículo em (uma superfície com um elevado coeficiente de atrito (tal como o piso seco (tipicamente µ = 0,85))) com a mesma velocidade de arranque e manobra de condução;

(d)com base no ABS e na pressão de travagem. A intervenção do ABS está ativa por mais de 200 ms. A pressão de travagem é inferior a 20 % da pressão máxima de travagem possível;

(3)com base na estimativa do coeficiente de atrito:

(a)o coeficiente de atrito é inferior a 0,3 durante pelo menos 5 s (o coeficiente de atrito do gelo é < 0,2; para neve e fragmentos soltos, é de aprox. 0,4. O coeficiente de atrito tem de ser detetado por um determinado período);

(b)o coeficiente de atrito é inferior a 0,2 durante pelo menos 5 s.

(288)Se as condições 1 a) a c) ou 2 a) a c) forem consideradas válidas, a aceleração/desaceleração do veículo deve ser determinada pelo sinal de barramento do veículo e não pela análise do GNSS.

(289)Não deve ser gerada uma DENM nova ou de atualização no Detection Blocking Time. O Detection Blocking Time é iniciado após o evento ser detetado e ter sido acionada uma DENM para esse efeito. Desta forma, não é possível que um único evento acione uma série de DENM. Para a estimativa do coeficiente de atrito (condições 3 a) e 3 b)), o Detection Blocking Time deve ser de 15 s. Para as outras condições, será de 20 s.

(290)Para assegurar um comportamento funcional coerente para as condições de acionamento a) a d) e o Detection Blocking Time, o Intervalo Mínimo de Deteção entre dois eventos detetados deve ser de 20 s.

18.2.3.Qualidade das informações

(291)O valor do elemento de dados informationQuality na DENM depende da forma como o evento é detetado (ver ponto (287)). O valor informationQuality deve ser definido de acordo com o seguinte quadro (deve ser utilizado o valor mais alto possível):

Quadro 36: Qualidade das informações de «condições meteorológicas adversas — perda de tração»

Deteção de evento

Valor da informationQuality

Sem implementação em conformidade com as TRCO

desconhecido(0)

A condição 1a) ou 2a) está reunida

1

A condição 1b) está reunida

2

A condição 1c) ou 2b) está reunida

3

A condição 2c) está reunida

4

Condição 1d) ou 2d) reunida

5

A condição 3a) está reunida

6

A condição 3b) está reunida

7

(292)Se as condições de acionamento se alterarem entre duas atualizações, a informationQualitynão deve ser alterada até à próxima atualização. Se as condições alteradas ainda estiverem reunidas enquanto a DENM é atualizada, a informationQuality deve ser atualizada.

18.3.Condições de terminação

(293)Não será considerada a terminação do serviço STI-C.

18.3.1.Cancelamento

(294)Não deve ser utilizada uma DENM de cancelamento para este serviço STI-C.

18.3.2.Negação

(295)Não deve ser utilizada uma DENM de negação para este serviço STI-C.

18.4.Atualização

(296)O procedimento de atualização adequado da DENM deve ser determinado com base nas seguintes condições:

(a)está reunida pelo menos uma das condições do ponto (287) após o Minimum Detection Interval especificado no ponto 18.2.2;

(b)a validityDuration da DENM anterior não expirou;

(c)nem o valor do elemento de dados DeltaLatitude nem o do elemento de dados DeltaLongitude, que representam a distância entre o evento detetado atual e o evento detetado anterior, excedem o limite que pode ser abrangido pelos elementos de dados DeltaLatitude e DeltaLongitude.

(297)No caso de se reunirem as condições a), b) e c) especificadas no ponto (296), deve ser gerada uma DENM de atualização. As informações dos elementos de dados anteriores da DENM (eventPosition, eventDeltaTime, informationQuality) devem ser armazenadas no eventHistory enquanto eventPoint adicional.

Os pontos de evento devem seguir uma ordem ascendente em relação ao seu tempo de vida, com o eventPoint mais recente na primeira posição. Os pontos de evento no eventHistory com tempos de vida que excedem a validityDuration (ver ponto (303)) devem ser eliminados do eventHistory para a DENM de atualização. Se a distância abrangida pelo eventHistory exceder o limite permitido pela segurança, os pontos de evento mais antigos serão eliminados do mesmo.

As informações do evento atual detetado terão de ser atribuídas aos campos de dados de DENM da DENM atualizada.

Nota: cabe ao recetor o tratamento dos pontos de evento com tempos de vida que excedem a validityDuration após a geração da DENM de atualização.

(298)Se as condições a) e b) estiverem reunidas, mas não a condição c), não deve ser gerada qualquer DENM de atualização. Em vez disso, deve ser gerada uma DENM nova. As informações do evento atual detetado devem ser atribuídas aos campos de dados de DENM da DENM nova adicional. A anterior DENM deve continuar a ser transmitida enquanto a repetitionDuration da anterior DENM não expirar.

(299)Se estiver reunida a condição a), mas não a condição b), não deve ser gerada qualquer DENM de atualização, mas sim uma DENM nova de acordo com o evento atualmente detetado.

Nota: nesse caso, a transmissão da antiga DENM já foi terminada, porque a repetitionDuration da antiga DENM expirou.

(300)Caso não se verifique a condição a), não é necessário gerar uma DENM de atualização.

18.5.Duração de repetição e intervalo de repetição

(301)Por predefinição, as DENM que são novas ou foram atualizadas devem ser repetidas para uma repetitionDuration de 300 s com um repetitionInterval de 1 s.

No entanto, se a DENM for acionada numa área urbana, conforme determinado por um mapa digital ou um algoritmo de sensor de bordo, deve ser repetida para uma repetitionDuration de 180 s com um repetitionInterval de 4 s.

Consequentemente, os parâmetros de interface repetitionDuration e repetitionIntervalde repetição entre a aplicação e o serviço básico de DEN devem ser definidos de acordo com os valores acima.

Nota: a validityDuration é regulada para 600 s ou 300 s, respetivamente. Desta forma, é possível evitar uma lacuna de DENM se a repetitionDuration da DENM original tiver expirado e a atualização ainda não tiver sido recebida.

Nota: quando duas DENM com o mesmo causeCode provêm da mesma estação STI-C, o caso deve ser gerido pela estação STI-C recetora.

18.6.Classe de tráfego

(302)Devem ser definidas DENM novas e de atualização para a traffic class 1.

18.7.Parâmetros de mensagem

18.7.1.DENM

(303)O quadro a seguir especifica os elementos de dados de DENM que devem ser definidos.

Quadro 37: Elementos de dados de DENM de «condições meteorológicas adversas — perda de tração»

Campo de dados

Valor

Contenção de gestão

actionID

Identificador de uma DENM. Deve ser definido em conformidade com a norma [TS 102 894-2].

detectionTime

TimestampIts- timestamp em que o evento é detetado pela estação STI-C de origem. O selo temporal reflete o início da deteção do ponto de evento atual. Deve ser definido em conformidade com a norma [TS 102 894-2].

Deve ser renovado para uma DENM de atualização e definido para o tempo de deteção do atual ponto de evento.

referenceTime

TimestampIts - timestamp em que é gerada uma DENM nova ou uma DENM de atualização. Deve ser definido em conformidade com a norma [TS 102 894-2].

termination

Não deve ser definido, pois nem a negação nem o cancelamento devem ser utilizados neste serviço STI-C.

eventPosition

ReferencePosition. Deve ser definido em conformidade com a norma [TS 102 894-2].

Deve ser renovado para uma DENM de atualização e definido para a posição do atual ponto de evento.

relevanceDistance

·DENM nova: menosDe1000m(4)

·DENM de atualização: lessThan5km(5) (Ao utilizar atualizações, a distância abrangida pelo eventHistory torna-se mais longa. Para considerar todas as estações STI relevantes, a relevanceDistance é maior neste caso.)

relevanceTrafficDirection

allTrafficDirections(0)

validityDuration

Predefinição: 600 s

Em áreas urbanas, conforme determinado pelo mapa digital ou pelo algoritmo do sensor de bordo: 300 s (Se o veículo não dispuser de informações sobre o estatuto urbano/não-urbano, deve ser utilizado o valor predefinido.)

stationType

O tipo de estação STI-C de origem. Deve ser definido em conformidade com a norma [TS 102 894-2].

Contenção de situação

informationQuality

Ver ponto (291). Deve ser renovado para cada DENM de atualização e definido para a informationQuality do atual ponto de evento.

causeCode

adverseWeatherCondition-Adhesion(6)

subCauseCode

indisponível(0)

eventHistory

Este elemento apenas deve ser utilizado para DENM de atualização (ver ponto 18.4).

Contenção de localização

traces

PathHistory da estação STI-C de origem em relação ao ponto de evento atual.
Deve ser definido em conformidade com a norma [TS 102 894-2].
Deve ser renovado para uma DENM de atualização.

roadType

roadType da estrada em que a estação STI-C de deteção está situada.

Deve ser renovado para uma DENM de atualização e definido para o roadType do atual ponto de evento.

Deve ser definido em conformidade com a norma [TS 102 894-2] em conjugação com as seguintes regras:

Urbano / não urbano

Separação estrutural

Elemento de dados

Urbano

Não

urbano-NoStructuralSeparation ToOppositeLanes(0)

Urbano

Sim

urbano-WithStructuralSeparation ToOppositeLanes(1)

Urbano

Desconhecido

urbano-NoStructuralSeparation ToOppositeLanes(0)

Não urbano

Não

nãoUrbano-NoStructuralSeparation ToOppositeLanes(2)

Não urbano

Sim

nãoUrbano-WithStructuralSeparation ToOppositeLanes(3)

Não urbano

Desconhecido

nãoUrbano-NoStructuralSeparation ToOppositeLanes(2)

Se não for possível determinar as informações sobre o estatuto urbano/não urbano, deve ser omitido o elemento de dados.

18.7.2.CAM

(304)Não deve ser utilizada a CAM de adaptação para este serviço STI-C.

18.8.Rede e camada de transporte

(305)O parâmetro de interface DENM destination area entre o serviço básico DEN e a rede e a camada de transporte devem ser iguais a uma forma circular com raio igual à relevanceDistance.

18.9.Camada de segurança

(306)No caso de se aplicarem as condições de acionamento conforme descrito no ponto (287), será bloqueada uma alteração de CA para DENM novas e de atualização durante 15 minutos (desde o momento em que a DENM nova foi gerada). Devem ser enviadas DENM novas e de atualização correspondentes com o mesmo CA.

(307)Se o CA mudar e houver uma transmissão ativa de uma DENM nova ou de atualização, a transmissão deve ser interrompida. Adicionalmente, o EventHistory e o PathHistory devem ser eliminados. O processo de geração regular de DENM deve então prosseguir.

19.Sinalização no veículo — informações de limite de velocidade dinâmico

Este serviço STI-C transmite informações de I2V (com recurso a IVI) no limite de velocidade atualmente válido, por troço, faixa ou categoria de veículo, continuamente, conforme definido e transmitido pelo operador rodoviário.

(308)As informações devem ser coerentes com os sinais de trânsito dinâmicos atualmente válidos.

(309)[ISO/TS 14823] O Data Field deve ser definido com serviceCategoryCode = regulamentar, natureza = 5, serialnumber = 57, atributos/spe/spm = o valor do limite de velocidade em km/h e unidade = 0 (ou seja, km por hora) ou o equivalente para outros países (por exemplo, 1 para milhas por hora).

(310)No que respeita ao fim do limite de velocidade, pode utilizar-se o seguinte: [ISO 14823] Data Field com serviceCategoryCode = regulamentar (12), natureza = 6, númeroDeSérie = 14 (aviso de fim de limite de velocidade) ou serviceCategoryCode = informativo (13), nature = 6, serial number = 63 (aviso de fim de todas as restrições por sinais eletrónicos) se este sinal for exibido na estrada. Pode ser redundante finalizar as frases, já que o ponto final da zona de relevância da mensagem IVI inicial já encerra o limite de velocidade.

20.Sinalização no veículo — «texto livre» de VMS incorporado

Este serviço STI-C transmite informações infraestrutura-veículo (I2V) [com recurso a informações veículo-infraestrutura (IVI)] em «texto livre», conforme definido e transmitido pelo operador rodoviário. A prioridade das mensagens IVS enviadas é definida pelo operador rodoviário.

(311)As informações devem ser coerentes com os sinais de trânsito dinâmicos atualmente válidos.

21.Sinalização no veículo — outras informações de sinalização

Este serviço STI-C transmite informações de sinalização I2V (com recurso a IVI) além do limite de velocidade dinâmico e das informações de texto livre, nomeadamente proibições de ultrapassagem ou orientação de faixas, conforme definido e transmitido pelo operador rodoviário.

(312)As informações devem ser coerentes com os sinais de trânsito dinâmicos atualmente válidos.

(313)[ISO/TS 14 823] O Data Field está definido com serviceCategoryCode = informativo; natureza = 6; serialnumber = 59 (para faixa fechada), 60 (para faixa livre), 61 (para faixa livre à esquerda) ou 62 (para faixa livre à direita).

(314)Em relação a «fim de restrição»: serviceCategoryCode = informativo (13), natureza = 6, número de série = 63 para «fim de todas as restrições por sinais eletrónicos» pode ser utilizado se for exibido este sinal eletrónico. Pode ser redundante finalizar as frases, já que o ponto final da zona de relevância da mensagem IVI inicial já encerra informações de sinalização.

22.notificação relativa a localizações perigosas — zona de acidentes

Este serviço STI-C transmite informações de I2V (com recurso a DEN) sobre uma zona de acidentes utilizando um único identificador de mensagem de aviso, conforme definido e transmitido pelo operador rodoviário.

(315)O CauseCode deve ser definido como 2 (acidente) e o subCauseCode deve ser definido entre 0 e 7 (exceto 6).

23.notificação relativa a localizações perigosas — engarrafamento à frente

Este serviço STI-C transmite informações de I2V (com recurso a DEN) sobre um engarrafamento à frente, por troço ou faixa, utilizando um único identificador de mensagem de aviso, conforme definido e transmitido pelo operador rodoviário (com referência às posições, ao comprimento do engarrafamento e aos troços/as faixas em causa, se essas informações estiverem disponíveis).

(316)O CauseCode deve ser definido como 27 (fim de fila perigoso) e o subCauseCode deve ser definido como 0 (não disponível) para sinalizar um fim de fila perigoso. Para transmitir informações sobre todo o comprimento da fila, o causeCode deve ser definido como 1 (engarrafamento) e o subCauseCode deve ser definido como 0.

24.notificação relativa a localizações perigosas — veículo imobilizado

Este serviço STI-C transmite informações de I2V (com recurso a DEN) sobre um veículo imobilizado utilizando um único identificador de mensagem de aviso, conforme definido e transmitido pelo operador rodoviário.

(317)O CauseCode deve ser regulado para 94 (veículo imobilizado) e o subCauseCode deve ser regulado para 0 (disponível) ou 2 (veículo avariado).

25.notificação relativa a localizações perigosas — aviso de condições meteorológicas

Este serviço STI-C transmite informações de I2V (com recurso a DEN) sobre a precipitação atual e/ou prevista ou condições meteorológicas extremas (cenário 1) ou campos de visibilidade reduzida (cenário 3), utilizando um único identificador de mensagem de aviso, conforme definido e transmitido pelo operador rodoviário.

(318)O CauseCode deve ser regulado para 17 (condições meteorológicas extremas) ou 19 (precipitação).

26.notificação relativa a localizações perigosas — piso temporariamente escorregadio

Este serviço STI-C transmite informações de I2V (com recurso a DEN) sobre troços de estrada escorregadios utilizando um único identificador de mensagem de aviso, conforme definido e transmitido pelo operador da estrada.

(319)O CauseCode deve ser regulado para 6 (aderência) e o subCauseCode deve ser regulado entre 0 e 9.

27.notificação relativa a localizações perigosas — animal ou pessoa na via

Este serviço STI-C transmite informações de I2V (com recurso a DEN) sobre animais ou pessoas na via, utilizando um único identificador de mensagem de aviso, conforme definido e transmitido pelo operador da estrada.

(320)O CauseCode deve ser regulado para 11 (animal na via) ou 12 (presença humana na via).

28.notificação relativa a localizações perigosas — obstáculo na via

Este serviço STI-C transmite informações de I2V (com recurso a DEN) sobre um ou mais obstáculos em uma ou mais faixas. No entanto, o tráfego ainda pode passar (não há um bloqueio). Utiliza um único identificador de mensagem de aviso, conforme definido e transmitido pelo operador rodoviário.

(321)O CauseCode deve ser regulado para 10 (obstáculo na via) e o subCauseCode deve ser regulado entre 0 e 5 (o 6 e o 7 não são utilizados).

29.Aviso de obras na estrada — faixa fechada ao trânsito (ou outras restrições)

Este serviço STI-C transmite informações de I2V (com recurso a DEN) sobre o encerramento de parte de uma faixa, uma faixa inteira ou várias faixas (incluindo a faixa de emergência), mas sem o encerramento total da via. Utiliza um único identificador de mensagem de aviso, conforme definido e transmitido pelo operador rodoviário.

Poderá ser prestada de uma das seguintes formas:

·obras rodoviárias planeadas e estáticas [Centro Operacional Rodoviário (TOC) acionado] – o operador rodoviário programa as obras rodoviárias estáticas e planeadas (ou ad hoc) no seu sistema de gestão do tráfego (TMS);

·modo autónomo – é utilizado um reboque de sinalização para obras de curto ou de longo prazo, mas sem ligação ao TOC (sem ligação disponível);

·aumentado (autónomo seguido de acionamento do TOC) – a mensagem é primeiro enviada de um reboque de sinalização e pode ser atualizada posteriormente, nomeadamente com informações adicionais do TOC.

(322)O CauseCode deve ser regulado para 3 (obras na via) e o subCauseCode deve ser regulado entre 0 e 4.

30.Aviso de obras na estrada — via fechada ao trânsito

Este serviço STI-C transmite informações de I2V (com recurso a DEN) sobre o encerramento de uma via devido a um conjunto de obras estáticas. O encerramento é temporário. Utiliza um único identificador de mensagem de aviso, conforme definido e transmitido pelo operador da estrada.

(323)O CauseCode deve ser regulado para 3 (obras na via) e o subCauseCode deve ser regulado para 1.

31.Aviso de obras na estrada — obras na estrada (móveis)

Este serviço STI-C transmite informações de I2V (com recurso a DEN) sobre uma zona na via em que, num determinado ponto, uma faixa é estreitada ou fechada (mas sem encerramento da via), devido a um local de obras móvel planeado. Utiliza um único identificador de mensagem de aviso, conforme definido e transmitido pelo operador rodoviário.

Este serviço STI-C pode ser fornecido de uma das seguintes formas:

·TOC acionado – o operador rodoviário programa as obras rodoviárias móveis e planeadas (ou ad hoc) no seu TMS. As informações contêm todos os elementos que podem ser utilizados para identificar a zona de obras (posição inicial/final, duração). Os agentes operacionais não utilizarão toda a zona, mas marcarão o local de obras efetivo no seu interior. Podem ser adicionadas mais informações, como o limite de velocidade em cada parte estreitada;

·modo autónomo – é utilizado um reboque de sinalização para obras de curto ou de longo prazo, mas sem ligação ao TOC (sem ligação disponível).

(324)O CauseCode deve ser regulado para 3 (obras na via) e o subCauseCode deve ser regulado para 3.

32.Cruzamentos sinalizados — velocidade ótima recomendada na proximidade da passagem para a luz verde

Este serviço STI-C transmite informações de I2V, utilizando Fase e Temporização de Sinal (SPAT) e Informações Topológicas para a Interseção (MAP), sobre a recomendação de velocidade para os utilizadores das vias que se aproximam e passam por cruzamentos controlados por semáforos, com base no estado de fase atual e na temporização prevista dos semáforos, assim como da topologia da estrada para o(s) cruzamento(s) à frente.

Pode ser fornecido de uma das seguintes formas:

·o veículo calcula a recomendação de velocidade – o cruzamento sinalizado transmite periodicamente e em tempo real o estado de fase atual dos semáforos e a temporização das próximas mudanças de fase. O veículo em aproximação, conhecendo a sua própria localização e velocidade, recebe as mensagens e calcula a velocidade ideal para se aproximar do cruzamento;

·a infraestrutura calcula o aviso de velocidade – o cruzamento sinalizado calcula e transmite periodicamente e em tempo real a recomendação de velocidade para vários troços de estrada relativamente à aproximação do cruzamento. O veículo em aproximação, conhecendo a sua própria localização e velocidade, recebe as mensagens e extrai a velocidade ideal para se aproximar do cruzamento;

·aviso de velocidade perante onda verde – uma sequência de cruzamentos sincronizados controlados por semáforos transmitem recomendações de velocidade predefinidas/planeadas perante múltiplos sinais verdes. O veículo em aproximação, conhecendo a sua própria localização e velocidade, recebe as mensagens e obtém a velocidade de onda verde para passar pelos cruzamentos.

(325)As informações sobre o atual estado e temporização das próximas mudanças do cruzamento sinalizado devem ser suficientemente precisas e fiáveis para garantir recomendações de velocidade de alta qualidade.

(326)As informações devem ser coerentes com os semáforos físicos do cruzamento.

(327)As condições de tráfego, como as filas ou os engarrafamentos, afetam a validade das recomendações de velocidade e, por conseguinte, devem ser levadas em consideração.

(328)As velocidades recomendadas nunca devem exceder os limites de velocidade legais.

33.Cruzamentos sinalizados — priorização dos transportes públicos

Este serviço STI-C dá prioridade a veículos de transportes públicos em relação aos veículos particulares nos cruzamentos sinalizados utilizando Mensagens Alargadas de Pedido de Sinal (SREM) e Mensagens Alargadas de Estado de Pedido de Sinal (SSEM). O veículo de transportes públicos transmite um pedido de priorização com recurso a V2I. O sistema de priorização dos transportes públicos processa o pedido, aceita-o ou rejeita-o, e envia feedback ao veículo de transportes públicos com recurso a I2V. Se o pedido for aceite, por exemplo, as «fases vermelhas» podem ser encurtadas e as «fases verdes» prolongadas e o veículo de transportes públicos recebe «luz verde», com tempo mínimo de paragem. Depois de ter passado com êxito pelo cruzamento, o controlador do semáforo regressa à operação normal.

(329)O stationID do veículo não deve mudar durante o processamento de um pedido de priorização.

(330)Devem ser asseguradas a autenticação e a autorização de veículos de transportes públicos.

(331)O pedido de priorização deve ser fornecido a tempo de permitir uma reação por parte do sistema de priorização de transportes públicos.

Início

ANEXO II

1.Introdução

1.1.Referências

No presente anexo, utilizam-se as seguintes referências:

EN 302 636-4-1    ETSI EN 302 636-4-1, Sistemas de transporte inteligentes (IST); Comunicações em veículos; GeoNetworking; Parte 4: Endereçamento e encaminhamento geográfico para comunicações ponto-a-ponto e ponto-multiponto; Subparte 1: Funcionalidade independente de suportes. V1.3.1 (2017-08)

TS 102 894-2    ETSI TS 102 894-2, Sistemas de Transporte Inteligentes (STI); Requisitos de utilizadores e aplicações; Parte 2: Dicionário de dados comuns das camadas de aplicações e instalações, V1.3.1 (2018-08)

ISO/TS 19091    ISO/TS 19091, Sistemas de Transporte Inteligentes – STI Cooperativos – Utilização de comunicações V2I e I2V para aplicações relacionadas com interseções sinalizadas, (2017-03)

EN 302 663    ETSI EN 302 663, Sistemas de Transporte Inteligentes (STI); Especificação da camada de acesso para Sistemas de Transporte Inteligentes operando na banda de frequências de 5 GHz, V1.2.1 (2013-07)

TS 102 687    ETSI TS 102 687, Sistemas de Transporte Inteligentes (STI); Mecanismos de Controlo de Congestionamento Descentralizado para Sistemas de Transporte Inteligentes operando na banda de 5 GHz; Parte da camada de acesso, V1.2.1 (2018-04)

TS 102 792    ETSI TS 102 792, Sistemas de Transporte Inteligentes (STI); Técnicas de mitigação para evitar a interferência entre o equipamento de comunicações dedicadas de curto alcance do CEN (CEN DSRC) e os Sistemas de Transporte Inteligentes (STI) operando na banda de frequências de 5 GHz, V1.2.1 (2015-06)

EN 302 637-2    ETSI EN 302 637-2, Sistemas de Transporte Inteligentes (STI); Comunicações em veículos; Conjunto básico de aplicações; Parte 2: Especificação do Serviço Básico de Perceção Cooperativa, V1.4.0 (2018-08); esta referência passa a ser entendida como a referência à versão 1.4.1 a partir da data de publicação dessa versão.

TS 102 724    ETSI TS 102 724, Sistemas de Transporte Inteligentes (STI); Especificações de canal harmonizadas para Sistemas de Transporte Inteligentes operando na banda de frequências de 5 GHz, V1.1.1 (2012-10)

EN 302 636-5-1    ETSI EN 302 636-5-1, Sistemas de transportes inteligentes (ITS) Comunicações em veículos; GeoNetworking; Parte 5: Protocolos de Transporte; Subparte 1: Protocolo básico de transporte, V2.1.1 (2017-08)

TS 103 248    ETSI TS 103 248, Sistemas de Transporte Inteligentes (STI); GeoNetworking; Números de porta para o protocolo básico de transporte (BTP), V1.2.1 (2018-08)

EN 302 931    ETSI EN 302 931, Comunicações em veículos; Definição da área geográfica, V1.1.1 (2011-7)

EN 302 637-3    ETSI EN 302 637-3, Sistemas de Transporte Inteligentes (STI); Comunicações em veículos; Conjunto básico de aplicações; Parte 3: Especificações do Serviço Básico de Notificação Ambiental Descentralizada, V1.3.0 (2018-08); esta referência passa a ser entendida como a referência à versão 1.4.1 a partir da data de publicação dessa versão.

TS 102 636-4-2    ETSI TS 102 636-4-2, Sistemas de Transportes Inteligentes (STI) Comunicações em veículos; GeoNetworking; Parte 4: Endereçamento e encaminhamento geográfico para comunicações ponto-a-ponto e ponto-multiponto; Subparte 2: Funcionalidade independente de suportes para STI-G5, V1.1.1 (2013-10)

SAE J2945/1    SAE J2945/1, Requisitos de sistemas de bordo para comunicações de segurança V2V (2016-03)

TS 103 097    ETSI TS 103 097, Sistemas de Transporte Inteligentes (STI); Segurança; Rubrica de segurança e formatos de certificado, V1.3.1 (2017-10)

ISO 8855    ISO 8855, Veículos rodoviários — Dinâmica do veículo e capacidade de aderência — Vocabulário, (2011-12)

TS 103 301    ETSI TS 103 301, Sistemas de Transporte Inteligentes (STI); Comunicações em veículos; Conjunto básico de aplicações; Protocolos de camada de instalações e requisitos de comunicação para serviços de infraestrutura, V1.2.1 (2018-08)

TS 103 175    ETSI TS 103 175, Sistemas de Transporte Inteligentes (STI); Entidade de gestão de DCC de camada cruzada para operação nos meios STI G5A e STI G5B, V1.1.1 (2015-06)

ISO/TS 19321    ISO/TS 19321, Sistemas de transporte inteligentes — STI cooperativos — Dicionário de estruturas de dados de informação em veículos (IVI), (2015-04-15)

ISO 3166-1    ISO 3166-1:2013, Códigos para a representação dos nomes de países e respetivas subdivisões – Parte 1: Códigos de países

ISO 14816    ISO 14816:2005, Transporte rodoviário e telemática do tráfego; Identificação automática de equipamentos e veículos; Numeração e estrutura de dados

ISO/TS 14823    ISO/TS 14823:2017, Sistemas de transporte inteligentes – Dicionário de dados gráficos

IEEE 802.11    IEEE 802.11-2016, Norma IEEE de Tecnologias da Informação – Telecomunicações e intercâmbio de informações entre sistemas, redes locais e metropolitana – Requisitos específicos, parte 11: LAN sem fios Medium Access Control (MAC) e Especificações de Nível Físico (PHY), (2016-12-14)

1.2.Notações e abreviaturas

No presente anexo, utilizam-se as seguintes notações e abreviaturas:

CA                Certificado de Autorização

BTP                Basic Transport Protocol ( Protocolo Básico de Transporte)

CC                Cooperative Awareness (Perceção Cooperativa)

CAM                Cooperative Awareness Message (Mensagem de Perceção Cooperativa)

CBR                Channel Busy Ratio (Taxa de Ocupação de Canal)

CCH                Control Channel (Canal de Controlo)

CDD                Common Data Dictionary (Dicionário de Dados Comum)

CEN-DSRC    Comité Europeu de Normalização - Comunicações Dedicadas de Curto Alcance

STI-C            Sistemas Cooperativos de Transporte Inteligentes

DCC                Decentralized Congestion Control (Controlo de Congestionamento Descentralizado)

DEN                Decentralized Environmental Notification (Notificação Ambiental Descentralizada)

DENM            Decentralized Environmental Notification Message (Mensagem de Notificação Ambiental Descentralizada)

PD                Perfil de Controlo de Congestionamento Descentralizado

ETSI                European Telecommunications Standards Institute (Instituto Europeu de Normalização das Telecomunicações)

GBC                GeoBroadcast

GN                GeoNetworking

GNSS            Global Navigation Satellite System (Sistema Global de Navegação por Satélite)

IEEE                Institute of Electrical and Electronic Engineers (Instituto de Engenharia Elétrica e Eletrónica)

IVI                informações veículo-infraestrutura

IVIM                mensagem de informações veículo-infraestrutura

MAP                Informações topológicas para a interseção

MAPEM            Mensagem Alargada MAP

PR                Próxima Rubrica

NTP                Network Time Protocol (Protocolo de Sincronização de Tempo)

IPP                Indicador de Precisão de Posição

PoTe                Posição e Tempo

QPSK            Quadrature Phase-Shift Keying (modulação por deslocamento de fase em quadratura)

TFR                Topologia de Faixa de Rodagem

RSU                Road-side Unit (Unidade Localizada nas Vias Rodoviárias)

SCF                Store Carry Forward (Armazenamento Transporte Encaminhamento)

SHB                Single Hop Broadcast (Difusão de Um Só Salto)

SPATEM            Signal Phase and Timing Extended Message (Mensagem de Fase e Temporização de Sinal Alargadas)

SREM            Signal Request Extended Message (Mensagem Alargada de Pedido de Sinal)

SSEM            Signal Request Status Extended Message (Mensagem Alargada de Estado de Pedido de Sinal)

TAI                International Atomic Time (Tempo Atómico Internacional)

NGC                Nível de Garantia de Confiança

TLM                Manobra de semáforo

CT                Classe de Tráfego

UTC                Coordinated Universal Time (Tempo Universal Coordenado)

WGS84            World Geodetic System 84 (Sistema Geodésico Mundial 84)

1.3.Definições

No presente anexo, entende-se por:

(a)«Tempo STI-C» ou «base temporal»: o número de milissegundos do tempo atómico internacional (TAI) decorrido desde 2004-01-01 00: 00: 00.00000:00:00.000 Tempo Universal Coordenado (UTC)+0, conforme definido na norma [ETSI EN 302 636-4-1]. Os selos temporais conforme definidos na norma [ETSI TS 102 894-2] obedecem a este formato.

Nota: «milissegundos TAI» denota o número real de milissegundos contados e não alterados por segundos intercalares após 1 de janeiro de 2004.

(b)«relógio da estação»: um relógio que representa o tempo dos Sistemas Cooperativos de Transporte Inteligentes (STI-C) numa estação STI-C.

2.Requisitos para estações STI-C de bordo projetadas para comunicações de pequeno alcance

Este perfil de sistema especifica um conjunto mínimo de normas e colmata as lacunas conforme necessário para a realização de uma estação STI-C de bordo interoperável do lado da transmissão. O perfil inclui apenas requisitos de interoperabilidade, deixando em aberto quaisquer requisitos adicionais. Por conseguinte, não descreve todas as funcionalidades da estação STI-C de bordo.

Este perfil do sistema permite a implantação dos serviços de prioridade (em especial, V2V). Poderá suportar outros serviços, mas estes poderão exigir especificações de sistema adicionais.

O perfil fornece descrições, definições e regras para as camdas (Aplicações, Instalações, Ligação em Rede e Transporte e Acesso) da arquitetura de referência da estação STI ETSI/central de STI-S.

2.1.Definições

Nesta parte do presente anexo entende-se por:

(a)«estados dos veículos»: abrange a posição absoluta, o rumo e a velocidade num determinado ponto no tempo;

(b)as informações fornecidas com um «nível de confiança» de 95 %: o valor real está dentro do intervalo especificado pelo valor estimado mais/menos o intervalo de confiança em 95 % dos pontos de dados numa determinada base estatística;

(c)«obstrução do céu»: a fração de valores de meio hemisfério que estão obstruídos para o Galileo ou outros satélites do Sistema Global de Navegação por Satélite (GNSS) devido a montanhas, edifícios, árvores, etc.

(d)«CEN-DSRC»: (Comité Europeu de Normalização - Comunicações Dedicadas de Curto Alcance) uma tecnologia de micro-ondas utilizada para os sistemas eletrónicos de portagem para financiar os custos da infraestrutura rodoviária ou para cobrar as taxas de utilização das estradas. Para efeitos do presente anexo, «CEN-DSRC» abrange todas as tecnologias de micro-ondas de 5,8 GHZ referidas na Diretiva 2004/52/CE do Parlamento Europeu e do Conselho e na Decisão 2009/750/CE da Comissão.

2.2.Definições de parâmetro

São usadas nesta parte do anexo as definições de parâmetro do quadro 1.

Quadro 1: Definições de parâmetro

Parâmetro

Valor

Unidade

Descrição

pAlDataRateCch

6

Mbit/s

Débito de dados predefinido para o Canal de Controlo (CCH)

pAlDataRateCchHigh

12

Mbit/s

Débito de dados facultativo mais elevado para CCH do que o predefinido

pAlDataRateCchLow

3

Mbit/s

Débito de dados facultativo mais baixo para CCH do que o predefinido

pBtpCamPort

2001

n/d

Porta de destino para CAM conhecida

pBtpDenmPort

2002

n/d

Porta de destino para DENM conhecida

pBtpDestPortInfo

0

n/d

Valor para as informações da porta de destino

pCamGenNumber

3

n/d

Número de CAM consecutivas geradas sem restrições de tempo

pCamTraceMaxLength

500

m

Comprimento máximo de um rastreio em CAM

pCamTraceMinLength

200

m

Comprimento mínimo de um rastreio em CAM

pCamTrafficClass

2

n/d

Valor da classe de tráfego (CF) com o qual são enviadas as CAM

pDccCcaThresh

-85

dBm

Sensibilidade mínima do canal

pDccMeasuringInterval

100

ms

Valor para o intervalo em que a carga do canal é fornecida

pDccMinSensitivity

-88

dBm

Valor para sensibilidade mínima do recetor

pDccProbingDuration

8

µs

Valor para a duração da sonda de recolha

pDccPToll

10

dBm

Valor para potência de transmissão dentro de zonas protegidas

pDCCSensitivityMargin

3

dB

Valor da margem do parâmetro pMargemSensibilidadeDCC

pDenmTraceMaxLength

1000

m

Comprimento máximo de um rastreio em DENM

pDenmTraceMinLength

600

m

Comprimento mínimo de um rastreio em DENM

pGnAddrConfMode

ANÓNIMO (2)

n/d

Método de configuração para o endereço GeoNetworking (GN)

pGnBtpNh

2

n/d

Valor para o campo de Próxima Rubrica (PR) da rubrica comum de GN

pGnChannelOffLoad

0

n/d

Valor para o campo de descarregamento de canal

pGnEtherType

0x8947

--

Valor para o Tipo de Ether a utilizar

pGnGbcHtField

4

n/d

Valor para o campo TipoDeRubrica nos casos de GeoBroadcast (GBC)

pGnGbcScf

1

n/d

Valor para o campo armazenamento-transporte-encaminhamento nos casos de GBC

pGnInterfaceType

STI-G5 (1)

n/d

Tipo de interface a ser utilizado pela GN

pGnIsMobile

1

n/d

Define se a estação C-ITS é móvel ou não

pGnMaxAreaSize

80

km²

Área suportada a cobrir

pGnSecurity

ATIVADO (1)

n/d

Define a utilização de rubricas de segurança da GN

pGnShbHstField

0

n/d

Valor para o campo HeaderSubType nos casos de difusão de salto único (SHB)

pGnShbHtField

5

n/d

Valor para o campo HeaderType nos casos de SHB

pGnShbLifeTimeBase

1

n/d

Valor para o campo LifeTimeBase no caso de SHB.

pGnShbLifeTimeMultiplier

1

n/d

Valor para o campo LifeTimeMultiplier nos casos de SHB

pPotiMaxTimeDiff

20

ms

Diferença máxima de tempo entre o relógio da estação e a base temporal

pPotiWindowTime

120

s

Dimensão de janela deslizante de Posição e Tempo (PoTe) em segundos

pPotiUpdateRate

10

Hz

Taxa de atualização para informações de posição e tempo

pSecCamToleranceTime

2

s

Desvio máximo de tempo entre o tempo na rubrica de segurança da Mensagem de Perceção Cooperativa (CAM) e o relógio da estação para aceitar a CAM

pSecGnScc

0

n/d

Valor para o campo SCC do endereço GN

pSecGnSourceAddressType

0

n/d

Valor para o campo M do endereço GN (tipo de configuração do endereço)

pSecMaxAcceptDistance

6

km

Distância máxima entre o remetente e o recetor para aceitar mensagens

pSecMessageToleranceTime

10

min

Desvio máximo de tempo entre o tempo na rubrica de segurança da mensagem (excluindo CAM) e o relógio da estação para aceitar a mensagem

pSecRestartDelay

1

min

Período de carência para a alteração do CA após ligar o terminal de ignição

pTraceAllowableError

0,47

m

Parâmetro para cálculo do histórico de trajeto; para mais informações, ver Apêndice A.5 da [SAE J2945/1].

pTraceDeltaPhi

1

°

Parâmetro para cálculo do histórico de trajeto; para mais informações, ver Apêndice A.5 da [SAE J2945/1].

pTraceEarthMeridian

6 378,137

km

Raio médio da Terra (de acordo com a União Internacional de Geodésia e Geofísica (IUGG). Utilizado para o cálculo de rastreios; para mais informações, ver Apêndice A.5 da [SAE J2945/1].

pTraceMaxDeltaDistance

22,5

m

Parâmetro para o cálculo de rastreios; para mais informações, ver Apêndice A.5 da [SAE J2945/1].

2.3.Segurança

(1)A estação STI-C de bordo deve possuir uma ligação segura a um veículo específico. Quando a estação STI-C de bordo está alimentada, deve verificar se está a operar no veículo ao qual está ligada de forma segura. Se a condição de correto funcionamento não puder ser verificada, a estação STI-C deve ser desativada, evitando que envie mensagens (ou seja, desativando pelo menos o nível de transmissão de rádio da estação STI-C).

(2)A estação STI-C de bordo deve verificar o selo temporal na rubrica de segurança em relação ao horário de receção e aceitar apenas CAM na última vez de pSecCamToleranceTime e outras mensagens no último horário de pSecMessageToleranceTime.

(3)A estação STI-C de bordo deve verificar a distância da posição do remetente — na rubrica de segurança, se disponível — e encaminhar apenas mensagens com uma distância do remetente de pSecMaxAcceptDistance ou menos.

(4)A verificação de uma mensagem deve incluir, pelo menos, a verificação criptográfica da assinatura da mensagem.

(5)A estação STI-C de bordo deve encaminhar apenas mensagens verificadas.

(6)A estação STI-C de bordo deve utilizar uma rubrica de segurança de ponta a ponta e uma assinatura por mensagem, em conformidade com as normas [TS 103 097] e [EN 302 636-4-1].

(7)A assinatura deve ser gerada utilizando uma chave privada correspondente a um CA válido, de acordo com o ponto 7.2.1 da norma [TS 103 097].

(8)Todos os endereços e identificadores transmitidos através de comunicações de curto alcance devem ser alterados quando o CA for alterado.

2.4.Posicionamento e temporização

(9)Os estados do veículo devem ser coerentes. Assim, o rumo e a velocidade devem referir-se ao mesmo tempo que a posição absoluta (por exemplo, GenerationDeltaTime em CAM).

Nota: quaisquer imprecisões que possam resultar de efeitos relacionados com o tempo devem ser levadas em conta nas precisões das variáveis de estado.

(10)A estação STI-C de bordo deve utilizar o Sistema Geodésico Mundial 84 (WGS84) como sistema de coordenadas de referência, conforme especificado na norma [TS 102 894-2].

Nota: Com base na deriva do Sistema Europeu de Referência Terrestre (ETRS89), que é fixado à placa continental da Europa, de 2,5 cm/ano no WGS84, importa notar que as estações STI-C de bordo necessitam de percecionar qual é o sistema de referência utilizado. Quando um sistema otimizado de referenciação, como um sistema otimizado de cinemática em tempo real, é utilizado para a referenciação geográfica de alta precisão, essa mudança pode ter de ser compensada.

(11)As informações de altitude devem ser interpretadas como altitude acima da elipsoide do WGS84.

Nota: Não devem ser utilizadas interpretações alternativas de altitude usando definições geoidais (por exemplo, relativas ao nível médio do mar).

(12)Para a posição horizontal, é utilizada uma área de confiança em vez de um único intervalo de confiança. A área de confiança é descrita como elipse especificada através de um eixo maior, eixo menor e a orientação do eixo maior em relação à direção norte, conforme definido no ponto (10).

(13)A estação STI-C de bordo deve interpretar «rumo» como a direção do vetor de velocidade horizontal. O ponto de partida do vetor velocidade deve ser o ponto de referência do veículo STI, conforme definido em B.19 «referencePosition» na norma [EN 302 637-2].

Nota: não devem ser utilizadas interpretações de rumo alternativas no que se refere à orientação do corpo do veículo.

Nota: esta definição implica que a condução inversa a direito resulta numa diferença de 180 ° entre o rumo e a orientação do corpo do veículo.

(14)A hora do STI-C deve ser a base de todos os selos temporais em todas as mensagens transmitidas pela estação STI-C de bordo em todos os Estados-Membros da UE.

(15)Quando ativo, as estações STI-C devem atualizar os estados do veículo com uma frequência de pelo menos o pPotiUpdateRate.

(16)Os selos temporais nas mensagens devem basear-se no relógio da estação.

(17)Deve ser estimada a diferença entre o relógio da estação e o tempo do STI-C. Se a diferença absoluta |Station clock time - C-ITS time | >= pPotiMaxTimeDiff, a estação STI-C de bordo não deve estar ativa.

Nota: um selo temporal preciso não só é necessário para a sincronização temporal, como também implica que os estados do sistema são válidos precisamente naquele momento, isto é, que os estados do veículo permanecem coerentes.

(18)Ao paralisar, o sistema deve comunicar o último valor de rumo conhecido (sentido de movimento do veículo). O valor deve ser desbloqueado ao retomar o movimento,

2.5.Comportamento do sistema

(19)A estação STI-C de bordo deve operar o Serviço Básico de Perceção Cooperativa quando estiver em vias públicas e sujeita a uma dinâmica de condução regular.

Nota: a operação do serviço básico de perceção cooperativa inclui a transmissão de CAM se estiverem reunidas todas as condições para a geração de CAM.

(20)Os dados dos rastreios e do histórico de trajeto apenas devem ser gerados quando as informações de confiança da posição estiverem disponíveis e o relógio da estação estiver em conformidade com o ponto (90) (91).

(21)Um ocupante do veículo deve ser capaz de desativar a estação STI-C de bordo facilmente a qualquer momento.

(22)A estação STI-C de bordo deve tratar as transmissões CAM de forma que não seja transmitida qualquer mensagem desatualizada, mesmo se for aplicado o controlo de congestionamento.

2.6.Camada de acesso

(23)A estação STI-C de bordo deve utilizar o canal de controlo G5-CCH, conforme especificado no Quadro 3 da norma [EN 302 663], para enviar mensagens de apoio ao Serviço Básico de Perceção Cooperativa e os serviços prioritários STI-C especificados no Anexo I do presente regulamento.

(24)A camada de acesso da estação STI-C de bordo deve ser conforme com a norma [EN 302 663], com exceção dos limites de emissão e dos pontos 4.2.1, 4.5 e 6.

(25)A estação STI-C de bordo deve utilizar uma taxa de transferência predefinida de pAlDataRateCch no canal de controlo.

(26)A estação STI-C de bordo também deve suportar taxas de transferência e pAlDataRateCchHigh no canal de controlo.

(27)A camada de acesso da estação STI-C de bordo deve estar em conformidade com a norma [TS 102 724].

(28)A estação STI-C de bordo deve suportar os seguintes perfis descentralizados de controlo de congestionamento (PD) definidos na norma [TS 102 724]: PD0, PD1, PD2 e PD3.

Estes perfis DCC devem utilizar os seguintes valores de identificação de perfil DCC:

·DP0, usado apenas para DENM com TC = 0;    

·DP1, usado apenas para DENM com TC = 1;

·DP2, usado para CAM com TC = pCamTrafficClass;

·DP3, usado para DENM encaminhadas e outras mensagens de baixa prioridade.

(29)O mecanismo DCC da estação STI-C de bordo deve estar em conformidade com a norma [TS 102 687].

(30)Devem ser utilizadas as definições do quadro A.2 da norma [TS 102 687] se o algoritmo DCC reativo descrito no ponto 5.3 da norma [TS 102 687] for implementado.

Nota: O Quadro A.2 da norma [TS 102 687] baseia-se na disseminação da CAM e da Mensagem de Notificação Ambiental Descentralizada (DENM) para serviços prioritários STI-C com uma tonelada média de 500 μs.

(31)A seguinte função de alisamento dos valores da taxa de ocupação de canais (CBR) deve ser executada se a estação STI-C de bordo utilizar o algoritmo DCC reativo descrito no ponto 5.3 da norma [TS 102 687]: CBR_now = (CBR(n)+CBR(n-1))/2 (

Nota: sendo que «n» e «n-1» são os períodos de amostragem CBR atual e anterior, respetivamente).

(32)A estação STI-C de bordo deve, no mínimo, poder gerar e transmitir o número de mensagens determinado pelo valor da taxa de geração de CAM mais elevada (ou seja, 10 Hz) e, se forem utilizados algoritmos de deteção, deve ser aumentado pela taxa mínima de geração de DENM necessária derivada dessas condições de acionamento.

(33)A estação STI-C de bordo deve respeitar as seguintes taxas máximas de mensagens, se utilizar o algoritmo DCC reativo descrito no ponto 5.3 da norma [TS 102 687]:

·para o estado relaxado: a soma de todas as mensagens enviadas em DP1, DP2 e DP3 não deve ultrapassar Rmáx_relaxed = 16,7 mensagens por segundo. As rajadas de mensagens são permitidas para DP0 com RBurst = 20 mensagens por segundo, com uma duração máxima de TBurst = 1 segundo, e podem ocorrer apenas a cadaTBurstPeriod = 10 segundos. Assim, adicionando mensagens DP0, a taxa máxima de mensagens equivale a Rmax_relaxed = 36,7 mensagens por segundo;

·para estados ativos: a taxa máxima de mensagens para cada estado é indicada no quadro A.2 da norma [TS 102 687];

·para o estado restritivo: a taxa máxima de mensagens por estação STI-C de bordo é definida para 2,2 mensagens por segundo, ou seja, o inverso de TTX_MAX = 460 ms.

(34)A estação STI-C de bordo deve suportar o controlo de potência de transmissão por pacote.

Nota: PTx pode depender do estado atual do DCC (isto é, relaxado, ativo ou restritivo) e do perfil DCC (isto é, DP0, DP1, etc.).

(35)A estação STI-C de bordo deve reduzir a sua potência de transmissão para PToll = pDccPToll assim que a zona protegida for inserida e sem alterar quaisquer outros parâmetros de transmissão DCC conforme o quadro A.2 da norma [TS 102 687]. As mensagens DP0 são excluídas desta restrição.

(36)Quando a estação STI-C de bordo não está equipada com um detetor rádio CEN-DSRC, conforme descrito no ponto 5.2.5 da norma [TS 102 792], deve manter uma lista das posições da zona protegida, conforme descrito no ponto 5.5.1 da norma [TS 102 792]. A lista deve ser composta por:

·um conjunto de zonas de proteção, conforme listado na «versão mais recente» (disponível quando o veículo é desenvolvido) da base de dados da zona protegida. A estação STI-C de bordo pode incluir mecanismos de atualização da case de dados;

·um conjunto de zonas protegidas, conforme identificado pela receção das CAM de mitigação CEN-DSRC, conforme descrito nos pontos 5.2.5 e 5.2.2.3 da norma [TS 102 792];

·uma zona temporariamente protegida, conforme identificado pela receção das CAM de mitigação CEN-DSRC, conforme descrito no ponto 5.2.2.2 da norma [TS 102 792].

(37)Quando a estação STI-C de bordo está equipada com um detetor rádio CEN-DSRC, deve ser aplicada a mitigação conforme descrito no ponto 5.2.5 da norma [TS 102 792] e a estação STI-C de bordo deve gerar CAM, conforme descrito no ponto 5.5.1 da norma [TS 102 792].

(38)Quando a estação STI-C de bordo está equipada com um detetor rádio CEN-DSRC, deve ser aplicada a mitigação em conformidade com a norma [TS 102 792] com base na lista definida no ponto (36)e nas CAM recebidas de outros utilizadores da via que tenham implementado o ponto (37).

Nota: clarificação do ponto 5.2.5 da norma [TS 102 792]: uma estação STI móvel deve mitigar cada vez para a posição central do posto de portagem mais próxima. Quando são dadas várias posições na mesma área, a estação STI móvel deve responder a cada posição central, possivelmente numa sequência. As zonas protegidas com identificador de protectedZone idêntico podem ser consideradas uma única estação. Nos casos em que a base de dados da zona protegida e as CAM de mitigação CEN-DSRC contiverem uma zona protegida válida com o mesmo identificador de protectedZone, a mitigação deve basear-se apenas no conteúdo da CAM de mitigação CEN-DSRC.

2.7.Rede e camada de transporte

(39)A parte de GeoNetworking (GN) independente de suportes da estação STI-C de bordo deve estar em conformidade com a norma [EN 302 636-4-1].

(40)Todas as constantes e os parâmetros predefinidos do perfil da estação STI-C de bordo não definidos ou substituídos no presente regulamento devem ser definidos conforme especificado no anexo H da norma [EN 302 636-4-1].

(41)O GN deve ser utilizado com itsGnSecurity ajustado para pGnSecurity.

(42)O GN deve ser utilizado com itsGnLocalAddrConfMethod definido para pGnAddrConfMode.

(43)O parâmetro GN itsGnMaxGeoAreaSize deve ser definido para .

(44)A repetição de pacotes não deve ser realizada por GN numa estação STI-C de bordo e não devem ser executadas as etapas correspondentes de repetição nos procedimentos de tratamento de pacotes descritos no ponto 10.3 da norma [EN 302 636-4-1].

O parâmetro «tempo máximo de repetição» do pedido.DADOS-GN primitivo de serviço e da constante do protocolo GN itsGnMinPacketRepetitionInterval não se aplica a uma estação STI-C de bordo.

(45)O GN deve ser utilizado com GnIfType definido para

(46)A estação STI-C de bordo deve utilizar rubricas de difusão de salto único (SHB) conforme definido na norma [EN 302 636-4-1] em todos os pacotes CAM que envia.

Assim, a rubrica comum de GN deve utilizar um valor de pGnShbHtField para o campo TR e um valor de pGnShbHstField para o campo STR ao transmitir pacotes SHB.

A estação STI-C de bordo deve utilizar rubricas GBC conforme definido na norma [EN 302 63641] em todos os pacotes DENM que envia.

Assim, a rubrica comum de GN deve utilizar um valor de pGnGbcHtField para o campo TR ao transmitir pacotes DENM.

Para o campo STR, deve ser utilizado um dos seguintes valores:

·0 para áreas circulares;

·1 para áreas retangulares;

·2 para áreas elipsoidais.

Nota: este perfil abrange o tratamento de pacotes SHB e GBC. Uma vez que não abrange o tratamento de outros tipos de pacotes GN definidos na norma [EN 302 636-4-1], tal não impede a sua implementação.

(47)A estação STI-C de bordo deve definir o campo LifeTime de todos os pacotes SHB da seguinte forma:

·definindo o multiplicador de subcampo para pGnShbLifeTimeMultiplier e a base do subcampo para pGnShbLifeTimeBase.

(48)A estação STI-C de bordo deve definir o campo LifeTime de todos os pacotes GBC com o valor mínimo de ValidityDuration e RepetitionInterval, em que ValidityDuration e RepetitionInterval são definidos no perfil de serviço pertinente. O valor do campo LifeTime não deve exceder o itsGnMaxPacketLifetime, conforme especificado no anexo H da norma [EN 302 636-4-1].

(49)A estação STI-C de bordo deve tamponar os pacotes GBC nos casos em que não haja vizinhos disponíveis (armazenamento-transporte-encaminhamento). Consequentemente, o bit de armazenamento, transporte e encaminhamento (SCF) do campo TC dos pacotes GBC deve ser definido como pGnGbcScf.

(50)Não é necessário que a estação STI-C de bordo descarregue pacotes para outro canal. Desta forma, o bit de descarregamento de canal do campo TC deve ser regulado para pGnChannelOffLoad.

(51)A estação STI-C de bordo deve utilizar os perfis DCC especificados no ponto (28). Consequentemente, os bits do Identificador do Perfil DCC do campo TC devem utilizar os valores de identificação do perfil DCC definidos no ponto (28).

(52)A estação STI-C de bordo deve definir o bit itsGnIsMobile do campo Indicadores para pGnIsMobile.

(53)A estação STI-C de bordo deve suportar o modo de operação de múltiplos saltos. Deve implementar o algoritmo de encaminhamento especificado nos Anexos D, E.3 e F.3 da norma [EN 302 63641].

(54)Ao encaminhar pacotes, a estação STI-C de bordo deve utilizar o perfil PD3 do DCC conforme definido na norma [TS 102 724] e referido no ponto (28).

(55)A estação STI-C de bordo deve utilizar a deteção de pacotes duplicados na rede e na camada de transporte. Consequentemente, deve ser utilizado o algoritmo especificado no Anexo A.2 da norma [EN 302 636-4-1] para detetar pacotes duplicados.

(56)Todos os quadros GN enviados pela estação STI-C de bordo devem utilizar o valor EtherType pGnEtherType conforme indicado pela Autoridade de Registo do Instituto de Engenharia Elétrica e Eletrónica (IEEE) em http://standards.ieee.org/develop/regauth/ethertype/eth.txt .

(57)O Protocolo Básico de Transporte (BTP) da estação STI-C de bordo deve estar em conformidade com a norma [EN 302 636-5-1].

(58)A estação STI-C de bordo deve utilizar rubricas BTP-B. Assim, a rubrica comum GN deve utilizar um valor de pGnBtpNhpara o campo PR.

(59)A estação STI-C de bordo deve definir o campo de informação da porta de destino com o valor pBtpDestPortInfo.

(60)Na rubrica BTP-B, a estação STI-C de bordo deve definir a porta de destino para o valor pBtpCamPort para CAM.

(61)Na rubrica BTP-B, a estação STI-C de bordo deve definir a porta de destino para o valor pBtpDenmPort para DENM.

(62)A estação STI-C de bordo deve suportar áreas geográficas circulares, retangulares e elipsoidais conforme definido na norma [EN 302 931]. Cada caso de utilização definido no perfil de serviço pertinente deve especificar um dos tipos de área geográfica indicados acima através da rubrica GN, conforme especificado na norma [EN 302 636-4-1].

(63)Quando uma estação STI-C de um veículo calcula a distância entre duas posições com recurso ao Galileo ou outras coordenadas de GNSS (por exemplo, para PathDeltaPoints ou em casos de área de relevância circular), deve ser usado o círculo máximo ou um método de maior precisão.

2.8.Camada das instalações

(64)O Serviço básico de perceção cooperativa (CA) da estação STI-C de bordo deve estar em conformidade com a norma [EN 302 636637-2].

(65)O campo do histórico de trajeto no contentor de baixa frequência de CAM deve ser gerado de acordo com o método especificado no ponto (86) e deve conter um elemento de dados PathHistory que cubra uma distância mínima de pCamTraceMinLength (parâmetro K_PHDISTANCE_M, conforme definido no apêndice A.5 da norma [SAE J2945/1]).

Apenas deve ser aberta uma exceção à distância mínima abrangida pelo PathHistory se:

·o veículo ainda não tiver coberto fisicamente a distância com o seu CA atual (por exemplo, após a partida do veículo ou logo após a mudança de CA durante a condução); ou

·é utilizado o número máximo de PathPoints, mas o comprimento total coberto pelo PathHistory ainda não atinge o pCamTraceMinLength.

Nota: esta situação pode ocorrer se a topologia da estrada possuir curvas apertadas e a distância entre os PathPoints consecutivos for reduzida.

O veículo apenas pode enviar informações de PathHistory cobrindo uma distância inferior aopCamTraceMinLength nos casos acima indicados.

(66)O PathHistory em CAM deve cobrir no máximo o pCamTraceMaxLength.

(67)O PathHistory em CAM deve incluir o PathDeltaTime em cada PathPoint. Deve descrever uma lista das localizações geográficas efetivamente percorridas que conduzem à posição atual do veículo, ordenadas pelo momento em que as posições foram alcançadas pelo veículo, sendo o primeiro ponto o mais próximo do tempo atual.

(68)Nos casos em que a estação STI-C de bordo não se move, ou seja, as informações de posição do PathPoint não se alteram, o PathDeltaTime do primeiro PathPoint ainda deve ser atualizado com cada CAM.

(69)Nos casos em que a estação STI-C de bordo não se move, isto é, as informações de posição do PathPoint não se alteram, por uma duração superior ao valor máximo de PathDeltaTime (especificado nanorma [TS 102 894-2]) o PathDeltaTime do primeiro PathPoint na CAM ser fixado como valor máximo.

(70)O serviço básico da CA deve estar ativo enquanto o veículo estiver em vias públicas e numa dinâmica de condução regular. Enquanto o serviço básico da CA estiver ativo, as CAM devem ser geradas de acordo com as regras de geração da norma [EN 302 637-2].

(71)A estação STI-C de bordo deve transmitir mensagens CAM se as informações de confiança da posição estiverem disponíveis e o relógio da estação estiver em conformidade com o ponto (91).

(72)O valor TC de mensagens CAM deve ser definido para pCamTrafficClass.

(73)O parâmetro T_GenCam_Dcc (veja [EN 302 637-2]) deve ser configurado para o valor do tempo mínimo entre duas transmissões, Toff, conforme indicado no quadro A.2 (mecanismos de DCC) na norma [TS 102 687].

(74)O parâmetro ajustável N_GenCam (ver [EN 302 637-2]) especificado na gestão de frequência de geração de CAM deve ser definido como pCamGenNumber para a estação STI-C de bordo.

(75)O serviço básico de Notificação Ambiental Descentralizada (DENM) da estação STI-C de bordo deve estar em conformidade com a norma [EN 302 637-3].

(76)A repetição da DENM deve ser efetuada pelo serviço básico de DEN, conforme especificado na norma [EN 302 637-3].

(77)O campo do histórico de trajeto nas mensagens DEN deve ser gerado de acordo com o método especificado no ponto (86) e deve conter um elemento de dados que cubra uma distância mínima de pDenmTraceMinLength (parâmetro K_PHDISTANCE_M, conforme definido no apêndice A.5 da norma [SAE J2945/1]).

Apenas deve ser aberta uma exceção para a distância mínima abrangida pelos rastreios se:

·veículo ainda não tiver coberto fisicamente a distância com o seu CA atual. (por exemplo, após a partida do veículo ou logo após a mudança de CA durante a condução); ou

·é utilizado o número máximo de PathPoints, mas o comprimento total coberto pelo PathHistory ainda não atinge o pDenmTraceMinLength.

Nota: esta situação pode ocorrer se a topologia da estrada possuir curvas apertadas e a distância entre os PathPoints consecutivos for reduzida.

O veículo apenas pode enviar informações de rastreio cobrindo uma distância inferior ao nos dois casos acima indicados.

(78)Os rastreios nas DENM devem cobrir no máximo o pDenmTraceMaxLength.

(79)A estação STI-C de um veículo deve utilizar os rastreios de DENM da seguinte forma:

·o primeiro elemento de rastreio deve descrever uma lista das localizações geográficas efetivamente percorridas que conduzem à posição atual do veículo, conforme especificado no ponto (67).

(80)Os elementos de dados PathDeltaTime dos PathPoints no primeiro elemento de rastreio de DENM apenas devem ser atualizados se a DENM for atualizada.

(81)Nos casos em que o veículo que deteta o evento não se move, ou seja, as informações de posição do PathPoint não se alteram, o PathDeltaTime do primeiro PathPoint do primeiro elemento de rastreio de DENM ainda deve ser atualizado com cada Atualização_DEN.

Nota: é apenas o caso de eventos estacionários em que o veículo de deteção é idêntico ao evento, por exemplo, um aviso de bordo imobilizado. Tal não se aplica a eventos dinâmicos, nomeadamente, situações perigosas ou eventos que não são idênticos ao veículo (avisos de condições climáticas adversas, etc.).

(82)Nos casos em que a estação STI-C de bordo não se move, isto é, as informações de posição do PathPoint não se alteram, por uma duração superior ao valor máximo de PathDeltaTime (especificado na norma [TS 102 894-2]) o PathDeltaTime do primeiro PathPoint no primeiro element de rastreio de DENM deve ser fixado para o valor máximo.

(83)Poderão estar presentes elementos adicionais do PathHistory nos rastreios de DENM. No entanto, ao contrário do primeiro elemento, estes devem descrever rotas alternativas para o local do evento. Essas rotas podem ou não estar disponíveis no momento de deteção do evento. Nas rotas alternativas, os PathPoints devem ser ordenados por posição (ou seja, rotas de caminho mais curto) e não devem incluir o PathDeltaTime.

(84)Para os serviços prioritários, a estação STI-C de bordo deve gerar apenas DENM conforme descrito no perfil de serviço pertinente.

(85)Os elementos de dados que constituem o conteúdo da CAM e DENM devem estar em conformidade com a norma [TS 102 894-2] e utilizar o sistema de coordenadas especificado nos pontos (87), (10) e (11)

(86)Os históricos de rastreio e de trajeto utilizados pela estação STI-C de bordo devem ser gerados usando o método Design Method One, conforme especificado no apêndice A.5 da norma [SAE J2945 / 1]. A estação STI-C de bordo deve utilizar esse método de geração com as seguintes configurações:

·K_PHALLOWABLEERROR_M = pTraceAllowableError, em que PH_ActualError < K_PHALLOWABLEERROR_M;

·distância máxima entre pontos de trajeto concisos, K_PH_CHORDLENGTHTHRESHOLD = pTraceMaxDeltaDistance;

·K_PH_MAXESTIMATEDRADIUS = REarthMeridian;

·K_PHSMALLDELTAPHI_R = pTraceDeltaPhi;

·REarthMeridian = pTraceEarthMeridian(de acordo com o IUGG), utilizado para o cálculo de distância do círculo máximo ou ortodrómico:

PH_ActualChordLength =    
REarthMeridian*cos
-1[cos(lat1)cos(lat2)cos(long1-long2)+sin(lat1)sin(lat2)]

(87)A estação STI-C de bordo deve utilizar um sistema de coordenadas em conformidade com o ponto 2.13 da norma [ISO 8855].

Nota: tal significa que os eixos X e Y são paralelos ao plano do solo, o eixo Z é alinhado numa vertical ascendente, o eixo Y aponta para o lado esquerdo na direção póstero-anterior do veículo e o eixo X aponta para a direção de póstero-anterior do veículo.

2.9.Requisitos relacionados com equipamento informático

(88)O valor de confiança de 95 % (ver pontos 2.1 (b) e (12)) deve ser válido em cada cenário indicado no ponto (92). Tal implica que, num teste de avaliação do valor de confiança (que pode estar fora de linha), uma média estatística sobre todos os estados e cenários não é adequada.

Em vez disso, deve ser usada uma janela deslizante que contenha os estados do veículo (ver ponto 2.1 (a)) dos últimos segundos de pPotiWindowTime como base estatística.

Nota: o mecanismo de validação de confiança proposto de utilização da janela deslizante é geralmente realizado fora de linha, em fase de pós-processamento dos dados de teste recolhidos. Não é necessário que a estação STI-C de bordo realize a validação de confiança em linha, ou seja, em vias públicas e numa dinâmica de condução regular.

Nota: A abordagem de janela deslizante possui as seguintes vantagens face a estatísticas individuais para cada cenário:

·estão incluídas as transições entre cenários;

·a confiança é válida «agora» em vez de «ao longo da vida». Não são permitidas «rajadas de erros» (muitos valores de confiança inválidos num curto período de tempo), o que:

·aumenta a utilidade do valor de confiança para aplicações;

·requer uma deteção rápida da degradação da precisão dentro de POTI;

·a definição exata de dados de teste não tem efeito sobre os parâmetros de validação de confiança. No entanto, os dados do teste devem conter todos os cenários indicados no ponto (92);

·não são necessários cálculos estatísticos adicionais; os cenários cobrem todos os estados relevantes;

·a duração do intervalo é semelhante aos comprimentos dos cenários típicos (ambiente e condição de condução) (por exemplo, túnel urbano, posição no semáforo, manobras de condução);

·5 % do intervalo é semelhante aos efeitos típicos de curto prazo (por exemplo, condução por baixo de uma ponte).

(89)Considera-se que um veículo está numa dinâmica de condução regular quando:

·passou a fase inicial de arranque;

·está a ser utilizado como previsto pelo fabricante;

·é possível o controlo normal do veículo (por exemplo, não está diretamente envolvido num acidente, a superfície da estrada permite a aderência normal dos pneus);

·Todas as seguintes condições (valores) são aplicáveis aos veículos de passageiros:

·a aceleração lateral do veículo é < 1,9 m/s^2;

·a aceleração longitudinal do veículo é < -2,4 m/s^2 (desaceleração);

·a aceleração longitudinal do veículo é < 2,5 m/s^2;

·a velocidade do veículo é <= mínimo de (130 km/h, Vmax).

(90)Em condições ótimas de GNSS e numa dinâmica de condução regular, conforme definido no ponto (89), os valores de confiança devem ser iguais ou inferiores aos seguintes valores em pelo menos 95 % dos pontos de dados de posição 3D num conjunto de dados:

·posição horizontal de confiança de 5 m;

·posição vertical de confiança de 20 m.

Noutros cenários, aplica-se o requisito de degradação do ponto (92) . Este requisito assegura a utilidade das informações enviadas em todas as mensagens do STI-C.

(91)O relógio da estação deve estar dentro da pPotiMaxTimeDiff dotempo STI-C, ou seja, Delta t = |tempo do relógio da estação - tempo STI-C| < pPotiMaxTimeDiff.

(92)A estação STI-C de um veículo deve ser capaz de fornecer estimativas úteis do estado do veículo mesmo em cenários problemáticos. Para contabilizar as inevitáveis degradações, os valores de confiança exigidos são definidos para diferentes cenários no Quadro 2.

«C» corresponde ao máximo de semiMajorConfidence e semiMinorConfidence. A condição para «C» deve ser satisfeita em 95 % dos dados no conjunto de dados do cenário em causa.

Nota: critérios devem ser cumpridos na seguinte dinâmica de declive para a fração de rastreamento analisada: declive médio <= 4 % e declive máximo <= 15 %

Nota: constitui uma condição prévia o facto de cada cenário ser iniciado com um minuto de condução a céu aberto e dinâmica de condução regular.

Nota: a inexistência de valores C indica que o cenário deve ser testado para garantir que o intervalo de confiança comunicado é válido, mas sem que seja estabelecido um limite.

Quadro 2: Cenários

Identificador

Cenário

Definição

Aceitação

Ambiente em dinâmica de condução regular

S1

Céu aberto

O nível de obstrução do céu é inferior a 20 % e o veículo está em movimento com dinâmica de condução normal e condições normais da estrada

C <= 5 m

S2

Túnel

Nenhum satélite GNSS é visível durante pelo menos 30 s 250 m (Vmin = 30 km/h); Reflexão do sinal GNSS à entrada e à saída do túnel

C < 15 m

S3

Estrutura de Estacionamento

Não há satélites GNSS visíveis diretos, mas ligação por reflexos, T > 60 s, vmax < 20 km/h, mínimo de duas curvas de 90 ° e s > 100 m, duas rampas na área de entrada e saída

é permitido qualquer valor

S4

Céu semiaberto

O nível de obstrução do céu é de 30-50 % (obstrução concentrada num lado do veículo) por mais de 30 s; condições de condução como em S1

C < 7 m

S5

Floresta

O nível de obstrução do céu por objetos é de 30-50 %, incluindo árvores de altura superior à antena, durante mais de 30 s.

C < 10 m

S6

Montanhas (vales)

O nível de obstrução do céu por montanha(s) é de 40-60 %. condições de condução como em S1

C < 10 m

S7

Cidade

Numa viagem de 300 s, o nível de obstrução do céu é de 30-50 % (são permitidos períodos curtos de obstrução a menos de 30-50 %), frequente sinalização GNSS dos edifícios, incluindo perdas curtas do sinal GNSS (ou seja, menos de quatro satélites); condições de condução como em S1

C < 14 m

S8

Semiurbano

O nível de obstrução do céu é de 2040 %, t > 60 s, s > 400 m. Condições de condução como em S1, com paragens, árvores e/ou edifícios, bem como becos

C < 10 m

Condições de condução a céu aberto

S9

Condução dinâmica

Ensaio de condução com acelerações longitudinais de mais de -6 m/s² e acelerações laterais de (±) 5 m/s²

C < 7 m

S10

Estático

Veículo paralisado durante 30 min

C < 5 m

S11

Estrada acidentada

Ensaio de condução em estada de terra com buracos, v= 20-50 km/h

C < 10 m

S12

Estrada com gelo

Ensaio de condução com acelerações longitudinais de mais de -0,5 m/s² e acelerações laterais de (±) 0,5 m/s², µ < 0,15

C < 7 m

S13

Alta velocidade

V= mínimo de (130 km/h, Vmáx) em piso seco durante 30 s

C < 5 m

(93)Em condições ótimas de GNSS e numa dinâmica de condução regular, conforme definido no ponto (89), os valores de velocidade de confiança devem ser iguais ou inferiores aos seguintes valores em pelo menos 95 % dos pontos de dados num conjunto de dados:

·0,6 m/s para velocidades entre 1,4 m/s e 12,5 m/s;

·0,3 m/s para velocidades superiores a 12,5 m/s.

(94)Em condições ótimas de GNSS e numa dinâmica de condução regular, conforme definido no ponto (89), os valores de rumo de confiança devem ser iguais ou inferiores aos seguintes valores em pelo menos 95 % dos pontos de dados num conjunto de dados:

·3 ° para velocidades entre 1,4 m/s e 12,5 m/s;

·2 ° para velocidades superiores a 12,5 m/s.

3.Requisitos para estações STI-C rodoviárias projetadas para comunicações de curto alcance

Este perfil de sistema especifica um conjunto mínimo de padrões e colmata as lacunas conforme necessário para a realização de uma estação STI-C rodoviária interoperável no lado de transmissão. O perfil inclui apenas requisitos de interoperabilidade, deixando em aberto quaisquer requisitos adicionais. Por conseguinte, não descreve todas as funcionalidades da estação STI-C rodoviária.

Este perfil do sistema permite a implantação dos serviços de prioridade (em especial, I2V). Poderá suportar outros serviços, mas estes poderão exigir especificações de sistema adicionais.

O perfil fornece descrições, definições e regras para as camadas (Aplicações, Instalações, Ligação em Rede e Transportes e Acesso) e a gestão da arquitetura de referência da estação ETSI STI/alojamento de STI-S.

3.1.Posicionamento e temporização

(95)O tempo STI-C de uma estação STI-C estática na estrada deve ser a base para todos os selos temporais em todas as mensagens e balizas GN transmitidas.

Nota: tal significa que os selos temporais na rubrica GN devem utilizar o mesmo relógio e a mesma base de tempo que os selos temporais nas cargas úteis de CAM/DENM/IVIM. Para SPATEM e MAPEM, o selo temporal utilizado deve ser conforme especificado na norma [ISO TS 19091].

(96)A posição das estações STI-C estáticas na estrada deve ser medida e definida com precisão de forma permanente.

Os valores de confiança devem ser iguais ou inferiores aos seguintes valores em pelo menos 95 % dos conjuntos de dados:

·posição horizontal (latitude, longitude) de confiança de 5 m;

·posição de altitude de confiança de 20 m.

Nota: evita a instabilidade do GNSS na precisão da posição e aumenta a confiança para quase 100 %.

(97)Deve ser estimada a diferença entre o relógio da estação e o tempo de base. A diferença absoluta | tempo do relógio da estação — base de tempo não deve exceder 20 ms, mas deve, em qualquer caso, ser inferior a 200 ms. A estação STI-C rodoviária não deve transmitir mensagens se a hora do relógio da estação diferir em mais de 200 ms.

Nota: um selo temporal preciso não só é necessário para a sincronização temporal, como também significa que os estados do sistema são válidos precisamente naquele momento, isto é, que os estados do sistema permanecem coerentes.

Nota: as informações para sincronização temporal podem ser obtidas a partir de um Galileo ou outro recetor GNSS ou de um serviço do Protocolo de Sincronização de Tempo (NTP).

3.2.Comportamento do sistema

(98)Todas as estações STI-C rodoviárias devem poder transmitir as mensagens de infraestrutura [por exemplo, DENM, CAM, Mensagem de Informações Veículo-Infraestrutura (IVIM), Mensagem de Fase e Temporização de Sinal Alargadas (SPATEM), Mensagem Alargada MAP (MAPEM) e Mensagem Alargada de Estado de Pedido de Sinal (SSEM)].

(99)As estações STI-C rodoviárias devem poder receber mensagens DENM, CAM e Mensagens Alargadas de Pedido de Sinal(SREM), conforme definido no ponto 3.6.

3.3.Camada de acesso

A camada de acesso compreende as duas camadas mais baixas na pilha de protocolos, isto é, as camadas físicas (FÍS) e de ligações de dados, em que a última ainda é subdividida em controlo de acesso ao meio (MAC) e controlo de ligação lógica (LLC).

(100)As estações STI-C rodoviárias devem aplicar os requisitos de desempenho otimizado de recetor opcionais conforme definido nos Quadros 17-19 da norma IEEE 802.11.

(101)As estações STI-C rodoviárias devem utilizar o canal de controlo G5-CCH conforme especificado no Quadro 3 da norma [EN 302 663] para enviar mensagens de apoio aos serviços prioritários STI-C especificados no Anexo 3, utilizando uma velocidade de transferência predefinida de 6 Mbit/s [modulação por deslocamento de fase em quadratura (QPSK) 1/2].

(102)A camada de acesso das estações STI-C rodoviárias deve estar em conformidade com a norma [EN 302 663], com exceção dos limites de emissão e dos pontos 4.2.1, 4.5 e 6.

(103)As estações STI-C rodoviárias devem estar em conformidade com a norma [TS 102 687].

(104)as estações STI-C rodoviárias devem gerir os recursos limitados de hardware e software à sua disposição e podem realizar configuração de tráfego ou encaminhamento seletivo de acordo com o princípio do «melhor esforço».

Nota: a configuração de tráfego é especialmente relevante para as mensagens DENM retransmitidas, pois prevê-se que, em algumas situações (como forte congestionamento rodoviário ou outros cenários extremos da rede veicular), a carga DENM possa aumentar abruptamente. Nesses casos, as estações STI-S rodoviárias estão expressamente autorizadas a renunciar ao encaminhamento de mensagens DENM estrangeiras.

(105)Uma estação STI-C rodoviária deve, no mínimo, poder gerar e transmitir o número de mensagens conforme determinado pelo valor da taxa de geração de CAM mais elevada (ou seja, 10 Hz) e, se forem utilizados algoritmos de deteção, deve ser aumentado pela taxa mínima de geração de DENM necessária derivada dessas condições de acionamento.

(106)Uma estação STI-C rodoviária deve suportar o modo de difusão definido na norma [EN 302 663].

(107)Uma zona protegida deve definir-se da seguinte forma:

·nos casos em que um local de portagens consiste numa única Unidade Localizada nas Vias Rodoviárias (RSU) CEN-DSRC, deve ser definida uma zona protegida com um raio predefinido de 55 m, estando a localização da RSU CEN-DSRC na posição central;

·nos casos em que existem várias RSU CEN-DSRC nas imediações, as sobreposições de zonas protegidas devem ser evitadas, tanto quanto possível, através de uma zona protegida combinada. Uma Zona Protegida combinada deve utilizar o centro geográfico (circuncentro) de todas as RSU DSRC em questão na posição central; o raio deve ser determinado pelo circunraio de + 55 m. Em qualquer caso, não deve ser excedido um raio máximo de 255 m.

Nota: devido ao raio máximo de 255 m, nem sempre é possível evitar sobreposições.

(108)Nos casos em que uma estação STI-C rodoviária está localizada próxima de um equipamento de portagem com base no CEND-SRC (pelo menos no interior da zona protegida), deve aplicar técnicas de mitigação conforme definido da norma [TS 102 792].

(109)As estações móveis STI-C rodoviárias devem aplicar métodos de mitigação com base nas mensagens de aviso de zona de portagens.

(110)Caso a estação STI-C rodoviária seja utilizada para indicar a presença de um posto de portagem, deve transmitir CAM abrangendo zonas protegidas de acordo com a técnica definida na norma [TS 102 792] e com o formato de mensagem de CA especificado na norma [EN 302 637-2]. Deve transmitir essas CAM no canal de controlo, antes que uma estação STI-C de um veículo entre na zona protegida.

(111)A camada de acesso das estações STI-C rodoviárias deve estar em conformidade com a norma [TS 102 724].

(112)As estações STI-C rodoviárias devem aplicar técnicas de DCC em conformidade com a norma [TS 102 687].

3.4.Rede e camada de transporte

(113)As estações STI-C rodoviárias devem aplicar GN enquanto protocolo de ligação em rede, em conformidade com a norma [EN 302 636-4-1].

(114)Todas as constantes e os parâmetros predefinidos do perfil rodoviário de infraestrutura não definidos no presente anexo devem ser definidos conforme especificado no anexo H da norma [EN 302 636-4-1].

(115)A repetição de pacotes não deve ser realizada por GN e não devem ser executadas as etapas correspondentes nos procedimentos de tratamento de pacotes definidos no ponto 10.3 da norma [EN 302 63641]. O parâmetro «tempo máximo de repetição» doGN-DATA.request primitivo de serviço e a constante do protocolo GN itsGnMinPacketRepetitionInterval não se aplicam.

(116)As estações STI-C rodoviárias podem optar por «endereço anónimo» para a configuração do endereço GN [itsGnLocalAddrConfMethod definido para ANÓNIMO (2)].

(117)As estações STI-C rodoviárias devem utilizar GN com itsGnIfType definido para STI-G5 (1).

(118)Se um pacote de repetição GN estiver desativado, o itsGnMinPacketRepetitionInterval não é aplicável.

(119)O campo LifeTime de todos os pacotes SHB deve ser configurado para um segundo.

(120)O campo LifeTime de todos os pacotes GBC deve ser definido para o mínimo de ValidityDuration e RepetitionInterval, mas não deve exceder o parâmetro itsGnMaxPacketLifetime, especificado no Anexo H da norma [EN 302 636-4-1].

(121)Se o «armazenamento-transporte-encaminhamento» estiver ativado, o bit de SCF no campo de TC deve ser configurado para um.

Nota: consequentemente, os pacotes podem ser armazenados em memória intermédia se nenhum vizinho estiver disponível.

(122)Não é necessário que as estações STI-C rodoviárias descarreguem pacotes para outro canal. Desta forma, o bit de descarregamento de canal do campo TC deve ser regulado para 0 para todos os tipos de mensagens.

(123)Uma estação STI-C rodoviária fixa deve definir o bit itsGnIsMobile do campo Indicadores para 0. Uma estação STI-C rodoviária deve definir o bit itsGnIsMobile do campo Indicadores para 1.

(124)As estações STI-C rodoviárias devem suportar o modo de operação de múltiplos saltos com recurso aos algoritmos especificados nos Anexos E.3 e F.3, com base nos princípios de seleção descritos no Anexo D da norma [EN 302 636-4-1].

(125)As estações STI-C rodoviárias devem utilizar a deteção de pacotes duplicados na rede e na camada de transporte. Para a deteção de pacotes duplicados, deve ser utilizado o algoritmo especificado no Anexo A.2 da norma [EN 302 636-4-1].

(126)As estações STI-C rodoviárias podem apenas enviar balizas GN com o Indicador de Precisão de Posição (PAI) configurado para 1.

(127)Os quadros GN enviados pela estação STI-C rodoviária devem utilizar o valor EtherType 0x8947 conforme indicado pela Autoridade de Registo do IEEE em http://standards.ieee.org/develop/regauth/ethertype/eth.txt .

(128)As estações STI-C rodoviárias devem implementar o BTP em conformidade com a norma [EN 302 636-5-1].

(129)As estações STI-C rodoviárias devem utilizar rubricas BTP-B. Consequentemente,a rubrica comum GN deve utilizar um valor de 2 para o campo NH.

(130)As estações STI-C rodoviárias devem configurar o campo de informações da porta de destino com o valor 0.

(131)As estações STI-C rodoviárias devem definir a porta de destino em função do conjunto de mensagens especificado na norma [TS 103 248].

(132)As áreas geográficas devem ser aplicadas de acordo com a norma [EN 302 931].

(133)As estações STI-C rodoviárias devem suportar pelo menos áreas geográficas circulares, retangulares e elipsoidais conforme definido na norma [EN 302 931]. Cada serviço STI-C deve especificar um dos tipos de área geográfica indicados acima através da rubrica GN, conforme especificado na norma [EN 302 636-4-1].

(134)Quando uma estação STI-C rodoviária calcula a distância entre duas posições com recurso ao Galileo ou outras coordenadas de GNSS (por exemplo, para PathDeltaPoints ou em casos de área de relevância circular), recomenda-se a utilização do círculo máximo ou de um método de maior precisão. Deve-se ter cuidado (por exemplo, usando a fórmula de Haversine) para evitar grandes erros de arredondamento em sistemas de vírgula flutuante de baixa precisão.

Nos casos em que a área de relevância é uma elipse ou um retângulo, as coordenadas cartesianas do centro da área e da posição atual devem ser calculadas tal como especificado na norma [EN 302 931] para avaliar se o pacote deve ser saltado. Para esse efeito, recomenda-se o método «plano tangente local» ou outro método de igual rigor.

3.5.Camada das instalações

(135)O serviço básico de DEN das estações STI-C rodoviárias deve estar em conformidade com a norma [EN 302 637-3]

(136)As estações STI-C rodoviárias devem implementar a repetição de DENM conforme especificado na norma [EN 302 637-3].

(137)Os casos em que as atualizações de DENM são acionadas encontram-se especificados no Anexo I, no perfil de serviço pertinente.

(138)Nos casos em que uma estação STI-C rodoviária envia uma DENM, os rastreios devem ser descritos como uma lista de localizações geográficas que conduzem da posição do evento de volta ao primeiro ponto de trajeto.

(139)Quando uma estação móvel STI-C rodoviária se torna fixa, o PathDeltaTime do primeiro PathPoint do primeiro elemento de rastreios de DENM deve ser fixado no valor máximo especificado nanorma [EN 302 637-3]. Desta forma, os PathPoints não «caem» no primeiro elemento de rastreamento de DENM. Tal aplica-se apenas aos serviços STI-C baseados em reboques.

(140)Poderão estar presentes elementos adicionais do PathHistory nos rastreios de DENM. No entanto, ao contrário do primeiro elemento, estes devem descrever rotas alternativas para o local do evento. Essas rotas podem ou não estar disponíveis no momento de deteção do evento.

(141)No caso das estações STI-C rodoviárias, o valor CT de uma mensagem é específico para o serviço de base do formato da mensagem ou do próprio serviço STI-C, razão pela qual é especificado no perfil de serviço pertinente no Anexo I. O valor TC selecionado deve estar em conformidade com as classificações de mensagem conforme especificado nas normas [TS 102 636-4-2] e [TS 103 301], com a exceção de que as mensagens de informações veículo-infraestrutura (IVI) relacionadas com limites de velocidade variáveis são equivalentes a DENM de baixa prioridade, podendo assim ter o mesmo valor de TC.

(142)A estação STI-C rodoviária deve utilizar um sistema de coordenadas em conformidade com o ponto 2.13 da norma [ISO 8855].

Nota: tal significa que os eixos X e Y são paralelos ao plano do solo, o eixo Z é alinhado numa vertical ascendente, o eixo Y aponta para o lado esquerdo na direção póstero-anterior do veículo e o eixo X aponta para a direção de póstero-anterior do veículo.

(143)Para a transmissão de mensagens por sistemas rodoviários, deve ser utilizado o protocolo de nível de instalações e a configuração do perfil de comunicação CPS_001, conforme especificado na norma [TS 103 301].

(144)Os dados da zona protegida fornecidos numa CAM enviada por uma estação STI-C rodoviária não devem entrar em conflito com as informações da zona protegida fornecidas na base de dados da zona protegida ou num base de dados equivalente. Se a mesma zona for definida na base de dados da zona protegida, deve ser utilizado o mesmo identificador como protectedZoneID. Caso contrário, deve ser utilizado um identificador superior a 67108863 que não é usado na base de dados.

(145)As estações STI-C rodoviárias destinadas a disseminar dados de zona protegida devem transmitir CAM regularmente contendo dados da zona protegida com recurso ao formato de mensagem especificado na norma [EN 302 637-2]. Não é utilizada a terminação de CAM.

Nota: os elementos de dados específicos para o serviço STI-C de coexistência estão localizados no quadro de dados highFrequencyContainer e rsuContainerHighFrequency.

Nota: uma CAM pode conter outros elementos de dados não relacionados com o serviço STI-C de coexistência.

(146)A antena de uma estação STI-C rodoviária destinada a disseminar dados da zona protegida deve ser colocada de modo que as CAM da zona de proteção possam ser recebidas a tempo antes da entrada na zona protegida.

Nota: as medidas adotadas para cumprir este requisito devem ter em conta o tempo de processamento de que o equipamento do utente da via necessita para processar as informações recebidas. Deve ser utilizado um tempo de 300 ms como referência.

(147)Uma estação STI-C rodoviária destinada a disseminar dados da zona protegida deve transmitir CAM que contenham dados da zona protegida com uma frequência de transmissão que garanta que as estações STI-C móveis sejam capazes de identificar a presença de zonas protegidas a tempo.

(148)Uma estação STI-C rodoviária destinada a disseminar dados da zona protegida deve ser instalada fora das zonas protegidas ou configurada de acordo com a norma [ETSI TS 102 792].

(149)Uma CAM não deve conter mais de uma zona protegida temporária (por exemplo, ProtectedCommunicationZone com ProtectedZoneType= 1).

Nota: esta condição aplica-se especificamente aos veículos temporários de portagens e aos veículos das forças de segurança. As estações STI-C móveis são obrigadas a armazenar apenas uma zona de proteção temporária de acordo com o ponto 5.2.2.2 da norma [TS 102 792], a fim de evitar ambiguidades.

(150)Nos casos em que é utilizado o Serviço de Camadas de Instalações de coexistência (STI-G5 - CEN-DSRC), este deverá ser aplicado de acordo com a norma [EN 302 637-2] e conforme especificado na norma [TS 102 792].

(151)A norma [ISO/TS 19321] refere-se a uma versão mais antiga (1.2.1) do dicionário de dados comum da norma [TS 102 894-2] (CDD) para dados de carga útil. Todos os serviços STI-C IVI baseados na norma [ISO/TS 19 321] deverão, assim, basear-se na versão atualizada (1.3.1), até que a norma [ISO/TS 19321] seja atualizada em conformidade.

(152)O serviço básico da CA deve estar ativo enquanto a estação móvel STI-C rodoviária estiver a participar em vias públicas numa dinâmica de condução regular. Enquanto o serviço básico da CA estiver ativo, as CAM devem ser geradas de acordo com as regras de geração da norma [EN 302 637-2].

(153)A estação STI-C rodoviária deve transmitir mensagens CAM se as informações de confiança da posição estiverem disponíveis e o relógio da estação estiver em conformidade com o ponto (97).

(154)O parâmetro T_GenCam_Dcc deve ser configurado para o valor do tempo mínimo entre duas transmissões, Toff, conforme estabelecido pelo mecanismo de DCC especificado no ponto (103).

(155)O parâmetro ajustável N_GenCam especificado na gestão de frequência de geração de CAM deve ser ajustado para 0 para a estação STI-C rodoviária, a menos que se destine a disseminar dados da zona protegida, conforme definido no ponto (145).

3.6.Gestão

Nem todos os serviços de segurança especificados necessitam de ser implementados. Além disso, para alguns serviços, a implementação é definida internamente pelo operador da estação STI-C.

(156)As estações STI-C rodoviárias que implementam as funcionalidades do STI-G5 devem implementar uma camada de gestão que inclua uma entidade DCC_CROSS conforme especificado na norma [TS 103 175].

3.7.Elementos do serviço

3.7.1.Serviço básico de DEN

O serviço básico de DEN utiliza os serviços prestados pelas entidades de protocolo da camada de ligação em rede e transporte STI para disseminar as DENM.

Uma DENM contém informações relativas a um evento que tem um impacto potencial na segurança rodoviária ou nas condições de tráfego. Um evento é caracterizado por um tipo de evento, uma posição de evento, um tempo de deteção e uma duração de tempo. Esses atributos podem alterar-se no espaço e ao longo do tempo. A transmissão de DENM pode ser independente da estação STI-C de origem em algumas situações.

São gerados quatro tipos de DENM pelo serviço básico de DEN:

   DENM novas;

   DENM de atualização;

   DENM de cancelamento;

   DENM de negação.

(157)A rubrica de DENM deve ser conforme especificado no dicionário de dados da norma [TS 102 894-2].

(158)Os elementos de dados, os quadros de dados e os parâmetros de serviço de DENM devem ser definidos de acordo com o Quadro 3. Além disso, para os serviços STI-C sobre avisos de obras na estrada, os quadros de dados e os parâmetros de serviço de DENM devem ser definidos de acordo com o Quadro 4.

Quadro 3: Elementos de DENM em geral

Nome

Utilização

Uso

Contenção de gestão

Obrigatório

actionID

Obrigatório

Conteúdo:

O actionID é o identificador exclusivo de uma DENM e consiste nos elementos de dados originatingStationID e sequenceNumber. originatingStationID é o identificador único da estação STI-C cuja camada de instalações criou a mensagem, que pode ser a estação central ou a estação STI-C rodoviária. Se não forem definidas pela estação STI-C central, as mensagens cujo conteúdo é gerado centralmente, mas que são transmitidas de diferentes estações STI-C rodoviárias, terão diferentes originatingStationIDs, resultando em diferentes actionIDs

Se o originatingStationID e o sequenceNumber forem fornecidos pela estação STI-C central em que o conteúdo gerado centralmente é (potencialmente) enviado através de várias estações STI-C rodoviárias, o sistema fornece o mesmo actionID para todas as mensagens relacionadas com o mesmo evento, independentemente da estação STI-C rodoviária que estiver a enviar a mensagem. Uma vez definido, o actionID não será alterado para mensagens relacionadas com o mesmo evento, mesmo que sejam atualizadas com frequência.

Valor:

não predefinido, definido pelo sistema

detectionTime

Obrigatório

Inicialmente, este DE deve ser ajustado para a hora/data em que o evento foi detetado. A hora deve provir de uma fonte horária local na estação STI-C rodoviária em cenários de utilização autónoma. Em situações de utilização com ligação à estação STI-C central, o método detectionTime deve ser inicialmente definido para o momento em que a aplicação que cria a DENM recebe as informações relevantes, ou seja, no momento em que se iniciam ou se detetam obras na estrada ou uma localização perigosa a um nível funcional.

Valor:

O detectionTime é inicialmente configurado para a hora de início do evento (DENM nova) e redefinido para cada DENM de atualização. Para a terminação de DENM, este DE será o momento em que a terminação do evento é detetada.

referenceTime

Obrigatório

Conteúdo:

O referenceTime deve ser configurado para o horário em que a mensagem DENM é gerada ou atualizada.

Valor:

Definido automaticamente

termination

Facultativo

Específico do serviço STI-C

eventPosition

Obrigatório

Nos casos de utilização de I2V, a DF eventPosition é utilizada para localizar bloqueios de faixa ou de via ou localizações perigosas. Representa a posição em que o bloqueio físico da faixa (incluindo a berma pavimentada) ou a via ou da localização perigosa começa. É necessário que a precisão seja pelo menos no nível da via, embora deva ser ao nível da faixa.

Os DE de altitude e confiança podem ser usados ou ajustados para os valores correspondentes a «indisponível».

relevanceDistance

Facultativo

Facultativo

relevanceTrafficDirection

Obrigatório

Conteúdo:

Valor fixo. Nas autoestradas, este valor é configurado para 1 (tráfego a montante).

Este DF indica para que sentido de circulação a mensagem é relevante (da perspetiva da eventPosition).

validityDuration

Obrigatório

Os eventos são representados por mensagens DEN. A duração de uma DENM singular baseia-se no valor (configurável) de «validityDuration». Desde que um evento seja válido para o operador rodoviário, será continuamente enviada (com recurso à repetição de DENM) e atualizado (com recurso à DENM de atualização, renovando «validityDuration», «detectionTime» e «referenceTime» no processo). Será acionada uma atualização de mensagem por «validityDuration» abaixo de um certo limite (também configurável). Se o evento deixar de ser válido, será expirado ou cancelado ativamente (cancelamento de DENM).

Conteúdo:

O DE validityDuration está ajustado para um valor fixo.

Valor:

Específico do serviço STI-C.

TransmissionInterval

Não utilizado

Não utilizado

stationType

Obrigatório

Conteúdo:

Valor fixo, ajustado em 15 (roadSideUnit). Tal aplica-se a estações fixas e móveis de STI-C rodoviárias. O valor pode ser 9 (reboque) ou 10 (specialVehicles) no caso de bordos de operador rodoviário.

Valor:

Definido para 9, 10 ou 15.

Contenção de situação

Obrigatório

informationQuality

Obrigatório

A qualidade das informações constitui a probabilidade de ocorrência, num intervalo de 0 a 7.

Valores: risco (2), provável (4), certo (6)

Caso seja recebido o valor (0), deve ser rejeitado; caso seja recebido o valor (7), considera-se certo.

eventType

Obrigatório

Combinação do DE causeCode e DE subCauseCode. Específico do serviço STI-C.

linkedCause

Facultativo

Possibilidade de associar a mensagem atual a um conjunto de causeCode /subCauseCode (semelhante a eventType) para fornecer informações adicionais.

eventHistory

Facultativo

Conteúdo:

Este perfil utiliza opcionalmente este DE quando o ponto final do bloqueio físico pode ser determinado. Nesse caso, descreve o início de um bloqueio até ao final do bloqueio ou o início de um novo bloqueio (outra DENM). Nesse contexto, os valores do eventPoint são fornecidos sem o correspondente eventDeltaTime, pois os pontos descrevem uma extensão geoespacial e não uma trajetória.

O DE informationQuality no eventHistory será definido com o mesmo valor que a informationQuality de toda a DENM especificada acima.

Caso sejam utilizadas projeções cartográficas, estas devem referir-se a pontos no meio da faixa ou da via.

O desvio máximo entre a realidade e as projeções cartográficas não deve exceder um quarto da largura da via.

Contenção de localização

Facultativo

eventSpeed

Facultativo

Este DF apenas deve ser fornecido no caso de um evento em movimento, se disponível. Em caso de eventos estáticos, não deve ser fornecido.

eventPositionHeading

Facultativo

As informações de rumo apenas devem ser fornecidas para eventos em movimento através do eventPositionHeading. Os eventos estacionários baseados em DENM não usarão este DF.

traces

Obrigatório

O primeiro ponto de rastreio na mensagem é o ponto mais próximo da posição do evento. Esse ponto situa-se no meio da faixa ou via a montante a montante da posição do evento, considerando a curvatura da estrada. É codificado como uma posição delta ou de deslocamento sobre a posição do evento. Os pontos de rastreio adicionais são definidos como deslocamentos ou posições delta em relação ao seus pontos de rastreio anteriores. Os pontos de rastreio serão listados na ordem a montante, definindo também a rubrica do evento.

Podem estar presentes até sete rastreios.

Caso sejam utilizadas projeções cartográficas, estas devem referir-se a pontos no meio da faixa ou da via.

O desvio máximo entre a realidade e as projeções cartográficas não deve exceder um quarto da largura da via.

roadType

Facultativo

Facultativo

Contenção a la carte

Facultativo

lanePosition

Facultativo

Específico do serviço STI-C.

impactReduction

Não utilizado

Não utilizado

externalTemperature

Não utilizado

Não utilizado

lightBarSirenInUse

Não utilizado

Não utilizado



Quadro 4: Elementos de DENM específicos de avisos de obras na estrada

Nome

Utilização

Uso

Contenção a la carte

Facultativo

lanePosition

Facultativo

facultativo

closedLanes

Facultativo

As faixas são contadas a partir da berma interna da estrada, excluindo a berma pavimentada.

Este DF consiste em drivingLaneStatus e hardShoulderStatus.

speedLimit

Facultativo

facultativo

recommendedPath

Facultativo

facultativo

startingPointSpeedLimit

Facultativo

facultativo

trafficFlowRule

Facultativo

facultativo

De um modo geral, a passToRight(2) ou passToLeft(3) são suportadas em todos os cenários de serviço STI-C.

referenceDenms

Facultativo

As DENM de aviso de obras na estrada pertencentes à mesma situação de obras na estrada serão associadas na estação central STI-C, listando todos os actionIDs pertencentes ao elemento de dados referenceDenms de cada mensagem.

3.7.2.Serviço IVI

O serviço IVI utiliza os serviços prestados pelas entidades de protocolo da camada de ligação em rede e transporte STI para disseminar IVIM.

Uma IVIM suporta sinalização rodoviária obrigatória e de recomendação, como velocidades contextuais e avisos de obras na estrada. As IVIM fornecem informações de sinais de trânsito físicos, como sinais de trânsito estáticos ou variáveis, sinais virtuais ou obras na estrada.

O serviço IVI instanciado numa estação STI-C deve fornecer o serviço de transmissão ou o serviço de receção.

O serviço IVI gera quatro tipos de IVIM:

·IVIM novas;

·IVIM de atualização;

·IVIM de cancelamento;

·IVIM de negação.

(159)A rubrica de IVIM deve ser conforme especificado na norma [TS 102 894-2].

(160)Os elementos de dados da carga útil da mensagem IVIM são definidos na norma [ISO/TS 19321].

(161)Os elementos de dados de IVIM, os quadros de dados de IVIM e os parâmetros de serviço devem ser definidos de acordo com o Quadro 5.

Quadro 5

Nome

Utilização

Uso

Contenção de gestão de IVI

Obrigatório

serviceProviderId

Obrigatório

O serviceProviderID consiste em elementos de dados de «countryCode» e «providerIdentifier».

o countryCode é uma sequência de bits em conformidade com a norma [ISO 3166-1]. Para a Áustria, por exemplo, a sequência de bits corresponde a «AT» (código de sequência de bits: A (11000) e T (00001) 1100000001 em conformidade com a norma [ISO 14 816]).

Juntamente com iviIdentificationNumber, este é o identificador exclusivo de mensagens para a estação STI-C de bordo recetora.

iviIdentificationNumber

Obrigatório

Este DE é o identificador da estrutura de IVI, conforme atribuído pelo prestador de serviços. Este componente serve como o identificador da mensagem por serviceProvider e pode ser utilizado como referência por outras mensagens relacionadas.

timestamp

Obrigatório

Esse DE é o timestamp que representa a hora em que a mensagem IVI é gerada ou quando o conteúdo das mensagens foi alterado pela última vez.

validFrom

Obrigatório

Este componente pode conter a data e hora de início do período de validade da mensagem. Se a data e hora de início não for relevante ou for desconhecida para o sistema, o parâmetro validFrom não está presente ou é igual a timestamp.

validTo

Obrigatório

Este DE deve ser sempre utilizado para determinar a validade. Deve ser enviada uma atualização antes que a mensagem expire.

Valor: definido pela aplicação

O período de validade predefinido é definido pelo operador rodoviário.

connectedIviStructures (1..8)

Não utilizado

Não utilizado.

iviStatus

Obrigatório

Este componente contém o estado da estrutura IVI. Pode ser definido para novo (0), de atualização (1), de cancelamento (2) ou de negativa (3). É utilizado para o tratamento de mensagens.

Contenção de localização geográfica (GLC)

Obrigatório

referencePosition

Obrigatório

Este DE é utilizado como ponto de referência para todas as zonas no GLC.

O ponto de referência para IVI é o meio da via, num pórtico, e é o primeiro ponto das definições de zona para zonas de relevância e zonas de deteção.

A altitude pode ser definida como indisponível se for desconhecida. Se a altitude for fornecida, corresponde à altitude da estrada.

Valor: definido pela aplicação

referencePositionTime

Não utilizado

Não utilizado.

referencePositionHeading

Não utilizado

Não utilizado

referencePositionSpeed

Não utilizado

Não utilizado.

GlcPart

Obrigatório

partes (1..16). Podem ser definidas até 16 partes em cada GLC. O GLC contém pelo menos duas zonas: uma relativa à relevância e uma relativa à deteção.

Valor: definido pela aplicação

zoneId

Obrigatório

Devem ser fornecidas pelo menos uma zona de deteção e uma zona de relevância para cada mensagem.

laneNumber

Facultativo

Obrigatório se as faixas individuais forem descritas neste contentor de localização. Predefinição ausente (sem informação de faixa).

zoneExtension

Não utilizado

Não utilizado.

zoneHeading

Obrigatório

Obrigatório

zona

Obrigatório

Definição de uma zona utilizando a zona DF que consiste num segmento DF escolhido, polygonalLine do DF ou computedSegment do DF.

A opção de segmento deve ser utilizada com polygonalLine como uma linha (construída com deltaPosition como para rastreamentos de DENM) e com laneWidth opcionalmente (usada apenas nos casos em que uma única faixa é referenciada dentro da zona).

Contenção de aplicação de IVI

Obrigatório

detectionZoneIds

Obrigatório

Lista de identificador(es) da(s) definição(ões) da(s) zona(s) de deteção, utilizando o DE Zid (1..8)

its-Rrid

Não utilizado

Não utilizado.

relevanceZoneIds

Obrigatório

Lista de identificador(es) da(s) definição(ões) da(s) zona(s) de relevância a que se aplica a contenção de IVI, utilizando o DE Zid (1..8)

sentido

Obrigatório

Sentido de relevância em relação ao sentido (implicitamente) definido pela zona utilizando o sentido dos DE. Definir sempre para mesmoSentido(0).

driverAwarnessZoneIds

Não utilizado

Não utilizado.

minimumAwarenessTime

Não utilizado

Não utilizado.

applicableLanes (1..8)

Facultativo

Lista de identificadores da(s) faixa(s) a que a contenção de IVS se aplica com recurso ao DE LanePosition (1..8).

iviType

Obrigatório

Fornece o tipo de IVI (por exemplo, mensagem de perigo iminente, mensagem regulamentar, mensagem de informação de tráfego) para permitir a classificação e a priorização de IVI na estação STI-C recetora.

iviPurpose

Não utilizado

Não utilizado.

laneStatus

Facultativo

Indica o estado da faixa (por exemplo, aberta, fechada, mergeL, mergeR) das applicableLanes.

completeVehicleCharacteristics

Facultativo

As completeVehicleCharacteristics devem conter a definição das características dos veículos aos quais é aplicável uma contenção de aplicação. O componente «reboque» (se presente) deve conter as características aplicáveis a todo o veículo articulado.

driverVehicleCharacteristics

Não utilizado

Não utilizado.

layoutId

Não utilizado

Não utilizado.

preStoredLayoutId

Não utilizado

Não utilizado.

roadSignCodes

Obrigatório

Deve conter a definição do código do sinal de trânsito. Permite diferentes opções apontando para diferentes catálogos de pictogramas.

Este componente especifica quais os sinais rodoviários que são aplicáveis a uma zona de relevância. Os códigos dos sinais rodoviários dependem do esquema de classificação referenciado.

Podem ser adicionados atributos adicionais ao código do sinal rodoviário conforme fornecidos pelas opções.

Lista de 1..4 do RSCode

RSCode (código de sinais de trânsito)

Obrigatório

Contém o layoutComponentId e um código.

layoutComponentId

Não utilizado

Este quadro de dados pode ser usado para associar o RSCode ao componente de apresentação da apresentação referenciada.

Código

Obrigatório

Para a codificação dos sinais, deve utilizar-se a norma [ISO/TS 14 823].

Código ISO 14823

Obrigatório

Para a codificação dos sinais, deve utilizar-se a norma [ISO/TS 14 823].

Este quadro de dados inclui vários DF e DE.

Inclui pictogramCode (countryCode, serviceCategorycode e pictogramCategoryCode).

Os atributos SET (troço) e NOL (número de faixas) não são suportados, pois duplicam informações que já são suportadas na contenção da aplicação.

extraText ((1..4),...)

Facultativo

Lista de linhas de texto associadas à lista ordenada de códigos de sinais rodoviários. Cada elemento contém o código de língua mais texto extra de tamanho limitado na língua selecionada com recurso ao texto do DF.

Nota: esse DF pode ser sobrecarregado com segurança para incluir mais linhas de texto.

3.7.3.Serviço de Topologia de Faixa de Rodagem (TFR)

O serviço TFR utiliza os serviços prestados pelas entidades de protocolo da camada de ligação em rede e transporte STI para disseminar TFR.

Inclui a topologia de faixa para veículos, bicicletas, estacionamento, transporte público e os percursos para passadeiras para peões, por exemplo, e as manobras admissíveis dentro de uma área de interseção ou um troço de estrada. Em aperfeiçoamentos futuros, o mapa digital incluirá descrições topológicas adicionais, como rotundas.

(162)As rubricas de MAPEM devem ser conforme especificado na norma [ETSI TS 102 894-2].

(163)Os elementos de dados de MAPEM, os quadros de dados de MAPEM e os parâmetros de serviço devem ser definidos de acordo com o Quadro 6.

Quadro 6: Elementos de dados de MAPEM

Nível

Nome

Tipo

Utilização

Uso

*

mapData

DF

Obrigatório

**

timeStamp

DE

Não utilizado

Não utilizado.

**

Revisão de msgIssue

DE

Obrigatório

Obrigatório e definido para 0. Conforme definido na norma ISO TS 19091.

**

layerType

DE

Não utilizado

Não utilizado.

**

layerID

DE

Facultativo

Facultativo. Conforme definido na norma ISO TS 19091.

**

interseções
(1..32)

DF

Obrigatório

IntersectionGeometryList::= SEQUENCE (SIZE(1..32)) DE IntersectionGeometry (ver quadro 6.1)

Obrigatório para serviços de Manobra de semáforo (TLM)/TFR de STI-C.

**

roadSegments
(1..32)

DF

Não utilizado

Não utilizado. Os elementos de dados já não são objeto de perfil.

**

dataParameters

DF

Facultativo

Facultativo.

***

processMethod

DE

Não utilizado

Não utilizado.

***

processAgency

DE

Facultativo

Facultativo.

***

lastCheckedDate

DE

Facultativo

Facultativo, como aaaa-mm-dd

***

geoidUsed

DE

Não utilizado

Não utilizado.

**

Lista de restrição
(1..32)

DF

Facultativo

RestrictionClassList::= SEQUENCE (SIZE(1..254)) OF RestrictionClassAssignment (ver quadro 6.3).

Facultativo.

**

regional

DE

Não utilizado

REGION.Reg-MapData.

Não utilizado.

Quadro 6.1: IntersectionGeometryList -> Intersection Geometry

Nível

Nome

Tipo

Utilização

Uso

*

intersectionGeometry

QD

Obrigatório

Obrigatório se «interseções» for utilizado.

**

nome

DE

Facultativo

Facultativo. Geralmente legível por pessoas e reconhecível pela autoridade rodoviária.

**

identificador

DF

Obrigatório

(IntersectionReferenceID)

Obrigatório. Tem de ser o mesmo que na SPATEM. A combinação de região e identificador deve ser única dentro de um país.

***

região

DE

Facultativo

Facultativo.

***

identificador

DE

Obrigatório

Obrigatório.

**

revisão

DE

Obrigatório

Obrigatório. O número de revisão deve ser aumentado em um de cada vez que os MapData dessa interseção forem alterados. Os números de revisão de SPATEM e MAPEM devem ser os mesmos, para indicar que é utilizada a revisão correta de MAPEM. Conforme definido na norma ISO TS 19091.

**

refPoint

DF

Obrigatório

Obrigatório.

***

lat

DE

Obrigatório

Obrigatório.

***

longa

DE

Obrigatório

Obrigatório.

***

elevação

DE

Não utilizado

Não utilizado. Substituído por RegPosition3D regional.

***

regional

DF

Facultativo

REGION.Reg-Position3D.

Facultativo. Quando disponível, fornece a altitude.

****

altitude,

DF

Obrigatório

Obrigatório. Consiste em altitudeValue e altitudeConfidence

*****

altitudeValue

DE

Obrigatório

Obrigatório.

*****

altitudeConfidence

DE

Facultativo

Obrigatório; quando não disponível, definir como (15) = indisponível.

**

laneWidth

DE

Facultativo

Facultativo.

**

speedLimits
(1..9)

DF

Facultativo

SpeedLimitList::= SEQUENCE (SIZE(1..9)) OF RegulatorySpeedLimit (ver Quadro 6.2).

Facultativo.

**

laneSet
(1..255)

DF

Obrigatório

LaneList::= SEQUENCE (SIZE(1..255)) OF GenericLane (ver Quadro 6.4).

Obrigatório.

**

preemptPriorityData
(1..32)

DF

Não utilizado

Não utilizado. Os elementos de dados já não são objeto de perfil.

**

Regional

DF

Não utilizado

REGION.Reg- IntersectionGeometry). Não utilizado.

Quadro 6.2: SpeedLimitList -> RegulatorySpeedLimit

Nível

Nome

Tipo

Utilização

Uso

*

regulatory SpeedLimit

DF

Obrigatório

Obrigatório se forem utilizados «speedLimits».

**

tipo

DE

Obrigatório

Obrigatório.

**

velocidade

DE

Obrigatório

Obrigatório.

Quadro 6.3: RestrictionClassList -> RestrictionClassAssignment

Nível

Nome

Tipo

Utilização

Uso

*

restriction ClassAssignment

DF

Obrigatório

Obrigatório se for utilizada a restrictionList .

**

id

DE

Obrigatório

Obrigatório.

**

utilizadores

DF

Obrigatório

RestrictionUserTypeList::= SEQUENCE (SIZE(1..16)) OF RestrictionUserType

Obrigatório.

***

restrictionUserType

DF

Obrigatório

****

basicType

DE

Facultativo

Usado.

****

regional
(1..4)

DF

Facultativo

REGION.Reg-RestrictionUserType-addGrpC. Facultativo para fornecer restrições de emissão.

*****

emissão

DE

Facultativo

Facultativo.

Quadro 6.4: LaneList -> GenericLane

Nível

Nome

Tipo

Utilização

Uso

*

genericLane

DF

Obrigatório

Obrigatório se for utilizado «laneSet».

**

laneID

DE

Obrigatório

Obrigatório.

**

nome

DE

Facultativo

Facultativo.

**

ingressApproach

DE

Facultativo

Facultativo. Se usadas, as abordagens de entrada e saída do mesmo braço têm o mesmo ApproachID.

**

egressApproach

DE

Facultativo

Facultativo. Se usadas, as abordagens de entrada e saída do mesmo braço têm o mesmo ApproachID.

**

laneAttributes

DF

Obrigatório

Obrigatório.

***

uso Direcional

DE

Obrigatório

Obrigatório.

***

sharedWith

DE

Obrigatório

Obrigatório.

Com bit conforme definição: overlappingLaneDescriptionProvided (0) multipleLanesTreatedAsOneLane (1)

-- não é permitido no perfil, pois todas as faixas devem ser descritas.

otherNonMotorizedTrafficTypes (2)

-- p. ex. puxado a cavalo

individualMotorizedVehicleTraffic (3)

-- ligeiros de passageiros

busVehicleTraffic (4)

taxiVehicleTraffic (5)

pedestriansTraffic (6)

cyclistVehicleTraffic (7)

trackedVehicleTraffic (8) pedestrianTraffic (9)
-- utilizar antes 6 (erro)

***

laneType

DF

Obrigatório

Obrigatório. Utilizado neste perfil:

veículo

passadeira

bikeLane

trackedVehicle

-- consultar exemplos de passadeiras na norma ISO TS 19091.

****

Veículo

DE

Facultativo

Facultativo (escolha).

****

passadeira

DE

Facultativo

Facultativo (escolha).

****

bikeLane

DE

Facultativo

Facultativo (escolha).

****

passeio

DE

Não utilizado

Não utilizado.

****

mediana

DE

Não utilizado

Não utilizado.

****

striping

DE

Não utilizado

Não utilizado.

****

trackedVehicle

DE

Facultativo

Facultativo (escolha).

****

estacionamento

DE

Não utilizado

Não utilizado.

***

regional

DF

Não utilizado

Reg-laneAttributes. Não utilizado.

**

manobras

DE

Não utilizado

Não utilizado.

**

nodeList

DF

Obrigatório

Obrigatório.

***

nós

(2..63)

DF

Obrigatório

NodeSetXY::= SEQUENCE (SIZE(2..63)) OF NodeXY (ver Quadro 6.5)

Obrigatório se for utilizado «nodeList».

A utilização recomendada para faixas curvas consiste em acrescentar um nó adicional quando a linha central da GenericLane apresenta um desvio superior a 0,5 m da linha central real.

***

informático

DF

Não utilizado

Não utilizado.

**

connectsTo
(1..16)

DF

Facultativo

ConnectsToList::= SEQUENCE (SIZE(1..16)) OF Connection (ver Quadro 6.6).

Facultativo. Exemplo de faixa(s) de saída não gerida(s) por um semáforo.

**

sobreposições

DF

Não utilizado

Não utilizado.

**

regional

DF

Não utilizado

REGION-Reg-GenericLane. Não utilizado (até à próxima publicação da norma ISO TS 19091). Para obter ConnectionTrajectory-addGrpC. Relevante para casos de utilização de manobra de interseção segura.

Quadro 6.5: NodeSetXY -> NodeXY

Nível

Nome

Tipo

Utilização

Uso

*

nodeXY

DF

Obrigatório

Obrigatório se forem utilizados «nodes».

**

delta

DF

Obrigatório

Obrigatório.

***

node-XY1

DF

Facultativo

Facultativo (escolha).

DF composto por X e Y, ambos obrigatórios.

***

node-XY2

DF

Facultativo

Facultativo (escolha).

DF composto por X e Y, ambos obrigatórios.

***

node-XY3

DF

Facultativo

Facultativo (escolha).

DF composto por X e Y, ambos obrigatórios.

***

node-XY4

DF

Facultativo

Facultativo (escolha).

DF composto por X e Y, ambos obrigatórios.

***

node-XY5

DF

Facultativo

Facultativo (escolha).

DF composto por X e Y, ambos obrigatórios.

***

node-XY6

DF

Facultativo

Facultativo (escolha).

DF composto por X e Y, ambos obrigatórios.

***

node-LatLon

DF

Não utilizado

Não utilizado para interseções. A utilização em autoestradas, por exemplo, é aceitável.

***

regional

DF

Não utilizado

REGION.Reg-NodeOffsetPointXY.

Não utilizado.

**

atributos

DF

Facultativo

Este DE fornece quaisquer atributos facultativos que são necessários. Tal inclui alterações na largura e na elevação da faixa atual. Todos os atributos são fornecidos pela ordem dos nós (por oposição ao sentido de marcha). Também as indicações esquerda/direita por atributos devem ser interpretadas com base na ordem dos nós.

***

localNode

(1..8)

DF

Facultativo

NodeAttributeXYList::=

SEQUENCE (SIZE(1..8)) OF

NodeAttributeXY

Facultativo. Dependente do caso É obrigatória a linha de paragem quando presente no campo.

****

nodeAttributeXY

DE

Obrigatório

Obrigatório se for utilizado o localNode .

***

desativados

(1..8)

DF

Facultativo

SegmentAttributeXYList::=

SEQUENCE (SIZE(1..8)) OF

SegmentAttributeXY

Facultativo. Dependente do caso

****

segmentAttributeXY

DE

Obrigatório

Obrigatório se for utilizado o desativado.

***

ativado

(1..8)

DF

Facultativo

SegmentAttributeXYList::=

SEQUENCE (SIZE(1..8)) OF

SegmentAttributeXY

Facultativo. Dependente do caso

****

segmentAttributeXY

DE

Obrigatório

Obrigatório se for utilizado o ativado.

***

dados

DF

Facultativo

Facultativo.

****

pathEndPointAngle

DE

Não utilizado

Não utilizado.

****

pathEndPointAngle

DE

Não utilizado

Não utilizado.

****

laneCrownPointCenter

DE

Não utilizado

Não utilizado.

****

laneCrownPointLeft

DE

Não utilizado

Não utilizado.

****

laneCrownPointRight

DE

Não utilizado

Não utilizado.

****

laneAngle

DE

Não utilizado

Não utilizado.

****

speedLimits (1..9)

DE

Facultativo

SpeedLimitList::= SEQUENCE

(SIZE(1..9)) OF

RegulatorySpeedLimit

(ver quadro 6.2).

Facultativo (escolha).

****

regional

DF

Não utilizado

REGION.Reg-
LaneDataAttribute.
Não utilizado.

***

dWidth

DE

Facultativo

Facultativo.

***

dElevation

DE

Facultativo

Facultativo.

***

regional

DF

Não utilizado

REGION.Reg-NodeAttributeSetXY.
Não utilizado.

Quadro 6.6: ConnectsToList -> Connection

Nível

Nome

Tipo

Utilização

Uso

*

conexão

DF

Facultativo

Obrigatório se for utilizado «connectsTo».

**

connectingLane

DF

Obrigatório

Obrigatório.

***

faixa

DE

Obrigatório

Obrigatório.

***

manobra

DE

Facultativo

Facultativo.

**

remoteIntersection

DF

Facultativo

Facultativo. Utilizado apenas se a interseção referenciada fizer parte da mesma MAPEM.

***

Região

DE

Facultativo

Facultativo.

***

Identificador

DE

Obrigatório

Obrigatório.

**

signalGroup

DE

Facultativo

Facultativo, uma vez que nem todas as ligações podem ter grupos de sinais relacionados. No entanto, para ligações controladas por um semáforo, o grupo de sinais deve ser definido.

**

userClass

DE

Facultativo

Facultativo.

**

connectionID

DE

Obrigatório

Obrigatório.

3.7.4.Serviço de TLM

O serviço TLM utiliza os serviços prestados pelas entidades de protocolo da camada de ligação em rede e transporte STI para disseminar TLM.

Ele inclui informações relacionadas com a segurança para ajudar os participantes do tráfego (veículos, peões, etc.) a executar manobras seguras numa área de interseção. O objetivo é entrar e sair da «área de conflito» de uma interseção de forma controlada. O serviço TLM fornece informações em tempo real sobre os estados operacionais do controlador de semáforos, o estado atual do sinal, o tempo residual do estado antes de mudar para o próximo estado e as manobras permitidas, auxiliando na passagem.

(164)As rubricas de SPATEM devem ser conforme especificado na norma [TS 102 894-2].

(165)Os elementos de dados, os quadros de dados e os parâmetros de serviço de SPATEM devem ser definidos de acordo com o quadro 7.

Quadro 7: Elementos de dados de SPATEM

Nível

Nome

Tipo

Utilização

Uso

*

Spat

DF

Obrigatório

**

timeStamp

DE

Facultativo

Não utilizado, mas ainda facultativo.

**

nome

DE

Facultativo

Não utilizado, mas ainda facultativo.

**

Interseções

(1..32)

DF

Obrigatório

IntersectionStateList::= SEQUENCE (SIZE(1..32)) OF IntersectionState (ver Quadro 7.1).

Obrigatório

**

regional (1..4)

DF

Não utilizado

REGION.Reg-SPAT.

Não utilizado.

Quadro 7.1: IntersectionStateList -> IntersectionState

Nível

Nome

Tipo

Utilização

Uso

*

intersectionState

DF

Obrigatório

**

nome

DE

Facultativo

Utilizado, mas ainda facultativo.

Baseado num esquema de numeração utilizado pela autoridade rodoviária.

**

identificador

DF

Obrigatório

(IntersectionReferenceID)

Obrigatório. Tem de ser o mesmo que na MAPEM. A combinação de região e identificador deve ser única dentro de um país.

***

região

DE

Facultativo

Facultativo.

***

identificador

DE

Obrigatório

Obrigatório.

**

revisão

DE

Obrigatório

Obrigatório. O número de revisão deve ser aumentado em um de cada vez que os MapData dessa interseção forem alterados. Os números de revisão de SPATEM e MAPEM devem ser os mesmos, para indicar que é utilizada a revisão correta de MAPEM. Conforme definido na norma ISO TS 19091.

**

estado

DE

Obrigatório

Obrigatório. Geralmente utilizados, com base na norma EN 12675:

manualControlIsEnabled (0);

fixedTimeOperation (5);

trafficDependentOperation (6);

standbyOperation (7);

failureMode (8).

**

moy

DE

Obrigatório

Obrigatório. Também utilizado para validar o tempo de referência dos SelosTemporais.

**

timeStamp

DE

Obrigatório

Obrigatório.

**

enabledLanes

DF

Facultativo

Obrigatório se o bit revocableLane for utilizado em qualquer uma das descrições de faixa; caso contrário, não é utilizado.

**

estados

(1..16)

DF

Obrigatório

MovementList::= SEQUENCE (SIZE(1..255)) OF MovementState (ver Quadro 7.2).

Obrigatório.

**

maneuverAs sistList

(1..16)

DF

Não utilizado

ManeuverAssistList::= SEQUENCE (SIZE(1..16)) OF ConnectionManeuverAssist (ver Quadro 7.5).

Não usado, deixando assim de ser objeto de perfil neste nível.

**

Regional (1..4)

DF

Facultativo

REGION.Reg-IntersectionState.

Facultativo, para garantir a interoperabilidade com os sistemas existentes de priorização de transportes públicos.

Quadro 7.2: MovementList -> MovementState

Nível

Nome

Tipo

Utilização

Uso

*

movementState

DF

Obrigatório

Obrigatório se for utilizado «states».

**

movementName

DE

Facultativo

Facultativo.

**

signalGroup

DE

Obrigatório

Obrigatório.

**

estado-tempo-velocidade

DF

Obrigatório

MovementEventList::= SEQUENCE (SIZE(1..16)) OF MovementEvent.

Obrigatório (1-16).

(ver quadro 7.3).

**

maneuverAssistList

(1..16)

DF

Facultativo

ManeuverAssistList::= SEQUENCE (SIZE(1..16)) OF ConnectionManeuverAssist (ver Quadro 7.5).

Facultativo.

**

regional

(1..4)

DF

Não utilizado

REGION.Reg-MovementState.

Não utilizado.

Quadro 7.3: MovementEventList -> MovementEvent

Nível

Nome

Tipo

Utilização

Uso

*

movementEvent

QD

Obrigatório

Obrigatório se for utilizado «estado-tempo-velocidade».

**

eventState

DE

Obrigatório

Obrigatório se definido do seguinte modo:

(0)indisponível (desconhecido ou erro);

(1)escuro (não utilizado na UE);

(2)sinal de paragem permissivo (por exemplo, luz vermelha combinada com sinal de trânsito com seta verde para movimento de viragem);

(3)sinal de paragem não permissivo (p. ex. luz vermelha);

(4)pré-movimento (por exemplo, vermelho/âmbar, tal como usado em alguns países da UE antes do sinal verde);

(5)movimento permissivo permitido (por exemplo, luz verde de «bola cheia», com tráfego potencialmente conflituoso, especialmente nas viragens);

(6)movimento Protegido Permitido (por exemplo, luz de «seta» verde, sem tráfego conflituoso ou peões ao atravessar a área de conflito);

(7)liberação permissiva (por exemplo, luz âmbar de «bola cheia», preparação para parar. Utilizado após um estado de sinal «verde»);

(8)liberação protegida (por exemplo, luz de «seta» âmbar, preparação direcional para parar. Utilizado após um estado de sinal «seta verde»);

(9)atenção-Tráfego-Conflituoso (por exemplo, luz âmbar intermitente; prosseguir com atenção; o tráfego conflituoso pode estar presente na área de conflito da interseção).

**

temporização

DF

Facultativo

Facultativo. Por exemplo, os dados de temporização podem não estar disponíveis quando o «estado» for 0, 1 ou 9.

Todos os TimeMarks são definidos como um deslocamento para a hora completa UTC (ver norma [ISO TS 19091]) e não para efeitos de segurança funcional, mas sim informativos relacionados com a temporização do sinal. As medidas likelyTime com confiança ou minEndTime com maxEndTime destinam-se ao cálculo de probabilidade e podem ser usadas de forma intercambiável, dependendo da disponibilidade.

***

startTime

DE

Não utilizado

Não utilizado.

***

minEndTime

DE

Obrigatório

Obrigatório. Valor pré-configurado ou calculado com alta probabilidade, mas por vezes não disponível (36001). Em casos de controlo de tempo fixo, por exemplo, à semelhança de maxEndTime, que indica alta probabilidade.

***

maxEndTime

DE

Obrigatório

Obrigatório. Valor pré-configurado ou calculado com alta probabilidade, mas por vezes não disponível (36001). Em casos de controlo de tempo fixo, por exemplo, à semelhança de minEndTime, que indica alta probabilidade.

***

likelyTime

DE

Facultativo

Facultativo.

***

confiança

DE

Facultativo

Obrigatório se for fornecido o likelyTime .

Não é utilizável a definição de «confiança» na norma base. Em vez disso, a confiança é definida pelo desvio padrão (sigma) do likelyTime em segundos. O valor fornecido por esse elemento de dados, entre 0 e 15, representa 1 sigma (arredondado). 15 = desconhecido Assim, não é utilizada a tabela de conversão com probabilidades, conforme estabelecido na SAE J2735.

Assumindo uma distribuição normal e um desvio padrão de 3,6 segundos, o likelyTime é:

dentro de 26 e 34 segundos (1 sigma), com 68,27 % de probabilidade;

dentro de 22 e 38 segundos (2 sigma), com 95,44 % de probabilidade;

dentro de 18 e 42 segundos (3 sigma), com 99,73 % de probabilidade.

***

nextTime

DE

Facultativo

Facultativo.

**

velocidades

(1..16)

DF

Facultativo

AdvisorySpeedList::= SEQUENCE (SIZE(1..16)) OF AdvisorySpeed (ver Quadro 7.4).

Facultativo.

**

regional

(1..4)

DF

Facultativo

REGION.Reg-MovementEvent, Optional.

Quadro 7.4: AdvisorySpeedList -> AdvisorySpeed

Nível

Nome

Tipo

Utilização

Uso

*

advisorySpeed

DF

Obrigatório

Obrigatório se for utilizado «speeds».

**

tipo

DE

Obrigatório

Obrigatório.

onda verde (1) = velocidade para uma sequência de cruzamentos coordenados (repetida em cada cruzamento).

ecoDrive (2) = velocidade para cruzamento atual.

trânsito (3) = restrito ao tipo de bordo específico.

**

velocidade

DE

Facultativo

Facultativo.

**

confiança

DE

Não utilizado

Não utilizado.

**

distância

DE

Facultativo

Facultativo.

Não utilizado para onda verde (1). Noutros casos, a distância é especificada a montante da barra de stop ao longo da faixa de entrada.

**

classe

DE

Facultativo

Facultativo.

**

regional
(1..4)

DF

Não utilizado

REGION.Reg-AdvisorySpeed.

Não utilizado.

Quadro 7.5: ManeuverAssistList -> ConnectionManeuverAssist

Nível

Nome

Tipo

Utilização

Uso

*

connection ManeuverAssist

DF

Obrigatório

Obrigatório se for utilizada a «maneuverAssistList».

**

connectionID

DE

Obrigatório

Obrigatório.

**

queueLength

DE

Facultativo

Facultativo.

**

availableStorageLength

DE

Não utilizado

Não utilizado.

**

waitOnStop

DE

Não utilizado

Não utilizado.

**

pedBicycleDetect

DE

Não utilizado

Não utilizado.

**

regional

(1..4)

DF

Não utilizado

REGION.Reg-ConnectionManeuverAssist.

Não utilizado.

Início

ÍNDICE

1.Introdução9

1.1.Visão geral e âmbito de aplicação da presente política9

1.2.Definições e siglas11

1.3.Participantes da PKI13

1.3.1.Introdução13

1.3.2.Autoridade da política de certificação de STI-C16

1.3.3.Gestor da lista aprovada17

1.3.4.Auditor acreditado da PKI17

1.3.5.Ponto de contacto para STI-C (CPOC)17

1.3.6.Funções operacionais18

1.4.Utilização de certificados18

1.4.1.Domínios de utilização aplicáveis18

1.4.2.Limites de responsabilidade19

1.5.Administração da política de certificação19

1.5.1.Atualização dos CPS de CA enumerados no ECTL19

1.5.2.Procedimentos de aprovação da CPS20

2.Responsabilidades de publicação e criação de repositórios20

2.1.Métodos para a publicação de informações de certificados20

2.2.Altura ou frequência de publicação21

2.3.Repositórios21

2.4.Controlos de acesso a repositórios21

2.5.Publicação de informações de certificados22

2.5.1.Publicação de informações de certificados pelo TLM22

2.5.2.Publicação de informações de certificados pelas CA22

3.Identificação e autenticação23

3.1.Nomenclatura23

3.1.1.Tipos de nomes23

3.1.1.1.Nomes para TLM, CA de raiz, EA e AA23

3.1.1.2.Nomes para as entidades finais23

3.1.1.3.Identificação de certificados23

3.1.2.Necessidade de os nomes serem significativos23

3.1.3.Anonimato e pseudonímia das entidades finais23

3.1.4.Regras de interpretação das diversas formas de nomes23

3.1.5.Exclusividade dos nomes24

3.2.Validação inicial de identidade24

3.2.1.Método para demonstrar posse de chave privada24

3.2.2.Autenticação de identidade de uma organização24

3.2.2.1.Autenticação da identidade de uma organização de CA24

3.2.2.2.Autenticação da identidade de uma organização do TLM25

3.2.2.3.Autenticação da identidade de uma organização de CA subordinadas25

3.2.2.4.Autenticação da organização do subscritor da entidade final26

3.2.3.Autenticação de entidade individual26

3.2.3.1.Autenticação de entidade individual de TLM/CA26

3.2.3.2.Autenticação de identidade de subscritores de estações de STI-C27

3.2.3.3.Autenticação de identidade de estações de STI-C27

3.2.4.Informações de subscritor não verificadas27

3.2.5.Validação de autoridade27

3.2.5.1.Validação de TLM, CA de raiz, EA, AA27

3.2.5.2.Validação de subscritores de estações de STI-C28

3.2.5.3.Validação de estações de STI-C28

3.2.6.Critérios de interoperação28

3.3.Identificação e autenticação para pedidos de reemissão de chave28

3.3.1.Identificação e autenticação para pedidos de reemissão de chave de rotina28

3.3.1.1.Certificados de TLM28

3.3.1.2.Certificados de CA de raiz28

3.3.1.3.Renovação ou reemissão de chave de certificados de EA/AA28

3.3.1.4.Credenciais de inscrição de entidades finais29

3.3.1.5.Bilhetes de autorização das entidades finais29

3.3.2.Identificação e autenticação para pedidos de reemissão de chave após revogação29

3.3.2.1.Certificados de CA29

3.3.2.2.Credenciais de inscrição de entidades finais29

3.3.2.3.Pedidos de autorização de entidades finais29

3.4.Identificação e autenticação para pedidos de revogação29

3.4.1.Certificados de CA de raiz/EA/AA29

3.4.2.Credenciais de inscrição de estações de STI-C30

3.4.3.Certificados de autorização de estações de STI-C30

4.Requisitos operacionais do ciclo de vida dos certificados30

4.1.Pedido de certificado30

4.1.1.Quem pode submeter um pedido de certificado30

4.1.1.1.CA de raiz30

4.1.1.2.TLM31

4.1.1.3.EA e AA31

4.1.1.4.Estação de STI-C31

4.1.2.Processo de inscrição e responsabilidades31

4.1.2.1.CA de raiz31

4.1.2.2.TLM32

4.1.2.3.EA e AA32

4.1.2.4.Estação de STI-C32

4.2.Processamento de pedidos de certificado33

4.2.1.Realização de funções de identificação e autenticação33

4.2.1.1.Identificação e autenticação de CA de raiz33

4.2.1.2.Identificação e autenticação de TLM33

4.2.1.3.Identificação e autenticação de EA e AA33

4.2.1.4.Identificação e autenticação de subscritores de EE34

4.2.1.5.Certificados de autorização34

4.2.2.Aprovação ou rejeição de pedidos de certificado34

4.2.2.1.Aprovação ou rejeição de certificados de CA de raiz34

4.2.2.2.Aprovação ou rejeição de certificados de TLM34

4.2.2.3.Aprovação ou rejeição de certificados de EA e AA34

4.2.2.4.Aprovação ou rejeição de EC34

4.2.2.5.Aprovação ou rejeição de CA35

4.2.3.Tempo de processamento do pedido de certificado35

4.2.3.1.Pedido de certificado da CA de raiz35

4.2.3.2.Pedido de certificado do TLM35

4.2.3.3.Pedido de certificado da EA e AA35

4.2.3.4.Pedido de EC35

4.2.3.5.Pedido de CA35

4.3.Emissão do certificado35

4.3.1.Ações da CA durante a emissão de certificados35

4.3.1.1.Emissão de certificados de CA de raiz35

4.3.1.2.Emissão de certificados de TLM36

4.3.1.3.Emissão de certificados de EA e AA36

4.3.1.4.Emissão de EC36

4.3.1.5.Emissão de CA36

4.3.2.Notificação da CA aos subscritores da emissão de certificados.36

4.4.Aceitação de certificados37

4.4.1.Realização da aceitação de certificados37

4.4.1.1.CA de raiz37

4.4.1.2.TLM37

4.4.1.3.EA e AA37

4.4.1.4.Estação de STI-C37

4.4.2.Publicação do certificado37

4.4.3.Notificação de emissão de certificado37

4.5.Par de chaves e utilização do certificado37

4.5.1.Chave privada e utilização do certificado37

4.5.1.1.Chave privada e utilização de certificados para TLM37

4.5.1.2.Chave privada e utilização de certificados para CA de raiz37

4.5.1.3.Chave privada e utilização de certificados para EA e AA37

4.5.1.4.Chave privada e utilização de certificados para a entidade final38

4.5.2.Chave pública e utilização de certificados da parte utilizadora38

4.6.Renovação de certificado38

4.7.Reemissão de chave de certificado38

4.7.1.Circunstâncias para a reemissão de chave de certificado38

4.7.2.Quem pode solicitar a reemissão de chave38

4.7.2.1.CA de raiz38

4.7.2.2.TLM38

4.7.2.3.EA e AA38

4.7.2.4.Estação de STI-C39

4.7.3.Processo de reemissão de chave39

4.7.3.1.Certificado do TLM39

4.7.3.2.Certificado da CA de raiz39

4.7.3.3.Certificados de EA e AA39

4.7.3.4.Certificados da estação de STI-C40

4.8.Alteração de certificado40

4.9.Revogação e suspensão de certificado40

4.10.Serviços de estado de certificado40

4.10.1.Características operacionais40

4.10.2.Disponibilidade do serviço40

4.10.3.Características facultativas40

4.11.Fim da subscrição40

4.12.Retenção e recuperação de chaves40

4.12.1.Subscritor40

4.12.1.1.Que par de chaves pode ser retido40

4.12.1.2Quem pode submeter um pedido de recuperação40

4.12.1.3.Processo de recuperação e responsabilidades40

4.12.1.4.Identificação e autenticação40

4.12.1.5Aprovação ou rejeição de pedidos de recuperação40

4.12.1.6.Ações da autoridade de retenção de chaves e da autoridade de recuperação de chaves durante a recuperação do par de chaves41

4.12.1.7.Disponibilidade da autoridade de retenção de chaves e da autoridade de recuperação de chaves41

4.12.2.Política e práticas de encapsulação e recuperação de chaves de sessão41

5.Instalações, gestão e controlos operacionais41

5.1.Controlos físicos41

5.1.1.Localização física e construção41

5.1.1.1.CA de raiz, CPOC e TLM41

5.1.1.2.EA/AA42

5.1.2.Acesso físico42

5.1.2.1.CA de raiz, CPOC e TLM42

5.1.2.2.EA/AA43

5.1.3.Energia e ar condicionado43

5.1.4.Exposição à água43

5.1.5.Prevenção e proteção contra incêndios44

5.1.6.Gestão de suportes44

5.1.7.Eliminação de resíduos44

5.1.8.Salvaguarda fora do local44

5.1.8.1.CA de raiz, CPOC e TLM44

5.1.8.2.EA/AA45

5.2.Procedimentos de controlo45

5.2.1.Funções de confiança45

5.2.2.Número de pessoas necessário por tarefa45

5.2.3.Identificação e autenticação para cada função46

5.2.4.Funções que requerem a separação de tarefas46

5.3.Controlos de pessoal47

5.3.1.Requisitos relativos a qualificações, experiência e credenciação47

5.3.2.Procedimentos de verificação de antecedentes47

5.3.3.Requisitos de formação48

5.3.4.Frequência e requisitos de ações de reciclagem48

5.3.5.Frequência e sequência da rotação de funções48

5.3.6.Sanções para ações não autorizadas48

5.3.7.Requisitos aplicáveis aos contratantes independentes49

5.3.8.Documentação fornecida ao pessoal49

5.4.Procedimentos de registo de auditorias49

5.4.1.Tipos de eventos a serem registados e comunicados por cada CA49

5.4.2.Frequência do registo de processamento50

5.4.3.Período de conservação de registos de auditoria50

5.4.4.Proteção de registos de auditoria51

5.4.5.Procedimentos de salvaguarda de registos de auditoria51

5.4.6.Sistema de recolha de auditorias (interno ou externo)51

5.4.7.Notificação ao sujeito causador de evento51

5.4.8.Avaliação de vulnerabilidades51

5.5.Arquivo de registos52

5.5.1.Tipos de registos arquivados52

5.5.2.Período de conservação de arquivos53

5.5.3.Proteção de arquivos53

5.5.4.Arquivo e armazenamento do sistema53

5.5.5.Requisitos de validação cronológica de registos54

5.5.6.Sistema de recolha de arquivos (interno ou externo)54

5.5.7.Procedimentos para obter e verificar informações do arquivo54

5.6.Transferência da chave para elementos do modelo de confiança de STI-C54

5.6.1.TLM54

5.6.2.CA de raiz54

5.6.3.Certificado da EA/AA54

5.6.4.Auditor55

5.7.Recuperação em caso de comprometimento e catástrofe55

5.7.1.Tratamento de incidentes e comprometimentos55

5.7.2.Corrupção de recursos informáticos, aplicações informáticas e/ou dados56

5.7.3.Procedimentos em caso de comprometimento de chaves privadas de entidades56

5.7.4.Capacidade de continuidade das atividades em caso de catástrofe56

5.8.Cessação e transferência57

5.8.1.TLM57

5.8.2.CA de raiz57

5.8.3.EA/AA58

6.Controlos de segurança técnica58

6.1.Geração e instalação de pares de chaves58

6.1.1.TLM, CA de raiz, EA, AA58

6.1.2.EE — estação móvel de STI-C58

6.1.3.EE — estação fixa de STI-C59

6.1.4.Requisitos de criptografia59

6.1.4.1.Comprimento de algoritmos e chaves — algoritmos de assinatura59

6.1.4.2.Comprimento de algoritmos e chaves — algoritmos de encriptação para inscrição e autorização60

6.1.4.3.Criptoagilidade61

6.1.5.Armazenamento seguro de chaves privadas61

6.1.5.1.Nível de CA de raiz, CA subordinada e TLM61

6.1.5.2.Entidade final62

6.1.6.Salvaguarda de chaves privadas63

6.1.7.Destruição de chaves privadas63

6.2.Dados de ativação63

6.3.Controlos de segurança informática63

6.4.Controlos técnicos do ciclo de vida63

6.5.Controlos de segurança de rede63

7.Perfis de certificados, CRL e CTL63

7.1.Perfil do certificado63

7.2.Validade do certificado64

7.2.1.Certificados de pseudónimos64

7.2.2.Bilhetes de autorização para estações de STI-C fixas65

7.3.Revogação de certificados65

7.3.1.Revogação de certificados de CA, EA e AA65

7.3.2.Revogação de credenciais de inscrição66

7.3.3.Revogação de bilhetes de autorização66

7.4.Lista de revogação de certificados66

7.5.Lista aprovada de certificados europeus66

8.Auditoria de conformidade e outras avaliações66

8.1.Aspetos abrangidos pela auditoria e base da auditoria66

8.2.Frequência das auditorias67

8.3.Identidade/qualificações do auditor67

8.4.Relação do auditor com a entidade auditada67

8.5.Medidas tomadas face a deficiência67

8.6.Comunicação dos resultados68

9.Outras disposições68

9.1.Taxas68

9.2.Responsabilidade financeira68

9.3.Confidencialidade das informações comerciais69

9.4.Plano de privacidade69

10.Referências69

ANEXO III

1.Introdução

1.1.Visão geral e âmbito de aplicação da presente política

A presente política de certificação define o modelo europeu de confiança de STI-C baseado numa infraestrutura de chave pública (PKI) no âmbito do sistema geral de gestão de credenciais de segurança dos STI-C da UE (EU CCMS). Define requisitos para a gestão de certificados de chave pública para aplicações STI-C por entidades emissoras e a sua utilização por entidades finais na Europa. No seu nível mais elevado, a PKI é composta de um conjunto de CA de raiz «ativadas» devido ao facto de o gestor da lista aprovada (TLM) inserir os seus certificados numa lista aprovada de certificados europeus (ECTL), que é emitida e publicada pela entidade central do TLM (ver secções 1.2 e 1.3).

A presente política é vinculativa para todas as entidades que participam no sistema STI-C na Europa. Funciona como auxílio na avaliação do nível de confiança que pode ser estabelecido em relação às informações recebidas por qualquer recetor de uma mensagem autenticada por um certificado de entidade final da PKI. Para permitir a avaliação da confiança nos certificados fornecidos pelo EU CCMS, estabelece um conjunto obrigatório de requisitos para a operação da entidade central do TLM e a compilação e gestão da ECTL. Por conseguinte, o presente documento rege os seguintes aspetos relacionados com a ECTL:

·identificação e autenticação de diretores que obtêm funções de PKI para o TLM, incluindo declarações dos privilégios atribuídos a cada função;

·requisitos mínimos para práticas de segurança locais para o TLM, incluindo controlos físicos, de pessoal e processuais;

·requisitos mínimos para práticas de segurança técnica para o TLM, nomeadamente segurança informática, segurança de rede e controlos de engenharia de módulos criptográficos;

·requisitos mínimos para práticas operacionais para o TLM, incluindo o registo de novos certificados de CA de raiz, o cancelamento temporário ou permanente de CA de raiz existentes e incluídas e a publicação e distribuição de atualizações da ECTL;

·um perfil da ECTL, incluindo todos os campos de dados obrigatórios e facultativos na ECTL, algoritmos criptográficos a utilizar, o formato exato da ECTL e recomendações para o processamento da ECTL;

·gestão do ciclo de vida de certificados da ECTL, incluindo a distribuição de certificados da ECTL, a ativação, a expiração e a revogação;

·gestão da revogação da confiança das CA de raiz quando necessário.

Uma vez que a confiabilidade da ECTL não depende somente da própria ECTL, mas em grande parte também das CA de raiz que compõem a PKI e respetivas CA subordinadas, a presente política também estabelece requisitos mínimos, que são obrigatórios para todas as CA participantes (CA de raiz e CA subordinadas). As áreas sujeitas a requisitos são:

·identificação e autenticação de diretores que obtêm funções de PKI (por exemplo, agentes de segurança, responsáveis pelas questões de privacidade, administradores de segurança, administradores de diretório e utilizadores finais), incluindo uma declaração de deveres, obrigações, responsabilidades e privilégios associados a cada função;

·gestão de chaves, incluindo algoritmos aceitáveis e obrigatórios de assinatura de certificados e de assinatura de dados e períodos de validade de certificados;

·requisitos mínimos para práticas de segurança locais, incluindo controlos físicos, de pessoal e processuais;

·requisitos mínimos para práticas de segurança técnica, como segurança informática, segurança de rede e controlos de engenharia de módulos criptográficos;

·requisitos mínimos para as práticas operacionais da CA, EA AA e entidades finais, nomeadamente, aspetos do registo, do cancelamento de registos (retirada da lista), da revogação, do comprometimento de chaves, da demissão por justa causa, da atualização de certificados, das práticas de auditoria e da não divulgação de informações relacionadas com a privacidade;

·certificado e perfil da CRL, incluindo formatos, algoritmos aceites, campos de dados obrigatórios e opcionais e respetivos intervalos de valores válidos, e a forma como os verificadores devem processar os certificados;

·deveres de monitorização regular, elaboração de relatórios, emissão de alertas e restauração das entidades do modelo de confiança de STI-C, a fim de estabelecer uma operação segura, inclusive em casos de comportamento indevido.

Além dos referidos requisitos mínimos, as entidades que gerem as CA de raiz e CA subordinadas podem decidir os seus próprios requisitos adicionais e defini-los nas declarações de práticas de certificação (CPS) pertinentes, desde que não contradigam os requisitos definidos na política de certificação. Para mais informações sobre o modo como as CPS são auditadas e publicadas, ver secção 1.5.

A CP também estabelece as finalidades para as quais as CA de raiz e CA subordinadas, bem como os respetivos certificados emitidos, podem ser utilizados. Estabelece as responsabilidades assumidas:

·pelo TLM;

·por cada CA de raiz cujos certificados constem na ECTL;

·pelas CA subordinadas da CA de raiz (EA e AA);

·por cada membro ou organização responsável por, ou que opere, uma das entidades do modelo de confiança de STI-C.

A CP define igualmente as obrigações obrigatórias aplicáveis:

·ao TLM;

·a cada CA de raiz cujos certificados constem na ECTL;

·a cada CA subordinada certificada por uma CA de raiz;

·a todas as entidades finais;

·a cada membro da organização responsável por, ou que opere, uma das entidades do modelo de confiança de STI-C.

Por último, a CP estabelece requisitos no que diz respeito à documentação das limitações de responsabilidades e obrigações na CPS de cada CA de raiz cujos certificados constem na ECTL.

A presente CP está em linha com a política de certificação e o quadro de práticas de certificação adotado pela Internet Engineering Task Force (IETF)[3].

1.2.Definições e siglas

Aplicam-se as definições de [2], [3] e [4].

AA

autoridade de autorização

CA

certificado de autorização

CA

autoridade de certificação

CP

política de certificação

CPA

autoridade da política de certificação de STI-C

CPOC

ponto de contacto para STI-C

CPS

declaração de práticas de certificação

CRL

lista de revogação de certificados

EA

autoridade de inscrição

EC

credencial de inscrição

ECIES

esquema integrado de curva de criptografia elítica

EE

entidade final (ou seja, estação de STI-C)

ECTL

Lista aprovada de certificados europeus

EU CCMS

sistema de gestão de credenciais de segurança dos STI-C da UE

GDPR

Regulamento Geral sobre a Proteção de Dados:

HSM

módulo de segurança do equipamento

PKI

infraestrutura de chave pública

RA

autoridade de registo

CA subordinada

EA e AA

TLM

gestor da lista aprovada



Glossário

requerente

A pessoa singular ou entidade jurídica que solicita (ou pretende renovar) um certificado. Uma vez criado o certificado inicial (inicialização), o requerente é referido como o subscritor.

Para certificados emitidos para entidades finais, o subscritor (requerente do certificado) é a entidade que controla ou opera/mantém a entidade final para a qual o certificado é emitido, mesmo se a entidade final enviar o pedido de certificado real.

autoridade de autorização

No presente documento, o termo «autoridade de autorização» (AA) refere-se não apenas à função específica da AA, mas também à entidade jurídica e/ou operacional que o gere.

autoridade de certificação

A autoridade de certificação de raiz, a autoridade de inscrição e a autoridade de autorização são cumulativamente referidas como a autoridade de certificação (CA).

Modelo de confiança de STI-C

O modelo de confiança de STI-C é responsável por estabelecer uma relação de confiança entre as estações de STI-C. É implementada através da utilização de uma PKI composta de CA de raiz, o CPOC, o TLM, as EA e AA e uma rede segura.

Criptoagilidade

A capacidade das entidades do modelo de confiança de STI-C de adaptar a CP a ambientes em mudança ou a novos requisitos futuros, por exemplo, através da mudança de algoritmos criptográficos e de comprimento da chave ao longo do tempo

módulo criptográfico

Um elemento seguro baseado em equipamento informático no qual as chaves são geradas e/ou armazenadas, são gerados números aleatórios e os dados são assinados ou encriptados.

autoridade de inscrição

No presente documento, o termo «autoridade de inscrição» (EA) refere-se não apenas à função específica da EA, mas também à entidade jurídica e/ou operacional que o gere.

Participantes da PKI

Entidades do modelo de confiança de STI-C, a saber, o TLM, as CA de raiz, as EA, as AA e as estações de STI-C.

reemissão de chave

Este subcomponente é utilizado para descrever certos elementos relacionados com um subscritor ou outro participante que gera um novo par de chaves e solicita a emissão de um novo certificado que certifica a nova chave pública, tal como descrita em [3].

repositório

O repositório utilizado para armazenar os certificados e informações sobre certificados fornecidos pelas entidades do modelo de confiança de STI-C, conforme definido na secção 2.3.

autoridade de certificação de raiz

No presente documento, o termo «autoridade de certificação de raiz» (CA) refere-se não apenas à função específica da CA, mas também à entidade jurídica e/ou operacional que o gere.

sujeito

A pessoa singular, dispositivo, sistema, unidade ou entidade jurídica identificada num certificado como o sujeito, ou seja, o subscritor ou um dispositivo sob o controlo e a operação do subscritor.

subscritor

Pessoa singular ou entidade jurídica à qual é emitido um certificado e que está juridicamente vinculada por um contrato de subscritor ou termos de utilização.

contrato de subscritor

Um acordo entre a CA e o requerente/subscritor que especifica os direitos e as responsabilidades das partes.

1.3.Participantes da PKI

1.3.1.Introdução

Os participantes da PKI desempenham uma função na PKI definida pela presente política. A menos que seja explicitamente proibido, um participante pode assumir várias funções em simultâneo. Pode estar proibido de assumir funções específicas em simultâneo, a fim de evitar conflitos de interesses ou garantir a separação de tarefas.

Os participantes também podem delegar partes da sua função a outras entidades no âmbito de um contrato de serviços. Por exemplo, quando as informações de estado de revogação são fornecidas utilizando CRL, a CA também é o emissor da CRL, mas pode delegar a responsabilidade de emitir CRL numa entidade diferente.

As funções da PKI consistem em:

·funções de autoridade, ou seja, cada função é instanciada de forma única;

·funções operacionais, ou seja, funções que podem ser instanciadas em uma ou mais entidades.

Por exemplo, uma CA de raiz pode ser implementada por uma entidade comercial, um grupo de interesse comum, uma organização nacional e/ou uma organização europeia.

A Figure 1 mostra a arquitetura do modelo de confiança STI-C baseada na [2]. A arquitetura é aqui brevemente descrita, mas os principais elementos são descritos em maior detalhe nas secções 1.3.2 a 1.3.6.

A CPA nomeia o TLM, que é, por conseguinte, uma entidade de confiança para todos os participantes da PKI. A CPA aprova a operação da CA de raiz e confirma que o TLM pode confiar na(s) CA de raiz. O TLM emite a ECTL que garante a confiança das CA de raiz aprovadas a todos os participantes da PKI. A CA de raiz emite certificados para a EA e a AA, garantindo assim confiança na sua operação. A EA emite certificados de inscrição para as estações STI-C de envio e retransmissão (como entidades finais), garantindo assim confiança na sua operação. A AA emite CA para as estações de STI-C com base na confiança na EA.

A estação de STI-C de receção e retransmissão (como parte retransmissora) pode confiar noutras estações de STI-C, uma vez que os CA são emitidos por uma AA de confiança aprovada por uma CA de raiz, que é aprovada pelo TLM e pela CPA.

Observe-se que a Figure 1 descreve apenas o nível da CA de raiz do modelo de confiança do STI-C. Os detalhes das camadas inferiores são apresentados nas secções subsequentes da presente CP ou na CPS das CA de raiz específicas.

A Figure 2 fornece uma visão geral dos fluxos de informação entre os participantes da PKI. Os pontos verdes indicam fluxos que exigem comunicações máquina a máquina. Os fluxos de informação a vermelho definiram requisitos de segurança.

O modelo de confiança de STI-C baseia-se numa arquitetura de CA de raiz múltipla, em que os certificados da CA raiz são transmitidos periodicamente (conforme estabelecido abaixo) para o ponto central de contacto (CPOC) por meio de um protocolo seguro (por exemplo, certificados de ligação) definido pelo CPOC.

Uma CA de raiz pode ser operada por uma organização governamental ou privada. A arquitetura do modelo de confiança de STI-C contém pelo menos uma CA de raiz (a CA de raiz da UE com o mesmo nível que as outras CA de raiz). A CA de raiz da UE é delegada por todas as entidades que participam no modelo de confiança de STI-C que não pretendem configurar sua própria CA de raiz. O CPOC transmite os certificados da CA de raiz recebidos ao TLM, que é responsável por recolher e assinar a lista de certificados da CA de raiz e os enviar de volta ao CPOC, o que os torna publicamente disponíveis para todos (ver abaixo).

As relações de confiança entre as entidades no modelo de confiança de STI-C são descritas nas figuras, nos quadros e nas secções a seguir.

Figura 1: Arquitetura do modelo de confiança de STI-C

Figura 2: Fluxos de informação do modelo de confiança de STI-C



ID do fluxo

De

Para

Conteúdo

Referência

(1).

CPA

TLM

aprovação do pedido da CA de raiz

8

(2).

CPA

TLM

informações sobre revogação da CA de raiz

8.5

(3).

CPA

CA de raiz

atualizações da CP

1.5

(4).

CPA

CA de raiz

aprovação/rejeição do formulário de pedido da CA de raiz ou das alterações do pedido da CPS ou do processo de auditoria.

8.5, 8.6

(5).

TLM

CPA

notificação de alteração da ECTL

4, 5.8.1

(6).

TLM

CPOC

Certificado do TLM

4.4.2

(7).

TLM

CPOC

ECTL

4.4.2

(8).

CPOC

TLM

informações de certificado da CA de raiz

4.3.1.1

(9).

CPOC

TLM

revogação de certificado da CA de raiz

7.3

(10).

CPOC

todas as entidades finais

certificado do TLM

4.4.2

(11).

CA de raiz

CPOC

informações de certificado da CA de raiz

4.3.1.1

(12).

CA de raiz

CPOC

revogação de certificado da CA de raiz

7.3

(13).

CA de raiz

auditor

pedido de auditoria

8

(14).

CA de raiz

CPA

formulário de pedido da CA de raiz — pedido inicial

4.1.2.1

(15).

CA de raiz

CPA

formulário de pedido da CA de raiz — alterações da CPS

1.5.1

(16).

CA de raiz

CPA

formulário de pedido da CA de raiz — relatório de auditoria

8.6

(17).

CA de raiz

CPA

relatórios de incidentes da CA de raiz, nomeadamente a revogação de uma CA subordinada (EA, AA)

Anexo III, 7.3.1

(18).

CA de raiz

EA

resposta do certificado da EA

4.2.2.3

(19).

CA de raiz

AA

resposta de certificado da AA

4.2.2.3

(20).

CA de raiz

Todos

certificado da EA/AA, CRL

4.4.2

(21).

EA

CA de raiz

pedido de certificado da EA

4.2.2.3

(22).

EA

Estação de STI-C

resposta de credencial de inscrição

4.3.1.4

(23).

EA

AA

resposta de autorização

4.2.2.5

(24).

AA

CA de raiz

pedido de certificado da AA

4.2.2.3

(25).

AA

EA

pedido de autorização

4.2.2.5

(26).

AA

Estação de STI-C

resposta de bilhete de autorização

4.3.1.5

(27).

EA

CA de raiz

submissão de pedido

4.1.2.3

(28).

AA

CA de raiz

submissão de pedido

4.1.2.3

(29).

CA de raiz

EA

resposta

4.12 e 4.2.1

(30).

CA de raiz

AA

resposta

4.12 e 4.2.1

(31).

Estação de STI-C

EA

pedido de credencial de inscrição

4.2.2.4

(32).

Estação de STI-C

AA

pedido de certificado de autorização

4.2.2.5

(33).

fabricante/operador

EA

registo

4.2.1.4

(34).

fabricante/operador

EA

desativação

7.3

(35).

EA

fabricante/operador

resposta

4.2.1.4

(36).

auditor

CA de raiz

relatório

8.1

(37).

todos

CPA

pedido de alteração da CP

1.5

(38).

TLM

CPA

formulário de pedido

4.1.2.2

(39).

CPA

TLM

aprovação/rejeição

4.1.2.2

(40).

TLM

CPA

Relatório de auditoria

4.1.2.2

Quadro 1:    Descrição detalhada dos fluxos de informação no modelo de confiança de STI-C

1.3.2.Autoridade da política de certificação de STI-C

(1)A autoridade da política de certificação (CPA) de STI-C é composta pelos representantes dos intervenientes públicos e privados (por exemplo, Estados-Membros, fabricantes de veículos, etc.) que participam no modelo de confiança de STI-C. É responsável por duas subfunções:

(1)gestão da política de certificação, nomeadamente:

·aprovação da presente CP e futuros pedidos de alteração da CP;

·decisão sobre a análise de pedidos de alteração da CP e recomendações enviadas por outros participantes ou entidades da PKI;

·decisão sobre o lançamento de novas versões da CP;

(2)gestão das autorizações da PKI, nomeadamente:

·definir, decidir e publicar a aprovação da CPS e os procedimentos de auditoria da CA (coletivamente designados «procedimentos de aprovação da CA»);

·autorizar o CPOC a operar e apresentar relatórios periodicamente;

·autorizar o TLM a operar e apresentar relatórios periodicamente;

·aprovação da CPS da CA de raiz, se estiver de acordo com a CP comum e válida;

·escrutínio dos relatórios de auditoria do auditor acreditado da PKI para todas as CA de raiz;

·notificar o TLM sobre a lista das CA de raiz aprovadas ou não aprovadas e respetivos certificados com base nos relatórios de aprovação recebidos das CA de raiz e nos relatórios de operações regulares.

(2)O representante autorizado da CPA é responsável por autenticar o representante autorizado do TLM e aprovar o formulário de pedido do processo de inscrição do TLM. A CPA é responsável por autorizar que o TLM opere conforme estabelecido na presente secção.

1.3.3.Gestor da lista aprovada

(3)O TLM é uma entidade única designada pela CPA.

(4)O TLM é responsável:

·pela operação da ECTL de acordo com a CP comum válida e a apresentação regular de relatórios de atividades à CPA para a operação geral segura do modelo de confiança de STI-C;

·por receber certificados de CA do CPOC;

·por incluir/excluir certificados de CA de raiz na ECTL após notificação pela CPA;

·por assinar a ECTL;

·pela comunicação regular e atempada da ECTL ao CPOC.

1.3.4.Auditor acreditado da PKI

(5)O auditor da PKI acreditado é responsável por:

·executar ou organizar auditorias de CA de raiz, TLM e CA subordinada;

·distribuir o relatório de auditoria (de uma auditoria inicial ou periódica) à CPA, de acordo com os requisitos da secção 8 abaixo. O relatório de auditoria deve incluir recomendações do auditor da PKI acreditado;

·notificar a entidade que gere a CA de raiz do sucesso ou insucesso da realização de uma auditoria inicial ou periódica das CA subordinadas;

·avaliar a conformidade da CPS com a presente CP.

1.3.5.Ponto de contacto para STI-C (CPOC)

(6)O CPOC é uma entidade única designada pela CPA. O representante autorizado da CPA é responsável por autenticar o representante autorizado do CPOC e aprovar o formulário de registo do processo de inscrição do CPOC. A CPA é responsável por autorizar que o CPOC opere conforme estabelecido na presente secção.

(7)O CPOC é responsável por:

·estabelecer e contribuir para o intercâmbio seguro de comunicações entre todas as entidades do modelo de confiança de STI-C de forma eficiente e rápida;

·analisar pedidos e recomendações de alteração de procedimentos enviados por outros participantes do modelo de confiança (por exemplo, CA de raiz);

·transmitir certificados da CA de raiz ao TLM;

·publicar a âncora de confiança comum (chave pública atual e certificado de ligação do TLM);

·publicar a ECTL.

A secção 7 contém todos os detalhes relativos à ECTL.

1.3.6.Funções operacionais

(8)As seguintes entidades definidas na norma [2] desempenham uma função operacional, conforme definido no RFC 3647:

Elemento funcional

Função da PKI ([3] e [4])

Função detalhada ([2])

autoridade de certificação de raiz

CA/RA (autoridade de registo)

Comprova à EA e AA que pode emitir EC e CA

autoridade de inscrição

subscritor da CA de raiz/sujeito do certificado da EA

CA/RA

Autentica uma estação de STI-C e concede-lhe acesso a comunicações STI

autoridade de autorização

subscritor da CA de raiz/sujeito do certificado da AA

CA/RA

Comprova irrefutavelmente à estação de STI-C que pode utilizar serviços de STI específicos

estação de STI-C remetente

sujeito do certificado (EE) da entidade final (EE)

Adquire os direitos da EA para aceder a comunicações STI

Negoceia os direitos de AA de invocar serviços STI

Envia mensagens de difusão de salto único e retransmitidas

estação de STI-C de retransmissão (encaminhamento)

parte retransmissora / sujeito do certificado de EE

Recebe a mensagem de difusão da estação de STI-C remetente e encaminha-a para a estação de STI-C recetora, se necessário

estação de STI-C recetora

parte retransmissora

Recebe mensagens de difusão da estação de STI-C remetente ou retransmissora

fabricante

subscritor da EA

Instala informações necessárias para a gestão de segurança na estação de STI-C na produção

operador

subscritor da EA/AA

Instala e atualiza informações necessárias para a gestão de segurança na estação de STI-C durante a operação

Quadro 2: Funções operacionais

Nota: de acordo com a norma [4], a presente CP utiliza termos diferentes para o «subscritor» que contrata a CA para a emissão de certificados e o «sujeito» ao qual o certificado se aplica. São subscritores todas as entidades que possuem uma relação contratual com uma CA. Os sujeitos são as entidades às quais o certificado se aplica. As EA/AA agem na qualidade de subscritores e sujeitos da CA de raiz e podem solicitar certificados EA/AA. As estações de STI-C são sujeitos e podem solicitar certificados de entidade final.

(9)Autoridades de registo:

A EA deve desempenhar a função de uma autoridade de registo para entidades finais. Apenas os subscritores autenticados e autorizados podem registar novas entidades finais (estações de STI-C) numa EA. As CA de raiz pertinentes devem desempenhar a função de autoridades de registo para EA e AA.

1.4.Utilização de certificados

1.4.1.Domínios de utilização aplicáveis

(10)Os certificados emitidos ao abrigo da presente CP destinam-se a ser utilizados para validar assinaturas digitais no contexto de comunicações de STI cooperativos de acordo com a arquitetura de referência da norma [2].

(11)Os perfis de certificado da norma [5] determinam utilizações de certificados para o TLM, a CA de raiz, as EA, as AA e as entidades finais.

1.4.2.Limites de responsabilidade

(12)Os certificados não se destinam a ser utilizados, nem podem sê-lo, em:

·circunstâncias que infrinjam, violem ou se oponham a qualquer lei, regulamento (por exemplo, o GDPR), decreto ou decisão aplicável do governo;

·circunstâncias que violem ou infrinjam os direitos de terceiros;

·violem a presente CP ou o contrato de subscritor pertinente;

·quaisquer circunstâncias em que a respetiva utilização possa levar diretamente à morte, a lesões corporais ou danos ambientais graves (por exemplo, por falha na operação de instalações nucleares, na navegação ou comunicação de aeronaves ou em sistemas de controlo de armas);

·circunstâncias que contrariem os objetivos gerais de uma maior segurança rodoviária e de transportes rodoviários mais eficientes na Europa.

1.5.Administração da política de certificação

1.5.1.Atualização de CPS das CA incluídas na ECTL

(13)Cada CA de raiz incluída na ECTL deve publicar a sua própria CPS, que deve estar em conformidade com a presente política. Uma CA de raiz pode acrescentar requisitos adicionais, mas deve garantir o cumprimento permanente de todos os requisitos da presente CP.

(14)Cada CA de raiz incluída na ECTL deve implementar um processo de alteração apropriado para o seu documento CPS. As principais propriedades do processo de alteração devem ser documentadas na parte pública da CPS.

(15)O processo de alteração deve assegurar que todas as alterações à presente CP são cuidadosamente analisadas e, se necessário para o cumprimento da CP de acordo com as alterações, que a CPS é atualizada dentro do prazo estabelecido na etapa de implementação do processo de alteração para a CP. Em especial, o processo de alteração deve envolver procedimentos de alteração de emergência que garantam a implementação atempada de alterações à CP que sejam relevantes no que respeita à segurança.

(16)O processo de alteração deve incluir medidas apropriadas para verificar a conformidade da CP para todas as alterações à CPS. Qualquer alteração à CPS deve ser claramente documentada. Antes que uma nova versão de uma CPS seja implementada, a sua conformidade com a CP deve ser confirmada por um auditor de PKI acreditado.

(17)A CA de raiz deve notificar a CPA de qualquer alteração feita à CPS com pelo menos as seguintes informações:

·uma descrição exata da alteração;

·os motivos que justificam a alteração;

·um relatório do auditor acreditado da PKI confirmando o cumprimento da CP;

·o contacto da pessoa responsável pela CPS;

·o calendário previsto para a implementação.

1.5.2.Procedimentos de aprovação da CPS

(18)Antes de iniciar as suas operações, uma futura CA de raiz deve apresentar a sua CPS a um auditor de PKI acreditado no âmbito de um pedido de auditoria para verificar a conformidade (fluxo 13) e à CPA para que esta dê a sua aprovação (fluxo 15).

(19)Uma CA de raiz deve apresentar as alterações da sua CPS a um auditor de PKI acreditado no âmbito de um pedido de auditoria para verificar a conformidade (fluxo 13) e à CPA para que esta dê a sua aprovação (fluxo 15) antes de as alterações se tornarem efetivas.

(20)A EA/AA deve apresentar a sua CPS, ou alterações à sua CPS, à CA de raiz. A CA de raiz pode solicitar um certificado de conformidade do organismo nacional ou entidade privada responsável pela aprovação da EA/AA, conforme definido nas secções 4.1.2 e 8.

(21)O auditor de PKI acreditado deve avaliar a CPS de acordo com a secção 8.

(22)O auditor da PKI acreditado deve comunicar os resultados da avaliação da CPS no âmbito do relatório de auditoria, conforme estabelecido na secção 8.1. A CPS deve ser aceite ou rejeitada no âmbito da aceitação do relatório de auditoria referido nas secções 8.5 e 8.6.

2.Responsabilidades de publicação e criação de repositórios

2.1.Métodos para a publicação de informações de certificados

(23)As informações do certificado podem ser publicadas de acordo com a secção 2.5:

·de forma regular ou periódica; ou

·em resposta a um pedido de uma das entidades participantes.

Em cada caso, aplicam-se graus de urgência de publicação diferentes e, por conseguinte, calendários diferentes, mas as entidades devem estar preparadas para ambas as situações.

(24)A publicação regular das informações do certificado permite determinar um prazo máximo até ao qual as informações dos certificados são atualizadas para todos os nós da rede de STI-C. A frequência da publicação de todas as informações do certificado é definida na secção 2.2.

(25)A pedido de entidades participantes da rede de STI-C, qualquer participante pode começar a publicar as informações do certificado a qualquer momento e, dependendo do seu estado, solicitar um conjunto atual de informações do certificado para se tornar um nó de total confiança da rede de STI-C. O principal objetivo dessa publicação é atualizar as entidades quanto ao estado geral atual das informações de certificado na rede e permitir que estas comuniquem com confiança até à próxima publicação regular das informações.

(26)Uma CA de raiz individual também pode iniciar a publicação de informações de certificado a qualquer momento enviando um conjunto atualizado de certificados a todos os «membros inscritos» da rede de STI-C que são recetores regulares dessas informações. Essa situação apoia a operação das CA e permite que estes se dirijam aos membros entre as datas regulares e agendadas para publicar os certificados.

(27)A secção 2.5 define o mecanismo e todos os procedimentos para publicar certificados de CA de raiz e a ECTL.

(28)O CPOC deve publicar os certificados da CA de raiz (conforme incluídos na ECTL e destinados ao consumo público), o certificado do TLM e a ECTL que emite.

(29)As CA de raiz devem publicar os seus certificados EA/AA e CRL e ser capazes de suportar os três mecanismos aqui referidos para os publicar aos seus membros inscritos e partes utilizadoras, tomando todas as medidas necessárias para garantir a transmissão segura, conforme referido na secção 4.

2.2.Altura ou frequência de publicação

(30)Os requisitos aplicáveis ao agendamento da publicação de certificados e CRL devem ser determinados à luz dos vários fatores limitantes dos nós do STI-C individuais, com o objetivo geral de operar uma «rede de confiança» e publicar as atualizações o mais rapidamente possível para todas as estações de STI-C envolvidas.

·Para a publicação regular de informações atualizadas do certificado (por exemplo, alterações na composição da ECTL ou da CRL), é necessário um período máximo de três meses para a operação segura da rede de STI-C.

·As CA de raiz devem publicar os seus certificados de CA e CRL logo que possível após a emissão.

·Para a publicação da CRL, deve ser utilizado o repositório da CA de raiz.

Além disso, o CPS para cada CA deve especificar o período de tempo dentro do qual um certificado será publicado após a CA emitir o certificado.

Esta secção especifica apenas o tempo ou a frequência da publicação regular. Os meios de conectividade para atualizar as estações de STI-C com a ECTL e as CRL no espaço de uma semana após a sua publicação (sob condições normais de operação, por exemplo, com cobertura celular, veículo em operação real, etc.) devem ser implementados em conformidade com os requisitos do presente documento.

2.3.Repositórios

(31)Os requisitos relativos à estrutura do repositório para armazenar os certificados e às informações que são fornecidas pelas entidades da rede de STI-C são os seguintes para as entidades únicas:

·em geral, cada CA de raiz deve utilizar um repositório das suas próprias informações de certificado EA/AA e CRL atualmente ativas para publicar certificados para os outros participantes na PKI (por exemplo, um serviço de diretório baseado em LDAP). O repositório de cada CA de raiz deve suportar todos os controlos de acesso necessários (secção 2.4) e tempos de transmissão (secção 2.2) para cada modalidade de distribuição de informações relacionadas com STI-C;

·o repositório do TLM (que armazena a ECTL e os certificados do TLM publicados pelo CPOC, por exemplo) deve basear-se num mecanismo de publicação capaz de garantir os tempos de transmissão definidos na secção 2.2 para cada modalidade de distribuição.

Os requisitos das AA não estão definidos, mas devem suportar os mesmos níveis de segurança que as outras entidades e devem ser declarados na sua CPS.

2.4.Controlos de acesso a repositórios

(32)Os requisitos de controlo de acesso a repositórios de informações de certificado devem, no mínimo, estar em conformidade com os padrões gerais de tratamento seguro de informações descritos na norma ISO/IEC 27001 e com os requisitos da secção 4. Adicionalmente, devem refletir as necessidades de segurança do processo a serem estabelecidas para as etapas do processo único na publicação das informações do certificado.

·Tal inclui a implementação do repositório para certificados TLM e a ECTL no TLM/CPOC. Cada CA ou operador de repositório deve implementar controlos de acesso em relação a todas as entidades do STI-C e partes externas a pelo menos três níveis diferentes (por exemplo, público, restrito a entidades de STI-C, nível da CA de raiz), para evitar que entidades não autorizadas adicionem, alterem ou excluam entradas do repositório.

·Os mecanismos exatos de controlo de acesso da entidade única devem fazer parte da respetiva CPS.

·Para cada CA de raiz, os repositórios da EA e da AA devem cumprir os mesmos requisitos para os procedimentos de controlo de acesso, independentemente do local ou do vínculo contratual com o prestador de serviços que opera o repositório.

Como ponto de partida para os níveis de controlo de acesso, cada CA de raiz ou operador de repositório deve fornecer pelo menos três níveis diferentes (por exemplo, público, restrito a entidades de STI-C, nível da CA de raiz).

2.5.Publicação de informações de certificados

2.5.1.Publicação de informações de certificados pelo TLM

(33)O TLM no domínio de confiança comum europeu de STI-C deve publicar as seguintes informações através do CPOC:

·todos os certificados de TLM atualmente válidos para o próximo período de operação (certificado atual e de ligação, se disponíveis);

·informações de ponto de acesso para o repositório do CPOC para fornecer a lista assinada da CA de raiz (ECTL);

·ponto de informação geral para a implantação da ECTL e do STI-C.

2.5.2.Publicação de informações de certificados pelas CA

(34)As CA de raiz no domínio de confiança comum europeu de STI-C devem publicar as seguintes informações:

·certificados de CA de raiz emitidos (válidos à data) (certificados atuais e com correta reemissão de chave, incluindo um certificado de ligação) no repositório referido na secção 2.3;

·todas as entidades de EA, AA válidas, com a respetiva identificação de operador e período planeado de operação;

·certificados da CA emitidos nos repositórios referidos na secção 2.3;

·as CRL de todos os certificados de CA revogados que cobrem as respetivas EA e AA subordinadas;

·informações relativas ao ponto de acesso da CA de raiz às informações da CRL e da CA.

Todas as informações do certificado devem ser categorizadas de acordo com três níveis de confidencialidade e os documentos para o público em geral devem estar publicamente disponíveis sem restrições.

3.Identificação e autenticação

3.1.Nomenclatura

3.1.1.Tipos de nomes

3.1.1.1.Nomes para TLM, CA de raiz, EA e AA

(35)O nome no certificado TLM deve consistir num único atributo nome_sujeito com o valor reservado EU_TLM».

(36)O nome das CA de raiz deve consistir num único atributo nome_sujeito com um valor atribuído pela CPA. A exclusividade dos nomes é da inteira responsabilidade da CPA e o TLM deve manter o registo dos nomes da CA de raiz mediante notificação pela CPA (aprovação, revogação/retirada de uma CA de raiz). Os nomes de sujeitos nos certificados têm um limite de 32 bytes. Cada CA de raiz propõe o seu nome à CPA no formulário do pedido (fluxo  14). A CPA é responsável por verificar a exclusividade do nome. Se o nome não for exclusivo, o formulário de pedido será rejeitado (fluxo 4).

(37)O nome em cada certificado de EA/AA pode consistir num único atributo nome_sujeito com um valor gerado pelo emissor do certificado. A exclusividade dos nomes é da inteira responsabilidade da CA de raiz emissora.

(38)Os certificados de EA e AA não devem utilizar um nome que exceda 32 bytes, porque o nome_sujeito em certificados tem um limite de 32 bytes.

(39)Os CA não devem conter um nome.

3.1.1.2.Nomes para as entidades finais

(40)Cada estação de STI-C deve receber dois tipos de identificador único:

·uma identificação canónica que é armazenada no registo inicial da estação de STI-C sob a responsabilidade do fabricante. Deve conter uma subsequência que identifique o fabricante ou operador, para que este identificador possa ser único;

·um sujeito_nome, que pode fazer parte da EC da estação de STI-C, sob a responsabilidade da EA.

3.1.1.3.Identificação de certificados

(41)Os certificados que seguem o formato da norma [5] devem ser identificados através do cálculo de um valor de HashedId8 conforme definido na norma [5].

3.1.2.Necessidade de os nomes serem significativos

Não estipulado.

3.1.3.Anonimato e pseudonímia das entidades finais

(42)A AA deve assegurar que a pseudonímia de uma estação de STI-C é estabelecida fornecendo à estação de STI-C certificados de autorização que não contenham nomes ou informações que possam vincular o sujeito à sua identidade real.

3.1.4.Regras de interpretação das diversas formas de nomes

Não estipulado.

3.1.5.Exclusividade dos nomes

(43)Os nomes para o TLM, as CA de raiz, as EA, as AA e as identificações canónicas para estações de STI-C devem ser únicos.

(44)O TLM deve garantir, no processo de registo de uma determinada CA de raiz na ECTL, que o seu identificador de certificado (HashedId8) é único. A CA de raiz deve garantir, no processo de emissão, que o identificador de certificado (HashedId8) de cada CA subordinada é único.

(45)O HashedId8 de uma EC deve ser único dentro da CA emissora. O HashedId8 de um CA não necessita de ser único.

3.2.Validação inicial de identidade

3.2.1.Método para demonstrar posse de chave privada

(46)A CA de raiz deve comprovar que detém legitimamente a chave privada correspondente à chave pública no certificado autoassinado. O CPOC deve verificar esse elemento de prova.

(47)A EA/AA deve comprovar que detém legitimamente a chave privada correspondente à chave pública a ser inserida no certificado. A CA de raiz deve verificar esse elemento de prova.

(48)A posse de uma nova chave privada (para reemissão de chave) deve ser comprovada pela assinatura do pedido com a nova chave privada (assinatura interna) seguida da geração de uma assinatura externa sobre o pedido assinado com a chave privada válida à data (para garantir a autenticidade do pedido). O requerente deve apresentar o pedido de certificado assinado à CA emissora através de um meio de comunicação seguro. A CA emissora deve verificar se a assinatura digital do requerente na mensagem de pedido foi criada utilizando a chave privada correspondente à chave pública anexada ao pedido do certificado. A CA de raiz deve especificar quais os pedidos de certificado e respostas que suporta na sua CPS.

3.2.2.Autenticação de identidade de uma organização

3.2.2.1.Autenticação da identidade de uma organização de CA

(49)Num formulário do pedido para a CPA (ou seja, fluxo 14), a CA de raiz deve apresentar a identidade da organização e as informações de registo, compostas por:

·nome da organização;

·endereço postal;

·endereço de correio eletrónico;

·o nome da pessoa singular a contactar na organização;

·número de telefone;

·impressões digitais (ou seja, SHA 256 hashvalue) do certificado da CA de raiz em papel;

·informações criptográficas (por exemplo, algoritmos criptográficos, comprimentos de chave) no certificado da CA de raiz;

·todas as permissões que a CA de raiz está autorizada a utilizar e transmitir às CA subordinadas.

(50)A CPA deve verificar a identidade da organização e outras informações de registo fornecidas pelo requerente do certificado para a inserção de um certificado da CA de raiz na ECTL.

(51)A CPA deve reunir elementos de prova diretos, ou uma comprovação de uma fonte apropriada e autorizada, da identidade (por exemplo, o nome) e, se aplicável, quaisquer atributos específicos de sujeitos para os quais é emitido um certificado. Os elementos de prova enviados podem ser em papel ou em formato eletrónico.

(52)A identidade do sujeito deve ser verificada no momento do registo através dos meios adequados e de acordo com a presente política de certificado.

(53)Em cada pedido de certificado, devem ser fornecidos elementos de prova:

·do nome completo da entidade organizacional (organização privada, entidade governamental ou entidade não comercial);

·registo nacionalmente reconhecido ou outros atributos que possam ser utilizados, na medida do possível, para distinguir a entidade organizacional de outras com o mesmo nome.

As regras acima baseiam-se na norma TS 102 042 [4]: A CA deve assegurar que os elementos de prova da identificação do subscritor e do sujeito e a precisão de seus nomes e dados associados são adequadamente analisados no âmbito do serviço definido ou, quando aplicável, concluídos através da análise de atestados de fontes adequadas e autorizadas, e que os pedidos de certificado são precisos e autorizados e estão completos de acordo com os elementos de prova ou atestação reunidos.

3.2.2.2.Autenticação da identidade de uma organização do TLM

(54)A organização que opera o TLM deve apresentar elementos que comprovem a identificação e a precisão do nome e dos dados associados, a fim de permitir a verificação adequada na criação inicial e na reemissão de chave do certificado do TLM.

(55)A identidade do sujeito deve ser verificada no momento de criação do certificado ou de reemissão de chave através dos meios adequados e em conformidade com a presente CP.

(56)A organização deve apresentar elementos de prova conforme especificado na secção 3.2.2.1.

3.2.2.3.Autenticação da identidade de uma organização de CA subordinadas

(57)A CA de raiz deve verificar a identidade da organização e outras informações de registo fornecidas pelos requerentes de certificados para os certificados da CA subordinada (EAAA).

(58)A CA de raiz deve, no mínimo:

·determinar que a organização existe utilizando pelo menos um serviço ou base de dados de verificação de identidade de terceiros ou, em alternativa, documentação da organização emitida pela agência governamental pertinente, ou arquivada junto da mesma, ou autoridade reconhecida que confirme a existência da organização;

·utilizar o correio postal ou um procedimento semelhante solicitando que o requerente do certificado confirme determinadas informações sobre a organização, que autorizou o pedido de certificado e que a pessoa que apresentou o pedido em nome do requerente está autorizada a fazê-lo. Quando um certificado inclui o nome de um indivíduo como representante autorizado da organização, deve ainda confirmar que esse indivíduo está ao seu serviço e o autorizou a agir em seu nome.

(59)Os procedimentos de validação para a emissão de certificados da CA devem ser documentados numa CPS da CA de raiz.

3.2.2.4.Autenticação da organização do subscritor da entidade final

(60)Antes que o subscritor de entidades finais (fabricante/operador) se possa registar numa EA de confiança para permitir que suas entidades finais enviem pedidos de certificados de EC, a EA deve:

·verificar a identidade da organização do subscritor e outras informações de registo fornecidas pelo requerente do certificado;

·verificar se o tipo de estação de STI-C (ou seja, o produto específico que se baseia na marca, no modelo e na versão da estação de STI-C) cumpre todos os critérios de avaliação da conformidade.

(61)A EA deve, no mínimo:

·determinar que a organização existe utilizando pelo menos um serviço ou base de dados de verificação de identidade de terceiros ou, em alternativa, documentação da organização emitida pela agência governamental pertinente, ou arquivada junto da mesma, ou autoridade reconhecida que confirme a existência da organização;

·utilizar o correio postal ou um procedimento semelhante para solicitar que o requerente do certificado confirme determinadas informações sobre a organização, que autorizou o pedido de certificado e que a pessoa que apresentou o pedido em seu nome está autorizada a fazê-lo. Quando um certificado inclui o nome de um indivíduo como representante autorizado da organização, deve ainda confirmar que esse indivíduo está ao seu serviço e o autorizou a agir em seu nome.

(62)Os procedimentos de validação para o registo de uma estação de STI-C pelo seu subscritor devem ser documentados numa CPS da EA.

3.2.3.Autenticação de entidade individual

3.2.3.1.Autenticação de entidade individual de TLM/CA

(63)Para a autenticação de uma entidade individual (pessoa singular) identificada em associação com uma pessoa coletiva ou entidade organizacional (por exemplo, o subscritor), devem ser apresentados elementos que comprovem:

·o nome completo do sujeito (incluindo apelido e nomes próprios, de acordo com a legislação e as práticas nacionais de identificação aplicáveis);

·data e local de nascimento, referência a um documento de identificação nacionalmente reconhecido ou a outros atributos do subscritor que possam ser utilizados, na medida do possível, para distinguir a pessoa de outras pessoas com o mesmo nome;

·nome completo e estatuto jurídico da pessoa coletiva associada ou outra entidade organizacional (por exemplo, o subscritor);

·qualquer informação de registo relevante (por exemplo, registo de empresa) da pessoa coletiva associada ou outra entidade organizacional;

·elementos que comprovem que o sujeito está associado à pessoa coletiva ou a outra entidade organizacional.

Os elementos de prova enviados podem ser em papel ou em formato eletrónico.

(64)Para verificar a sua identidade, o representante autorizado de uma CA de raiz, EA, AA ou subscritor deve apresentar documentos que comprovem que trabalha para a organização (certificado de autorização). Deve também apresentar documentos de identificação oficiais.

(65)Para o processo de inscrição inicial (fluxo 31/32), um representante da EA/AA deve fornecer à CA de raiz correspondente todas as informações necessárias (ver secção 4.1.2).

(66)O pessoal da CA de raiz deve verificar a identidade do representante do requerente do certificado e todos os documentos associados, aplicando os requisitos do «pessoal de confiança», conforme estabelecido na secção 5.2.1. (O processo de validação das informações do pedido e geração do certificado pela CA de raiz deve ser executado por «pessoas de confiança» na CA de raiz, no mínimo sob dupla supervisão, uma vez que se trata de operações delicadas na aceção da secção 5.2.2).

3.2.3.2.Autenticação de identidade de subscritores de estações de STI-C

(67)Os subscritores são representados por utilizadores finais autorizados na organização que estão registados na EA e AA emissora. Esses utilizadores finais designados pelas organizações (fabricantes ou operadores) devem comprovar a sua identidade e autenticidade antes de:

·registar a EE na sua EA correspondente, incluindo a respetiva chave pública canónica, a identidade canónica (identificador único) e as permissões de acordo com a EE;

·registar-se na AA e garantir a existência de elementos que comprovem um contrato de subscritor que possa ser enviado à EA.

3.2.3.3.Autenticação de identidade de estações de STI-C

(68)Os sujeitos da EE das EC devem autenticar-se ao pedir EC (fluxo 31) utilizando a sua chave privada canónica para a autenticação inicial. A EA deve verificar a autenticação utilizando a chave pública canónica correspondente à EE. As chaves públicas canónicas das EE são transmitidas à EA antes que o pedido inicial seja executado, através de um canal seguro entre o fabricante ou operador da estação de STI-C e a EA (fluxo 33).

(69)Os sujeitos da EE dos CA devem autenticar-se ao pedir CA (fluxo 32) utilizando a sua chave privada única de inscrição. A AA deve encaminhar a assinatura para a EA (fluxo 25) para que esta seja validada; a EA deve validá-la e confirmar o resultado à AA (fluxo 23).

3.2.4.Informações de subscritor não verificadas

Não estipulado.

3.2.5.Validação de autoridade

3.2.5.1.Validação de TLM, CA de raiz, EA, AA

(70)Todas as organizações devem identificar na CPS pelo menos um representante (por exemplo, um agente de segurança) responsável por solicitar novos certificados e renovações. Aplicam-se as regras de nomenclatura descritas na secção 3.2.3.

3.2.5.2.Validação de subscritores de estações de STI-C

(71)Deve ser conhecida e aprovada pela EA (ver secção 3.2.3) pelo menos uma pessoa singular responsável por registar as estações de STI-C numa EA (por exemplo, um agente de segurança).

3.2.5.3.Validação de estações de STI-C

(72)O subscritor de uma estação de STI-C pode registar estações de STI-C numa EA específica (fluxo 33), desde que esteja autenticado nessa EA.

Quando a estação de STI-C está registada numa EA com uma identidade canónica única e uma chave pública canónica, pode solicitar uma EC utilizando um pedido assinado com a chave privada canónica associada à chave pública canónica anteriormente registada.

3.2.6.Critérios de interoperação

(73)Para comunicações entre estações de STI-C e as EA (ou AA), a estação de STI-C deve ser capaz de estabelecer comunicações seguras com as EA (ou AA), ou seja, implementar funções de autenticação, confidencialidade e integridade, conforme especificado na norma [1]. Podem ser utilizados outros protocolos, desde que seja implementada a norma [1]. As EA e AA devem suportar essas comunicações seguras.

(74)A EA e a AA devem suportar pedidos de certificados e respostas em conformidade com a norma [1], que prevê um protocolo seguro de pedido/resposta de CA que suporta o anonimato do requerente em relação à AA e a separação de tarefas entre a AA e a EA. Podem ser utilizados outros protocolos, desde que seja implementada a norma [1]. Para evitar a divulgação da identidade de longo prazo das estações de STI-C, a comunicação entre uma estação de STI-C móvel e uma EA deve ser confidencial (por exemplo, os dados de comunicação devem ser encriptados de ponta a ponta).

(75)A AA deve enviar um pedido de validação de autorização (fluxo 25) para cada pedido de autorização que receber de um sujeito do certificado da EE. A EA deve validar esse pedido no que respeita:

·ao estatuto da EE na EA;

·à validade da assinatura;

·aos AID-STI (ID dos pedidos de STI) e permissões solicitados;

·ao estatuto de prestação de serviços da AA ao subscritor.

3.3.Identificação e autenticação para pedidos de reemissão de chave

3.3.1.Identificação e autenticação para pedidos de reemissão de chave de rotina

3.3.1.1.Certificados de TLM

(76)O TLM gera um par de chaves e dois certificados: um autoassinado e um certificado de ligação nos termos da secção 7.

3.3.1.2.Certificados de CA de raiz

Não aplicável.

3.3.1.3.Renovação ou reemissão de chave de certificados de EA/AA

(77)Antes da expiração de um certificado de EA/AA, a EA/AA deve pedir um novo certificado (fluxo 21/fluxo 24) para manter a continuidade da utilização do certificado. A EA/AA deve gerar um novo par de chaves para substituir o par de chaves que expirou e assinar o pedido de reemissão de chave contendo a nova chave pública com a chave privada válida à data («reemissão de chave»). A EA ou AA gera um novo par de chaves e assina o pedido com a nova chave privada (assinatura interna) para comprovar a posse da nova chave privada. O pedido é integralmente assinado com a chave privada válida à data (assinatura externa) para garantir a integridade e a autenticidade do pedido. Se for utilizado um par de chaves de encriptação e desencriptação, deve ser comprovada a posse de chaves de desencriptação privadas (para uma descrição detalhada da reemissão de chave, ver secção 4.7.3.3).

(78)O método de identificação e autenticação para a reemissão de chave de rotina é o mesmo que para a emissão inicial de uma validação de certificado de EA de raiz inicial, conforme estabelecido na secção 3.2.2.

3.3.1.4.Credenciais de inscrição de entidades finais

(79)Antes da expiração de uma EC existente, a EE deve pedir um novo certificado (fluxo 31) para manter a continuidade da utilização do certificado. A EE deve gerar um novo par de chaves para substituir o par de chaves que está a expirar e solicitar um novo certificado contendo a nova chave pública; o pedido deve ser assinado com a chave privada da EC válida à data.

(80)A EE pode assinar o pedido com a chave privada recém-criada (assinatura interna) para comprovar a posse da nova chave privada. O pedido é depois integralmente assinado com a chave privada válida à data (assinatura externa) e encriptado para a EA recetora, conforme especificado na norma [1], para garantir a confidencialidade, a integridade e a autenticidade do pedido. Podem ser utilizados outros protocolos, desde que seja implementada a norma [1].

3.3.1.5.Certificados de autorização das entidades finais

(81)A nova chave do certificado para CA baseia-se no mesmo processo que a autorização inicial, conforme definido na norma [1]. Podem ser utilizados outros protocolos, desde que seja implementada a norma [1].

3.3.2.Identificação e autenticação para pedidos de reemissão de chave após revogação

3.3.2.1.Certificados de CA

(82)A autenticação de uma organização da CA para a reemissão de chave de certificados da CA de raiz, da EA e da AA após a revogação é tratada da mesma forma que a emissão inicial de um certificado da CA, conforme estabelecido na secção 3.2.2.

3.3.2.2.Credenciais de inscrição de entidades finais

(83)A autenticação de uma EE para a reemissão de chave de certificado de EC após a revogação é tratada da mesma forma que a emissão inicial de um certificado da EE, conforme estabelecido na secção 3.2.2.

3.3.2.3.Pedidos de autorização de entidades finais

Não aplicável, uma vez que os CA não são revogados.

3.4.Identificação e autenticação para pedidos de revogação

3.4.1.Certificados de CA de raiz/EA/AA

(84)Os pedidos para excluir um certificado da CA de raiz da ECTL devem ser autenticados pela CA de raiz para o TLM (fluxos 12 e 9). Os pedidos de revogação de um certificado da EA/AA devem ser autenticados pela CA de raiz pertinente e pela própria CA subordinada.

(85)Os procedimentos aceitáveis para autenticar os pedidos de revogação de um subscritor abrangem:

·uma mensagem escrita e assinada em papel de carta da empresa do subscritor solicitando a revogação, fazendo referência ao certificado a ser revogado;

·comunicações com o subscritor que forneçam garantias razoáveis de que a pessoa ou organização que solicita a revogação é, de facto, o subscritor. Dependendo das circunstâncias, essas comunicações podem incluir um ou mais dos seguintes elementos: correio eletrónico, correio postal ou serviço de correio expresso.

3.4.2.Credenciais de inscrição de estações de STI-C

(86)O subscritor da estação de STI-C pode revogar a EC de uma estação de STI-C previamente registada numa EA (fluxo 34). O subscritor requerente deve criar um pedido de revogação de uma determinada estação de STI-C ou lista de estações de STI-C. A EA deve autenticar o pedido de revogação antes de a processar e confirmar a revogação das estações de STI-C e respetiva EC.

(87)A EA pode revogar a EC de uma estação de STI-C em conformidade com a secção 7.3.

3.4.3.Certificados de autorização de estações de STI-C

(88)Os CA não são revogados, devendo a sua validade estar limitada a um período específico. O intervalo de períodos de validade aceitáveis na presente política de certificado encontra-se especificado na secção 7.

4.Requisitos operacionais do ciclo de vida dos certificados

4.1.Pedido de certificado

(89)A presente secção define os requisitos aplicáveis a pedidos iniciais de emissão de um certificado.

(90)O termo «pedido de certificado» refere-se aos seguintes processos:

·registo e configuração de uma relação de confiança entre o TLM e a CPA;

·registo e configuração de uma relação de confiança entre a CA de raiz e a CPA e o TLM, incluindo a inserção do primeiro certificado da CA de raiz na ECTL

·registo e configuração de uma relação de confiança entre a EA/AA e a CA de raiz, incluindo a emissão de um novo certificado da EA/AA;

·registo da estação de STI-C na EA pelo fabricante/operador;

·pedido da estação de STI-C de EC/CA.

4.1.1.Quem pode submeter um pedido de certificado

4.1.1.1.CA de raiz

(91)As CA de raiz geram os seus próprios pares de chaves e emitem o seu certificado de raiz por sua conta. Uma CA de raiz pode enviar um pedido de certificado através do seu representante designado (fluxo 14).

4.1.1.2.TLM

(92)O TLM gera o seu próprio par de chaves e emite o seu certificado por sua conta. A criação inicial do certificado do TLM deve ser processada por um representante da organização do TLM sob o controlo da CPA.

4.1.1.3.EA e AA

(93)Um representante autorizado da EA ou AA pode submeter o pedido de certificado da CA subordinada (AA e/ou AA) ao representante autorizado da CA de raiz pertinente (fluxo 27/28).

4.1.1.4.Estação de STI-C

(94)Os subscritores devem registar cada estação de STI-C na EA em conformidade com a secção 3.2.5.3.

(95)Cada estação de STI-C registada na EA pode enviar pedidos de EC (fluxo 31).

(96)Cada estação de STI-C pode enviar pedidos de CA (fluxo 32) sem solicitar qualquer interação do subscritor. Antes de pedir um CA, uma estação de STI-C deve possuir uma EC.

4.1.2.Processo de inscrição e responsabilidades

(97)As permissões para CA de raiz e CA subordinadas que emitem certificados para finalidades (governamentais) especiais (ou seja, estações de STI-C móveis e fixas especiais) só podem ser concedidas pelos Estados-Membros em que as organizações estão localizadas.

4.1.2.1.CA de raiz

(98)Depois de serem auditadas (fluxos 13 e 36, secção 8), as CA de raiz podem pedir a inserção do(s) seu(s) certificado(s) na ECTL junto da CPA (fluxo 14). O processo de inscrição baseia-se num formulário de pedido manual assinado que deve ser fisicamente entregue à CPA pelo representante autorizado da CA de raiz e que contenha pelo menos as informações referidas nas secções 3.2.2.1, 3.2.3 e 3.2.5.1.

(99)O formulário de pedido da CA de raiz deve ser assinado pelo seu representante autorizado.

(100)Além do formulário de pedido, o representante autorizado da CA de raiz deve fornecer uma cópia da CPS da CA de raiz (fluxo 15) e o seu relatório de auditoria à CPA para que estes sejam aprovados (fluxo 16). Nos casos de aprovação efetiva, a CPA gera e envia um certificado de conformidade ao CPOC/TLM e à CA de raiz correspondente.

(101)Em seguida, o representante autorizado da CA de raiz deve apresentar o seu formulário de pedido (contendo as impressões digitais do certificado autoassinado), a identificação oficial e um elemento que comprove a autorização ao CPOC/TLM. O certificado autoassinado deve ser entregue por via eletrónica ao CPOC/TLM. O CPOC/TLM deve verificar todos os documentos e o certificado autoassinado.

(102)Nos casos de verificações positivas, o TLM deve adicionar o certificado da CA de raiz à ECTL com base na notificação da CPA (fluxos 1 e 2). O processo encontra-se descrito em detalhe na CPS do TLM.

(103)Deve ser possível um procedimento adicional para obter uma aprovação da CPS e um relatório de auditoria de uma CA de raiz num organismo nacional de países específicos.

4.1.2.2.TLM

(104)Depois de ser auditado, o TLM pode inscrever-se na CPA. O processo de inscrição baseia-se num formulário de pedido manual assinado que deve ser fisicamente entregue à CPA (fluxo 38) pelo representante autorizado do TLM e conter pelo menos as informações referidas nas secções 3.2.2.2 e 3.2.3.

(105)O formulário de pedido do TLM deve ser assinado pelo seu representante autorizado.

(106)Em primeiro lugar, o TLM gera seu certificado autoassinado e transmite-o à CPA de forma segura. Em seguida, o TLM apresenta o seu formulário de pedido (contendo as impressões digitais do certificado autoassinado), uma cópia da sua CPS, uma identificação oficial, um elemento que comprove a autorização e o seu relatório de auditoria à CPA (fluxo 40). A CPA deve verificar todos os documentos e o certificado autoassinado. Nos casos de verificação positiva de todos os documentos, do certificado autoassinado e das impressões digitais, a CPA deve confirmar o processo de inscrição enviando a sua aprovação ao TLM e ao CPOC (fluxo 39). A CPA deve armazenar as informações do pedido enviadas pelo TLM. O certificado do TLM é em seguida emitido através do CPOC.

4.1.2.3.EA e AA

(107)Durante o processo de inscrição, a EA/AA deve apresentar os documentos pertinentes (por exemplo, a CPS e o relatório de auditoria) à CA de raiz correspondente para que estes sejam aprovados (fluxo 27/28). Nos casos de verificações positivas dos documentos, a CA de raiz envia uma aprovação às CA subordinadas correspondentes (fluxo 29/30). A CA subordinada (EA ou AA) deve em seguida transmitir o seu pedido assinado eletronicamente, e entregar fisicamente o seu formulário de pedido (em conformidade com a secção 3.2.2.1), elementos que comprovem a autorização e um documento de identificação à CA de raiz correspondente. A CA de raiz verifica o pedido e os documentos recebidos (formulário de pedido que contém as impressões digitais, que é o hashvalue SHA 256 do pedido da CA subordinada, os elementos que comprovam a autorização e o documento de identificação). Se todas as verificações conduzirem a um resultado positivo, a CA de raiz emite o certificado de CA subordinada correspondente. A forma de efetuar um pedido inicial encontra-se descrita em detalhe na sua CPS específica.

(108)Além do formulário de pedido da CA subordinada, o representante autorizado da CA subordinada deve anexar uma cópia da CPS à CA de raiz.

(109)Um auditor de PKI credenciado deve ser informado sobre as auditorias nos termos da secção 8.

(110)Se uma CA subordinada for propriedade de uma entidade diferente da entidade proprietária de uma CA de raiz, antes de emitir um pedido de certificado de CA subordinada, a entidade da CA subordinada deve assinar um contrato referente ao serviço da CA de raiz.

4.1.2.4.Estação de STI-C

(111)O registo inicial de sujeitos de entidades finais (estações de STI-C) deve ser realizado pelo subscritor responsável (fabricante/operador) da EA (fluxos 33 e 35) após a autenticação bem-sucedida da organização do subscritor e um dos seus representantes em conformidade com as secções 3.2.2.4 e 3.2.5.2.

(112)Uma estação de STI-C pode gerar um par de chaves de EC (ver secção 6.1) e criar um pedido de EC assinado em conformidade com a norma [1]. Podem ser utilizados outros protocolos, desde que seja implementada a norma [1].

(113)Durante o registo de uma estação de STI-C normal (por oposição a uma estação especial de STI-C móvel ou fixa), a EA deve verificar se as permissões no pedido inicial não se destinam a utilização governamental. As permissões para utilização governamental são definidas pelos Estados-Membros correspondentes. O procedimento detalhado para o registo e a resposta da EA ao fabricante/operador (fluxos 33 e 35) deve ser estabelecido na CPS correspondente da EA.

(114)Uma estação de STI-C deve ser registada numa EA (secção 3.2.5.3) enviando o seu pedido inicial de EC de acordo com a norma [1].

(115)Após o registo inicial por um representante do subscritor autenticado, a EA aprova os CA que o sujeito da entidade final (ou seja, a estação de STI-C) pode obter. Além disso, é atribuído a cada entidade final um nível de garantia de confiança, que está relacionado com a certificação da entidade final de acordo com um dos perfis de proteção indicados na secção 6.1.5.2.

(116)Os veículos normais devem possuir apenas uma estação de STI-C registada numa EA. Os veículos para fins especiais (como carros da polícia e outros veículos para fins especiais com direitos específicos) podem ser registados numa EA adicional ou possuir uma estação de STI-C adicional para autorizações que recaiam no âmbito da finalidade especial. Os veículos aos quais essa isenção se aplica serão definidos pelos Estados-Membros responsáveis. As permissões para estações de STI-C móveis e fixas especiais apenas serão concedidas pelos Estados-Membros responsáveis. As CPS das CA de raiz ou CA subordinadas que emitem certificados para esses veículos nesses Estados-Membros devem determinar de que forma o processo de certificação se aplica a esses veículos.

(117)Quando o subscritor está em processo de migração de uma estação de STI-C de uma EA para outra EA, a estação de STI-C pode ser registada em duas EA (semelhantes).

(118)Uma estação de STI-C gera um par de chaves do CA (ver secção 6.1) e cria um pedido de CA em conformidade com a norma [1]. Podem ser utilizados outros protocolos, desde que seja implementada a norma [1].

(119)As estações de STI-C enviam um pedido de autorização para o URL da AA (fluxos 32 e 26) enviando pelo menos as informações necessárias referidas na secção 3.2.3.3). A AA e a EA validam a autorização para cada pedido em conformidade com as secções 3.2.6 e 4.2.2.5.

4.2.Processamento de pedidos de certificado

4.2.1.Realização de funções de identificação e autenticação

4.2.1.1.Identificação e autenticação de CA de raiz

(120)O representante autorizado da CPA é responsável por autenticar o representante autorizado da CA de raiz e aprovar o respetivo processo de inscrição em conformidade com a secção 3.

4.2.1.2.Identificação e autenticação de TLM

(121)O representante autorizado da CPA é responsável por autenticar o representante autorizado do TLM e aprovar o respetivo formulário do pedido de processo de inscrição em conformidade com a secção 3.

4.2.1.3.Identificação e autenticação de EA e AA

(122)A CA de raiz correspondente é responsável por autenticar o representante autorizado da EA/AA e aprovar o respetivo formulário do pedido de processo de inscrição em conformidade com a secção 3.

(123)A CA de raiz deve confirmar a sua validação positiva do formulário de pedido à EA/AA. A EA/AA pode em seguida enviar um pedido de certificado à CA de raiz (fluxo 21/24), que deve emitir certificados à EA/AA correspondente (fluxo 18/19).

4.2.1.4.Identificação e autenticação de subscritores de EE

(124)Antes que uma estação de STI-C possa pedir um certificado de EC, o subscritor da EE deve transmitir de forma segura as informações do identificador da estação de STI-C à EA (fluxo 33). A EA deve verificar o pedido e, em caso de verificação positiva, registar as informações da estação de STI-C na sua base de dados e confirmá-lo ao subscritor da EE (fluxo 35). Esta operação é efetuada apenas uma vez pelo fabricante ou operador para cada estação de STI-C. Uma vez registada por uma EA, uma estação de STI-C pode pedir apenas um certificado de EC de que necessita (fluxo 31) de cada vez. A EA autentica e verifica se as informações contidas no pedido de certificado de EC são válidas para uma estação de STI-C.

4.2.1.5.Bilhetes de autorização

(125)Durante os pedidos de autorização (fluxo 32), em conformidade com a norma [1], a AA deve autenticar a EA da qual a estação de STI-C recebeu a sua EC. Podem ser utilizados outros protocolos, desde que seja implementada a norma [1]. Se a AA não puder autenticar a EA, o pedido será rejeitado (fluxo 26). Constitui uma condição necessária o facto de a AA possuir o certificado da EA para autenticar a EA e verificar a sua resposta (fluxos 25 e 23, secção 3.2.5.3).

(126)A EA autentica a estação de STI-C que solicita um CA verificando a sua EC (fluxos 25 e 23).

4.2.2.Aprovação ou rejeição de pedidos de certificado

4.2.2.1.Aprovação ou rejeição de certificados de CA de raiz

(127)O TLM insere/elimina os certificados da CA de raiz na ECTL de acordo com a aprovação da CPA (fluxo 1/2).

(128)O TLM deve verificar a assinatura, as informações e a codificação de certificados de CA de raiz depois de receber uma aprovação pela CPA (fluxo 1). Após a validação positiva e a aprovação da CPA, o TLM deve inserir o certificado de raiz correspondente na ECTL e notificar a CPA (fluxo 5).

4.2.2.2.Aprovação ou rejeição do certificado do TLM

(129)A CPA é responsável por aprovar ou rejeitar os certificados do TLM.

4.2.2.3.Aprovação e rejeição de certificados da EA e da AA

(130)A CA de raiz verifica os pedidos de certificado da CA subordinada (fluxo 21/24) e os relatórios pertinentes (emitidos pelo auditor acreditado da PKI) ao recebê-los (fluxo 36, secção 8) da CA subordinada correspondente da CA de raiz. Se a verificação do pedido conduzir a um resultado positivo, a CA de raiz correspondente emite um certificado para a EA/AA requerente (fluxo 18/19); caso contrário, o pedido é rejeitado e não é emitido qualquer certificado para a EA/AA.

4.2.2.4.Aprovação ou rejeição de EC

(131)A EA deve verificar e validar os pedidos de EC de acordo com as secções 3.2.3.2 e 3.2.5.3.

(132)Se o pedido de certificado em conformidade com a norma [1] estiver correto e válido, a EA deve gerar o certificado solicitado.

(133)Quando o pedido de certificado é inválido, a EA recusa-o e envia uma resposta que indique o motivo da recusa, em conformidade com a norma [1]. Se uma estação de STI-C ainda pretender uma EC, deverá proceder a um novo pedido de certificado. Podem ser utilizados outros protocolos, desde que seja implementada a norma [1].

4.2.2.5.Aprovação ou rejeição de CA

(134)O pedido de certificado é verificado pela EA. A AA deve estabelecer uma comunicação com a EA para validar o pedido (fluxo 25). A EA deve autenticar a estação de STI-C requerente e confirmar se tem direito a receber o CA solicitado de acordo com a CP (por exemplo, verificando o estado de revogação e validando a validade hora/região, as permissões, o nível de garantia, etc.). A EA deve enviar de volta uma resposta de validação (fluxo 23) e, se a resposta for positiva, a AA deve gerar o certificado solicitado e transmiti-lo à estação de STI-C. Se o pedido de CA não estiver correto ou a resposta de validação da EA for negativa, a AA recusará o pedido. Se uma estação de STI-C ainda exigir um CA, deverá proceder a um novo pedido de autorização.

4.2.3.Tempo de processamento do pedido de certificado 

4.2.3.1.Pedido de certificado da CA de raiz

(135)O período para processar o processo de identificação e autenticação de um pedido de certificado é nos dias úteis e deve estar sujeito a um prazo máximo estabelecido na CPS da CA de raiz.

4.2.3.2.Pedido de certificado do TLM

(136)O processamento do pedido de certificado do TLM deve estar sujeito a um prazo máximo estabelecido na CPS do TLM.

4.2.3.3.Pedido de certificado da EA e AA

(137)O período para processar o processo de identificação e autenticação de um pedido de certificado é nos dias úteis de acordo com o acordo e o contrato entre a CA de raiz do Estado-Membro/da organização privada e a CA subordinada. O período para processar os pedidos de certificado da CA subordinada deve estar sujeito a um prazo máximo estabelecido na CPS da CA subordinada.

4.2.3.4.Pedido de EC

(138)O processamento de pedidos de EC deve estar sujeito a um prazo máximo estabelecido na CPS da EA.

4.2.3.5.Pedido de CA

(139)O processamento de pedidos de CA deve estar sujeito a um prazo máximo estabelecido na CPS da AA.

4.3.Emissão do certificado

4.3.1.Ações da CA durante a emissão de certificados

4.3.1.1.Emissão de certificados de CA de raiz

(140)As CA de raiz emitem os seus próprios certificados de CA de raiz autoassinados, certificados de ligação, certificados de CA subordinadas e CRL.

(141)Após a aprovação da CPA (fluxo 4), a CA de raiz envia o seu certificado ao TLM através do CPOC a ser adicionado à ECTL (fluxos 11 e 8) (ver secção 4.1.2.1). O TLM verifica se a CPA aprovou o certificado (fluxo 1).

4.3.1.2.Emissão de certificados de TLM

(142)O TLM emite o seu próprio certificado de TLM autoassinado e de ligação e envia-o para o CPOC (fluxo 6).

4.3.1.3.Emissão de certificados de EA e AA

(143)As CA subordinadas geram um pedido de certificado assinado e transmitem-no à CA de raiz correspondente (fluxos 21 e 24). A CA de raiz verifica o pedido e emite um certificado à CA subordinada requerente de acordo com a norma [5] com a maior brevidade possível, conforme estabelecido na CPS para as práticas operacionais habituais, o mais tardar cinco dias úteis após a receção do pedido.

(144)A CA de raiz deve atualizar o repositório que contém os certificados das CA subordinadas.

4.3.1.4.Emissão de EC

(145)A estação de STI-C deve enviar um pedido de EC à EA em conformidade com a norma [1]. A EA deve autenticar e verificar se as informações contidas no pedido de certificado são válidas para uma estação de STI-C. Podem ser utilizados outros protocolos, desde que seja implementada a norma [1].

(146)Em caso de validação positiva, a EA deve emitir um certificado de acordo com o registo da estação de STI-C (ver ponto 4.2.1.4) e enviá-lo para a estação de STI-C utilizando uma mensagem de resposta de EC, em conformidade com a norma [1]. Podem ser utilizados outros protocolos, desde que seja implementada a norma [1].

(147)Na ausência de um registo, a EA deve gerar um código de erro e enviá-lo para a estação de STI-C utilizando uma mensagem de resposta EC, em conformidade com a norma [1]. Podem ser utilizados outros protocolos, desde que seja implementada a norma [1].

(148)Os pedidos e as respostas de EC devem ser encriptados para garantir a confidencialidade e assinados para garantir a autenticação e a integridade.

4.3.1.5.Emissão de  CA

(149)A estação de STI-C deve enviar uma mensagem de pedido de CA à AA em conformidade com a norma [1]. A AA deve enviar um pedido de validação do CA à EA em conformidade com a norma [1]. A EA deve enviar uma resposta de validação do CA à AA. Em caso de resposta positiva, a AA deve gerar um CA e enviá-lo para a estação de STI-C utilizando uma mensagem de resposta de CA, em conformidade com a norma [1]. Em caso de resposta negativa, a AA deve gerar um código de erro e enviá-lo para a estação de STI-C utilizando uma mensagem de resposta de CA, em conformidade com a norma [1]. Podem ser utilizados outros protocolos, desde que seja implementada a norma [1].

(150)Os pedidos e as respostas de CA devem ser encriptados (necessário apenas para as estações de STI-C móveis) para garantir a confidencialidade e assinadas para garantir autenticação e integridade.

4.3.2.Notificação da CA aos subscritores da emissão de certificados.

Não aplicável.

4.4.Aceitação de certificados

4.4.1.Realização da aceitação de certificados

4.4.1.1.CA de raiz

Não aplicável.

4.4.1.2.TLM

Não aplicável.

4.4.1.3.EA e AA

(151)A EA/AA deve verificar o tipo de certificado, a assinatura e as informações no certificado recebido. A EA/AA deve rejeitar todos os certificados de EA/AA que não estão verificados corretamente e emitir um novo pedido.

4.4.1.4.Estação de STI-C

(152)A estação de STI-C deve verificar a resposta de EC/CA recebida da EA/AA em relação ao seu pedido original, incluindo a assinatura e a cadeia de certificação. Deve rejeitar todas as respostas de EC/CA que não sejam corretamente verificadas. Nesses casos, deve enviar um novo pedido de EC/CA.

4.4.2.Publicação do certificado

(153)Os certificados de TLM e respetivos certificados de ligação devem ser disponibilizados a todos os participantes através do CPOC.

(154)Os certificados de CA de raiz são publicados pelo CPOC através da ECTL, que é assinada pelo TLM.

(155)Os certificados das subautoridades de certificação (EA e AA) são publicados pela CA de raiz.

(156)As EC e os CA não são publicados.

4.4.3.Notificação de emissão de certificado

Não há lugar a notificações de emissão.

4.5.Par de chaves e utilização do certificado

4.5.1.Chave privada e utilização do certificado

4.5.1.1.Chave privada e utilização de certificados para TLM

(157)O TLM deve utilizar as suas chaves privadas para assinar os próprios certificados (de TLM e de ligação) e a ECTL.

(158)O certificado do TLM deve ser utilizado pelos participantes da PKI para verificar a ECTL e autenticar o TLM.

4.5.1.2.Chave privada e utilização de certificados para CA de raiz

(159)As CA de raiz devem utilizar as suas chaves privadas para assinar os próprios certificados, CRL, certificados de ligação e os certificados de EA/AA.

(160)Os certificados da CA de raiz devem ser utilizados pelos participantes da PKI para verificar os certificados de AA e EA associados, os certificados de ligação e as CRL.

4.5.1.3.Chave privada e utilização de certificados para EA e AA

(161)As EA devem utilizar as suas chaves privadas para assinar EC e para desencriptar pedidos de inscrição.

(162)Os certificados de EA devem ser utilizados para verificar a assinatura das EC associadas e para a encriptação de pedidos de EC e CA por EE conforme definido na norma [1].

(163)As AA devem utilizar as suas chaves privadas para assinar CA e para desencriptar pedidos de CA.

(164)Os certificados de AA devem ser utilizados pelas EE para verificar os CA associados e para a encriptação de pedidos de CA, conforme definido na norma [1].

4.5.1.4.Chave privada e utilização de certificados para a entidade final

(165)As EE devem utilizar a chave privada correspondente a uma EC válida para assinar um novo pedido de inscrição conforme definido na norma [1]. A nova chave privada deve ser utilizada para construir a assinatura interna no pedido, para comprovar a posse da chave privada correspondente à nova chave pública de EC.

(166)As EE devem utilizar a chave privada correspondente a uma EC válida para assinar um pedido de autorização conforme definido na norma [1]. A chave privada correspondente ao novo CA deve ser utilizada para construir a assinatura interna no pedido para comprovar a posse da chave privada correspondente à nova chave pública do CA.

(167)A EE deve utilizar a chave privada correspondente a um CA adequado para assinar mensagens da estação de STI-C conforme definido na norma [5].

4.5.2.Chave pública e utilização de certificados da parte utilizadora

(168)As partes utilizadoras utilizam o caminho de certificação de confiança e as chaves públicas associadas para os fins referidos nos certificados e para autenticar a identidade comum de confiança de EC e CA.

(169)Não devem ser utilizados certificados de CA de raiz, de EA e de AA, EC e CA sem uma verificação preliminar por uma parte utilizadora.

4.6.Renovação de certificado

Não autorizada.

4.7.Reemissão de chave de certificado

4.7.1.Circunstâncias para a reemissão de chave de certificado

(170)Deve ser processado um certificado de reemissão de chave quando um certificado atinge o fim de vida útil ou uma chave privada atinge o fim da utilização operacional, mantendo, contudo, a relação de confiança com a CA. Deve sempre ser gerado e emitido um novo par de chaves, bem como o certificado correspondente.

4.7.2.Quem pode solicitar a reemissão de chave

4.7.2.1.CA de raiz

(171)A CA de raiz não solicita a reemissão de chave. O processo de reemissão de chave é um processo interno para a CA de raiz, uma vez que esta assina o próprio certificado. A CA de raiz deve proceder à reemissão de chave através de certificados de ligação ou de uma nova emissão (ver secção 4.3.1.1).

4.7.2.2.TLM

(172)O TLM não solicita a reemissão de chave. O processo de reemissão de chave é um processo interno para o TLM de raiz, uma vez este assina o próprio certificado.

4.7.2.3.EA e AA

(173)O pedido de certificado da CA subordinada deve ser enviado em tempo útil para garantir a criação de um novo certificado da CA subordinada e um par de chaves operacional da CA subordinada antes de expirar a atual chave da CA subordinada privada. A data de apresentação deve ainda levar em conta o tempo necessário para a aprovação.

4.7.2.4.Estação de STI-C

Não aplicável.

4.7.3.Processo de reemissão de chave

4.7.3.1.Certificado do TLM

(174)O TLM decide proceder à reemissão de chave com base nos requisitos das secções 6.1 e 7.2. O processo encontra-se definido em detalhe na respetiva CPS.

(175)O TLM deve executar o processo de reemissão de chave em tempo útil, a fim de permitir a distribuição do novo certificado de TLM e certificado de ligação a todos os participantes antes de o atual certificado de TLM expirar.

(176)O TLM deve utilizar certificados de ligação para a reemissão de chaves e para garantir a relação de confiança do novo certificado autoassinado. O certificado de TLM e de ligação recém-gerado é transferido para o CPOC.

4.7.3.2.Certificado da CA de raiz

(177)A CA de raiz decide proceder à reemissão de chaves com base nos requisitos das secções 6.1.5 e 7.2. O processo deve ser definido em detalhe na respetiva CPS.

(178)A CA de raiz deve executar o processo de reemissão de chave em tempo útil (antes da expiração do certificado da CA de raiz) para permitir a inserção do novo certificado na ECTL antes de o certificado da CA de raiz se tornar válido (ver secção 5.6.2). O processo de reemissão de chave deve ser realizado seja através de certificados de ligação seja como um pedido inicial.

4.7.3.3.Certificados de EA e AA

(179)A EA ou AA deve solicitar um novo certificado do seguinte modo:

Etapa

Indicação

Pedido de reemissão de chave

1

Geração de par de chaves

As CA subordinadas (EA e AA) devem gerar novos pares de chaves de acordo com a secção 6.1.

2

Pedido de geração de certificado e assinatura interna

A CA subordinada gera um pedido de certificado a partir da chave pública recém-gerada considerando o esquema de nomenclatura (subject_info) da secção 3, o algoritmo de assinatura, os Service Specific Permissions (SSP) e o parâmetro adicional facultativo e gera a assinatura interna com a nova chave privada correspondente. Se for necessária uma chave de encriptação, a CA subordinada também deve comprovar a posse da chave privada de desencriptação correspondente.

3

Gerar uma assinatura externa

Todo o pedido deve ser assinado com a chave privada válida à data, para garantir a autenticidade do pedido assinado.

4

Enviar pedido à CA de raiz

O pedido assinado deve ser enviado à CA de raiz correspondente.

5

Verificação do pedido

A CA de raiz correspondente deve verificar a integridade e a autenticidade do pedido. Deve, em primeiro lugar, verificar a assinatura externa. Se a verificação for positiva, deve verificar a assinatura interna. Na presença de elementos que comprovem a posse da chave de desencriptação privada, esse elemento também deverá ser verificado.

6

Aceitar ou rejeitar pedido

Se todas as verificações conduzirem a um resultado positivo, a CA de raiz aceita o pedido; caso contrário, rejeita-o.

7

Gerar e emitir certificado

A CA de raiz gera um novo certificado e o transmite-o à CA subordinada requerente.

8

Enviar reposta

A CA subordinada deve enviar uma mensagem de estado (indicando se o certificado foi ou não recebido) à CA de raiz.

Quadro 3: Processo de reemissão de chave para EA e AA

(180)Durante a reemissão de chave automática para CA subordinadas, a CA raiz deve garantir que o requerente está realmente na posse da sua chave privada. Devem ser aplicados protocolos adequados para a comprovação da posse de chaves de desencriptação privadas, por exemplo, conforme definido nos RFC 4210 e 4211. Para chaves de assinatura privada, deve ser utilizada a assinatura interna.

4.7.3.4.Certificados da estação de STI-C

Não aplicável a CA.

4.8.Alteração de certificado

Não autorizada.

4.9.Revogação e suspensão de certificado

Ver secção 7

4.10.Serviços de estado de certificado

4.10.1.Características operacionais

Não aplicável

4.10.2.Disponibilidade do serviço

Não aplicável

4.10.3.Características facultativas

Não aplicável

4.11.Fim da subscrição

Não aplicável

4.12.Retenção e recuperação de chaves

4.12.1.Subscritor

4.12.1.1.Que par de chaves pode ser retido

Não aplicável.

4.12.1.2.Quem pode submeter um pedido de recuperação

Não aplicável.

4.12.1.3.Processo de recuperação e responsabilidades

Não aplicável.

4.12.1.4.Identificação e autenticação

Não aplicável.

4.12.1.5.Aprovação ou rejeição de pedidos de recuperação

Não aplicável.

4.12.1.6.Ações da autoridade de retenção de chaves e da autoridade de recuperação de chaves durante a recuperação do par de chaves

Não aplicável.

4.12.1.7.Disponibilidade da autoridade de retenção de chaves e da autoridade de recuperação de chaves

Não aplicável.

4.12.2.Política e práticas de encapsulação e recuperação de chaves de sessão

Não aplicável.

5.Instalações, gestão e controlos operacionais

(181)A PKI é composta pela CA de raiz, a EA/AA, o CPOC e o TLM, incluindo os respetivos componentes de TIC (por exemplo, redes e servidores).

(182)Na presente secção, a entidade responsável por um elemento da PKI é identificada pelo próprio elemento. Por outras palavras, o enunciado «a CA é responsável por executar a auditoria» é equivalente a «a entidade ou o pessoal que gere a CA é responsável por executar ...».

(183)A expressão «elementos do modelo de confiança de STI-C» inclui a CA de raiz, o TLM, a EA/AA, o CPOC e a rede segura.

5.1.Controlos físicos

(184)Todas as operações do modelo de confiança de STI-C devem ser conduzidas num ambiente fisicamente protegido que impeça, previna e detete a utilização, o acesso ou a divulgação não autorizados de informações e sistemas sensíveis. Os elementos do modelo de confiança de STI-C devem utilizar controlos de segurança física em conformidade com as normas ISO 27001 e ISO 27005.

(185)As entidades que gerem os elementos do modelo de confiança de STI-C devem descrever os controlos de segurança física, processual e de pessoal na sua CPS. Em especial, a CPS deve cobrir informações sobre a localização física e a construção dos edifícios e os seus controlos físicos de segurança, garantindo o acesso controlado a todas as divisões utilizadas nas instalações das entidades do modelo de confiança de STI-C.

5.1.1.Localização física e construção

5.1.1.1.CA de raiz, CPOC e TLM

(186)A localização e a construção das instalações que alojam os equipamentos e dados da CA de raiz, do CPOC e do TLM (HSM, dados de ativação, salvaguarda do par de chaves, computador, registo, script de cerimónia de chave, pedido de certificado, etc.) devem ser coerentes com as instalações utilizadas para armazenar informações sensíveis e de elevado valor. A CA de raiz deve ser operada numa área física dedicada, separada das áreas físicas de outros componentes da PKI.



(187)A CA de raiz, o CPOC e o TLM devem implementar políticas e procedimentos para garantir que é mantido um alto nível de segurança no ambiente físico em que o equipamento da CA de raiz está instalado, de modo a garantir que:

·está isolado de redes fora do modelo de confiança;

·está separado numa série de (pelo menos dois) perímetros físicos progressivamente mais seguros;

·os dados sensíveis (HSM, salvaguarda de pares de chaves, dados de ativação, etc.) são armazenados num cofre dedicado localizado numa área física dedicada sob controlo de acesso múltiplo.

(188)As técnicas de segurança utilizadas devem ser concebidas para resistir a um grande número e uma vasta combinação de diversas formas de ataque. Os mecanismos utilizados devem incluir pelo menos:

·alarmes de perímetro, televisão de circuito fechado, paredes reforçadas e detetores de movimento;

·autenticação de dois fatores (por exemplo, cartão inteligente e PIN) para qualquer pessoa e cartão de acesso que entre e saia das instalações da CA de raiz e da área física protegida e segura.

(189)A CA de raiz, o CPOC e o TLM utilizam pessoal autorizado para monitorizar continuamente o equipamento de alojamento das instalações, 24 horas por dia, todos os dias do ano. O ambiente operacional (por exemplo, as instalações físicas) nunca deve ser deixado sem vigilância. O pessoal do ambiente operacional nunca deve ter acesso às áreas seguras das CA de raiz ou das subautoridades de supervisão, a menos que seja autorizado.

5.1.1.2.EA/AA

(190)Aplicam-se as mesmas disposições que na secção 5.1.1.1.

5.1.2.Acesso físico

5.1.2.1.CA de raiz, CPOC e TLM

(191)Os equipamentos e dados (HSM, dados de ativação, salvaguarda do par de chaves, computador, registo, script de cerimónia de chave, pedido de certificado, etc.) devem estar sempre protegidos contra o acesso não autorizado. Os mecanismos de segurança física do equipamento devem, pelo menos:

·monitorizar em permanência, manual ou eletronicamente, intrusões não autorizadas;

·garantir que não é permitido qualquer acesso não autorizado ao equipamento informático e aos dados de ativação;

·assegurar que todos os suportes removíveis e documentos em papel que contêm informações confidenciais de texto simples são armazenados num recipiente seguro;

·garantir de forma permanente que qualquer pessoa que entre em áreas seguras e não autorizadas não fique sem a supervisão de um funcionário autorizado das instalações de CA raiz, CPOC e TLM;

·assegurar a manutenção permanente de um registo de acesso e a sua inspeção periódica;

·garantir pelo menos dois níveis de segurança progressivamente crescente, por exemplo, a nível do perímetro, do edifício e da sala de operações;

·exigir dois controlos de acesso físico fidedignos para os dados criptográficos do HSM e de ativação.

(192)Deve ser efetuada uma verificação de segurança do equipamento de armazenamento das instalações no caso de este ser deixado sem supervisão. No mínimo, a verificação deve confirmar que:

·o equipamento está num estado adequado ao modo de operação atual;

·no caso dos componentes fora de linha, todos os equipamentos estão desligados;

·os recipientes de segurança (sobrescritos invioláveis, cofres, etc.) estão devidamente protegidos;

·os sistemas de segurança física (por exemplo, fechaduras de porta, tampas de ventilação, eletricidade) funcionam corretamente;

·a área está protegida contra o acesso não autorizado.

(193)Os módulos criptográficos removíveis devem ser desativados antes do armazenamento. Quando não estiverem a ser utilizados, esses módulos e os dados de ativação utilizados para lhes aceder ou para os ativar devem ser colocados num cofre. Os dados de ativação devem ser memorizados ou gravados e armazenados de forma compatível com a segurança garantida ao módulo criptográfico. Não devem ser armazenados com o módulo criptográfico, de modo a evitar que apenas uma pessoa tenha acesso à chave privada.

(194)Uma pessoa ou um grupo de funções de confiança deve ser expressamente responsável por efetuar essas verificações. Quando a responsabilidade cabe a um grupo de pessoas, deve ser mantido um registo que identifique a pessoa que realiza cada verificação. Se a instalação não for continuamente vigiada, a última pessoa a sair deverá rubricar uma folha de controlo de saída que indique a data e a hora e confirmar que todos os mecanismos de proteção física necessários estão implementados e ativados.

5.1.2.2.EA/AA

(195)Aplicam-se as mesmas disposições que na secção 5.1.2.1.

5.1.3.Energia e ar condicionado

(196)As instalações protegidas dos elementos do modelo de confiança de STI-C (CA de raiz, CPOC, TLM, EA e AA) devem estar equipadas com acesso fiável à energia elétrica para garantir uma operação sem falhas ou com falhas mínimas. É necessário prever instalações primárias e de salvaguarda em caso de falha de energia externa e o desligamento sem ruturas do equipamento do modelo de confiança de STI-C em caso de falta de energia. As instalações do modelo de confiança de STI-C devem estar equipadas com sistemas de aquecimento/ventilação/ar condicionado, de forma a manter a temperatura e a humidade relativa do equipamento do modelo de confiança de STI-C dentro da gama de funcionamento. A CPS do elemento do modelo de confiança de STI-C descreverá em detalhe o plano e os processos para implementar tais requisitos.

5.1.4.Exposição à água

(197)As instalações protegidas dos elementos do modelo de confiança de STI-C (CA de raiz, CPOC, TLM, EA e AA) devem ser protegidas de forma a minimizar o impacto da exposição à água. Por esta razão, devem ser evitadas as condutas de água e condutas subterrâneas. A CPS do elemento do modelo de confiança de STI-C descreverá em detalhe o plano e os processos para implementar tais requisitos.

5.1.5.Prevenção e proteção contra incêndios

(198)Para evitar a exposição prejudicial a chamas ou fumo, as instalações de segurança dos elementos do modelo de confiança de STI-C (CA de raiz, CPOC, TLM, EA e AA) devem ser construídas e equipadas em conformidade e devem ser implementados procedimentos para fazer face a ameaças relacionadas com incêndios. Os suportes de armazenamento devem ser protegidos contra o fogo em recipientes adequados.

(199)Os elementos do modelo de confiança de STI-C devem proteger os suportes físicos que armazenam cópias de segurança de dados críticos do sistema ou de quaisquer outras informações sensíveis contra riscos ambientais e a utilização, o acesso ou a divulgação não autorizados desses suportes. A CPS do elemento do modelo de confiança de STI-C descreverá em detalhe o plano e os processos para implementar tais requisitos.

5.1.6.Gestão de suportes

(200)Os suportes utilizados nos elementos do modelo de confiança de STI-C (CA de raiz, CPOC, TLM, EA e AA) devem ser manipulados de forma segura, de forma que estejam protegidos contra danos, roubo e acesso não autorizado. Os procedimentos de gestão dos suportes são implementados de forma a proteger contra a obsolescência e a deterioração dos suportes no período em que os registos devem ser mantidos.

(201)Os dados sensíveis devem ser protegidos contra o acesso decorrente de objetos de armazenamento reutilizados (por exemplo, ficheiro eliminados), que podem tornar os dados sensíveis acessíveis a utilizadores não autorizados.

(202)Deve ser mantido um inventário de todos os elementos de informação e devem ser definidos requisitos para a proteção desses elementos em linha com a análise de riscos. A CPS do elemento do modelo de confiança de STI-C descreverá em detalhe o plano e os processos para implementar tais requisitos.

5.1.7.Eliminação de resíduos

(203)Os elementos do modelo de confiança de STI-C (CA de raiz, CPOC, TLM, EA e AA) devem implementar procedimentos para a eliminação segura e irreversível de resíduos (papel, suportes ou qualquer outro resíduo) para impedir a utilização, o acesso ou a divulgação não autorizados de resíduos que contenham informações confidenciais/privadas. Todos os suportes utilizados para o armazenamento de informações sensíveis, tais como chaves, dados de ativação ou ficheiros, devem ser destruídos antes de serem enviados para eliminação. A CPS do elemento do modelo de confiança de STI-C descreverá em detalhe o plano e os processos para implementar tais requisitos.

5.1.8.Salvaguarda fora do local

5.1.8.1.CA de raiz, CPOC e TLM

(204)As salvaguardas completas de componentes da CA de raiz, do CPOC e do TLM, suficientes para a recuperação de falhas do sistema, devem ser efetuadas fora de linha após a implantação da CA de raiz, do CPOC e do TLM e após cada nova geração de um par de chaves. Devem ser feitas cópias de segurança regulares de informações comerciais (par de chaves e CRL) e aplicações informáticas essenciais. Devem ser previstas instalações de salvaguarda adequadas para garantir que todas as informações comerciais e aplicações informáticas essenciais podem ser recuperados após uma catástrofe ou uma falha dos suportes. As medidas de salvaguarda no que respeita a sistemas individuais devem ser testadas regularmente para garantir que cumprem os requisitos do plano de continuidade das atividades. Deve ser armazenada pelo menos uma cópia de segurança completa fora do local (recuperação em caso de catástrofe). A cópia de segurança deve ser armazenada num local com controlos físicos e processuais compatíveis com o sistema da PKI operacional.

(205)Os dados salvaguardados devem estar sujeitos aos mesmos requisitos de acesso que os dados operacionais. Os dados salvaguardados devem ser encriptados e armazenados fora do local. Em caso de perda total de dados, as informações necessárias para colocar a CA raiz, o CPOC e o TLM de novo em funcionamento devem ser totalmente recuperadas a partir dos dados salvaguardados.

(206)O material privado de cifragem da CA de raiz, do CPOC e do TLM não deve ser salvaguardado utilizando mecanismos de salvaguarda padrão, mas utilizando a função de salvaguarda do módulo criptográfico.

5.1.8.2.EA/AA

(207)Aplicam-se a esta secção os processos descritos na secção 5.1.8.1.

5.2.Procedimentos de controlo

A presente secção descreve os requisitos aplicáveis no que respeita a funções, deveres e identificação do pessoal.

5.2.1.Funções de confiança

(208)Os funcionários, contratantes e consultores designados para funções de confiança devem ser considerados «pessoas de confiança». As pessoas que pretendam vir a ser pessoas de confiança assumindo um cargo de confiança devem cumprir os requisitos de rastreio da presente política de certificado.

(209)Pessoas de confiança têm acesso a, ou controlam, operações de autenticação ou criptográficas que podem afetar materialmente:

·as informações de validação dos pedidos de certificado;

·a aceitação, rejeição ou outros processamentos de pedidos de certificado, pedidos de revogação ou pedidos de renovação;

·a emissão ou revogação de certificados, incluindo pessoal com acesso a partes restritas do seu repositório ou o tratamento de informações ou pedidos de subscritores.

(210)A título de exemplo, referem-se as seguintes funções de confiança:

·serviço ao cliente;

·administração do sistema;

·engenharia designada;

·executivos encarregados da gestão da confiabilidade da infraestrutura.

(211)A CA deve apresentar descrições claras de todas as funções de confiança na sua CPS.

5.2.2.Número de pessoas necessário por tarefa

(212)Os elementos do modelo de confiança de STI-C devem estabelecer, manter e aplicar procedimentos de controlo rigorosos para garantir a separação de tarefas com base em funções de confiança e garantir que são necessárias várias pessoas de confiança para realizar tarefas sensíveis. Os elementos do modelo de confiança de STI-C (TLM, CPOC, CA de raiz, EA e AA) devem cumprir a norma [4] e cumprir os requisitos dos parágrafos a seguir.

(213)Devem estar implementadas políticas e procedimentos de controlo para garantir a separação de tarefas com base nas responsabilidades do cargo de trabalho. As tarefas mais sensíveis, como o acesso e a gestão do equipamento informático de criptografia (HSM) da CA e o material de cifragem associado, devem exigir a autorização de várias pessoas de confiança.

(214)Esses procedimentos de controlo interno devem ser projetados para garantir que pelo menos duas pessoas de confiança têm acesso físico ou lógico ao dispositivo. Devem ser aplicadas restrições rigorosas ao acesso ao equipamento informático de criptografia da CA por várias pessoas de confiança em todo o seu ciclo de vida, desde a receção e inspeção de entrada até à destruição final lógica e/ou física. Quando um módulo é ativado com chaves operacionais, é necessário invocar outros controlos de acesso para manter um controlo dividido do acesso físico e lógico ao dispositivo.

5.2.3.Identificação e autenticação para cada função

(215)Todas as pessoas designadas para uma função, conforme descrito na presente CP, são identificadas e autenticadas de forma a garantir que a função lhes permita desempenhar as suas obrigações de PKI.

(216)Os elementos do modelo de confiança de STI-C devem verificar e confirmar a identidade e a autorização de todos os membros do pessoal que pretendam tornar-se uma pessoa de confiança, antes de:

·lhes serem emitidos os seus dispositivos de acesso e lhes ser concedido o acesso às instalações necessárias;

·lhes serem fornecidas credenciais eletrónicas para aceder a, e executar, funções específicas nos sistemas da CA.

(217)A CPS descreve os mecanismos utilizados para identificar e autenticar indivíduos.

5.2.4.Funções que requerem a separação de tarefas

(218)A título de exemplo, referem-se as funções que requerem uma separação das tarefas:

·a aceitação, rejeição e revogação de pedidos e outros processamentos de pedidos de certificado de CA;

·a geração, emissão e destruição de um certificado de CA.

(219)A separação de funções pode ser aplicada utilizando equipamentos ou procedimentos da PKI, ou ambos. Não deve ser atribuída mais de uma identidade a nenhum indivíduo, a menos que seja aprovado pela CA de raiz.

(220)A parte da CA de raiz e da CA relacionada com a geração e a gestão da revogação de certificados deve ser independente de outras organizações para as decisões que tomar relacionadas com o estabelecimento, o fornecimento, a manutenção e a suspensão de serviços, de acordo com as políticas de certificação aplicáveis. Em especial, os respetivos quadros superiores e funcionários que assumem funções de confiança devem estar isentos de quaisquer pressões, nomeadamente comerciais e financeiras, que possam influenciar adversamente a confiança nos serviços prestados.

(221)A EA e a AA que servem estações móveis de STI-C devem ser entidades operacionais separadas, com equipas separadas de infraestrutura de TI e de gestão de TI. Nos termos do GDPR, a EA e a AA não devem trocar quaisquer dados pessoais, exceto no caso das autorizações de pedidos de CA. Devem transferir os dados relativos à aprovação de pedidos de CA utilizando apenas o protocolo de validação de autorização da norma [1] através de uma interface dedicada protegida. Podem ser utilizados outros protocolos, desde que seja implementada a norma [1].

(222)Os ficheiros de registo armazenados pela EA e pela AA podem ser utilizados com o único propósito de revogar EC com comportamento impróprio com base em CA em mensagens CAM/DENM intercetadas. Depois de uma mensagem CAM/DENM ser identificada como maliciosa, a AA procurará a chave de verificação do CA nos registos de emissão e enviará um pedido de revogação à EA contendo a assinatura encriptada sob a chave privada da EC utilizada durante a emissão do CA. Todos os ficheiros de registo devem ser adequadamente protegidos contra o acesso de partes não autorizadas e não podem ser partilhados com outras entidades ou autoridades.

Nota: no momento da elaboração da presente versão da CP, a conceção da função de comportamento impróprio não se encontra definida. Está prevista uma potencial conceção da função de comportamento impróprio em futuras revisões da política.

5.3.Controlos de pessoal

5.3.1.Requisitos relativos a qualificações, experiência e credenciação

(223)Os elementos do modelo de confiança de STI-C empregam um número suficiente de funcionários com os conhecimentos especializados, a experiência e as qualificações necessárias para as funções e os serviços oferecidos. O pessoal da PKI deve cumprir esses requisitos através de formação formal e credenciais, experiência real ou uma combinação de ambos. As funções e responsabilidades de confiança, conforme especificado na CPS, devem ser documentadas em descrições de cargos e claramente identificadas. Os subcontratantes do pessoal da PKI têm descrições de cargos definidos para garantir a separação de deveres e tarefas, e o caráter sensível da posição é determinado com base nos níveis de tarefas e de acesso, a verificação de antecedentes e a formação e sensibilização dos funcionários.

5.3.2.Procedimentos de verificação de antecedentes

(224)Os elementos do modelo de confiança de STI-C devem submeter o pessoal que pretenda tornar-se pessoa de confiança a verificações de antecedentes. No caso do pessoal que ocupa cargos de confiança, as verificações de antecedentes devem ser repetidas, pelo menos, de cinco em cinco anos.

(225)A título de exemplo, referem-se os fatores revelados numa verificação de antecedentes que possam ser considerados motivos para rejeitar candidatos para cargos de confiança ou intentar uma ação contra uma pessoa de confiança existente:

·falsas declarações feitas pelo candidato ou pessoa de confiança;

·referências profissionais altamente desfavoráveis ou pouco fiáveis;

·certas condenações penais;

·indicações de falta de responsabilidade financeira.

(226)O pessoal dos recursos humanos deve avaliar os relatórios que contenham essas informações, devendo tomar medidas adequadas em função do tipo, da magnitude e da frequência do comportamento revelado pela verificação de antecedentes. Essas medidas podem, em última análise, culminar no cancelamento de ofertas de emprego feitas a candidatos para cargos de confiança ou na cessação da relação de trabalho com atuais pessoas de confiança. A utilização das informações reveladas numa verificação de antecedentes como base para tais medidas estará sujeita à legislação aplicável.

(227)A título de exemplo, referem-se fatores da investigação de antecedentes de pessoas que pretendem tornar-se uma pessoa de confiança:

·confirmação de emprego anterior;

·uma verificação de referências profissionais que abranja o respetivo emprego por um período de pelo menos cinco anos;

·uma confirmação do grau de ensino mais elevado ou mais relevante obtido;

·averiguação de registos criminais.

5.3.3.Requisitos de formação

(228)Os elementos do modelo de confiança de STI-C devem fornecer ao seu pessoal a formação necessária para cumprir as suas responsabilidades relacionadas com as operações da CA de forma competente e satisfatória.

(229)Os programas de formação devem ser revistos periodicamente e a sua formação deve incidir sobre assuntos relevantes para as funções desempenhadas pelo seu pessoal.

(230)Os programas de formação devem incidir sobre assuntos relevantes para o ambiente particular do formando, nomeadamente:

·princípios e mecanismos de segurança dos elementos do modelo de confiança de STI-C;

·versões do equipamento informático e de aplicações informáticas utilizadas;

·todos as tarefas que a pessoa deve desempenhar e processos e sequências de relatórios internos e externos;

·processos empresariais e fluxos de trabalho da PKI;

·elaboração de relatórios e tratamento de incidentes e comprometimentos;

·recuperação em caso de catástrofe e procedimentos de continuidade das atividades;

·conhecimentos suficientes em matéria de TI.

5.3.4.Frequência e requisitos de ações de reciclagem

(231)As pessoas designadas para funções de confiança devem atualizar os conhecimentos adquiridos na formação de forma contínua, num ambiente de formação. A formação deve ser repetida sempre que necessário e pelo menos a cada dois anos.

(232)Os elementos do modelo de confiança de STI-C devem fornecer ações de formação de reciclagem e atualizações ao seu pessoal, na medida e com a frequência necessária para garantir que este mantém o nível de proficiência exigido para cumprir as responsabilidades do cargo de forma competente e satisfatória.

(233)Os indivíduos em funções de confiança devem estar cientes das alterações nas operações da PKI, conforme aplicável. Qualquer alteração significativa nas operações deve ser acompanhada de um plano de formação (sensibilização) e a execução desse plano deve ser documentada.

5.3.5.Frequência e sequência da rotação de funções

(234)Sem estipulação, desde que as competências técnicas, a experiência e os direitos de acesso sejam assegurados. Os administradores dos elementos do modelo de confiança de STI-C devem garantir que as alterações no pessoal não afetam a segurança do sistema.

5.3.6.Sanções para ações não autorizadas

(235)Cada elemento do modelo de confiança de STI-C deve desenvolver um processo disciplinar formal para garantir que as ações não autorizadas são devidamente sancionadas. Em casos graves, as atribuições de funções e os privilégios correspondentes devem ser retirados.

5.3.7.Requisitos aplicáveis aos contratantes independentes

(236)Os elementos do modelo de confiança de STI-C podem permitir que os contratantes ou consultores independentes se tornem pessoas de confiança apenas na medida necessária para ter relações de externalização claramente definidas e na condição de a entidade depositar confiança nos contratantes ou consultores tal como se fossem funcionários e de aqueles cumprirem os requisitos aplicáveis aos funcionários.

(237)Caso contrário, os contratantes e consultores independentes apenas devem ter acesso às instalações protegidas da PKI do STI-C se acompanhados e diretamente supervisionados por pessoas de confiança.

5.3.8.Documentação fornecida ao pessoal

(238)Os elementos do modelo de confiança de STI-C devem proporcionar ao seu pessoal a formação necessária e o acesso à documentação de que necessitam para cumprir as responsabilidades do cargo de forma competente e satisfatória.

5.4.Procedimentos de registo de auditorias

(239)A presente secção define os requisitos relativos aos tipos de eventos a serem registados e à gestão dos registos de auditorias.

5.4.1.Tipos de eventos a serem registados e comunicados por cada CA

(240)Um representante da CA deve rever regularmente os registos, os eventos e os procedimentos da CA.

(241)Os elementos do modelo de confiança de STI-C devem registar os seguintes tipos de eventos de auditoria (se aplicável):

·acesso às instalações físicas – o acesso de pessoas singulares às instalações será registado pelo armazenamento dos pedidos de acesso através de cartões inteligentes. Será criado um evento sempre que for criado um registo;

·a gestão de funções de confiança – qualquer alteração na definição e no nível de acesso das diversas funções será registada, incluindo a alteração dos atributos das funções. Será criado um evento sempre que for criado um registo;

·acesso lógico – será gerado um evento quando uma entidade (por exemplo, um programa) tiver acesso a áreas sensíveis (por exemplo, redes e servidores);

·gestão da salvaguarda – é criado um evento sempre que uma salvaguarda é concluída, com ou sem êxito;

·gestão dos registos – os registos serão armazenados. É criado um evento quando um registo excede uma dimensão específica;

·dados do processo de autenticação para subscritores e elementos do modelo de confiança STI-C – serão gerados eventos para cada pedido de autenticação por subscritores e elementos do modelo de confiança de STI-C;

·aceitação e rejeição de pedidos de certificado, incluindo a criação e renovação de certificados – periodicamente, será gerado um evento com uma lista de pedidos de certificado aceites e rejeitados nos últimos sete dias;

·registo do fabricante – será criado um evento quando um fabricante for registado;

·registo da estação de STI-C – será criado um evento quando uma estação de STI-C for registada;

·gestão do HSM – será criado um evento quando se registar uma violação da segurança do HSM;

·gestão de rede e das TI, uma vez que pertencem aos sistemas da PKI – será criado um evento quando um servidor da PKI for desligado ou reiniciado;

·gestão de segurança (tentativas de acesso ao sistema da PKI, com ou sem êxito, ações da PKI e do sistema de segurança executadas, alterações no perfil de segurança, falhas no sistema, falhas do equipamento informático e outras anomalias, atividades da firewall e do roteador; e entradas e saídas das instalações PKI);

·os dados relacionados com eventos serão armazenados por pelo menos cinco anos, a menos se apliquem regras nacionais adicionais.

(242)Nos termos do GDPR, os registos de auditorias não devem permitir o acesso a dados relacionados com a privacidade relativos a veículos particulares da estação de STI-C.

(243)Sempre que possível, os registos de auditorias devem ser automaticamente recolhidos. Caso não seja possível, deve ser utilizado um registo de operações, um formulário em papel ou outro suporte físico. Todos os registos de auditorias de segurança, eletrónicos e não eletrónicos, devem ser conservados e disponibilizados durante as auditorias de conformidade.

(244)Cada evento relacionado com o ciclo de vida do certificado é registado de forma a poder ser associado à pessoa que o executou. Todos os dados relacionados com uma identidade pessoal são encriptados e protegidos contra o acesso não autorizado.

(245)No mínimo, cada registo de auditoria deve incluir o seguinte (gravado automática ou manualmente para cada evento passível de auditoria):

·tipo de evento (a partir da lista acima);

·data e hora de confiança em que o evento ocorreu;

·resultado do evento – êxito ou insucesso, se apropriado;

·identidade da entidade e/ou operador que causou o evento, se aplicável;

·identidade da entidade visada pelo evento.

5.4.2.Frequência do registo de processamento

(246)Os registos de auditoria devem ser analisados em resposta a alertas com base em irregularidades e incidentes dentro dos sistemas da CA e, além disso, periodicamente todos os anos.

(247)O processamento dos registos de auditoria deve consistir numa análise dos registos de auditorias e na documentação do motivo de todos os eventos significativos num resumo do registo de auditorias. As análises dos registos de auditoria devem incluir uma verificação de que o registo não foi adulterado, uma inspeção de todas as entradas de registo e uma investigação de quaisquer alertas ou irregularidades nos registos. As medidas tomadas com base nas análises dos registos de auditorias devem ser documentadas.

(248)O registo de auditoria é arquivado pelo menos uma vez por semana. Um administrador deve arquivá-lo manualmente se o espaço livre no disco para o registo de auditoria for inferior à quantidade esperada de dados do registo de auditoria produzidos naquela semana.

5.4.3.Período de conservação de registos de auditoria

(249)Os registos guardados relacionados com os ciclos de vida dos certificados são mantidos por pelo menos cinco anos após o termo do certificado correspondente.

5.4.4.Proteção de registos de auditoria

(250)A integridade e a confidencialidade do registo de auditoria são garantidas através de um mecanismo de controlo de acesso baseado em funções. Só os administradores poderão ter acesso aos registos de auditoria internos; Os registos de auditoria relacionados com o ciclo de vida de um certificado também podem ser acedidos por utilizadores com uma autorização adequada através de uma página Web com autenticação do utilizador. O acesso deve ser concedido com múltiplos utilizadores (no mínimo, dois utilizadores) e pelo menos dois níveis de autenticação. As condições técnicas devem assegurar que os utilizadores não podem aceder aos seus próprios ficheiros de registo.

(251)Cada entrada de registo deve ser assinada utilizando material de cifragem do HSM.

(252)Os registos de eventos que contêm informações que possam levar à identificação pessoal, como um veículo particular, são encriptados de forma a apenas poderem ser lidos por pessoas autorizadas.

(253)Os eventos são registados de forma a não poderem ser facilmente eliminados ou destruídos (exceto no que toca à transferência para suportes de longo prazo) durante o período em que os registos tiverem de ser mantidos.

(254)Os registos de eventos são protegidos de forma a permanecerem legíveis durante o período de armazenamento.

5.4.5.Procedimentos de salvaguarda de registos de auditoria

(255)Os registos e resumos de auditoria são salvaguardados por meio de mecanismos de salvaguarda empresariais, sob o controlo de funções de confiança autorizadas, separados da geração de origem do seu componente. As salvaguardas de registos de auditoria devem ser protegidas com o mesmo nível de confiança que se aplica aos registos originais.

5.4.6.Sistema de recolha de auditorias (interno ou externo)

(256)O equipamento dos elementos do modelo de confiança de STI-C deve ativar os processos de auditoria na inicialização do sistema e desativá-los apenas no encerramento do sistema. Se os processos de auditoria não estiverem disponíveis, o elemento de modelo de confiança de STI-C deve suspender a sua operação.

(257)No final de cada período de operação e na reemissão de chave de certificados, o estado coletivo do equipamento deve ser comunicado ao gestor de operações e ao órgão que dirige as operações do respetivo elemento da PKI.

5.4.7.Notificação ao sujeito causador de evento

(258)Quando um evento é registado pelo sistema de recolha de auditorias, garante que é associado a uma função de confiança.

5.4.8.Avaliação de vulnerabilidades

(259)A função de conduzir a auditoria e as funções de realizar a operação do sistema PKI nos elementos do modelo de confiança de STI-C explicam todos os eventos significativos num resumo de um registo de auditoria. Essas análises envolvem a verificação de que o registo não foi adulterado e que não existe descontinuidade ou outra perda de dados de auditoria e, em seguida, uma breve inspeção de todas as entradas de registo, averiguando em maior detalhe quaisquer alertas ou irregularidades nos registos. As medidas tomadas na sequência dessa análise devem ser documentadas.



(260)Os elementos do modelo de confiança de STI-C devem:

·implementar controlos de deteção e prevenção organizacionais e/ou técnicos sob o controlo dos elementos do modelo de confiança de STI-C, para proteger os sistemas da PKI contra vírus e programas maliciosos;

·documentar e seguir um processo de correção de vulnerabilidades que incida sobre a identificação, a análise, a resposta e a correção de vulnerabilidades;

·ser objeto de, ou realizar, uma análise de vulnerabilidades:

·após quaisquer alterações no sistema ou na rede que os elementos do modelo de confiança de STI-C considerem significativas para os componentes da PKI; e ainda

·pelo menos uma vez por mês, em endereços IP públicos e privados identificados pela CA e o CPOC como os sistemas da PKI,

·ser objeto de um teste de penetração nos sistemas da PKI pelo menos uma vez por ano e após atualizações ou alterações da infraestrutura ou da aplicação que os elementos do modelo de confiança de STI-C considerem significativas para o componente PKI da CA;

·para sistemas em linha, registar elementos que comprovem que todas as análises de vulnerabilidades e todos os testes de penetração foram realizados por uma pessoa ou entidade (ou respetivo grupo coletivo) com as competências, as ferramentas, a proficiência, o código de ética e a independência necessários para realizar um teste de vulnerabilidades ou de penetração fiável;

·rastrear e corrigir vulnerabilidades de acordo com as políticas de segurança cibernética da empresa e a metodologia de minimização de riscos.

5.5.Arquivo de registos

5.5.1.Tipos de registos arquivados

(261)Os elementos do modelo de confiança de STI-C devem arquivar os registos em detalhe suficiente para estabelecer a validade de uma assinatura e da correta operação da PKI. No mínimo, devem ser arquivados os seguintes registos de eventos da PKI (se aplicável):

·registo de acesso às instalações físicas dos elementos do modelo de confiança de STI-C (no mínimo, um ano);

·registo da gestão de funções de confiança para elementos do modelo de confiança de STI-C (no mínimo, 10 anos);

·registo de acesso de TI para elementos do modelo de confiança de STI-C (no mínimo, cinco anos);

·registo da criação, utilização e destruição da chave da CA (no mínimo, cinco anos) (não para TLM e CPOC);

·registo da criação, utilização e destruição de certificados (no mínimo, dois anos);

·registo de pedidos da CPA (no mínimo, dois anos);

·registo da gestão de dados de ativação para elementos do modelo de confiança STI-C (no mínimo, cinco anos);

·registo de TI e rede para elementos do modelo de confiança STI-C (no mínimo, cinco anos);

·documentação da PKI para elementos do modelo de confiança de STI-C (no mínimo, cinco anos);

·incidente de segurança e relatório de auditoria para os elementos do modelo de confiança de STI-C (no mínimo, 10 anos);

·equipamento do sistema, aplicações informáticas e configuração (no mínimo, cinco anos).

(262)Os elementos do modelo de confiança de STI-C devem manter a seguinte documentação relativa aos pedidos de certificados e respetiva verificação, e todos os certificados de TLM, CA de raiz e CA e respetiva CRL, por pelo menos sete anos após o fim de validade de qualquer certificado que se baseie nessa documentação:

·a documentação de auditoria da PKI mantida pelos elementos do modelo de confiança de STI-C;

·os documentos da CPS mantidos pelos elementos do modelo de confiança de STI-C;

·o contrato entre a CPA e outras entidades mantido pelos elementos do modelo de confiança de STI-C;

·os certificados (ou outras informações de revogação) mantidos pela CA e pelo TLM;

·os registos de pedidos de certificado no sistema da CA de raiz (não aplicável ao TLM);

·outros dados ou aplicações suficientes para verificar o conteúdo do arquivo;

·todo o trabalho relacionado com, ou com origem em, elementos do modelo de confiança C-ITS e auditores de conformidade.

(263)A entidade da CA deve conservar toda a documentação relacionada com os pedidos de certificado e a respetiva verificação, e todos os certificados e respetiva revogação, por pelo menos sete anos após o fim de validade de qualquer certificado que se baseie nessa documentação.

5.5.2.Período de conservação de arquivos

(264)Sem prejuízo da regulamentação que exija um período de arquivamento mais longo, os elementos do modelo de confiança de STI-C devem manter todos os registos por pelo menos cinco anos após o fim de validade do certificado correspondente.

5.5.3.Proteção de arquivos

(265)Os elementos do modelo de confiança de STI-C devem armazenar o arquivo de registos em instalações de armazenamento seguras e protegidas, separadas do equipamento da CA, com controlos de segurança físicos e processuais equivalentes ou superiores aos da PKI.

(266)O arquivo deve ser protegido contra a visualização, a alteração, a eliminação ou outras adulterações não autorizadas através do armazenamento num sistema fiável.

(267)Os suportes que contêm os dados do arquivo e as aplicações necessárias para os processar devem ser mantidos para assegurar a possibilidade de acesso aos mesmos pelo período definido na presente CP.

5.5.4.Arquivo e armazenamento do sistema

(268)Os elementos do modelo de confiança de STI-C devem proceder diariamente a uma salvaguarda suplementar dos arquivos do sistema dessas informações e realizar salvaguardas completas semanalmente. As cópias dos registos em papel devem ser mantidas em instalações protegidas fora do local.

5.5.5.Requisitos de validação cronológica de registos

(269)Os elementos do modelo de confiança de STI-C que gerem uma base de dados de revogação devem assegurar que os registos contêm informações sobre a hora e a data em que os registos de revogação são criados. A integridade dessas informações será implementada com soluções baseadas em criptografia.

5.5.6.Sistema de recolha de arquivos (interno ou externo)

(270)O sistema de recolha de arquivos é interno.

5.5.7.Procedimentos para obter e verificar informações do arquivo

(271)Todos os elementos do modelo de confiança de STI-C apenas devem permitir o acesso ao arquivo a pessoas de confiança autorizadas. As CA de raiz e as CA devem descrever os procedimentos para criar, verificar, criar pacotes, transmitir e armazenar informações de arquivo na CPS.

(272)O equipamento da CA de raiz e da CA deve verificar a integridade das informações antes de ser restaurado.

5.6.Transferência da chave para elementos do modelo de confiança de STI-C

(273)Os seguintes elementos do modelo de confiança STI-C possuem requisitos específicos para a transmissão de chave: certificados do TLM, da CA de raiz e da EA/AA

5.6.1.TLM

(274)O TLM deve eliminar a sua chave privada após o termo de validade do certificado correspondente. Deve gerar um novo par de chaves e um certificado de TLM correspondente antes de desativar a chave privada válida à data. Deve certificar-se de que o novo certificado (de ligação) é inserido na ECTL a tempo de ser transmitido a todas as estações de STI-C antes de passar a ser válido. O certificado de ligação e o novo certificado autoassinado são transferidos para o CPOC.

5.6.2.CA de raiz

(275)A CA de raiz deve desativar e eliminar a chave privada atual (incluindo as chaves de salvaguarda), para que não emita certificados de EA/AA com uma validade que se estenda além da validade do certificado da CA de raiz.

(276)A CA de raiz deve gerar um novo par de chaves e o certificado de CA de raiz e de ligação correspondente antes de desativar a chave privada atual (incluindo as chaves de salvaguarda) e de os enviar ao TLM para inserção na ECTL. O período de validade do novo certificado de CA de raiz deve começar na desativação planeada da chave privada atual. A CA de raiz deve certificar-se de que o novo certificado é inserido na ECTL a tempo de ser distribuído a todas as estações de STI-C antes de passar a ser válido.

(277)A CA de raiz deve ativar a nova chave privada quando o certificado da CA de raiz correspondente passar a ser válido.

5.6.3.Certificado da EA/AA

(278)A EA/AA deve desativar a chave privada atual, para que não emita certificados de EC/CA com uma validade que se estenda além da validade do certificado de EA/AA.

(279)A EA/AA deve gerar um novo par de chaves e solicitar um certificado de EA/AA correspondente antes de desativar a chave privada atual. O período de validade do novo certificado de EA/AA deve começar na desativação planeada da chave privada atual. A EA/AA deve certificar-se de que o novo certificado pode ser publicado a tempo de ser transmitido a todas as estações de STI-C antes de passar a ser válido.

(280)A EA/AA deve ativar a nova chave privada quando o certificado de EA/AA correspondente passar a ser válido.

5.6.4.Auditor

Ausência de disposições.

5.7.Recuperação em caso de comprometimento e catástrofe

5.7.1.Tratamento de incidentes e comprometimentos

(281)Os elementos do modelo de confiança de STI-C devem monitorizar os seus equipamentos de forma contínua, para detetar possíveis tentativas de intrusão ou outras formas de comprometimento. Nesse caso, devem investigar a fim de determinar a natureza e o grau dos danos.

(282)Se o pessoal responsável pela gestão da CA de raiz ou do TLM detetar uma potencial tentativa de intrusão ou outra forma de comprometimento, deverá investigar a fim de determinar a natureza e o grau de dano. Em caso de comprometimento da chave privada, o certificado da CA de raiz deve ser revogado. Os especialistas em segurança de TI da CPA devem avaliar a extensão dos potenciais danos a fim de determinar se é necessário reconstruir a PKI, se apenas alguns certificados devem ser revogados e/ou se a PKI foi comprometida. Além disso, a CPA determina quais os serviços que devem ser mantidos (informações de estado de revogação e de certificado) e de que forma, de acordo com o plano de continuidade das atividades da CPA.

(283)A CPS abrange os incidentes, o comprometimento e a continuidade das atividades, podendo também contar com outros recursos e planos da empresa para a sua implementação.

(284)Se o pessoal responsável pela gestão da EA/AA/CPOC detetar uma potencial tentativa de intrusão ou outra forma de comprometimento, deverá investigar a fim de determinar a natureza e o grau dos danos. Os pessoal responsável pela gestão da CA ou a entidade do CPOC deve avaliar a extensão dos potenciais danos a fim de determinar se é necessário reconstruir o componente da PKI, se apenas alguns certificados devem ser revogados e/ou se o componente da PKI foi comprometido. Além disso, a entidade da CA subordinada determina quais os serviços que devem ser mantidos e de que forma, de acordo com o plano de continuidade das atividades da entidade da CA subordinada. Em caso de comprometimento de um componente da PKI, a entidade da CA deve alertar a sua própria CA de raiz e o TLM através do CPOC.

(285)A CPS abrange os incidentes, o comprometimento e a continuidade das atividades da CA de raiz ou do TLM ou outros documentos pertinentes no caso do CPOC, podendo também contar com outros recursos e planos da empresa para a sua implementação.

(286)A CA de raiz e a CA devem alertar, com informações precisas sobre as consequências do incidente, cada representante do Estado-Membro e CA de raiz com a qual tenham um acordo no contexto do STI-C, para permitir que estes ativem o seu próprio plano de gestão de incidentes.

5.7.2.Corrupção de recursos informáticos, aplicações informáticas e/ou dados

(287)No caso de se verificar uma situação de catástrofe que impeça a correta operação de um elemento do modelo de confiança de STI-C, esse elemento deve suspender a operação e investigar se a chave privada foi comprometida (exceto CPOC). O equipamento informático defeituoso deve ser substituído o mais rápido possível e devem ser aplicados os procedimentos descritos nas secções 5.7.3 e 5.7.4.

(288)Para os níveis de risco mais elevados, a corrupção de recursos informáticos, aplicações informáticas/ou dados deve ser comunicada à CA de raiz num prazo de 24 horas. Todos os outros eventos devem ser incluídos no relatório periódico da CA de raiz, da EA e da AA.

5.7.3.Procedimentos em caso de comprometimento de chaves privadas de entidades

(289)Em caso de comprometimento, perda ou destruição da chave privada de uma CA de raiz, ou caso suspeite que esta foi comprometida, a CA de raiz deve:

·suspender o seu funcionamento;

·iniciar o plano de recuperação e migração em caso de catástrofe;

·revogar o respetivo certificado de CA de raiz;

·investigar o «principal problema» que gerou o comprometimento e notificar a CPA, que revogará o certificado da CA de raiz por via do TLM (ver secção 7);

·alertar todos os subscritores com os quais tenha um contrato.

(290)Em caso de comprometimento, perda ou destruição da chave da EA/AA, ou caso suspeite que esta foi comprometida, a EA/AA deve:

·suspender o seu funcionamento;

·revogar o próprio certificado;

·investigar o «principal problema» e notificar a CA de raiz;

·alertar os subscritores com os quais exista um acordo.

(291)Em caso de comprometimento, perda ou destruição da chave da EA/AA, ou caso suspeite que esta foi comprometida, a EA/AA objeto de subscrição da estação de STI-C deve:

·revogar a EC do STI afetado;

·investigar o «principal problema» e notificar a CA de raiz;

·alertar os subscritores com os quais tenha um contrato.

(292)Se qualquer um dos algoritmos ou parâmetros associados utilizados pela CA de raiz e/ou CA ou estações de STI-C se revelar insuficiente para a restante utilização prevista, a CPA (com uma recomendação de especialistas em criptografia) deve informar a entidade da CA de raiz com a qual possui um acordo e alterar os algoritmos utilizados. (Para mais detalhes, ver secção 6 e as CPS da CA de raiz e da CA subordinada).

5.7.4.Capacidade de continuidade das atividades em caso de catástrofe

(293)Os elementos do modelo de confiança de STI-C que operam instalações seguras para operações da CA devem desenvolver, testar, manter e implementar um plano de recuperação em caso de catástrofe concebido para minimizar os efeitos de qualquer catástrofe natural ou causada pelo homem. Tais planos devem ter em vista a restauração dos serviços de sistemas de informação e das principais funções da atividade.

(294)Após um incidente de um determinado nível de risco, a CA comprometida deve ser novamente auditada por um auditor de PKI acreditado (ver secção 8).

(295)Quando a CA comprometida deixa de poder continuar a funcionar (por exemplo, após um incidente grave), deve ser elaborado um plano de migração para a transferência das suas funções para outra CA de raiz. No mínimo, a CA de raiz da UE deve estar disponível para auxiliar no plano de migração. A CA comprometida deve cessar funções.

(296)As CA de raiz devem incluir o plano de recuperação em caso de catástrofe e o plano de migração na CPS.

5.8.Cessação e transferência

5.8.1.TLM

(297)O TLM não deve cessar a sua atividade, mas uma entidade gestora do TLM pode tomar outra entidade a cargo.

(298)Em caso de mudança da entidade gestora:

·deve solicitar a aprovação da CPA relativamente a uma mudança de gestão do TLM da entidade antiga para a nova entidade;

·a CPA deve aprovar a mudança de gestão do TLM;

·todos os registos de auditoria e registos arquivados devem ser transferidos da entidade de gestão antiga para a nova entidade.

5.8.2.CA de raiz

(299)A CA de raiz não deve cessar/iniciar a sua atividade sem estabelecer um plano de migração (estabelecido na CPS pertinente) que garanta o funcionamento contínuo para todos os subscritores.

(300)Em caso de cessação do serviço da CA de raiz, esta deverá:

·notificar a CPA;

·notificar o TLM para que este possa excluir o certificado da CA de raiz da ECTL;

·revogar a CA de raiz correspondente emitindo uma CRL que a contenha;

·alertar as CA de raiz com as quais tem um acordo para a renovação de certificados de EA/AA;

·destruir a chave privada da CA de raiz;

·comunicar as informações de estado da última revogação (CRL assinada pela CA de raiz) à parte utilizadora, indicando claramente que são as informações mais recentes sobre a revogação;

·arquivar todos os registos de auditoria e outros registos antes da cessação da PKI;

·transferir registos arquivados para uma autoridade adequada.

(301)O TLM deve excluir o certificado da CA de raiz correspondente da ECTL.

5.8.3.EA/AA

(302)Em caso de cessação do serviço da EA/AA, a entidade da EA/AA deve fazer uma aviso antes da cessação. A EA/AA não deve cessar/iniciar a sua atividade sem estabelecer um plano de migração (estabelecido na CPS pertinente) que garanta o funcionamento contínuo para todos os subscritores. A EA/AA deve:

·informar a CA de raiz por carta registada;

·destruir a chave privada da CA;

·transferir a sua base de dados para a entidade designada pela CA de raiz;

·suspender a emissão de certificados;

·durante a transferência da sua base de dados e até que esta esteja totalmente operacional numa nova entidade, manter a capacidade de autorizar pedidos da autoridade de privacidade responsável;

·caso uma CA subordinada tenha sido comprometida, a CA de raiz deve revogar a CA subordinada e emitir uma nova CRL que elenque as CA subordinadas revogadas;

·arquivar todos os registos de auditoria e outros registos antes de cessar a PKI;

·transferir o seu arquivo de registos para a entidade designada pela CA de raiz;

(303)Em caso de cessação dos serviços da CA, esta será responsável por manter todos os registos pertinentes referentes às necessidades da CA e dos componentes da PKI.

6.Controlos de segurança técnica

6.1.Geração e instalação de pares de chaves

6.1.1.TLM, CA de raiz, EA, AA

(304)O processo de geração de pares de chaves deve cumprir os seguintes requisitos:

·cada participante deve ser capaz de gerar os seus próprios pares de chaves em conformidade com as secções 6.1.4 e 6.1.5

·o processo de obtenção de chaves de encriptação simétricas e de uma chave MAC para pedidos de certificado (ECIES) deve ser realizado em conformidade com a norma [1] e [5];

·o processo de geração de chaves deve utilizar os algoritmos e comprimentos de chave descritos nas secções 6.1.4.1 e 6.1.4.2;

·o processo de geração de pares de chaves deve estar sujeito aos requisitos de «armazenamento seguro de chaves privadas» (ver secção 6.1.5);

·as CA de raiz e respetivos subscritores (CA subordinadas) devem garantir que a integridade e a autenticidade das suas chaves públicas e de quaisquer parâmetros associados são mantidos durante a transmissão às entidades registadas na CA subordinada.

6.1.2.EA — estação móvel de STI-C

(305)Cada estação móvel de STI-C deve ser capaz de gerar os seus próprios pares de chaves em conformidade com as secções 6.1.4 e 6.1.5

(306)O processo de obtenção de chaves de encriptação simétricas e de uma chave MAC para pedidos de certificado (ECIES) deve ser realizado em conformidade com a norma [1] e [5].

(307)Os processos de geração de chaves devem utilizar os algoritmos e comprimentos de chave descritos nas secções 6.1.4.1 e 6.1.4.2.

(308)Os processos de geração de pares de chaves devem estar sujeitos aos requisitos de «armazenamento seguro de chaves privadas» (ver secção 6.1.5);

6.1.3.EA — estação fixa de STI-C

(309)Cada estação fixa de STI-C deve ser capaz de gerar o seu próprio par de chaves em conformidade com as secções 6.1.4 e 6.1.5.

(310)Os processos de geração de chaves devem utilizar os algoritmos e comprimentos de chave descritos nas secções 6.1.4.1 e 6.1.4.2.

(311)Os processos de geração de pares de chaves devem estar sujeitos aos requisitos de «armazenamento seguro de chaves privadas» (ver secção 6.1.5);

6.1.4.Requisitos de criptografia

(312)Todos os participantes da PKI devem cumprir os requisitos criptográficos estabelecidos nos parágrafos a seguir, no que diz respeito ao algoritmo de assinatura, ao comprimento de chave, ao gerador de números aleatórios e aos certificados de ligação.

6.1.4.1.Comprimento de algoritmos e chaves — algoritmos de assinatura

(313)Todos os participantes da PKI (TLM, CA de raiz, EA, AA e estações de STI-C) devem poder gerar pares de chaves e utilizar a chave privada para assinar operações com algoritmos selecionados, o mais tardar dois anos após a entrada em vigor do presente regulamento, em conformidade com o Table 4 .

(314)Todos os participantes da PKI que devem verificar a integridade da ECTL, de certificados e/ou de mensagens assinadas de acordo com sua função, conforme definido na secção 1.3.6, devem suportar os algoritmos correspondentes apresentados no Table 5 para fins de verificação. Em especial, as estações de STI-C devem poder verificar a integridade da ECTL.

TLM

CA de raiz

EA

AA

Estação de STI-C

ECDSA_nistP256_with_SHA 256

-

X

X

X

X

ECDSA_brainpoolP256r1_with_SHA 256

-

X

X

X

X

ECDSA_brainpoolP384r1_with_SHA 384

X

X

X

-

-

X indica suporte obrigatório

Quadro 4: Geração de pares de chaves e utilização da chave privada para operações de assinatura



TLM

CA de raiz

EA

AA

Estação de STI-C

ECDSA_nistP256_with_SHA 256

X

X

X

X

X

ECDSA_brainpoolP256r1_with_SHA 256

X

X

X

X

X

ECDSA_brainpoolP384r1_with_SHA 384

X

X

X

X

X

X indica suporte obrigatório

Quadro 5: Visão geral da verificação

(315)Se a CPA assim determinar com base em fragilidades criptográficas recentemente constatadas, todas as estações de STI-C devem poder mudar para um dos dois algoritmos (ECDSA_nistP256_with_SHA 256 ou ECDSA_brainpoolP256_with_SHA 256) logo que possível. O(s) algoritmo(s) real(is) utilizado(s) será(ão) determinado(s) na CPS da CA que emite o certificado para a chave pública correspondente, em conformidade com a presente CP.

6.1.4.2.Comprimento de algoritmos e chaves — algoritmos de encriptação para inscrição e autorização

(316)Todos os participantes da PKI (EA, AA e estações de STI-C) devem poder utilizar chaves públicas para encriptar os pedidos/respostas de inscrição e autorização com algoritmos selecionados, o mais tardar dois anos após a entrada em vigor do presente regulamento, em conformidade com o Table 6 . O(s) algoritmo(s) real(is) utilizado(s) será(ão) determinado(s) na CPS da CA que emite o certificado para a chave pública correspondente, em conformidade com a presente CP.

(317)Os algoritmos apresentados no Table 6 indicam o comprimento da chave e o comprimento do algoritmo Hash e devem ser implementados de acordo com a norma [5].

TLM

CA de raiz

EA

AA

Estação de STI-C

ECIES_nistP256_with_AES 128_CCM

-

-

X

X

X

ECIES_brainpoolP256r1_with_AES 128_CCM

-

-

X

X

X

X indica suporte obrigatório

Quadro 6: Utilização de chaves públicas para encriptação de pedidos/respostas de inscrição e autorização



(318)Todos os participantes da PKI (EA, AA e estações de STI-C) devem poder gerar pares de chaves e utilizar a chave privada para desencriptar pedidos/respostas de inscrição e autorização com algoritmos selecionados, o mais tardar dois anos após a entrada em vigor do presente regulamento, em conformidade com o Table 7 .

TLM

CA de raiz

EA

AA

Estação de STI-C

ECIES_nistP256_with_AES 128_CCM

-

-

X

X

X

ECIES_brainpoolP256r1_with_AES 128_CCM

-

-

X

X

X

X indica suporte obrigatório

Quadro 7: Geração de pares de chaves e utilização de chave privada para a desencriptação de pedidos/respostas de inscrição e autorização

6.1.4.3.Criptoagilidade

(319)É necessário alterar os requisitos aplicáveis aos comprimentos de chave e algoritmos de tempos a tempos, para manter um nível de segurança adequado. A CPA deve verificar a necessidade de tais mudanças à luz das vulnerabilidades reais e dos avanços da técnica em matéria de criptografia. Deverá redigir, aprovar e publicar uma atualização da presente política de certificação se decidir que os algoritmos criptográficos devem ser atualizados. Se uma nova edição da presente CP sinalizar uma mudança de algoritmo e/ou comprimento de chave, a CPA deverá adotar uma estratégia de migração que inclua períodos de transição durante os quais os antigos algoritmos e comprimentos de chave devem ser suportados.

(320)Para permitir e facilitar a transferência para novos algoritmos e/ou comprimentos de chave, recomenda-se que todos os participantes da PKI implementem equipamento informático e/ou aplicações informáticas capazes de transferir os comprimentos de chave e os algoritmos.

(321)As alterações de certificados raiz e TLM devem ser suportadas e executadas com a ajuda de certificados de ligação (ver secção 4.6) utilizados para cobrir o período de transição entre os certificados de raiz antigos e os novos («migração do modelo de confiança»).

6.1.5.Armazenamento seguro de chaves privadas

A presente secção descreve os requisitos aplicáveis ao armazenamento seguro e à geração de pares de chaves e números aleatórios para CA e entidades finais. Estes requisitos são definidos para módulos criptográficos e descritos nas subseções a seguir.

6.1.5.1.Nível de CA de raiz, CA subordinada e TLM

(322)Deve ser utilizado um modelo criptográfico para:

·gerar, utilizar, administrar e armazenar chaves privadas;

·gerar e utilizar números aleatórios (a avaliação da função de geração de números aleatórios deve fazer parte da avaliação e certificação de segurança);

·criar salvaguardas de chaves privadas de acordo com a secção 6.1.6;

·eliminação de chaves privadas.

O módulo criptográfico deve ser certificado com um dos seguintes perfis de proteção (PP), com nível de garantia EAL-4 ou superior:

·PP para HSM

·CEN EN 419 221-2: «Protection profiles for TSP cryptographic modules – Part 2: Cryptographic module for CSP signing operations with backup» (Perfis de proteção para módulos criptográficos de TSP – Parte 2: Módulo criptográfico para operações de assinatura do PSC com salvaguarda;

·CEN EN 419 221-4: «Protection profiles for TSP cryptographic modules – Part 4: Cryptographic module for CSP signing operations without backup» (Perfis de proteção para módulos criptográficos de TSP – Parte 2: Módulo criptográfico para operações de assinatura do PSC sem salvaguarda;

·CEN EN 419 221-5: «Protection profiles for TSP cryptographic modules – Part 5: Cryptographic module for trust services» (Perfis de proteção para módulos criptográficos de TSP – Parte 5: Módulo criptográfico para serviços de confiança);

·PP para cartões inteligentes

·CEN EN 419 211-2: «Protection profiles for secure signature creation device – Part 2: Device with key generation» (Perfis de proteção para dispositivo de criação de assinaturas seguras – Parte 2: Dispositivo com geração de chaves);

·CEN EN 419 211-3: «Protection profiles for secure signature creation device – Part 3: Device with key generation» (Perfis de proteção para dispositivo de criação de assinaturas seguras – Parte 3: Dispositivo com importação de chave).

O acesso manual ao módulo criptográfico requer a autenticação de dois fatores do administrador. Adicionalmente, impõe-se o envolvimento de duas pessoas autorizadas.

A implementação de um módulo criptográfico deve assegurar que as chaves não são acessíveis fora do módulo criptográfico. O módulo criptográfico deve incluir um mecanismo de controlo de acesso para impedir a utilização não autorizada de chaves privadas.

6.1.5.2.Entidade final

(323)Deve ser utilizado um modelo criptográfico para EA para:

·gerar, utilizar, administrar e armazenar chaves privadas;

·gerar e utilizar números aleatórios (a avaliação da função de geração de números aleatórios deve fazer parte da avaliação e certificação de segurança);

·proteger a eliminação de uma chave privada.

(324)O módulo criptográfico deve ser protegido contra a remoção, a substituição e a alteração não autorizadas. Todos os PP e documentos relacionados aplicáveis à certificação de segurança do módulo criptográfico devem ser avaliados, validados e certificados em conformidade com a norma ISO 15408, aplicando o Acordo de Reconhecimento Mútuo de Certificados de Avaliação da Segurança da Tecnologia da Informação do Grupo de Altos Funcionários para a Segurança dos Sistemas de Informação (SOG-IS), ou um sistema de certificação da cibersegurança europeu equivalente submetido ao devido enquadramento europeu de cibersegurança. Dada a importância de manter o nível de segurança mais elevado possível, os certificados de segurança para o módulo criptográfico devem ser emitidos no contexto do sistema de certificação de critérios comuns (ISO 15408) por um organismo de avaliação da conformidade reconhecido pelo comité de gestão no âmbito do Acordo SOG-IS, ou por um organismo de avaliação da conformidade acreditado por uma autoridade nacional de certificação da cibersegurança de um Estado-Membro. Tal organismo deve providenciar condições de avaliação de segurança pelo menos equivalentes às previstas no Acordo de Reconhecimento Mútuo SOG-IS.

Nota: a ligação entre o módulo criptográfico e a estação de STI-C deve ser protegida.

6.1.6.Salvaguarda de chaves privadas

(325)A geração, o armazenamento e a utilização de salvaguardas de chaves privadas devem pelo menos cumprir o requisito do nível de segurança exigido para as chaves originais.

(326)As salvaguardas de chaves privadas devem ser efetuadas pelas CA de raiz, EA e AA.

(327)As salvaguardas de chaves privadas não devem ser efetuadas para EC e CA.

6.1.7.Destruição de chaves privadas

(328)As CA de raiz, EA, AA e estações de STI-C móveis e fixas devem destruir a sua chave privada e todas as salvaguardas correspondentes, se um novo par de chaves e o certificado correspondente tiverem sido gerados e instalados com êxito e já tiver terminado o período de sobreposição (se aplicável — apenas a CA). A chave privada deve ser destruída utilizando o mecanismo oferecido pelo módulo criptográfico utilizado para o armazenamento das chaves ou conforme descrito no PP correspondente, conforme referido na secção 6.1.5.2.

6.2.Dados de ativação

(329)Os dados de ativação referem-se a fatores de autenticação necessários para operar módulos criptográficos a fim de impedir o acesso não autorizado. A utilização dos dados de ativação do dispositivo criptográfico de uma CA deve implicar a ação de duas pessoas autorizadas.

6.3.Controlos de segurança informática

(330)Os controlos de segurança informática das CA devem ser concebidos de acordo com o nível de segurança elevado, cumprindo os requisitos da norma ISO/IEC 27002.

6.4.Controlos técnicos do ciclo de vida

(331)Os controlos técnicos da CA devem cobrir todo o ciclo de vida da CA, nomeadamente, os requisitos da secção 6.1.4.3 («Criptoagilidade»).

6.5.Controlos de segurança de rede

(332)As redes das CA (CA de raiz, EA e AA) devem ser fortemente protegidas contra ataques de acordo com os requisitos e as orientações de implementação das normas ISO/IEC 27001 e ISO/IEC 27002.

(333)A disponibilidade das redes da CA deve ser projetada à luz do tráfego previsto.

7.Perfis de certificados, CRL e CTL

7.1.Perfil do certificado

(334)Os perfis de certificado definidos na norma [5] devem ser utilizados para o TLM, os certificados de raiz, certificados de EA, certificados de AA, CA e EC. As EA governamentais nacionais podem utilizar outros perfis de certificados para EC.

(335)Os certificados da CA de raiz, EA e AA devem indicar as permissões para as quais essas CA (CA de raiz, EA e AA) podem emitir certificados.

(336)Com base na norma [5]:

·cada CA de raiz deve utilizar a sua própria chave privada de assinatura para emitir CRL;

·o TLM deve utilizar a sua própria chave privada de assinatura para emitir a ECTL.

7.2.Validade do certificado

(337)Todos os perfis de certificados de STI-C devem incluir uma data de emissão e de termo, que representam o período de validade do certificado. Em cada nível da PKI, os certificados devem ser gerados em tempo útil antes do termo.

(338)O período de validade dos certificados CA e EC deve incluir um período de sobreposição. Os certificados TLM e CA de raiz devem ser emitidos e inseridos na ECTL durante um período máximo de três meses e, pelo menos, um mês antes do início da sua validade, com base na hora de início do certificado. Essa fase de pré-carregamento é necessária para distribuir com segurança os certificados por todas as partes utilizadoras correspondentes, em conformidade com a secção 2.2. Essa circunstância permite garantir que todas as partes utilizadoras podem verificar as mensagens emitidas com um novo certificado logo desde o início do período de sobreposição.

(339)No início do período de sobreposição, os certificados sucessivos de CA, EC e CA devem ser emitidos (se aplicável), distribuídos às partes utilizadoras correspondentes e instalados pelas mesmas. Durante o período de sobreposição, o certificado atual apenas deve ser utilizado para efeitos de verificação.

(340)Uma vez que os períodos de validade apresentados no Table 8 não devem exceder o período de validade do certificado superior, aplicam-se as seguintes restrições:

·maximumvalidity(CA de raiz) = privatekeyusage(CA de raiz) + maximumvalidity(EA,AA);

·maximumvalidity(EA) = privatekeyusage(EA) + maximumvalidity(EC);

·maximumvalidity(AA) = privatekeyusage(AA) + preloadingperiod(CA).

(341)A validade dos certificados de ligação (de raiz e TLM) tem início no momento de utilização da chave privada correspondente e termina no período máximo de validade da CA de raiz ou do TLM.

(342)O Table 8 mostra o período máximo de validade para os certificados de CA de STI-C (para os períodos de validade do CA, ver secção 7.2.1).

Entidade

Período máx. de utilização da chave privada

Período máximo de validade

CA de raiz

3 anos

8 anos

EA

2 anos

5 anos

AA

4 anos

5 anos

EC

3 anos

3 anos

TLM

3 anos

4 anos

Quadro 8: Períodos de validade dos certificados no modelo de confiança de STI-C

7.2.1.Certificados de pseudónimos

(343)Neste contexto, os pseudónimos são implementados por CA. Consequentemente, a presente secção refere-se a CA, e não a pseudónimos.

(344)Os requisitos estabelecidos na presente secção aplicam-se apenas a CA de estações móveis de STI-C que enviam mensagens CAM e DENM , em que o risco de privacidade de localização é aplicável. Não se aplicam requisitos específicos aos certificados de CA no caso de CA para estações de STI-C fixas e móveis utilizadas para funções especiais em que a privacidade de localização não é aplicável (por exemplo, veículos de emergência e veículos das forças de segurança).

(345)São aplicáveis as seguintes definições:

·«período de validade de CA»: o período durante o qual um CA é válido, ou seja, o período entre a data de início do CA e a sua data de termo;

·«período de pré-carregamento de CA»: o pré-carregamento é a possibilidade de as estações de STI-C obterem CA antes do início do período de validade. 
O período de pré-carregamento é o período de tempo máximo permitido desde o pedido de CA até ao termo da validade de qualquer CA solicitado;

·«período de utilização de CA»: o período durante o qual um CA é efetivamente utilizado para assinar mensagens CAM/DENM;

·«número máximo de CA paralelos»: o número de CA a partir do qual uma estação de STI-C pode escolher a qualquer momento, ao assinar uma mensagem CAM/DENM, ou seja, o número de CA diferentes emitidos para uma estação de STI-C e válidos em simultâneo.

(346)São aplicáveis os seguintes requisitos:

·o período de pré-carregamento para os CA não deve exceder três meses;

·o período de validade dos CA não deve exceder uma semana;

·o número máximo de CA paralelos não deve exceder 100 por estação de STI-C;

·O período de utilização de um CA depende da estratégia de alteração do CA e da quantidade de tempo que um veículo está em funcionamento, mas é limitado pelo número máximo de CA paralelos e pelo período de validade. Mais especificamente, o período de utilização médio para uma estação de STI-C é de pelo menos o tempo de funcionamento do veículo durante um período de validade dividido pelo número máximo de CA paralelos.

7.2.2.Bilhetes de autorização para estações de STI-C fixas

(347)Aplicam-se as definições da secção 7.2.1 e os seguintes requisitos:

·o período de pré-carregamento para os CA não deve exceder três meses;

·o número máximo de CA paralelos não deve exceder dois por estação de STI-C.

7.3.Revogação de certificados

7.3.1.Revogação de certificados de CA, EA e AA

Os certificados da CA de raiz, da EA e da AA devem ser revogáveis. Os certificados revogados de CA de raiz, EA e AA devem ser publicados numa CRL assim que possível e sem demora injustificada. Essa CRL deve ser assinada pela sua CA de raiz correspondente e utilizar o perfil descrito na secção 7.4. Para revogar certificados da CA de raiz, a CA de raiz correspondente deve emitir uma CRL que a contenha. Além disso, em casos de comprometimento da segurança, aplica-se a secção 5.7.3. Adicionalmente, o TLM deve remover as CA de raiz revogadas da lista aprovada e emitir uma nova lista aprovada. Os certificados expirados devem ser removidos da CRL e da lista aprovada.

(348)Os certificados são revogados quando:

·as CA de raiz têm motivos para crer ou suspeitar fortemente que a chave privada correspondente foi comprometida;

·as CA de raiz foram notificadas de que o contrato com o subscritor foi rescindido;

·as informações (como o nome e associações entre a CA e o sujeito) no certificado estão incorretas ou foram alteradas;

·ocorre um incidente de segurança que afeta o titular do certificado;

·uma auditoria (ver secção 8) leva a um resultado negativo.

(349)O subscritor deve notificar de imediato a CA de um comprometimento conhecido ou presumível da sua chave privada. Deve-se garantir que apenas os pedidos autenticados resultam em certificados revogados.

7.3.2.Revogação de credenciais de inscrição

(350)A revogação das EC pode ser iniciada pelo subscritor da estação de STI-C (fluxo 34) e deve ser implementada através de uma lista negra interna numa base de dados de revogação com um selo temporal, que é gerado e mantido por cada EA. A lista negra nunca é publicada e deve permanecer confidencial, sendo utilizada apenas pela EA correspondente para verificar a validade das EC correspondentes no contexto de pedidos de CA e novas EC.

7.3.3.Revogação de bilhetes de autorização

(351)Uma vez que os CA não são revogados pelas CA correspondentes, devem ter um tempo de vida curto e não podem ser emitidas muito antes de passarem a ser válidos. Os valores dos parâmetros do ciclo de vida do certificado permitidos encontram-se definidos na secção 7.2.

7.4.Lista de revogação de certificados

(352)O formato e o conteúdo da CRL emitida pelas CA de raiz são os estabelecidos na norma [1].

7.5.Lista aprovada de certificados europeus

(353)O formato e o conteúdo da ECTL emitida pelo TLM são os estabelecidos na norma [1].

8.Auditoria de conformidade e outras avaliações

8.1.Aspetos abrangidos pela auditoria e base da auditoria

(354)O objetivo de uma auditoria de conformidade é verificar se o TLM, as CA de raiz, as EA e as AA operam de acordo com a presente CP. O TLM, as CA de raiz, as EA e as AA devem selecionar um auditor da PKI de acreditado e independente para auditar a sua CPS. A auditoria deve ser conjugada com uma avaliação das normas ISO/IEC 27001 e ISO/IEC 27002.

(355)A CA de raiz deve solicitar uma auditoria de conformidade a si mesma (fluxo 13) e uma EA/AA deve fazê-lo para respetiva CA subordinada.

(356)A CPA deve solicitar uma auditoria de conformidade para o TLM (fluxo 38).

(357)Quando solicitado, um auditor da PKI acreditado deve realizar uma auditoria de conformidade num dos seguintes níveis:

(1)conformidade da CPS do TLM, da CA de raiz, da EA ou da AA com a presente CP;

(2)conformidade das práticas previstas do TLM, da CA de raiz, da EA ou da AA com a respetiva CPS antes das operações;

(3)conformidade das práticas e atividades operacionais do TLM, da CA de raiz, da EA ou da AA com a respetiva CPS durante as operações.

(358)A auditoria deve abranger todos os requisitos da presente CP a serem cumpridos pelo TLM, as CA de raiz, as EA e as AA a serem auditados. Deve também abranger a operação da CA na PKI do STI-C, incluindo todos os processos referidos na respetiva CPS, as instalações e as pessoas responsáveis.

(359)O auditor da PKI acreditado deve apresentar um relatório detalhado da auditoria à CA de raiz (fluxo 36), à EA, à AA ou à CPA (fluxos 16 e 40), conforme aplicável.

8.2.Frequência das auditorias

(360)Uma CA de raiz, um TLM, uma EA ou uma AA deve pedir para ser objeto de uma auditoria de conformidade a um auditor independente e acreditado da PKI nos seguintes casos:

·na sua primeira configuração (conformidade com os níveis 1 e 2);

·a cada alteração da CP. A CPA deve definir o teor da alteração da CP e a calendarização de implantação e determinar as necessidades de auditorias (incluindo o nível de conformidade necessário) em conformidade;

·a cada mudança da sua CPS (níveis 1, 2 e 3 de conformidade). Uma vez que as entidades de gestão das CA de raiz, o TLM e as EA/AA decidem quais as alterações de implementação que seguem a atualização da sua CPS, devem solicitar uma auditoria de conformidade antes de implementar essas alterações. Nos casos de pequenas alterações da CPS (por exemplo, de caráter editorial), a entidade administradora pode enviar à CPA um pedido devidamente justificado, para que a sua aprovação possa prescindir das auditorias de conformidade de nível 1, 2 ou 3;

·regularmente, e pelo menos de três em três anos durante a sua operação (nível 3 de conformidade).

8.3.Identidade/qualificações do auditor

(361)A CA a ser auditada deve selecionar uma empresa/organização independente e acreditada («organismo auditor») ou auditores da PKI acreditados para a auditar de acordo com a presente CP. O organismo auditor deve ser acreditado e certificado por um membro da European Accreditation 1 .

8.4.Relação do auditor com a entidade auditada

(362)O auditor da PKI acreditado deve ser independente da entidade auditada.

8.5.Medidas tomadas face a deficiência

(363)Caso um relatório de auditoria indique que o TLM não está em conformidade, a CPA deve solicitar ao TLM que tome medidas preventivas/corretivas imediatas.

(364)Quando uma CA de raiz com um relatório de auditoria não conforme efetua um novo pedido, a CPA deve rejeitar o pedido e enviar a rejeição correspondente à CA de raiz (fluxo 4). Nesses casos, a CA de raiz será suspensa. Deve tomar medidas corretivas, voltar a solicitar a auditoria e apresentar um novo pedido de aprovação à CPA. A CA raiz não deve poder emitir certificados durante a suspensão.

(365)No caso de a auditoria à CA de raiz ser regular ou em caso de alteração à CPS da CA de raiz, e dependendo da natureza da não conformidade descrita no relatório de auditoria, a CPA pode decidir revogar a CA de raiz e comunicar essa decisão ao TLM (fluxo 2), originando a exclusão do certificado da CA de raiz da ECTL e a inserção da CA de raiz na CRL. A CPA deve enviar a rejeição correspondente à CA de raiz (fluxo 4). A CA de raiz deve tomar medidas corretivas, voltar a solicitar uma auditoria completa (níveis 1 a 3) e efetuar um novo pedido de aprovação à CPA. Em alternativa, a CPA pode decidir não revogar a CA de raiz, mas conceder-lhe um período de carência em que a CA de raiz deve tomar medidas corretivas, voltar a solicitar uma auditoria e reenviar o relatório da auditoria à CPA. Nesse caso, a operação da CA de raiz deve ser suspensa, não lhe sendo permitido emitir certificados e CRL.

(366)No caso de uma auditoria da EA/AA, a CA de raiz deve decidir se aceita ou não o relatório. Dependendo do resultado da auditoria, a CA de raiz deve decidir se revoga o certificado da EA/AA de acordo com as regras da CPS da CA de raiz. A CA de raiz deve sempre garantir a conformidade da EA/AA com a presente CP.

8.6.Comunicação dos resultados

(367)A CA de raiz e o TLM devem enviar o relatório de auditoria à CPA (fluxo 16). A CA de raiz e o TLM devem armazenar todos os relatórios de auditoria que solicitaram. A CPA deve enviar a aprovação ou rejeição correspondente (fluxo 4) à CA de raiz e ao TLM.

(368)A CA de raiz deve enviar um certificado de conformidade à EA/AA correspondente.

9.Outras disposições

9.1.Taxas

(369)Constitui um princípio do modelo de confiança do STI-C da UE implementado o facto de as CA de raiz financiarem totalmente os custos recorrentes e regulares de funcionamento da CPA e os elementos centrais (TLM e CPOC) relacionados com as atividades definidas na presente CP.

(370)As CA de raiz (incluindo a CA de raiz da UE) podem cobrar taxas às suas subautoridades de certificação.

(371)Durante todo o período de funcionamento, cada participante do modelo de confiança de STI-C deve ter acesso a pelo menos uma CA de raiz, EA e AA numa base não discriminatória.

(372)Cada CA de raiz tem direito a aplicar as taxas que paga pela CPA e os elementos centrais (TLM e CPOC) aos participantes registados do modelo de confiança de STI-C, incluindo as estações de STI-C inscritas e autorizadas.

9.2.Responsabilidade financeira

(373)O estabelecimento inicial de uma CA de raiz deve abranger um período de pelo menos três anos de funcionamento, para que se torne membro do modelo de confiança do STI-C da UE. A CPS de um operador da CA de raiz também deve conter disposições detalhadas sobre a revogação ou o encerramento de da CA de raiz.

(374)Cada CA de raiz deve demonstrar a viabilidade financeira da entidade jurídica que a implementa por pelo menos três anos. Esse plano de viabilidade financeira faz parte do conjunto inicial de documentos para inscrição e deve ser atualizado a cada três anos e comunicado à CPA.

(375)Cada CA de raiz deve relatar a estrutura das taxas aplicadas às EA/AA e às estações de STI-C inscritas e autorizadas anualmente ao gestor de operações e à CPA, para demonstrar a sua sustentabilidade financeira.

(376)Todas as entidades financeiras e jurídicas responsáveis da CA de raiz, da EA, da AA e dos elementos centrais (CPOC e TLM) do modelo de confiança de STI-C devem cobrir as suas tarefas operacionais com níveis adequados de seguro para compensar erros operacionais e a recuperação financeira das suas tarefas no caso de um dos elementos técnicos falhar.

9.3.Confidencialidade das informações comerciais

(377)Os seguintes elementos devem permanecer confidenciais e privados:

·registos de pedidos de CA de raiz, EA e AA, aprovados ou rejeitados;

·relatórios de auditoria de CA de raiz, EA, AA e TLM;

·planos de recuperação em caso de catástrofe de CA de raiz, EA, AA, CPOC e TLM;

·chaves privadas dos elementos do modelo de confiança de STI-C (estações de STI-C, TLM, EA, AA, CA de raiz);

·qualquer outra informação identificada como confidencial pela CPA, CA de raiz, EA, AA, TLM e CPOC.

9.4.Plano de privacidade

(378)As CPS das CA de raiz e as EA/AA devem estabelecer o plano e os requisitos para o tratamento de informações pessoais e da privacidade com base no RGPD e noutros quadros legislativos aplicáveis (por exemplo, nacionais).

10.Referências

No presente anexo, utilizam-se as seguintes referências:

(1)ETSI TS 102 941 V1.2.1, «Intelligent transport systems (ITS) – security, trust and privacy management» [Sistemas de transporte inteligentes (STI) – Gestão da segurança, da confiança e da privacidade].

(2)ETSI TS 102 940 V1.3.1, «Intelligent transport systems (ITS) – security, ITS communications security architecture and security management» [Sistemas de transporte inteligentes (STI) – Segurança, arquitetura de segurança de comunicações de STI e gestão da segurança].

(3)«Certificate policy and certification practices framework» (Política de certificação e quadro de práticas de certificação) (RFC 3647, 1999).

(4)ETSI TS 102 042 V2.4.1 «Policy requirements for certification authorities issuing public key certificates» (Requisitos de política aplicáveis a autoridades de certificação que emitem certificados de chave pública).

(5)ETSI TS 103 097 V1.3.1, «Intelligent transport systems (ITS) – security, security header and certificate formats» [Sistemas de transporte inteligentes (STI) – Segurança, rubrica de segurança e formatos de certificado].

(6)Calder, A. (2006). Information security based on ISO 27001/ISO 1779: a management guide. Van Haren Publishing.

(7)ISO, I., & Std, I. E. C. (2011). ISO 27005 (2011) – «Information technology, security techniques, information security risk management» (Tecnologia da informação, técnicas de segurança, gestão de riscos de segurança da informação). ISO.

(1)    Os membros do organismo europeu de acreditação estão elencados em:    
http://www.european-accreditation.org/ea-members
Início

ÍNDICE

1.Política de segurança dos STIC2

1.1.Definições e acrónimos2

1.2.Definições2

1.3.Estratégia para a segurança da informação3

1.3.1.Sistemas de gestão da segurança das informações (Information security management system, «ISMS»)3

1.4.Classificação das informações4

1.5.Avaliação do risco6

1.5.1.Aspetos gerais6

1.5.2.Critérios de risco para a segurança6

1.5.2.1.Identificação do risco6

1.5.2.2.Análise do risco7

1.5.2.3.Avaliação do risco8

1.6.Tratamento do risco8

1.6.1.Aspetos gerais8

1.6.2.Controlos relativos às estações STIC8

1.6.2.1.Controlos genéricos8

1.6.2.2.Controlos relativos às comunicações entre estações STIC8

1.6.2.3.Controlos relativos às estações STIC enquanto entidades finais10

1.6.3.Controlos relativos aos participantes no EU CCMS10

1.7.Conformidade com a presente política de segurança10

2.Referências11

ANEXO IV

1.Política de segurança dos STIC

1.1.Definições e acrónimos

EU CCMS

Sistema de gestão das credenciais de segurança STIC da União Europeia

CAM

Mensagem de perceção cooperativa (Cooperative Awareness Message)

CP

Política de certificação (Certificate Policy)

DENM

Mensagem de notificação ambiental descentralizada (Decentralised Environmental Notification Message)

ISMS

Sistema de gestão da segurança das informações (Information Security Management System)

IVIM

Mensagem infraestruturaveículo (InfrastructuretoVehicle Information Message)

SPATEM

Mensagem de fase e temporização de sinal alargadas (Signal Phase and Timing Extended Message)

SREM

Mensagem alargada de pedido de sinal (Signal Request Extended Message)

SSEM

Mensagem alargada de estado de pedido de sinal (Signal Request Status Extended Message)

1.2.Definições

Disponibilidade

Ser acessível e utilizável, mediante pedido de uma entidade autorizada (ISO 27000) [2]

Infraestrutura STIC

Sistema de instalações, equipamento e aplicações necessários para o funcionamento de uma organização que presta serviços STIC relacionados a estações STIC fixas

Partes interessadas nos STIC

Pessoa, grupo ou organização com um papel e uma responsabilidade na rede STIC

Informações confidenciais

Informações que não devem ser disponibilizadas ou divulgadas a pessoas, entidades ou processos não autorizados (ISO 27000) [2]

Segurança da informação

Preservação da confidencialidade, integridade e disponibilidade das informações (ISO 27000) [2]

Incidente de segurança da informação

Um evento indesejado ou inesperado de segurança da informação, ou uma série de eventos, com probabilidade significativa de comprometer as operações comerciais e ameaçar a segurança da informação

Integridade

Propriedade de exatidão e exaustividade (ISO 27000) [2]

Mapa local dinâmico (Local Dynamic Map, «LDM»)

Um repositório de dados de atualização dinâmica de uma estação STIC de bordo, relativo às condições locais de condução; inclui informações recebida de sensores de bordo e de mensagens CAM e DENM (ETSI TR 102 893) [5]

Controlo do protocolo

Os instrumentos de controlo do protocolo selecionam o protocolo de transferência de mensagens adequado para um pedido de mensagem enviado e enviam a mensagem às camadas inferiores da pilha de protocolos, num formato que pode ser processado por essas camadas. As mensagens recebidas são convertidas num formato que pode ser tratado no âmbito da estação STIC e transferido para o instrumento funcional pertinente, para posterior processamento (ETSI TR 102 893) [5]

1.3.Estratégia para a segurança da informação

1.3.1.Sistema de gestão da segurança das informações (Information security management system, «ISMS»)

(1)Cada operador de estação STIC deve gerir um ISMS em conformidade com a norma ISO/IEC 27001 e com as restrições e os requisitos adicionais estabelecidos na presente secção.

(2)Cada operador de estação STIC deve determinar as questões externas e internas pertinentes para a estação STIC, incluindo:

·COM(2016) 766 final [10],

·o RGPD (Regulamento Geral sobre a Proteção de Dados) [6].

(3)Cada operador de estação STIC deve determinar as partes pertinentes para o ISMS e respetivos requisitos, incluindo todas as partes interessadas nos STIC.

(4)O âmbito do ISMS deve incluir todas as estações STIC exploradas e todos os outros sistemas de processamento da informação que processam dados STIC sob a forma de mensagens STIC conformes às seguintes normas:

·CAM [7]

·DENM [8]

·IVIM [9]

·SPATEM [9]

·MAPEM [9]

·SSEM [9]

·SREM [9]

(5)Cada operador de estação STIC deve assegurar que a sua política de segurança da informação é coerente com a presente política.

(6)Cada operador de estação STIC deve assegurar que os seus objetivos de segurança da informação incluem e são coerentes com os objetivos de segurança e os requisitos de alto nível da presente política.

(7)Os operadores de estação STIC devem classificar as informações referidas na secção 1.4.

(8)Os operadores de estações STIC devem aplicar o processo de avaliação do risco de segurança da informação, tal como estabelecido na secção 1.5, periodicamente ou quando forem propostas ou ocorrerem alterações significativas.

(9)Os operadores de estações STIC e/ou os fabricantes de estações STIC devem determinar os requisitos de atenuação dos riscos de segurança identificados no processo de avaliação do risco de segurança da informação, em consonância com a secção 1.6.

(10)Os fabricantes de estações STIC devem conceber, desenvolver e avaliar as estações STIC e outros sistemas de processamento da informação, de modo a assegurar que estes cumprem os requisitos aplicáveis.

(11)Os operadores de estações STIC devem explorar as estações STIC e todos os outros sistemas de processamento da informação que apliquem controlos adequados do risco em matéria de segurança da informação, em conformidade com a secção 1.6.

1.4.Classificação da informação

A presente secção estabelece os requisitos mínimos para a classificação da informação. Tal não impede que as partes interessadas nos STIC apliquem requisitos mais rigorosos.

(12)Os operadores de estações STIC devem classificar a informação tratada em categorias de segurança que podem ser representadas como se segue:

Categoria de segurança da informação = {(confidencialidade, impacto), (integridade, impacto), (disponibilidade, impacto)};

(13)As partes interessadas nos STIC devem classificar a informação gerida em sistemas de categorias de segurança que podem ser representados como se segue:

Sistema de categorias de segurança da informação = {(confidencialidade, impacto), (integridade, impacto), (disponibilidade, impacto)};

(14)Os valores aceitáveis para o impacto potencial são baixo, moderado e elevado, tal como resumido no quadro 1.

Quadro 1: «Definições de impacto potencial» para cada objetivo de segurança, no que respeita a confidencialidade, integridade e disponibilidade

Impacto potencial

Objetivo de segurança

BAIXO

MODERADO

ELEVADO

Confidencialidade

Preservar as restrições autorizadas em matéria de acesso e divulgação da informação, incluindo meios de proteção da privacidade pessoal e da informação protegida

A divulgação não autorizada da informação poderá ter um efeito adverso limitado nas operações organizacionais, nos ativos organizacionais ou nas pessoas.

A divulgação não autorizada da informação poderá ter um efeito adverso grave nas operações organizacionais, nos ativos organizacionais ou nas pessoas.

A divulgação não autorizada da informação poderá ter um efeito adverso grave ou catastrófico nas operações organizacionais, nos ativos organizacionais ou nas pessoas.

Integridade

Proteger contra a modificação ou destruição indevida da informação; tal inclui garantir a não repudiação e a autenticidade da informação

A modificação ou destruição não autorizadas da informação poderão ter um efeito adverso limitado nas operações organizacionais, nos ativos organizacionais ou nas pessoas.

A modificação ou destruição não autorizadas da informação poderão ter um efeito adverso grave nas operações organizacionais, nos ativos organizacionais ou nas pessoas.

A modificação ou destruição não autorizadas da informação poderão ter um efeito adverso grave ou catastrófico nas operações organizacionais, nos ativos organizacionais ou nas pessoas.

Disponibilidade

Garantir o acesso e a utilização atempados e fiáveis à informação

A perturbação do acesso ou da utilização da informação ou de um sistema de informação poderão ter um efeito negativo limitado nas operações organizacionais, nos ativos organizacionais ou nas pessoas.

A perturbação do acesso ou da utilização da informação ou de um sistema de informação poderão ter um efeito negativo grave nas operações organizacionais, nos ativos organizacionais ou nas pessoas.

A perturbação do acesso ou da utilização da informação ou de um sistema de informação poderão ter um efeito negativo grave ou catastrófico nas operações organizacionais, nos ativos organizacionais ou nas pessoas.

(15)Os seguintes tipos de impacto da classificação da informação devem ser considerados em termos do grau de danos ou custos para os serviços STIC e as partes interessadas nos STIC causados por um incidente de segurança da informação:

·segurança rodoviária — quando o impacto coloca os utentes da estrada em risco iminente de ferimentos,

·segurança — quando o impacto coloca qualquer uma das partes interessadas nos STIC em risco iminente de ferimentos,

·impactos operacionais — quando o impacto na eficiência do tráfego rodoviário é substancialmente negativo, ou outro impacto societal, como a pegada ambiental e a criminalidade organizada,

·jurídico — quando o impacto resulta numa ação de conformidade jurídica e/ou regulamentar significativa contra uma ou mais partes interessadas nos STIC,

·financeiro — quando o impacto resulta em custos monetários diretos ou indiretos para uma ou mais partes interessadas nos STIC,

·privacidade — impacto jurídico e financeiro do RGPD,

·reputação — quando o impacto resulta em danos para a reputação de uma ou mais partes interessadas nos STIC e/ou na rede STIC, por exemplo, cobertura mediática negativa e/ou grande pressão política a nível nacional ou internacional.

(16)As partes interessadas nos STIC devem respeitar os valores de impacto mínimos que se seguem nas informações tratadas:

Quadro 2: Impactos

Informação proveniente de
estações STIC fixas

Informação proveniente de
estações STIC móveis

Confidencialidade

CAM: baixo

DENM: baixo

IVIM: baixo

MAPEM: baixo

SPATEM: baixo

SSEM: baixo

CAM: baixo

DENM: baixo

SREM: baixo

Dados pessoais contidos em qualquer uma das três mensagens: moderado

Integridade

CAM: moderado

DENM: moderado

IVIM: moderado

MAPEM: moderado

SPATEM: moderado

SSEM: moderado

CAM: moderado

DENM: moderado

SREM: moderado

Disponibilidade

CAM: baixo

DENM: baixo

IVIM: baixo

MAPEM: baixo

SPATEM: baixo

SSEM: moderado

CAM: baixo

DENM: baixo

SREM: moderado

1.5.Avaliação do risco

1.5.1.Aspetos gerais

(17)A avaliação do risco deve ser efetuada periodicamente em conformidade com a norma ISO/IEC 27005. Deve incluir documentação adequada sobre:

·o âmbito da avaliação do risco, ou seja, o sistema avaliado, respetivos limites e finalidade, e a informação que é tratada,

·critérios de risco para a segurança,

·avaliação do risco, incluindo identificação, análise e avaliação.

1.5.2.Critérios de risco para a segurança

(18)Os critérios de avaliação do risco devem ser determinados tendo em conta os seguintes aspetos:

·o valor estratégico do serviço STIC e da rede STIC para todas as partes interessadas nos STIC,

·o valor estratégico do serviço STIC e da rede STIC para o operador da estação STIC do serviço,

·as consequências para a reputação da rede STIC,

·os requisitos jurídicos e regulamentares, e as obrigações contratuais.

(19)Os critérios de impacto do risco devem ser determinados à luz dos tipos de impacto da classificação da informação referidos na secção 1.4.

(20)Os critérios de aceitação do risco devem incluir a identificação dos níveis do risco inaceitáveis para os serviços STIC e as partes interessadas nos STIC, por tipo de impacto.

1.5.2.1.Identificação do risco

(21)Os riscos devem ser identificados em conformidade com a norma ISO/IEC 27005. Aplicamse os seguintes requisitos mínimos:

·os principais ativos a proteger são as mensagens STIC referidas na secção 1.3.1,

·os ativos de apoio devem ser identificados, incluindo:

·informação utilizada nas mensagens STIC (por exemplo, mapa local dinâmico, hora, controlo do protocolo, etc.),

·as estações STIC e os seus software, dados de configuração e canais de comunicação associados,

·ativos de controlo de STIC centrais,

·todas as entidades do EU CCMS,

·as ameaças a esses ativos e respetivas fontes devem ser identificadas,

·os controlos existentes e previstos devem ser identificados,

·as vulnerabilidades que possam ser exploradas por ameaças, a fim de causar danos aos ativos ou às partes interessadas nos STIC devem ser identificadas e descritas como cenários de incidentes,

·as eventuais consequências de incidentes de segurança nos ativos devem ser identificadas com base na classificação da informação.

1.5.2.2.Análise do risco

(22)Aplicamse os seguintes requisitos mínimos à análise de risco:

·o impacto dos incidentes de segurança da informação identificados nos serviços STIC e nas partes interessadas nos STIC deve ser avaliado com base na informação e na categoria de segurança do sistema de informação, utilizando, pelo menos, os três níveis estabelecidos na secção 1.4,

·os níveis de impacto devem ser identificados no que respeita:

·à totalidade da rede/dos serviços STIC existentes, e

·a uma parte interessada/entidade organizacional nos STIC individual,

·o nível mais elevado será considerado como o impacto total,

·a probabilidade de ocorrência dos cenários de incidentes identificados deve ser avaliada utilizando, pelo menos, os três níveis seguintes:

·improvável (valor 1) — o cenário de incidente não é suscetível de ocorrer/difícil de executar ou a motivação para a intrusão é muito baixa,

·possível (valor 2) — o cenário de incidente pode ocorrer/ser executado ou a motivação para a intrusão é razoável,

·provável (valor 3) — o cenário do incidente é suscetível de ocorrer/fácil de executar e a motivação para a intrusão é elevada,

·os níveis de risco devem ser determinados para todos os cenários de incidente identificados, com base no impacto e na probabilidade do produto, de que resultam pelo menos os seguintes níveis de risco: baixo (valores 1,2), moderado (valores 3,4) e elevado (valores 6,9), definidos do seguinte modo:

Quadro 3: Níveis de risco

Níveis de risco enquanto produto do impacto e da probabilidade

Probabilidade

improvável (1)

possível (2)

provável (3)

Impacto

baixo (1)

baixo (1)

baixo (2)

moderado (3)

moderado (2)

baixo (2)

moderado (4)

elevado (6)

elevado (3)

moderado (3)

elevado (6)

elevado (9)

1.5.2.3.Avaliação do risco

(23)Os níveis de risco devem ser comparados com critérios de avaliação do risco e critérios de aceitação do risco, a fim de determinar quais os riscos que devem ser sujeitos a tratamento. Devem ser tratados, pelo menos, os riscos de nível moderado ou elevado aplicáveis aos serviços STIC e à rede STIC, em conformidade com a secção 1.6.

1.6.Tratamento do risco

1.6.1.Aspetos gerais

(24)Os riscos devem ser tratados de uma das seguintes formas:

·a alteração do risco através da utilização dos controlos identificados nas secções 1.6.2 ou 1.6.3, de modo a que o risco residual possa ser reavaliado como aceitável,

·retenção de risco (quando o nível de risco cumpre os critérios de aceitação do risco),

·prevenção do risco.

(25)A partilha ou transferência do risco não é permitida para riscos para a rede STIC.

(26)O tratamento de risco deve ser documentado e incluir:

·a declaração de aplicabilidade em conformidade com a norma ISO 27001, que estabelece os controlos necessários e determina:

·a probabilidade residual de ocorrência,

·a gravidade residual do impacto,

·o nível de risco residual,

·as razões da retenção ou da prevenção dos riscos.

1.6.2.Controlos relativos às estações STIC

1.6.2.1.Controlos genéricos

(27)As estações STIC devem aplicar contramedidas adequadas para alterar o risco, em conformidade com a secção 1.6.1. Essas contramedidas devem aplicar controlos genéricos, tal como definidos nas normas ISO/IEC 27001 e ISO/IEC 27002.

1.6.2.2.Controlos relativos às comunicações entre estações STIC

(28)Do lado recetor, devem ser estabelecidos os seguintes controlos obrigatórios mínimos:

Quadro 4: Controlos do lado emissor

Informação proveniente de
estações STIC fixas

Informação proveniente de
estações STIC móveis

Confidencialidade

Os dados pessoais contidos nas mensagens devem ser securizados através de um procedimento de alteração CA adequado, a fim de garantir um nível de segurança adequado ao risco de reidentificação dos condutores, com base nos dados que transmitiram. Por conseguinte, as estações STIC devem alterar os CA de forma adequada, ao enviarem mensagens, e não devem reutilizar CA após uma alteração, exceto nos casos em que os condutores não tenham um comportamento de condução médio 1 .

Integridade

Todas as mensagens devem ser assinadas em conformidade com a TS 103 097 [14].

Todas as mensagens devem ser assinadas em conformidade com a TS 103 097 [14].

Disponibilidade

(29)Do lado recetor, devem ser estabelecidos os seguintes controlos obrigatórios mínimos:

Quadro 5: Controlos do lado recetor

Informação proveniente de
estações STI
C fixas

Informação proveniente de
estações STI
C móveis

Confidencialidade

Os dados pessoais recebidos devem ser conservados por um período tão curto quanto possível, para fins profissionais, durante um período máximo de retensão de cinco minutos, no caso dos elementos de dados brutos e identificáveis.

Uma CAM ou SRM recebidas não devem ser transmitidas/divulgadas.

Uma DENM recebida só pode ser transmitida/divulgada numa zona geográfica limitada.

Integridade

A integridade de todas as mensagens utilizadas pelas aplicações STI deve ser validada em conformidade com a norma TS 103 097 [14].

A integridade de todas as mensagens utilizadas pelas aplicações STI deve ser validada em conformidade com a norma TS 103 097 [14].

Disponibilidade

As SRM recebidas devem ser processadas e produzir uma emissão SSM para o remetente da SMR.

(30)A fim de apoiar os requisitos de segurança em matéria de confidencialidade, integridade e disponibilidade estabelecidos nos quadros supra, todas as estações STIC [estações de STIC móveis (incluindo estações STIC de bordo) e estações STIC fixas] devem ser avaliadas e certificadas utilizando os critérios de avaliação da segurança especificados nos «Critérios Comuns»/na norma ISO 15408 2 . Devido às diferentes características dos diferentes tipos de estações STIC e aos diferentes requisitos de privacidade de localização, podem ser definidos perfis de proteção diferentes.

(31)Todos os perfis de proteção e documentos conexos aplicáveis para a certificação de segurança das estações STIC devem ser avaliados, validados e certificados em conformidade com a norma ISO 15408, aplicando o Acordo de Reconhecimento Mútuo de Certificados de Avaliação da Segurança da Tecnologia da Informação do Grupo de Altos Funcionários para a Segurança dos Sistemas de Informação (SOGIS) 3 ou um sistema europeu de certificação da cibersegurança equivalente ao abrigo do quadro europeu de cibersegurança pertinente. Ao desenvolver esses perfis de proteção, o âmbito da certificação de segurança da estação STIC pode ser definido pelo fabricante, sob reserva da avaliação e da aprovação da CPA e de um organismo de avaliação da conformidade SOGIS ou, pelo menos, equivalente, como descrito no parágrafo que se segue.

(32)Dada a importância de manter o nível de segurança mais elevado possível, os certificados de segurança das estações STIC devem ser emitidos ao abrigo do regime de certificação de critérios comuns (ISO 15408) por um organismo de avaliação da conformidade reconhecido pelo comité de gestão no âmbito do Acordo SOGIS, ou emitidos por um organismo de avaliação da conformidade acreditado por uma autoridade nacional de certificação da cibersegurança de um EstadoMembro. Esse organismo de avaliação da conformidade deve fornecer, pelo menos, condições equivalentes de avaliação da segurança às previstas no Acordo de Reconhecimento Mútuo SOGIS.

1.6.2.3.Controlos relativos às estações STIC enquanto entidades finais

(33)As estações STIC devem cumprir a política de certificação [1] em conformidade com o seu papel enquanto entidade final do EU CCMS.

1.6.3.Controlos relativos aos participantes no EU CCMS

(34)Os participantes no EU CCMS devem cumprir a política de certificação [1] em conformidade com o seu papel no EU CCMS.

1.7.Conformidade com a presente política de segurança

(35)Os operadores de estações STIC devem solicitar periodicamente e obter a certificação da conformidade com a presente política, de acordo com as diretrizes para uma auditoria ISO 27001 em [12].

(36)O organismo de auditoria deve ser acreditado e certificado por um membro da Acreditação Europeia. Deve cumprir os requisitos de [11].

(37)Com o objetivo de obter a certificação, os operadores de estações STIC devem gerar e manter documentos relativos aos requisitos em matéria de informações documentadas em [3], cláusula 7.5. Em especial, os operadores de estações STIC devem gerar e conservar os seguintes documentos relacionados com o ISMS:

·âmbito de aplicação do ISMS (secção 1.3.1 e [3], cláusula 4.3),

·política e objetivos em matéria de segurança da informação (secção 1.3.1 e [3], cláusulas 5.2 e 6.2),

·Informações pormenorizadas sobre avaliação do risco e metodologia de tratamento do risco (secção 1.5 e [3], cláusula 6.1.2),

·relatório de avaliação do risco (secção 1.5 e [3], cláusula 8.2),

·declaração de aplicabilidade (secção 1.6 e [3], cláusula 6.1.3d),

·plano de tratamento de risco (secções 1.6 e [3], pontos 6.1.3e e 8.3),

·documentos necessários para a implementação dos controlos selecionados (secção 1.6 e [3], anexo A).

(38)Além disso, os operadores de estações STIC devem gerar e conservar os seguintes registos como prova dos resultados obtidos:

·registos de formação, competências, experiência e qualificações ([3], cláusula 7.2),

·resultados de monitorização e medição ([3], cláusula 9.1),

·programa de auditoria interna ([3], cláusula 9.2),

·resultados das auditorias internas ([3], cláusula 9.2),

·resultados da análise da gestão ([3], cláusula 9.3),

·resultados das medidas corretivas ([3], cláusula 10.1).

2.Referências

No presente anexo, utilizamse as seguintes referências:

[1]

Anexo III do presente regulamento

[2]

ISO/IEC 27000 (2016): Information technology – security techniques – information security management systems – overview and vocabulary (Tecnologias de informação — Técnicas de Segurança — Sistemas de gestão da segurança da informação — Visão geral e vocabulário)

[3]

ISO/IEC 27001 (2015): Tecnologias de informação — Técnicas de Segurança — Sistemas de gestão da segurança da informação — Requisitos

[4]

ISO/IEC 27005 (2011): Information technology – security techniques – information security risk management (Tecnologias de informação — Técnicas de Segurança — Gestão do risco para a segurança da informação)

[5]

ETSI TR 102 893 V1.2.1, Intelligent transport systems (ITS) – security; vulnerability and risk analysis (TVRA) [Sistemas de transporte inteligentes (STI) — Segurança; análise das ameaças, da vulnerabilidade e do risco (TVRA)]

[6]

Regulamento (UE) 2016/679 do Parlamento Europeu e do Conselho, de 27 de abril de 2016, relativo à proteção das pessoas singulares no que diz respeito ao tratamento de dados pessoais e à livre circulação desses dados e que revoga a Diretiva 95/46/CE (Regulamento Geral sobre a Proteção de Dados)

[7]

ETSI EN 302 6372 V1.4.0, Intelligent transport systems (ITS) – Vehicular communications; Basic set of applications [Sistemas de transporte inteligentes (STI) — Comunicações em veículos; Conjunto básico de aplicações], Part 2: Specification of cooperative awareness basic service (Parte 2: Especificação do serviço básico de perceção cooperativa)

[8]

ETSI EN 302 6373 V1.3.0, Intelligent transport systems (ITS) – Vehicular communications; Basic set of applications [Sistemas de transporte inteligentes (STI) — Comunicações em veículos; Conjunto básico de aplicações], Part 3: Specifications of decentralised environmental notification basic service (Parte 3: Especificações do serviço básico de notificação ambiental descentralizada)

[9]

ETSI TS 103 301 V1.2.1: Intelligent transport systems (ITS) – Vehicular communications; Basic set of applications; Facilities layer protocols and communication requirements for infrastructure services [Sistemas de transporte inteligentes (STI) — Comunicações em veículos; Conjunto básico de aplicações; Protocolos com camada de serviços e requisitos de comunicação aplicáveis aos serviços de infraestrutura]

[10]

Uma estratégia europeia relativa aos sistemas cooperativos de transporte inteligentes, uma etapa rumo a uma mobilidade cooperativa, conectada e automatizada [COM(2016) 766 de 30 de novembro de 2016]

[11]

ISO/IEC 27006:2015 Information technology — Security techniques — Requirements for bodies providing audit and certification of information security management systems (Tecnologias de Informação — Técnicas de Segurança — Requisitos para organismos que fornecem auditoria e certificação dos sistemas de gestão da segurança da informação)

[12]

ISO/IEC 27007:2011 Information technology — Security techniques — Guidelines for information security management systems auditing (Tecnologias de Informação — Técnicas de Segurança — Orientações para a auditoria de sistemas de gestão da segurança da informação)

[13]

ETSI EN 302 665 V1.1.1 Intelligent transport systems (ITS); Communications architecture [Sistemas de transporte inteligentes (ITS); Arquitetura das comunicações]

[14]

ETSI TS 103 097 V1.3.1. Intelligent transport systems (ITS) security; security header and certificate formats [Segurança dos sistemas de transporte inteligentes (STI); cabeçalho de segurança e formato do certificado]

(1)    A definição de comportamento de condução médio deve basear-se na análise estatística pertinente do comportamento de condução na União Europeia, por exemplo, com base em dados do Centro Aeroespacial Alemão («DLR»).
(2)    Portal «Critérios Comuns»: http://www.commoncriteriaportal.org/cc/
(3)    No setor dos transportes rodoviários, o SOG-IS já esteve envolvido na certificação da segurança do tacógrafo inteligente, por exemplo. O acordo SOG-IS é atualmente o único regime na Europa que pode apoiar a harmonização da certificação de segurança dos produtos eletrónicos. Na presente fase, o SOGIS apoia apenas o processo relativo aos «Critérios Comuns», pelo que as estações STI-C devem ser avaliadas e certificadas de acordo com os «Critérios Comuns»; ver https://www.sogis.org/
Início

ANEXO V

PARTE A

PROCEDIMENTOS DE AVALIAÇÃO DA CONFORMIDADE

Módulo A

Controlo interno da produção

1.O controlo interno da produção é o procedimento de avaliação da conformidade através do qual o fabricante cumpre as obrigações estabelecidas nos pontos 2, 3 e 4, e garante e declara, sob a sua exclusiva responsabilidade, que as estações STIC em causa cumprem os requisitos do presente regulamento que lhe são aplicáveis.

2.Documentação técnica

O fabricante deve elaborar a documentação técnica que permita avaliar a conformidade da estação STIC com os requisitos pertinentes e incluir uma análise e uma avaliação do(s) risco(s) adequadas. A documentação deve especificar os requisitos aplicáveis e abranger, se tal for pertinente para a avaliação, o projeto, o fabrico e o funcionamento do produto. Consoante o caso, deve incluir, pelo menos:

uma descrição geral da estação STIC,

os desenhos de projeto e de fabrico e esquemas de componentes, subconjuntos, circuitos, etc.

as descrições e explicações necessárias para a compreensão dos referidos desenhos e esquemas, e do funcionamento da estação STIC,

uma lista das normas harmonizadas e/ou de outras especificações técnicas pertinentes cujas referências tenham sido publicadas no Jornal Oficial da União Europeia, ou normas internacionais, aplicadas total ou parcialmente, e descrições das soluções adotadas para cumprir o disposto no presente regulamento, sempre que essas normas harmonizadas não tiverem sido aplicadas. Sempre que as normas harmonizadas tiverem sido parcialmente aplicadas, a documentação técnica deve especificar quais as partes que foram aplicadas,

os resultados dos cálculo de projeto, análises, etc., e

os relatórios relativos aos ensaios.

3.Fabrico

O fabricante deve tomar todas as medidas necessárias para que o processo de fabrico e o respetivo controlo garantam a conformidade das estações STIC com a documentação técnica referida no ponto 2 e com os requisitos dos instrumentos legislativos que lhes são aplicáveis.

4.Marcação de conformidade e declaração de conformidade

4.1.O fabricante deve apor a marcação de conformidade exigida pelo presente regulamento em cada estação STIC individual que cumpra os requisitos aplicáveis do presente regulamento.

4.2.O fabricante deve elaborar uma declaração de conformidade escrita para um modelo do produto e mantêla, com a documentação técnica, à disposição das autoridades nacionais, por um período de dez anos a contar da data de colocação no mercado do produto. A declaração de conformidade deve identificar a estação STIC para a qual foi elaborada.

Deve ser fornecida às autoridades competentes, a pedido destas, uma cópia da declaração.

5.Mandatário

As obrigações do fabricante, tal como enunciadas no ponto 4, podem ser cumpridas, em seu nome e sob a sua responsabilidade, pelo seu mandatário, desde que se encontrem especificadas no mandato.


PARTE B

DECLARAÇÃO CE DE CONFORMIDADE

1.N.º (número de identificação único da estação STIC): ...

2.Nome e endereço do fabricante ou do seu mandatário: ...

3.A presente declaração de conformidade é emitida sob a exclusiva responsabilidade do fabricante (ou instalador): ...

4.Objeto da declaração (identificação da estação STIC que permita rastreála; pode incluir uma fotografia, se for caso disso): ...

5.O objeto da presente declaração está em conformidade com a legislação da União pertinente em matéria de harmonização: ...

6.Referências às normas harmonizadas pertinentes utilizadas ou referências às demais especificações em relação às quais é declarada a conformidade: ...

8.Informações adicionais: ...

Assinado em nome de: ………………………….

(local e data de emissão)

(nome, cargo) (assinatura)


PARTE C

ESTAÇÕES STIC CENTRAIS: PROCEDIMENTOS DE AVALIAÇÃO DA CONFORMIDADE

Módulo A

Controlo interno da produção

1.O controlo interno da produção é o procedimento de avaliação da conformidade através do qual o operador cumpre as obrigações estabelecidas nos pontos 2, 3 e 4, e garante e declara, sob a sua exclusiva responsabilidade, que as estações STIC centrais em causa cumprem os requisitos do presente regulamento que lhe são aplicáveis.

2.Documentação técnica

O operador deve elaborar a documentação técnica que permita avaliar a conformidade da estação STIC central com os requisitos pertinentes e incluir uma análise e uma avaliação do(s) risco(s) adequadas. A documentação deve especificar os requisitos aplicáveis e abranger, se tal for pertinente para a avaliação, o projeto, o fabrico e o funcionamento do produto. Consoante o caso, deve incluir, pelo menos:

uma descrição geral da estação STIC central,

os desenhos de projeto e de fabrico e esquemas de componentes, subconjuntos, circuitos, etc.

as descrições e explicações necessárias para a compreensão dos referidos desenhos e esquemas, e do funcionamento da estação STIC central,

uma lista das normas harmonizadas e/ou de outras especificações técnicas pertinentes cujas referências tenham sido publicadas no Jornal Oficial da União Europeia, ou normas internacionais, aplicadas total ou parcialmente, e descrições das soluções adotadas para cumprir o disposto no presente regulamento, sempre que essas normas harmonizadas não tiverem sido aplicadas. Sempre que as normas harmonizadas tiverem sido parcialmente aplicadas, a documentação técnica deve especificar quais as partes que foram aplicadas,

os resultados dos cálculo de projeto, análises, etc., e

os relatórios relativos aos ensaios.

4.Declaração de conformidade

O operador deve elaborar uma declaração de conformidade escrita para um modelo do produto e mantêla, com a documentação técnica, à disposição das autoridades nacionais, enquanto a estação STIC estiver em funcionamento. A declaração de conformidade deve identificar a estação STIC central para a qual foi elaborada.

Deve ser fornecida às autoridades competentes, a pedido destas, uma cópia da declaração.

5.Mandatário

As obrigações do operador, tal como enunciadas no ponto 4, podem ser cumpridas, em seu nome e sob a sua responsabilidade, pelo seu mandatário, desde que se encontrem especificadas no mandato.

PARTE D

ESTAÇÕES STIC CENTRAIS: DECLARAÇÃO CE DE CONFORMIDADE

1.N.º (número de identificação único da estação STIC): ...

2.Nome e endereço do operador ou do seu mandatário: ...

3.A presente declaração de conformidade é emitida sob a exclusiva responsabilidade do operador: ...

4.Objeto da declaração (identificação da estação STIC central que permita rastreála): ...

5.O objeto da presente declaração está em conformidade com a legislação da União pertinente em matéria de harmonização: ...

6.Referências às normas harmonizadas pertinentes utilizadas ou referências às demais especificações em relação às quais é declarada a conformidade: ...

8.Informações adicionais: ...

Assinado em nome de: ………………………….

(local e data da emissão)

(nome, cargo) (assinatura)

Início