Use quotation marks to search for an "exact phrase". Append an asterisk (*) to a search term to find variations of it (transp*, 32019R*). Use a question mark (?) instead of a single character in your search term to find variations of it (ca?e finds case, cane, care).
Commission Implementing Regulation (EU) 2018/502 of 28 February 2018 amending Implementing Regulation (EU) 2016/799 laying down the requirements for the construction, testing, installation, operation and repair of tachographs and their components (Text with EEA relevance)
Regulamento de Execução (UE) 2018/502 da Comissão, de 28 de fevereiro de 2018, que altera o Regulamento de Execução (UE) 2016/799 que estabelece os requisitos para construção, ensaio, instalação, funcionamento e reparação de tacógrafos e seus componentes (Texto relevante para efeitos do EEE)
Regulamento de Execução (UE) 2018/502 da Comissão, de 28 de fevereiro de 2018, que altera o Regulamento de Execução (UE) 2016/799 que estabelece os requisitos para construção, ensaio, instalação, funcionamento e reparação de tacógrafos e seus componentes (Texto relevante para efeitos do EEE)
C/2018/1116
JO L 85 de 28.3.2018, pp. 1–71
(BG, ES, CS, DA, DE, ET, EL, EN, FR, HR, IT, LV, LT, HU, MT, NL, PL, PT, RO, SK, SL, FI, SV)
que altera o Regulamento de Execução (UE) 2016/799 que estabelece os requisitos para construção, ensaio, instalação, funcionamento e reparação de tacógrafos e seus componentes
(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 o Regulamento (UE) n.o 165/2014 do Parlamento Europeu e do Conselho, de 4 de fevereiro de 2014, relativo à utilização de tacógrafos nos transportes rodoviários (1), nomeadamente o artigo 11.o e o artigo 12.o, n.o 7,
Considerando o seguinte:
(1)
O Regulamento (UE) n.o 165/2014 introduziu os tacógrafos inteligentes, constituídos pelos tacógrafos digitais de segunda geração, que incluem uma ligação ao sistema global de navegação por satélite («GNSS»), um sistema de comunicação à distância para efeitos de deteção rápida e uma interface facultativa com sistemas de transporte inteligentes.
(2)
Os requisitos técnicos para construção, ensaio, instalação, funcionamento e reparação de tacógrafos e seus componentes constam do Regulamento de Execução (UE) 2016/799 da Comissão (2).
(3)
Em conformidade com os artigos 8.o, 9.o e 10.o do Regulamento (UE) n.o 165/2014, os tacógrafos instalados em veículos registados pela primeira vez em 15 de junho de 2019 ou em data posterior devem ser tacógrafos inteligentes. O Regulamento de Execução (UE) 2016/799 deve, por conseguinte, ser alterado a fim de que as disposições técnicas nele estabelecidas sejam aplicadas a partir dessa data.
(4)
Por forma a cumprir o disposto no artigo 8.o do Regulamento (UE) n.o 165/2014, que estabelece que a posição do veículo deve ser registada de três em três horas de tempo de condução acumulado, o Regulamento de Execução (UE) 2016/799 deve ser alterado a fim de permitir que as informações relativas à posição do veículo sejam armazenadas com uma frequência de três horas, utilizando um parâmetro que não possa ser reiniciado, e para evitar a confusão com o «tempo de condução contínua», que constitui um parâmetro com uma função diferente.
(5)
A unidade pode ser única ou consistir em diversas unidades distribuídas pelo veículo. Os módulos GNSS e as Comunicações Dedicadas de Curto Alcance («DSRC») poderiam, portanto, ser internos ou externos ao corpo principal da unidade-veículo. Quando forem externos, deveria ser possível que tanto os sistemas quanto o corpo principal da unidade-veículo pudessem ser homologados como componentes, de maneira a adaptar o processo de homologação dos tacógrafos inteligentes às necessidades do mercado.
(6)
As regras relativas à memorização de incidentes de conflito de tempo e de ajustamentos do tempo devem ser alteradas, de maneira a fazer a distinção entre os ajustamentos do tempo automáticos desencadeados na sequência de uma possível tentativa de adulteração e os ajustamentos do tempo que se devem a outras razões, como, por exemplo, manutenção.
(7)
Os identificadores de dados devem ser capazes de fazer a distinção entre os dados descarregados de um tacógrafo inteligente e os dados descarregados de um tacógrafo de uma geração anterior.
(8)
O período de validade do cartão de empresa deve ser prorrogado por dois a cinco anos, de maneira a equipará-lo ao período de validade do cartão de condutor.
(9)
A descrição de determinadas falhas e incidentes, a validação da introdução do lugar de início e/ou de final do período diário de trabalho, a utilização do consentimento do condutor para a interface com sistemas de transporte inteligentes («ITS») relativa a dados transmitidos pela unidade-veículo através da rede do veículo e outras questões de ordem técnica deveriam ser mais bem definidas.
(10)
A fim de garantir que a certificação dos selos tacográficos se encontra atualizada, estes precisam de ser ajustados à nova norma de segurança dos selos mecânicos utilizados nos tacógrafos.
(11)
O presente regulamento diz respeito à construção, ao ensaio, à instalação e à operação de sistemas que se compõem igualmente de equipamentos de rádio regulados pela Diretiva 2014/53/UE do Parlamento Europeu e do Conselho (3). Essa diretiva regula a colocação no mercado e a entrada em serviço de equipamentos elétricos e eletrónicos que fazem uso das ondas hertzianas para fins de radiocomunicação e/ou radiodeterminação ao nível horizontal, tendo em conta, muito particularmente, a segurança elétrica, a compatibilidade com outros sistemas, o acesso ao espetro de radiofrequências, o acesso aos serviços de emergência e/ou quaisquer outras disposições delegadas adicionais. Por forma a garantir uma utilização eficiente do espetro de radiofrequências, de maneira a evitar as interferências prejudiciais, para garantir a segurança e a compatibilidade eletromagnética dos equipamentos de rádio e para permitir quaisquer outros requisitos delegados específicos, o presente regulamento não deve prejudicar o disposto naquela diretiva.
(12)
Por conseguinte, o Regulamento de Execução (UE) 2016/799 deve ser alterado.
(13)
As medidas previstas no presente regulamento estão em conformidade com o parecer do comité a que se refere o artigo 42.o, n.o 3, do Regulamento (UE) n.o 165/2014,
ADOTOU O PRESENTE REGULAMENTO:
Artigo 1.o
O Regulamento de Execução (UE) 2016/799 é alterado do seguinte modo:
1)
O artigo 1.o é alterado do seguinte modo:
a)
Os n.os 2 e 3 passam a ter a seguinte redação:
«2. A construção, o ensaio, a instalação, a inspeção, o funcionamento e a reparação de tacógrafos inteligentes e dos respetivos componentes devem cumprir os requisitos técnicos constantes do anexo IC do presente regulamento.
3. No que respeita à construção, ao ensaio, à instalação, à inspeção, ao funcionamento e à reparação, os tacógrafos, com exceção dos tacógrafos inteligentes, devem continuar a cumprir os requisitos do anexo I do Regulamento (UE) n.o 165/2014 ou do anexo I-B do Regulamento (CEE) n.o 3821/85 do Conselho (*1), consoante o que for aplicável.
(*1) Regulamento (CEE) n.o 3821/85 do Conselho, de 20 de dezembro de 1985, relativo à introdução de um aparelho de controlo no domínio dos transportes rodoviários (JO L 370 de 31.12.1985, p. 8).»
"
b)
É aditado o seguinte n.o 5:
«5. O presente regulamento não prejudica a aplicação da Diretiva 2014/53/UE do Parlamento Europeu e do Conselho (*2).
(*2) Diretiva 2014/53/UE do Parlamento Europeu e do Conselho, de 16 de abril de 2014, relativa à harmonização da legislação dos Estados-Membros 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).»
"
2)
O artigo 2.o é alterado do seguinte modo:
a)
A definição constante do ponto 3) passa a ter a seguinte redação:
«3)
“dossiê de fabrico”: o dossiê completo, em formato eletrónico ou em papel, que contém todas as informações fornecidas pelo fabricante ou pelo seu mandatário à autoridade de homologação para efeitos da homologação de tacógrafos ou de componentes, incluindo os certificados referidos no artigo 12.o, n.o 3, do Regulamento (UE) n.o 165/2014, o resultado dos ensaios definidos no anexo IC do presente regulamento, assim como desenhos, fotografias e outros documentos pertinentes;»;
b)
A definição constante do ponto 7) passa a ter a seguinte redação:
«7)
“tacógrafo inteligente” ou “tacógrafo da segunda geração”: o tacógrafo digital que cumpre o prescrito nos artigos 8.o, 9.o e 10.o do Regulamento (UE) n.o 165/2014, bem como no anexo IC do presente regulamento;»;
c)
A definição constante do ponto 8) passa a ter a seguinte redação:
«8)
“componente do tacógrafo”: qualquer um dos seguintes elementos: unidade-veículo, sensor de movimentos, cartão tacográfico, folha de registo, módulo GNSS externo e sistema de deteção rápida à distância;»;
d)
É aditada a seguinte definição no ponto 10):
«10)
“unidade-veículo”: o tacógrafo, excluindo o sensor de movimentos e os cabos que o ligam.
A unidade pode ser única ou consistir em diversas unidades distribuídas pelo veículo, e inclui uma unidade de processamento, uma memória de dados, uma função de medição do tempo, duas interfaces para cartões inteligentes (condutor e ajudante), uma impressora, um ecrã de visualização, conectores e instrumentos para a introdução de dados do utilizador, um recetor GNSS e um módulo de comunicação à distância.
A unidade-veículo pode ser composta pelos seguintes componentes, sujeitos a homologação:
—
Unidade-veículo, de componente único (incluindo recetor GNSS e módulo de comunicação à distância),
—
Corpo principal da unidade-veículo (incluindo módulo de comunicação à distância) e módulo GNSS externo,
—
Corpo principal da unidade-veículo (incluindo recetor GNSS) e módulo de comunicação à distância externo,
—
Corpo principal da unidade-veículo, módulo GNSS externo e módulo de comunicação à distância externo.
Caso a unidade-veículo consista em diversas unidades distribuídas pelo veículo, o corpo principal da unidade-veículo é constituído pela unidade que alberga a unidade de processamento, a memória de dados e a função de medição do tempo.
O termo “unidade-veículo (VU)” é utilizado para “unidade-veículo” ou para “corpo principal da unidade-veículo”
»;
3)
No artigo 6.o, o terceiro parágrafo passa a ter a seguinte redação:
«No entanto, o anexo IC é aplicável a partir de 15 de junho de 2019, com exceção do apêndice 16, que é aplicável a partir de 2 de março de 2016.»;
4)
O anexo IC é alterado em conformidade com o anexo I do presente regulamento;
5)
O anexo II é alterado em conformidade com o anexo II do presente regulamento.
Artigo 2.o
Entrada em vigor
O presente regulamento entra em vigor no vigésimo dia seguinte ao da sua publicação no Jornal Oficial da União Europeia.
O presente regulamento é obrigatório em todos os seus elementos e diretamente aplicável em todos os Estados-Membros.
(2) Regulamento de Execução (UE) 2016/799 da Comissão, de 18 de março de 2016, que executa o Regulamento (UE) n.o 165/2014 do Parlamento Europeu e do Conselho que estabelece os requisitos para construção, ensaio, instalação, funcionamento e reparação de tacógrafos e seus componentes (JO L 139 de 26.5.2016, p. 1).
(3) Diretiva 2014/53/UE do Parlamento Europeu e do Conselho, de 16 de abril de 2014, relativa à harmonização da legislação dos Estados-Membros 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).
ANEXO I
O anexo IC do Regulamento (UE) 2016/799 é alterado do seguinte modo:
1)
O índice é alterado do seguinte modo:
a)
O capítulo 3.12.5 passa a ter a seguinte redação:
«3.12.5. Locais e posições em que se iniciam e concluem os períodos diários de trabalho e/ou em que são alcançados os períodos de três horas de condução acumulados»;
b)
O capítulo 4.5.3.2.16 passa a ter a seguinte redação:
«4.5.3.2.16 Dados relativos à localização das três horas de condução acumuladas»;
c)
O capítulo 4.5.4.2.14 passa a ter a seguinte redação:
«4.5.4.2.14 Dados relativos à localização das três horas de condução acumuladas»;
d)
O capítulo 6.2 passa a ter a seguinte redação:
«6.2 Verificação de componentes novos ou reparados»;
2)
O ponto 1 é alterado do seguinte modo:
a)
A definição constante do ponto ll) passa a ter a seguinte redação:
«ll)
“Sistema de comunicação à distância” ou “sistema de deteção rápida à distância”:
equipamento da unidade-veículo utilizado para controlos de estrada seletivos;»;
b)
A definição constante do ponto tt) passa a ter a seguinte redação:
«tt)
“Ajustamento de tempo”:
um ajustamento do tempo atual que pode ser automático e a intervalos regulares, utilizando o tempo previsto pelo recetor GNSS como referência, ou efetuado durante a calibração;»;
c)
O primeiro travessão da definição constante do ponto yy) passa a ter a seguinte redação:
«—
instalado e utilizado unicamente em veículos das categorias M1 e N1 (conforme a definição constante do anexo II da Diretiva 2007/46/CE do Parlamento Europeu e do Conselho (1), na sua última redação)»;
d)
É aditada uma nova definição no ponto fff):
«fff)
“tempo de condução acumulado”:
um valor que representa o número total acumulado de minutos de condução de um determinado veículo.
O valor tempo de condução acumulado constitui uma contagem livre de todos os minutos considerados como tempo de condução pelo controlo da função das atividades de condução do aparelho de controlo e só é utilizado para ativar o registo da posição do veículo cada vez que é alcançado um múltiplo de três horas de tempo de condução acumulado. A acumulação tem início no momento da ativação do equipamento de gravação. Não é afetada por qualquer outra condição, como, por exemplo, fora de alcance ou passagem de nível.
O valor tempo de condução acumulado não se destina a ser afixado, impresso ou descarregado;»;
3)
No capítulo 2.3, o último travessão do ponto 13 passa a ter a seguinte redação:
«—
as unidades-veículo têm um período normal de validade do funcionamento de 15 anos, a começar na data de vigência dos respetivos certificados, mas as unidades-veículo podem ser utilizadas por mais 3 meses, somente para descarregamento de dados.»;
4)
No capítulo 2.4, o primeiro parágrafo passa a ter a seguinte redação:
«O dispositivo de segurança do sistema visa proteger a memória contra acesso e manipulação não autorizados dos dados, bem como detetar tentativas nesse sentido, proteger a integridade e a autenticidade dos dados intercambiados entre o sensor de movimentos e a unidade-veículo, entre o aparelho de controlo e os cartões tacográficos e entre a unidade-veículo e o módulo GNSS externo, se existir, proteger a confidencialidade, a integridade e a autenticidade dos dados intercambiados através da comunicação de deteção rápida à distância para efeitos de controlo e verificar a integridade e a autenticidade dos dados descarregados.»;
5)
No capítulo 3.2, o segundo travessão do ponto 27 passa a ter a seguinte redação:
«—
posições em que o tempo de condução acumulado atinge um múltiplo de três horas;»;
6)
No capítulo 3.4, o ponto 49 passa a ter a seguinte redação:
«49)
A primeira mudança de atividade para BREAK/REST ou AVAILABILITY que ocorra dentro de 120 segundos após a passagem automática para WORK, devido à paragem do veículo, é considerada como tendo ocorrido no momento da paragem do veículo (podendo, portanto, anular a passagem para WORK).»;
7)
No capítulo 3.6.1, o ponto 59 passa a ter a seguinte redação:
«59)
O condutor deve então introduzir o lugar atual do veículo, que será considerado uma entrada temporária.
Nas seguintes condições, é validada a entrada temporária efetuada na última retirada do cartão (ou seja, deixa de ser sobreposta):
—
introdução de um lugar em que teve início o atual período diário de trabalho durante a introdução manual nos termos do ponto 61;
—
subsequente introdução de um lugar em que o atual período diário de trabalho tem início se o titular do cartão não introduzir nenhum lugar em que o período de trabalho tenha início ou termine durante a introdução manual nos termos do disposto no ponto 61.
Nas seguintes condições, é substituída a entrada temporária efetuada na última retirada do cartão e o novo valor é validado:
—
subsequente introdução de um lugar em que o atual período diário de trabalho termina se o titular do cartão não introduzir nenhum lugar em que o período de trabalho tenha início ou termine durante a introdução manual nos termos do disposto no ponto 61»;
8)
No capítulo 3.6.2, o sexto e o sétimo travessões passam a ter a seguinte redação:
«—
um lugar em que um período diário de trabalho anterior terminou, associado à hora pertinente (substituindo e validando assim a entrada feita aquando da última retirada do cartão);
—
um lugar em que teve início o atual período diário de trabalho, associado à hora pertinente (validando assim a entrada temporária feita aquando da última retirada do cartão).»;
9)
O capítulo 3.9.15 passa a ter a seguinte redação:
«3.9.15 Incidente “conflito de tempo”
86)
Este incidente produz-se, fora do modo de calibração, quando a VU deteta uma discrepância de mais de 1 minuto entre o tempo da função de medição do tempo da unidade-veículo e o tempo proveniente do recetor GNSS. O incidente é registado juntamente com o valor do relógio interno da unidade-veículo e surge juntamente com um ajustamento automático do tempo. Após a produção de um incidente de conflito de tempo, a VU não gera outros incidentes de conflito de tempo durante as 12 horas seguintes. Este incidente não se produz se não tiver sido detetado qualquer sinal GNSS válido pelo recetor GNSS num período igual ou superior a 30 dias.»;
10)
É aditado o seguinte travessão ao capítulo 3.9.17:
«—
Falha da interface ITS (quando aplicável)»;
11)
O capítulo 3.10 é alterado do seguinte modo:
i)
o parágrafo antes do quadro do ponto 89 passa a ter a seguinte redação:
Não diz respeito à versão portuguesa.
ii)
Ao quadro é aditada a seguinte linha:
«Interface ITS (opcional)
Funcionamento correto»
12)
No capítulo 3.12, o segundo travessão passa a ter a seguinte redação:
«—
O número médio de posições por dia é definido como pelo menos 6 posições em que o período diário de trabalho se inicia, 6 posições em que o tempo de condução acumulado atinge um múltiplo de três horas e 6 posições em que o período diário de trabalho termina, de modo que “365 dias” inclua pelo menos 6570 posições,»;
13)
O capítulo 3.12.5 é alterado do seguinte modo:
a)
O cabeçalho e o ponto 108 passam a ter a seguinte redação:
«3.12.5. Locais e posições em que se iniciam e concluem os períodos diários de trabalho e/ou em que são alcançados os períodos de três horas de condução acumulados
108)
O aparelho de controlo deve registar e memorizar na sua memória os seguintes dados:
—
locais e posições em que o condutor e/ou o ajudante inicia o seu período diário de trabalho;
—
posições em que o tempo de condução acumulado atinge um múltiplo de três horas;
—
locais e posições em que o condutor e/ou o ajudante conclui o seu período diário de trabalho.»;
b)
No ponto 110, o quarto travessão passa a ter a seguinte redação:
«—
O tipo de introdução (início, final ou 3 horas de tempo de condução acumulado),»;
c)
O ponto 111 passa a ter a seguinte redação:
«111)
A memória deve poder guardar os locais e as posições em que se iniciam e concluem os períodos diários de trabalho e/ou em que são alcançados os períodos de 3 horas de condução acumulados durante pelo menos 365 dias»;
14)
No capítulo 3.12.7, o ponto 116 passa a ter a seguinte redação:
«116)
O aparelho de controlo deve registar e memorizar na sua memória de dados a velocidade instantânea do veículo e as correspondentes data e hora, a cada segundo de pelo menos as últimas 24 horas de movimento do veículo»;
15)
No capítulo 3.12.8, o quadro é alterado como segue:
a)
É inserida a seguinte rubrica entre as rubricas «Ausência de informações sobre a posição do recetor GNSS» e «Erro nos dados de movimento»:
«Erro de comunicação com o módulo GNSS externo
—
o incidente mais longo de cada um dos últimos 10 dias de ocorrência,
—
os 5 incidentes mais longos dos últimos 365 dias.
—
data e hora do início do incidente,
—
data e hora do final do incidente,
—
tipo, número, Estado-Membro emissor e geração de qualquer cartão inserido no início e/ou no final do incidente,
—
número de incidentes similares nesse dia.»
b)
A rubrica «Conflito de tempo» passa a ter a seguinte redação:
«Conflito de tempo
—
o incidente mais grave de cada um dos últimos 10 dias de ocorrência (ou seja, os que apresentarem a maior diferença entre data e hora no aparelho de controlo e data e hora no GNSS),
—
os 5 incidentes mais graves dos últimos 365 dias.
—
data e hora do aparelho de controlo,
—
data e hora do GNSS,
—
tipo, número, Estado-Membro emissor e geração de qualquer cartão inserido no início e/ou no final do incidente,
—
número de incidentes similares nesse dia.»
16)
No capítulo 3.20, o ponto 200 passa a ter a seguinte redação:
«200)
O aparelho de controlo pode igualmente ser equipado com interfaces normalizadas que permitam utilizar, em modo de funcionamento ou calibração, os dados registados ou produzidos por tacógrafos, por um dispositivo externo.
No apêndice 13, especifica-se e normaliza-se uma interface ITS facultativa. Podem coexistir outras interfaces unidade-veículo, desde que cumpram integralmente os requisitos estabelecidos no apêndice 13 em termos de lista mínima de dados, segurança e consentimento do condutor.
O consentimento do condutor não se aplica aos dados transmitidos pelo aparelho de controlo para a rede do veículo. No caso de os dados pessoais injetados na rede do veículo continuarem a ser manuseados fora desta, é da responsabilidade do fabricante do veículo que o tratamento dos dados pessoais obedeça ao Regulamento (UE) 2016/679 («Regulamento Geral sobre a Proteção de Dados»).
O consentimento do condutor tão pouco se aplica aos dados tacográficos descarregados para uma empresa à distância (requisito 193), já que este cenário é controlado pelo direito de acesso por cartão de empresa.
Aos dados ITS disponibilizados através dessa interface aplicam-se os requisitos seguintes:
—
trata-se de um conjunto de dados existentes selecionados a partir do dicionário de dados tacográficos (apêndice 1),
—
desses dados selecionados, um subconjunto está marcado como «dados pessoais»,
—
o subconjunto de «dados pessoais» está disponível somente se estiver ativado o consentimento (verificável) do condutor para que os seus dados pessoais saiam da rede do veículo,
—
o consentimento do condutor pode ser ativado ou desativado através de comandos no menu, a qualquer momento, desde que o cartão de condutor esteja inserido,
—
o conjunto e o subconjunto de dados serão transmitidos via protocolo sem fios Bluetooth no raio da cabina do veículo, a um ritmo de atualização de 1 minuto,
—
o emparelhamento do dispositivo externo com a interface ITS será protegido por um PIN dedicado e aleatório de, pelo menos, 4 dígitos, registado e disponível através do visor de cada unidade-veículo,
—
em quaisquer circunstâncias, a presença da interface ITS não pode perturbar ou afetar o funcionamento correto e a segurança da unidade-veículo.
Complementarmente, também podem ser transmitidos outros dados ao conjunto de dados existentes selecionados, considerados como a lista mínima, desde que não se considerem como dados pessoais.
O aparelho de controlo deve ter capacidade para comunicar o estado do consentimento do condutor às outras plataformas existentes na rede do veículo.
Estando ligada a ignição do veículo (ON), estes dados devem ser transmitidos permanentemente.»
17)
No capítulo 3.23, o ponto 211 passa a ter a seguinte redação:
«211)
A hora do relógio interno da VU deve ser reajustada automaticamente cada 12 horas. Se este reajustamento não for possível porque o sinal GNSS não está disponível, o acerto da hora deve ser efetuado logo que a VU puder aceder a uma hora válida fornecida pelo recetor GNSS, de acordo com as condições de ignição do veículo. A referência temporal para o acerto automático da hora do relógio interno da VU deve ser determinada pelo recetor GNSS.»;
18)
No capítulo 3.26, os pontos 225) e 226) passam a ter a seguinte redação:
«225)
Em cada componente separado do aparelho de controlo deve ser afixada uma placa descritiva com os seguintes elementos:
—
nome e endereço do fabricante,
—
número dado pelo fabricante e ano de fabrico,
—
número de série,
—
marca de homologação.
226)
Se o espaço físico não for suficiente para mostrar todos os pormenores supramencionados, a placa descritiva deve indicar, pelo menos: o nome ou logótipo do fabricante e o número de peça do aparelho.»;
19)
No capítulo 4.1, o esquema correspondente ao anverso e ao verso do cartão de condutor é substituído pelo seguinte:
No capítulo 4.5.3.1.8, o primeiro travessão do ponto 263 passa a ter a seguinte redação:
«—
falha do cartão (se este for o protagonista da falha),»;
21)
No capítulo 4.5.3.2.8, o primeiro travessão do ponto 288 passa a ter a seguinte redação:
«—
falha do cartão (se este for o protagonista da falha),»;
22)
O capítulo 4.5.3.2.16 passa a ter a seguinte redação:
«4.5.3.2.16 Dados relativos à localização das três horas de condução acumuladas
305)
O cartão de condutor deve poder memorizar os seguintes dados relativos à posição do veículo, em que o tempo de condução acumulado atinge um múltiplo de três horas:
—
data e hora em que o tempo de condução acumulado atinge um múltiplo de três horas,
—
posição do veículo,
—
precisão GNSS, data e hora no momento de determinação da posição,
—
valor do conta-quilómetros do veículo.
306)
O cartão de condutor deve poder memorizar pelo menos 252 registos deste tipo.»;
23)
O capítulo 4.5.4.2.14 passa a ter a seguinte redação:
«4.5.4.2.14 Dados relativos à localização das três horas de condução acumuladas
353)
O cartão de oficina deve poder memorizar os seguintes dados relativos à posição do veículo, em que o tempo de condução acumulado atinge um múltiplo de três horas:
—
data e hora em que o tempo de condução acumulado atinge um múltiplo de três horas,
—
posição do veículo,
—
precisão GNSS, data e hora no momento de determinação da posição,
—
valor do conta-quilómetros do veículo.
354)
O cartão de oficina deve poder memorizar pelo menos 18 registos deste tipo»;
24)
No capítulo 5.2, o ponto 396 passa a ter a seguinte redação:
«396)
Na placa devem figurar pelo menos os seguintes elementos:
—
nome, endereço e marca do instalador ou oficina homologada,
—
coeficiente característico do veículo, sob a forma “w = … imp/km”,
—
constante do aparelho de controlo, sob a forma “k = … imp/km”,
—
perímetro efetivo dos pneus das rodas, sob a forma “l = … mm”,
—
medida do pneumático,
—
data de medição do coeficiente característico do veículo e do perímetro efetivo dos pneus das rodas,
—
número de identificação do veículo,
—
presença (ou ausência) de um módulo GNSS externo,
—
número de série do módulo GNSS externo, quando aplicável,
—
número de série do eventual dispositivo de comunicação à distância,
—
número de série de todos os selos em vigor,
—
parte do veículo onde eventualmente está instalado o adaptador,
—
parte do veículo onde está instalado o sensor de movimentos, se não estiver ligado à caixa de velocidades ou não estiver a ser utilizado um adaptador,
—
descrição da cor do cabo entre o adaptador e a parte do veículo de onde provêm os impulsos de entrada,
—
número de série do sensor de movimentos incorporado no adaptador.»;
25)
O capítulo 5.3 é alterado do seguinte modo:
a)
É inserido um novo ponto 398a após o ponto 398
«398a)
Os selos anteriormente referidos devem ser certificados de acordo com a norma EN 16882:2016.»;
b)
No ponto 401, o segundo parágrafo passa a ter a seguinte redação:
«O número de identificação único é definido como: MMNNNNNNNN por marcação não removível, sendo MM a identificação única do fabricante (registo da base de dados a gerir pela CE) e NNNNNNNN o código alfanumérico do selo, único no domínio do fabricante.»;
c)
O ponto 403 passa a ter a seguinte redação:
«403)
Os fabricantes de selos devem estar registados numa base de dados dedicada após obtenção de modelo de selo certificado de acordo com a norma EN 16882:2016 e disponibilizar publicamente os números dos selos de identificação através de um procedimento a estabelecer pela Comissão Europeia.»;
d)
O ponto 404 passa a ter a seguinte redação:
«404)
As oficinas e os fabricantes de veículos (homologados) devem, no âmbito do Regulamento (UE) n.o 165/2014, utilizar somente selos certificados de acordo com a norma EN 16882:2016 de entre os listados pelos fabricantes na base de dados supramencionada.»;
26)
O capítulo 6.2 passa a ter a seguinte redação:
«6.2. Verificação de componentes novos ou reparados
407)
Cada dispositivo individual, novo ou reparado, deve ser verificado em relação ao seu funcionamento correto e à precisão dos seus registos e leituras, dentro dos limites estabelecidos nos capítulos 3.2.1, 3.2.2, 3.2.3 e 3.3»;
27)
No capítulo 6.3, o ponto 408 passa a ter a seguinte redação:
«408)
Na fixação a um veículo, o conjunto da instalação (incluindo o aparelho de controlo) deve cumprir o disposto nos capítulos 3.2.1, 3.2.2, 3.2.3 e 3.3 em matéria de tolerâncias máximas. O conjunto da instalação deve ser selado em conformidade com o disposto no capítulo 5.3, incluindo uma calibração.»;
28)
O capítulo 8.1 é alterado do seguinte modo:
a)
No capítulo 8.1, os parágrafos antes do ponto 425 passam a ter a seguinte redação:
Na aceção do presente capítulo, por «aparelho de controlo» entende-se «o aparelho de controlo ou os seus componentes». Não é necessária homologação de tipo para o(s) cabo(s) que liga(m) o sensor de movimentos à VU, que liga(m) o módulo GNSS externo à VU ou que liga(m) o sistema externo de comunicação à distância à VU. O papel utilizado no aparelho de controlo é considerado um seu componente.
Qualquer fabricante pode solicitar a homologação de tipo de qualquer componente do aparelho de controlo, desde que estes estejam em conformidade com os requisitos do presente anexo. Em alternativa, os fabricantes podem também solicitar a homologação de tipo do aparelho de controlo.
Tal como descrito na definição (10) constante do artigo 2.o do presente regulamento, as unidades-veículo possuem variantes a nível do conjunto de componentes. Independentemente do conjunto de componentes da unidade-veículo, a antena externa e (quando aplicável) o repartidor de antena ligado ao recetor GNSS ou ao módulo de comunicação à distância não fazem parte da homologação de tipo da unidade-veículo.
Não obstante, os fabricantes que obtiveram a homologação de tipo para o aparelho de controlo devem publicitar uma lista de antenas e repartidores de antena compatíveis com cada uma das unidades-veículo, dos módulos GNSS externos e dos módulos de comunicação à distância homologados.»;
b)
O ponto 427 passa a ter a seguinte redação:
«427)
As autoridades responsáveis pela homologação de tipo nos Estados-Membros não podem emitir certificados de homologação de tipo se não tiverem na sua posse:
—
um certificado de segurança (se requerido no presente anexo),
—
um certificado de funcionalidade,
—
um certificado de interoperabilidade (se requerido no presente anexo)
relativos ao aparelho de controlo ou ao cartão tacográfico que são objeto do pedido de homologação de tipo.»;
29)
O apêndice 1 é alterado do seguinte modo:
a)
O índice é alterado do seguinte modo:
i)
O capítulo 2.63 passa a ter a seguinte redação:
«2.63 Reservado para utilização futura»;
ii)
O capítulo 2.78 passa a ter a seguinte redação:
«2.78 GNSSAccumulatedDriving»;
iii)
O capítulo 2.79 passa a ter a seguinte redação:
«2.79 GNSSAccumulatedDrivingRecord»;
iv)
O capítulo 2.111 passa a ter a seguinte redação:
«2.111 NoOfGNSSADRecords»;
v)
O capítulo 2.160 passa a ter a seguinte redação:
«2.160 Reservado para utilização futura»;
vi)
O capítulo 2.203 passa a ter a seguinte redação:
«2.203 VuGNSSADRecord»;
vii)
O capítulo 2.204 passa a ter a seguinte redação:
«2.204 VuGNSSADRecordArray»;
viii)
O capítulo 2.230 passa a ter a seguinte redação:
«2.230 Reservado para utilização futura»;
ix)
O capítulo 2.231 passa a ter a seguinte redação:
«2.231 Reservado para utilização futura»;
b)
No capítulo 2, é aditado o seguinte proémio antes do capítulo 2.1:
«Para os tipos de dados do cartão utilizados em aplicações de geração 1 e de geração 2, a dimensão especificada no presente apêndice refere-se à aplicação de geração 2. Supõe-se que a dimensão referente à aplicação de geração 1 já é conhecida pelo leitor. Os números dos requisitos do anexo IC referentes a tais tipos de dados abrangem tanto as aplicações de geração 1 como as de geração 2.»;
c)
O capítulo 2.19 passa a ter a seguinte redação:
«2.19. CardEventData
Geração 1:
Informação memorizada num cartão de condutor ou de oficina e relativa aos incidentes associados ao titular do cartão (requisitos 260 e 318 do anexo IC).
CardEventData é uma sequência de registos cardEventRecords (com exceção dos registos relacionados com tentativas de violação da segurança, os quais são reunidos no último conjunto da sequência), por ordem crescente do valor de EventFaultType.
cardEventRecords é um conjunto de registos de incidentes de determinado tipo (ou categoria, no caso de incidentes relativos a tentativas de violação da segurança).
Geração 2:
Informação memorizada num cartão de condutor ou de oficina e relativa aos incidentes associados ao titular do cartão (requisitos 285 e 341 do anexo IC).
CardEventData é uma sequência de registos cardEventRecords (com exceção dos registos relacionados com tentativas de violação da segurança, os quais são reunidos no último conjunto da sequência), por ordem crescente do valor de EventFaultType.
cardEventRecords é um conjunto de registos de incidentes de determinado tipo (ou categoria, no caso de incidentes relativos a tentativas de violação da segurança).»
d)
O capítulo 2.30 passa a ter a seguinte redação:
«2.30. CardRenewalIndex
O índice de renovação de um cartão, conforme definição i).
(17),–only to be used in the CHA field of a signing certificate
–Workshop Card (Sign)
(18), –only to be used in the CHA field of a signing certificate
–Vehicle Unit (Sign)
(19), –only to be used in the CHA field of a signing certificate
–RFU
(20..255)
Nota 1:
Os valores da geração 2 para a placa, o adaptador e a conexão GNSS externa, bem como os valores da geração 1 para a unidade-veículo e o sensor de movimentos, podem ser utilizados em SealRecord (se pertinente).
Nota 2:
No campo CardHolderAuthorisation (CHA) de um certificado de geração 2, os valores (1), (2) e (6) devem ser interpretados como indicando um certificado de autenticação mútua para o respetivo tipo de equipamento. Para indicar o respetivo certificado de criação de uma assinatura digital, devem ser utilizados os valores (17), (18) ou (19).»;
h)
No capítulo 2.70, o proémio antes do cabeçalho «Geração 2» passa a ter a seguinte redação:
«Geração 2:
Incidentes gerais
Sem pormenores adicionais
Inserção de cartão não válido
Conflito de cartões
Sobreposição de tempos
Condução sem cartão adequado
Inserção de cartão durante a condução
Última sessão de cartão encerrada incorretamente
Excesso de velocidade
Interrupção da alimentação energética
Erro nos dados de movimento
Conflito relativo ao movimento do veículo
Conflito de tempo (GNSS versus relógio interno da VU)
Erro de comunicação com o sistema de comunicação à distância
Ausência de informações sobre a posição do recetor GNSS
Erro de comunicação com o módulo GNSS externo
RFU
Incidentes de tentativa de violação da segurança relativos à VU
Sem pormenores adicionais
Falha da autenticação do sensor de movimentos
Falha da autenticação do cartão tacográfico
Mudança não autorizada de sensor de movimentos
Erro de integridade na entrada de dados relativos ao cartão
Erro de integridade nos dados de utilização memorizados
Erro na transferência interna de dados
Abertura não autorizada da caixa
Sabotagem do equipamento informático
Violação de deteção de GNSS
Falha de autenticação do módulo GNSS externo
Certificado do módulo GNSS externo expirado
RFU
Incidentes de tentativa de violação da segurança relativos ao sensor
Sem pormenores adicionais
Falha de autenticação
Erro de integridade em dados memorizados
Erro na transferência interna de dados
Abertura não autorizada da caixa
Sabotagem do equipamento informático
RFU
Falhas do aparelho de controlo
Sem pormenores adicionais
Falha interna da VU
Falha da impressora
Falha da visualização
Falha do descarregamento
Falha do sensor
Recetor GNSS interno
Módulo GNSS externo
Sistema de comunicação à distância
Interface ITS
RFU
Falhas do cartão
Sem pormenores adicionais
RFU
RFU
Específico do fabricante.»;
i)
O capítulo 2.71 passa a ter a seguinte redação:
«2.71. ExtendedSealIdentifier
Geração 2:
O identificador de selo alargado identifica, com caráter exclusivo, um selo (requisito 401 do anexo IC).
manufacturerCode é um código do fabricante do selo.
sealIdentifier é um identificador destinado ao selo, que é único para o fabricante.»;
j)
Os capítulos 2.78 e 2.79 passam a ter a seguinte redação:
«2.78 GNSSAccumulatedDriving
Geração 2:
Informação memorizada num cartão de condutor ou de oficina e relativa à posição GNSS do veículo, se o tempo de condução acumulado atingir um múltiplo de três horas (requisitos 306 e 354 do anexo IC).
gnssAccumulatedDrivingRecords SET SIZE(NoOfGNSSADRecords) OF
GNSSAccumulatedDrivingRecord
}
gnssADPointerNewestRecord é o índice do último registo GNSS atualizado da condução acumulada.
Valor atribuído é o número correspondente ao numerador do registo GNSS da condução acumulada, a começar por “0” na primeira ocorrência dos registos GNSS da condução acumulada na estrutura.
gnssAccumulatedDrivingRecords é o conjunto de registos que contêm a data e a hora em que a condução acumulada atinge um múltiplo de três horas e informações sobre a posição do veículo.
2.79. GNSSAccumulatedDrivingRecord
Geração 2:
Informação memorizada num cartão de condutor ou de oficina e relativa à posição GNSS do veículo, se o tempo de condução acumulado atingir um múltiplo de três horas (requisitos 305 e 353 do anexo IC).
A primeira opção é adequada para referenciar a chave pública de uma unidade-veículo ou de um cartão tacográfico ou de um módulo GNSS externo.
A segunda opção é adequada para referenciar a chave pública de uma unidade-veículo (caso o número de série da VU não possa ser conhecido no momento da geração do certificado).
A terceira opção é adequada para referenciar a chave pública de um Estado-Membro.»;
l)
O capítulo 2.92 passa a ter a seguinte redação:
«2.92. MAC
Geração 2:
Uma soma criptográfica de teste, com 8, 12 ou 16 bytes de comprimento, correspondente aos conjuntos de codificação especificados no apêndice 11.
cardNumberAndGenerationInformation refere-se ao número completo do cartão e à geração do cartão utilizado (dados tipo 2.74).
cardExtendedSerialNumber lido no ficheiro EF_ICC sob o MF do cartão.
cardStructureVersion lido no ficheiro EF_Application_Identification sob o DF_Tachograph_G2.
cardNumber lido no ficheiro EF_Identification sob o DF_Tachograph_G2.»;
r)
Os capítulos 2.203 e 2.204 passam a ter a seguinte redação:
«2.203 VuGNSSADRecord
Geração 2:
Informação memorizada numa unidade-veículo e relativa à posição GNSS do veículo, se o tempo de condução acumulado atingir um múltiplo de três horas (requisitos 108 e 110 do anexo IC).
timeStamp é a data e hora em que o tempo de condução acumulado atinge um múltiplo de três horas.
cardNumberAndGenDriverSlot identifica o cartão (incluindo a sua geração) que se encontrava inserido na ranhura do condutor.
cardNumberAndGenCodriverSlot identifica o cartão (incluindo a sua geração) que se encontrava inserido na ranhura do ajudante.
gnssPlaceRecord contém informação relacionada com a posição do veículo.
vehicleOdometerValue é o valor do conta-quilómetros no momento em que o tempo de condução acumulado atinge um múltiplo de três horas.
2.204. VuGNSSADRecordArray
Geração 2:
Informação memorizada numa unidade-veículo e relativa à posição GNSS do veículo, se o tempo de condução acumulado atingir um múltiplo de três horas (requisitos 108 e 110 do anexo IC).
Utilizam-se os seguintes elementos de dados, além dos utilizados na geração 1:
noOfGNSSADRecords é o número de registos GNSS de condução acumulados que o cartão pode memorizar.
noOfSpecificConditionRecords é o número dos registos de condição especial que o cartão pode memorizar.
noOfCardVehicleUnitRecords é o número de registos de utilização de unidades-veículo que o cartão pode memorizar»;
30)
O apêndice 2 é alterado do seguinte modo:
a)
No capítulo 1.1, são aditadas as seguintes abreviaturas:
«CHA
autorização do titular do certificado
DO
objeto de dados»;
b)
O capítulo 3.3 é alterado do seguinte modo:
i)
O ponto TCS_24 passa a ter a seguinte redação:
«TCS_24
Estes controlos de acesso podem ser ligados das seguintes formas:
E: Todos os controlos de acesso devem ser cumpridos
OU: Deve ser cumprido, pelo menos, um controlo de acesso
As regras de acesso ao sistema de ficheiros, ou seja, os comandos SELECT, READ BINARY e UPDATE BINARY, são especificadas no capítulo 4. As regras de acesso aos comandos restantes são especificadas nos quadros seguintes. É utilizado o termo “não aplicável” sempre que não houver requisito de apoio ao comando. Neste caso o comando pode ou não ser apoiado, mas a condição de acesso está fora de alcance.»;
ii)
No ponto TCS_25, o quadro passa a ter a seguinte redação:
«Comando
Cartão de condutor
Cartão de oficina
Cartão de controlo
Cartão de empresa
EXTERNAL AUTHENTICATE
—
Para autenticação da geração 1
ALW
ALW
ALW
ALW
—
Para autenticação da geração 2
ALW
PWD
ALW
ALW
Internal Authenticate
ALW
PWD
ALW
ALW
General Authenticate
ALW
ALW
ALW
ALW
Get Challenge
ALW
ALW
ALW
ALW
MSE:SET AT
ALW
ALW
ALW
ALW
MSE:SET DST
ALW
ALW
ALW
ALW
Process DSRC Message
Não aplicável
Não aplicável
Não aplicável
Não aplicável
PSO Compute Digital Signature
ALW OR
SM-MAC-G2
ALW OR
SM-MAC-G2
Não aplicável
Não aplicável
PSO Hash
Não aplicável
Não aplicável
ALW
Não aplicável
PERFORM HASH OF FILE
ALW OR
SM-MAC-G2
ALW OR
SM-MAC-G2
Não aplicável
Não aplicável
PSO VERIFY CERTIFICATE
ALW
ALW
ALW
ALW
PSO Verify Digital Signature
Não aplicável
Não aplicável
ALW
Não aplicável
Verify
Não aplicável
ALW
Não aplicável
Não aplicável»
iii)
No ponto TCS_26, o quadro passa a ter a seguinte redação:
«Comando
Cartão de condutor
Cartão de oficina
Cartão de controlo
Cartão de empresa
EXTERNAL AUTHENTICATE
—
Para autenticação da geração 1
Não aplicável
Não aplicável
Não aplicável
Não aplicável
—
Para autenticação da geração 2
ALW
PWD
ALW
ALW
Internal Authenticate
Não aplicável
Não aplicável
Não aplicável
Não aplicável
General Authenticate
ALW
ALW
ALW
ALW
Get Challenge
ALW
ALW
ALW
ALW
MSE:SET AT
ALW
ALW
ALW
ALW
MSE:SET DST
ALW
ALW
ALW
ALW
Process DSRC Message
Não aplicável
ALW
ALW
Não aplicável
PSO Compute Digital Signature
ALW OR
SM-MAC-G2
ALW OR
SM-MAC-G2
Não aplicável
Não aplicável
PSO Hash
Não aplicável
Não aplicável
ALW
Não aplicável
PERFORM HASH OF FILE
ALW OR
SM-MAC-G2
ALW OR
SM-MAC-G2
Não aplicável
Não aplicável
PSO VERIFY CERTIFICATE
ALW
ALW
ALW
ALW
PSO Verify Digital Signature
Não aplicável
Não aplicável
ALW
Não aplicável
Verify
Não aplicável
ALW
Não aplicável
Não aplicável»
iv)
No ponto TCS_27, o quadro passa a ter a seguinte redação:
«Comando
Cartão de condutor
Cartão de oficina
Cartão de controlo
Cartão de empresa
EXTERNAL AUTHENTICATE
—
Para autenticação da geração 1
Não aplicável
Não aplicável
Não aplicável
Não aplicável
—
Para autenticação da geração 2
ALW
PWD
ALW
ALW
Internal Authenticate
Não aplicável
Não aplicável
Não aplicável
Não aplicável
General Authenticate
ALW
ALW
ALW
ALW
Get Challenge
ALW
ALW
ALW
ALW
MSE:SET AT
ALW
ALW
ALW
ALW
MSE:SET DST
ALW
ALW
ALW
ALW
Process DSRC Message
Não aplicável
Não aplicável
Não aplicável
Não aplicável
PSO Compute Digital Signature
Não aplicável
Não aplicável
Não aplicável
Não aplicável
PSO Hash
Não aplicável
Não aplicável
Não aplicável
Não aplicável
PERFORM HASH OF FILE
Não aplicável
Não aplicável
Não aplicável
Não aplicável
PSO VERIFY CERTIFICATE
ALW
ALW
ALW
ALW
PSO Verify Digital Signature
Não aplicável
Não aplicável
Não aplicável
Não aplicável
Verify
Não aplicável
ALW
Não aplicável
Não aplicável»
c)
No capítulo 3.4, o ponto TCS_29 passa a ter a seguinte redação:
«TCS_29
As palavras de estatuto ou situação SW1 e SW2 são emitidas nas mensagens de resposta e denotam o estado de processamento do comando.
SW1
SW2
Significado
90
00
Processamento normal
61
XX
Processamento normal XX = número de bytes de resposta disponíveis
62
81
Processamento de alerta. Possível corrupção de parte dos dados devolvidos
63
00
Falha de autenticação (alerta)
63
CX
CHV (PIN) errado. Contador de tentativas remanescentes fornecido por “X”
64
00
Erro de execução — Estado de memória não viva inalterado. Erro de integridade
65
00
Erro de execução — Estado de memória não viva alterado
65
81
Erro de execução — Estado de memória não viva alterado — Falha de memória
66
88
Erro de segurança
:
soma criptográfica de teste errada (durante envio seguro de mensagens) ou
certificado errado (durante a verificação do certificado) ou
criptograma errado (durante autenticação externa) ou
assinatura errada (durante a verificação de assinatura)
67
00
Comprimento errado (Lc ou Le errados)
68
83
Último comando esperado da cadeia
69
00
Comando proibido (não há resposta disponível em T=0)
69
82
Estatuto de segurança não satisfeito
69
83
Método de autenticação bloqueado
69
85
Condições de utilização não satisfeitas
69
86
Comando não permitido (nenhum EF em curso)
69
87
Inexistentes os objetos de dados esperados do envio seguro de mensagens
69
88
Incorretos os objetos de dados do envio seguro de mensagens
6A
80
Parâmetros incorretos no campo de dados
6A
82
Ficheiro não encontrado
6A
86
Parâmetros P1-P2 errados
6A
88
Dados referenciados não encontrados
6B
00
Parâmetros errados (deslocamento fora de EF)
6C
XX
Comprimento errado; SW2 indica o comprimento exato. Sem devolução de campo de dados
6D
00
Código de instrução não aceite ou inválido
6E
00
Classe não aceite
6F
00
—
Outros erros de verificação
Podem ser devolvidas palavras de estatuto adicionais conforme definido na ISO/IEC 7816-4, caso o seu comportamento não seja expressamente referido no presente apêndice.
Por exemplo, podem ser eventualmente devolvidas as seguintes palavras de estatuto:
6881: Canal lógico não aceite
6882: Envio seguro de mensagens não aceite»;
d)
No capítulo 3.5.1.1, o último travessão do ponto TCS_38 passa a ter a seguinte redação:
«—
Se a aplicação selecionada for considerada corrompida (o erro de integridade é detetado nos atributos do ficheiro), o estado de processamento devolvido é “6400” ou “6500”.»;
e)
No capítulo 3.5.1.2, o último travessão do ponto TCS_41 passa a ter a seguinte redação:
«—
Se o ficheiro selecionado for considerado corrompido (o erro de integridade é detetado nos atributos do ficheiro), o estado de processamento devolvido é “6400” ou “6500”.»;
f)
No capítulo 3.5.2.1, o sexto travessão do ponto TCS_43 passa a ter a seguinte redação:
«—
Se for detetado um erro de integridade nos atributos do ficheiro, o cartão considera o ficheiro corrompido e irrecuperável e o estado de processamento devolvido é “6400” ou “6500”.»;
g)
O capítulo 3.5.2.1.1 é alterado do seguinte modo:
i)
No ponto TCS_45, o quadro passa a ter a seguinte redação:
«Byte
Comprimento
Valor
Descrição
#1
1
“81h”
TPV: Marcador para dados de valor simples
#2
L
“NNh” ou
“81 NNh”
LPV: comprimento dos dados devolvidos (= Le original).
L é 2 bytes se LPV>127 bytes.
#(2+L)-#(1+L+NN)
NN
“XX..XXh”
Valor de dado simples
#(2+L+NN)
1
“99h”
Marcador do estado de processamento (SW1-SW2) — opcional para o envio seguro de mensagens da geração 1
#(3+L+NN)
1
“02h”
Marcador do estado de processamento — opcional para o envio seguro de mensagens da geração 1
#(4+L+NN) — #(5+L+NN)
2
“XX XXh”
Estado de processamento da APDU de resposta desprotegida — opcional para o envio seguro de mensagens da geração 1
#(6+L+NN)
1
“8Eh”
TCC: Marcador para soma criptográfica de teste
#(7+L+NN)
1
“XXh”
LCC: Comprimento da soma criptográfica de teste infra
“04h” para envio seguro de mensagens da geração 1 (ver apêndice 11, parte A)
“08h”, “0Ch” ou “10h”, dependendo do comprimento da chave AES para o envio seguro de mensagens da geração 2 (ver apêndice 11, parte B)
#(8+L+NN)-#(7+M+L+NN)
M
“XX..XXh”
Soma criptográfica de teste
SW
2
“XXXXh”
Palavras de estatuto (SW1, SW2)»
ii)
No ponto TCS_46, o quadro passa a ter a seguinte redação:
«Byte
Comprimento
Valor
Descrição
#1
1
“87h”
TPI CG: Marcador para dados encriptados (criptograma)
#2
L
“MMh” ou
“81 MMh”
LPI CG: comprimento dos dados encriptados devolvidos (diferente do Le original do comando devido a preenchimento).
L é 2 bytes se LPI CG > 127 bytes.
#(2+L)-#(1+L+MM)
MM
“01XX..XXh”
Dados encriptados: Indicador de preenchimento e criptograma
#(2+L+MM)
1
“99h”
Marcador do estado de processamento (SW1-SW2) — opcional para o envio seguro de mensagens da geração 1
#(3+L+MM)
1
“02h”
Marcador do estado de processamento — opcional para o envio seguro de mensagens da geração 1
#(4+L+MM) — #(5+L+MM)
2
“XX XXh”
Estado de processamento da APDU de resposta desprotegida — opcional para o envio seguro de mensagens da geração 1
#(6+L+MM)
1
“8Eh”
TCC: Marcador para soma criptográfica de teste
#(7+L+MM)
1
“XXh”
LCC: Comprimento da soma criptográfica de teste infra
“04h” para envio seguro de mensagens da geração 1 (ver apêndice 11, parte A)
“08h”, “0Ch” ou “10h”, dependendo do comprimento da chave AES para o envio seguro de mensagens da geração 2 (ver apêndice 11, parte B)
#(8+L+MM)-#(7+N+L+MM)
N
“XX..XXh”
Soma criptográfica de teste
SW
2
“XXXXh”
Palavras de estatuto (SW1, SW2)»
h)
No capítulo 3.5.2.2, o sexto travessão do ponto TCS_50 passa a ter a seguinte redação:
«—
Se for detetado um erro de integridade nos atributos do ficheiro, o cartão considera o ficheiro corrompido e irrecuperável e o estado de processamento devolvido é “6400” ou “6500”.»;
i)
No capítulo 3.5.2.3, o ponto TCS_52 é alterado do seguinte modo:
i)
A última linha do quadro passa a ter a seguinte redação:
«Le
1
“XXh”
Conforme a norma ISO/IEC 7816-4»
ii)
É aditado o seguinte período:
«Quando T = 0 o cartão assume o valor Le = “00h” caso não for aplicado o envio seguro de mensagens.
Quando T = 1 o estado de processamento devolvido é “6700” se Le= “01h”.»;
j)
No capítulo 3.5.2.3, o sexto travessão do ponto TCS_53 passa a ter a seguinte redação:
«—
Se for detetado um erro de integridade nos atributos do ficheiro, o cartão considera o ficheiro corrompido e irrecuperável e o estado de processamento devolvido é “6400” ou “6500”.»;
k)
No capítulo 3.5.3.2, o sexto travessão do ponto TCS_63 passa a ter a seguinte redação:
«—
Se for detetado um erro de integridade nos atributos do ficheiro, o cartão considera o ficheiro corrompido e irrecuperável e o estado de processamento devolvido é “6400” ou “6500”.»;
l)
No capítulo 3.5.5, o ponto TCS_72 passa a ter a seguinte redação:
«TCS_72
O PIN introduzido pelo utilizador deve ser codificado ASCII e preenchido à direita com bytes “FFh” até um comprimento de 8 bytes pelo IFD (ver também o tipo de dados WorkshopCardPIN no apêndice 1).»;
m)
No capítulo 3.5.8, o ponto TCS_95 passa a ter a seguinte redação:
«TCS_95
Se o comando INTERNAL AUTHENTICATE for bem- sucedido, a chave de sessão de geração 1 em curso, a existir, é apagada e deixa de estar disponível. Para dispor de uma nova chave de sessão de geração 1, tem de se executar com êxito o comando EXTERNAL AUTHENTICATE para o mecanismo de autenticação da geração 1.
Nota:
Para chaves de sessão de geração 2 ver apêndice 11 CSM_193 e CSM_195. Se houver chaves de sessão de geração 2 e o cartão tacográfico receber o comando APDU simples INTERNAL AUTHENTICATE, a sessão de envio seguro de mensagens de geração 2 é abortada e as chaves de sessão de geração 2 são destruídas.»;
n)
No capítulo 3.5.9, o ponto TCS_97 passa a ter a seguinte redação:
«TCS_97
A variante de comando destinada a autenticação mútua do cartão VU da segunda geração pode ser executada no MF, no DF Tachograph e no DF Tachograph_G2 (ver igualmente TCS_34). Se o comando EXTERNAL AUTHENTICATE desta geração 2 for bem-sucedido, a chave de sessão de geração 1 em curso, a existir, é apagada e deixa de estar disponível.
Nota:
Para chaves de sessão de geração 2 ver apêndice 11 CSM_193 e CSM_195. Se houver chaves de sessão de geração 2 e o cartão tacográfico receber o comando APDU simples EXTERNAL AUTHENTICATE, a sessão de envio seguro de mensagens de geração 2 é abortada e as chaves de sessão de geração 2 são destruídas.»;
o)
No capítulo 3.5.10, é aditada a seguinte linha ao quadro do ponto TCS_101:
«5 + L + 1
1
“00h”
Conforme a norma ISO/IEC 7816-4»
p)
No capítulo 3.5.11.2.3, são aditados os seguintes parágrafos ao ponto TCS_114:
«—
Se o currentAuthenticatedTime do cartão for posterior à data de validade da chave pública selecionada o estado de processamento devolvido é
“6A88”.
Nota:
No caso de um comando MSE: SET AT para autenticação VU, a chave referenciada é a chave pública VU_MA. O cartão fixa a chave pública VU_MA para utilização, se esta estiver disponível na sua memória, que combina com a referência do titular do certificado (CHR) dada no campo de dados de comando (o cartão pode identificar as chaves públicas VU_MA através do campo CHA do certificado). O cartão só devolve “6A 88” a este comando quando apenas estiver disponível a chave pública VU_Sign ou não houver nenhuma chave pública de unidade-veículo disponível. Ver a definição do campo CHA no apêndice 11 e do tipo de dados equipmentType no apêndice 1.
Da mesma forma, no caso de um comando MSE: SET DST que referencie um EQT (ou seja, uma VU ou um cartão) que seja enviado para um cartão de controlo, de acordo com o CSM_234, a chave referenciada é sempre uma chave EQT_Sign que foi utilizada para verificação de uma assinatura digital. De acordo com a figura 13 do apêndice 11, o cartão de controlo terá sempre memorizado a chave pública EQT_Sign relevante. Em alguns casos, o cartão de controlo pode ter memorizado a chave pública EQT_MA correspondente. O cartão de controlo regula sempre a chave pública EQT_Sign para utilização quando recebe um comando MSE: SET DST.»;
q)
O capítulo 3.5.13 é alterado do seguinte modo:
i)
O ponto TCS_121 passa a ter a seguinte redação:
«TCS_121
O valor HASH OF FILE memorizado temporariamente será apagado se for calculado um novo valor HASH OF FILE por meio do comando PERFORM HASH OF FILE, se for selecionado um DF ou se o cartão tacográfico for reinicializado.»;
ii)
O ponto TCS_123 passa a ter a seguinte redação:
«TCS_123
A aplicação tacográfica da geração 2 é compatível com o algoritmo SHA-2 (SHA-256, SHA-384 ou SHA-512), especificado pela sequência de cifras constante do apêndice 11 parte B para a chave de assinatura do cartão Card_Sign.»;
iii)
No ponto TCS_124, o quadro passa a ter a seguinte redação:
«Byte
Comprimento
Valor
Descrição
CLA
1
“80h”
CLA
INS
1
“2Ah”
Executar operação de segurança
P1
1
“90h”
Marcador: Hash
P2
1
“00h”
Algoritmo implicitamente conhecido
Para a aplicação tacográfica de geração 1: SHA-1
Para a aplicação tacográfica de geração 2: algoritmo SHA-2 (SHA-256, SHA-384 ou SHA-512), definido pela sequência de cifras constante do apêndice 11 parte B para a chave de assinatura do cartão Card_Sign»
r)
O capítulo 3.5.14 é alterado do seguinte modo:
Os parágrafos a seguir ao título e até ao ponto TCS_126 passam a ter a seguinte redação:
«Utiliza-se este comando para calcular a assinatura digital do código HASH previamente calculado (ver PERFORM HASH OF FILE, ponto 3.5.13.
Para aceitar este comando em DF Tachograph e DF Tachograph_G2 são necessários apenas o cartão de condutor e o cartão da oficina.
Outros tipos de cartões tacográficos podem ou não executar este comando. No caso da aplicação tacográfica de geração 2, só o cartão de condutor e o cartão de oficina possuem uma chave de assinatura de geração 2, os restantes cartões não conseguem executar com sucesso o comando e terminar com um código de erro adequado.
O comando pode estar ou não acessível no MF. Se não estiver acessível no MF, interrompe-se com um código de erro adequado.
Este comando cumpre a norma ISO/IEC 7816-8. A comparar com a norma, a sua utilização é restrita.»;
s)
O capítulo 3.5.15 é alterado do seguinte modo:
i)
No ponto TCS_133, o quadro passa a ter a seguinte redação:
«Byte
Comprimento
Valor
Descrição
CLA
1
“00h”
CLA
INS
1
“2Ah”
Executar operação de segurança
P1
1
“00h”
P2
1
“A8h”
Marcador: campo de dados contém DO com interesse para verificação
Lc
1
“XXh”
Comprimento Lc do campo de dados subsequente
#6
1
“9Eh”
Marcador para assinatura digital
#7 ou
#7-#8
L
“NNh” ou
“81 NNh”
Comprimento da assinatura digital (L tem 2 bytes se a assinatura digital for superior a 127 bytes):
128 bytes codificados em conformidade com o apêndice 11, parte A, para a aplicação tacográfica da geração 1
Dependendo da curva selecionada para a aplicação tacográfica da geração 2 (ver apêndice 11, parte B).
#(7+L)-#(6+L+NN)
NN
“XX..XXh”
Conteúdo da assinatura digital»
ii)
Ao ponto TCS_134 é aditado o seguinte travessão:
«—
Se a chave pública selecionada (utilizada para verificar a assinatura digital) tiver um CHA.LSB (CertificateHolderAuthorisation.equipmentType) que não se adeque à verificação da assinatura digital de acordo com o apêndice 11, o estado de processamento devolvido é “6985”.»;
t)
O capítulo 3.5.16 é alterado do seguinte modo:
i)
No ponto TCS_138, é aditada a seguinte linha ao quadro:
«5 + L + 1
1
“00h”
Conforme a norma ISO/IEC 7816-4»
ii)
Ao ponto TCS_139 é aditado o seguinte parágrafo:
«—
“6985” indica que o selo temporal de 4-bytes fornecido no campo de dados do comando é anterior ao cardValidityBegin ou posterior à cardExpiryDate.»;
u)
O capítulo 4.2.2 é alterado do seguinte modo:
i)
Na estrutura de dados do ponto TCS_154, as linhas do DF Tachograph_G2 até ao EF CardMA_Certificate e as linhas desde o EF GNSS_Places até ao final do presente ponto passam a ter a seguinte redação:
No capítulo 4.3.1, o texto correspondente à abreviatura SC4 no ponto TCS_156 passa a ter a seguinte redação:
«SC4
Para o comando READ BINARY com byte INS par:
(SM-C-MAC-G1 E SM-R-ENC-MAC-G1) OU
(SM-C-MAC-G2 E SM-R-ENC-MAC-G2)
Para o comando READ BINARY com byte INS ímpar (quando aceite): NEV»;
w)
O capítulo 4.3.2 é alterado do seguinte modo:
i)
Na estrutura de dados do ponto TCS_162, as linhas do DF Tachograph_G2 até ao EF CardMA_Certificate e as linhas desde o EF Calibration até ao extendedSealIdentifier e as linhas do EF GNSS_Places até ao vehicleOdometerValue passam a ter a seguinte redação:
A rubrica NoOfGNSSCDRecords do quadro constante do ponto TCS_163 passa a ter a seguinte redação:
«
18
24»
31)
No apêndice 3, o capítulo 2 é alterado do seguinte modo:
a)
É inserida a linha seguinte após a linha onde constam os pictogramas «Local de início do período de trabalho diário» e «Local de final do período de trabalho diário»:
«
Posição após três horas de tempo de condução acumulado»;
b)
A combinação de pictogramas «Ajustamento do tempo (pela oficina)» passa a ter a seguinte redação:
«
Conflito de tempos ou ajustamento do tempo (pela oficina)»;
c)
São aditadas à lista de Incidentes as seguintes combinações de pictogramas:
«
Ausência de informações sobre a posição do recetor GNSS ou Erro de comunicação com o módulo GNSS externo;
Erro de comunicação com o módulo de comunicação à distância»;
32)
O apêndice 4 é alterado do seguinte modo:
a)
O capítulo 2 é alterado do seguinte modo:
i)
A secção 11.4 passa a ter a seguinte redação:
«11.4
Introdução do lugar de início e/ou final de um período de trabalho diário
pi = pictograma de local de início/final, hora, país, região
longitude da posição registada
latitude da posição registada
período de tempo em que a posição foi determinada
Conta-quilómetros
pihh:mm Cou Reg
lon ±DDDoMM.M’
lat ± DDoMM.M’
hh:mm
x xxx xxx km»
ii)
A secção 11.5 passa a ter a seguinte redação:
«11.5
Posições após três horas de tempo de condução acumulado
pi=posição após 3 horas de tempo de condução acumulado
tempo, tempo
longitude da posição registada
latitude da posição registada
período de tempo em que a posição foi determinada
Conta-quilómetros
»
b)
No ponto 3.1, a posição 11.5 do formato de impressão diária passa a ter a seguinte redação:
«11.5
Posições após 3 horas de tempo de condução acumulado por ordem cronológica»
c)
Na secção 3.2, o formato de impressão diária passa a ter a seguinte redação:
«1
Data e hora de impressão do documento
2
Tipo de impressão
3
Identificação do titular do cartão (para todos os cartões inseridos na VU + GEN)
4
Identificação do veículo (veículo do qual a impressão é tomada)
5
Identificação da VU (VU da qual a impressão é tomada + GEN)
6
Última calibração desta VU
7
Último controlo neste tacógrafo
9
Delimitador das atividades do condutor
10
Delimitador da ranhura do condutor (ranhura 1)
10a
Condição fora de âmbito no início deste dia
10.1 / 10.2 / 10.3 / 10.3a / 10.4
Atividades por ordem cronológica (ranhura do condutor)
10
Delimitador da ranhura do ajudante (ranhura 2)
10a
Condição fora de âmbito no início deste dia
10.1 / 10.2 / 10.3 / 10.3a / 10.4
Atividades por ordem cronológica (ranhura do ajudante)
11
Delimitador da síntese diária
11.1
Síntese dos períodos sem cartão na ranhura do condutor
11.4
Locais introduzidos, por ordem cronológica
11.5
Posições após 3 horas de tempo de condução acumulado por ordem cronológica
11.7
Totais de atividade
11.2
Síntese dos períodos sem cartão na ranhura do ajudante
11.4
Locais introduzidos, por ordem cronológica
11.5
Posições após 3 horas de tempo de condução acumulado por ordem cronológica
11.8
Totais de atividade
11.3
Síntese das atividades de um condutor, incluídas ambas as ranhuras
11.4
Locais introduzidos por este condutor, por ordem cronológica
11.5
Posições após 3 horas de tempo de condução acumulado por ordem cronológica
11.9
Totais de atividade para este condutor
13.1
Delimitador de incidentes/falhas
13.4
Registos de incidente/falha (últimos 5 incidentes ou falhas memorizados ou em curso na VU)
22.1
Local do controlo
22.2
Assinatura do controlador
22.3
Das horas (espaço disponível para um condutor sem cartão indicar os períodos pertinentes)
22.4
Às horas cujos períodos são relevantes para si próprio)
22.5
Assinatura do condutor»
d)
Na secção 3.7, o ponto PRT_014 passa a ter a seguinte redação:
«PRT_014
A impressão do histórico de cartões inseridos deve respeitar o seguinte formato:
1
Data e hora de impressão do documento
2
Tipo de impressão
3
Identificações do titular do cartão (para todos os cartões inseridos na VU)
23
Cartão mais recente inserido na VU
23.1
Cartões inseridos (até 88 registos)
12.3
Delimitador de falhas»
33)
O apêndice 7 é alterado do seguinte modo:
a)
O capítulo 1.1 passa a ter a seguinte redação:
«1.1. Âmbito de aplicação
Pode haver descarregamento de dados para um ESM:
—
a partir de uma unidade-veículo, por meio de um equipamento dedicado inteligente (IDE) ligado à unidade-veículo (VU),
—
a partir de um cartão tacográfico, por meio de um IDE equipado com dispositivo de interface para o cartão (IFD),
—
a partir de um cartão tacográfico, via uma unidade-veículo, por meio de um IDE ligado a essa VU.
Para possibilitar a verificação da autenticidade e da integridade dos dados descarregados memorizados num ESM, o descarregamento é feito com uma assinatura apensa em conformidade com o apêndice 11 (Mecanismos comuns de segurança). A identificação do equipamento-fonte (VU ou cartão) e os respetivos certificados de segurança (Estado-Membro e equipamento) são também descarregados. O verificador dos dados deve possuir, independentemente, uma chave pública europeia aprovada.
Os dados descarregados de uma VU são assinados utilizando os Mecanismos comuns de segurança, Parte B (sistema tacográfico de segunda geração) do apêndice 11, exceto quando o controlo dos condutores é efetuado por uma autoridade de controlo que não pertença à UE, utilizando um cartão de controlo de primeira geração, em cujo caso os dados são assinados utilizando os Mecanismos comuns de segurança, Parte A (sistema tacográfico de primeira geração) do apêndice 11, tal como solicitado pelo requisito MIG_015 Migração do apêndice 15.
O presente apêndice especifica, por conseguinte, dois tipos de descarregamento de dados da VU:
—
Dados descarregados da VU de geração 2, com a estrutura de dados da geração 2, assinados com os Mecanismos comuns de segurança, Parte B do apêndice 11,
—
Dados descarregados da VU de geração 1, com a estrutura de dados da geração 1, assinados com os Mecanismos comuns de segurança, Parte A do apêndice 11.
Da mesma maneira, há dois tipos de dados de descarregamentos de cartões de condutor de segunda geração inseridos numa VU, tal como se especifica nos pontos 3 e 4 do presente apêndice.»;
b)
A secção 2.2.2 é alterada do seguinte modo:
i)
O quadro passa a ter a seguinte redação:
«Message Structure
Max 4 Bytes Header
Max 255 Bytes Data
1 Byte CheckSum
IDE ->
<- VU
FMT
TGT
SRC
LEN
SID
DS_ / TRTP
DATA
CS
Start Communication Request
81
EE
F0
81
E0
Positive Response Start Communication
80
F0
EE
03
C1
EA, 8F
9B
Start Diagnostic Session Request
80
EE
F0
02
10
81
F1
Positive Response Start Diagnostic
80
F0
EE
02
50
81
31
Link Control Service
Verify Baud Rate (stage 1)
9 600 Bd
80
EE
F0
04
87
01,01,01
EC
19 200 Bd
80
EE
F0
04
87
01,01,02
ED
38 400 Bd
80
EE
F0
04
87
01,01,03
EE
57 600 Bd
80
EE
F0
04
87
01,01,04
EF
115 200 Bd
80
EE
F0
04
87
01,01,05
F0
Positive Response Verify Baud Rate
80
F0
EE
02
C7
01
28
Transition Baud Rate (stage 2)
80
EE
F0
03
87
02,03
ED
Request Upload
80
EE
F0
0A
35
00,00,00,00, 00,FF,FF,
FF,FF
99
Positive Response Request Upload
80
F0
EE
03
75
00,FF
D5
Transfer Data Request
Overview
80
EE
F0
02
36
01 or 21
97
Activities
80
EE
F0
06
36
02 or 22
Date
CS
Events & Faults
80
EE
F0
02
36
03 or 23
Date
99
Detailed Speed
80
EE
F0
02
36
04 or 24
Date
9A
Technical Data
80
EE
F0
02
36
05 or 25
Date
9B
Card download
80
EE
F0
02
36
06
Slot
CS
Positive Response Transfer Data
80
F0
EE
Len
76
TREP
Data
CS
Request Transfer Exit
80
EE
F0
01
37
96
Positive Response Request Transfer Exit
80
F0
EE
01
77
D6
Stop Communication Request
80
EE
F0
01
82
E1
Positive Response Stop Communication
80
F0
EE
01
C2
21
Acknowledge sub message
80
EE
F0
Len
83
Data
CS
Negative responses
General reject
80
F0
EE
03
7F
Sid Req
10
CS
Service not supported
80
F0
EE
03
7F
Sid Req
11
CS
Sub function not supported
80
F0
EE
03
7F
Sid Req
12
CS
Incorrect Message Length
80
F0
EE
03
7F
Sid Req
13
CS
Conditions not correct or Request sequence error
80
F0
EE
03
7F
Sid Req
22
CS
Request out of range
80
F0
EE
03
7F
Sid Req
31
CS
Upload not accepted
80
F0
EE
03
7F
Sid Req
50
CS
Response pending
80
F0
EE
03
7F
Sid Req
78
CS
Data not available
80
F0
EE
03
7F
Sid Req
FA
CS»
ii)
São aditados os seguintes travessões às notas a seguir ao quadro:
«—
Os TRPT 21 a 25 são utilizados nos pedidos de descarregamento de dados da VU de tipo geração 2, enquanto os TRPT 01 a 05 são utilizados para os de geração 1, que só podem ser aceites pelas VU no quadro de controlos de condutores efetuados por uma autoridade de controlo que não pertença à UE, com um cartão de controlo de primeira geração,
—
Os TRPT 11 a 19 e 31 a 39 estão reservados para pedidos de descarregamento específicos do fabricante.»;
c)
A secção 2.2.2.9 é alterada do seguinte modo:
i)
O ponto DDP_011 passa a ter a seguinte redação:
«DDP_011
Esta mensagem (pedido de transferência de dados) é enviada pelo IDE para especificar à VU o tipo dos dados que devem ser descarregados. O tipo de transferência é indicado por um Transfer Request Parameter (TRTP ou parâmetro de pedido de transferência) de um byte.
Há seis tipos de transferência de dados. No que toca ao descarregamento de dados da VU, dois valores diferentes de TRPT podem ser utilizados para cada tipo de transferência:
Data transfer type
TRTP value for generation 1 type of VU data download
TRTP value for generation 2 type of VU data download
Overview
01
21
Activities of a specified date
02
22
Events and faults
03
23
Detailed speed
04
24
Technical data
05
25
Data transfer type
TRTP value
Card download
06»
ii)
O ponto DDP_054 passa a ter a seguinte redação:
«DDP_054
Durante uma sessão de descarregamento, o IDE tem obrigatoriamente de pedir a transferência de dados panorâmica (TRTP 01 ou 21), pois só assim os certificados da VU são registados no ficheiro descarregado (e só assim pode ser verificada a assinatura digital).
No segundo caso (TRTP 02 ou 22), a mensagem Transfer Data Request inclui a indicação do dia de calendário a descarregar (formato
).»;
d)
Na secção 2.2.2.10, o ponto DDP_055 passa a ter a seguinte redação:
«DDP_055
No primeiro caso (TREP 01 ou 21), a VU envia dados para ajudar o utilizador do IDE a escolher os que pretende descarregar mais tarde. A informação contida nesta mensagem é a seguinte:
—
certificados de segurança,
—
identificação do veículo,
—
data e hora atuais da VU,
—
data descarregável mínima e máxima (dados da VU),
—
indicação de presença de cartões na VU,
—
descarregamento prévio para uma empresa,
—
bloqueios de empresa,
—
controlos prévios.»
e)
Na secção 2.2.2.16, o último travessão do ponto DDP_018 passa a ter a seguinte redação:
«—
FA dados não disponíveis
O objeto de um pedido de transferência de dados não está disponível na VU (por exemplo, não há cartão inserido, descarregamento de dados de geração 1 solicitado da VU fora do quadro de controlo do condutor por autoridade de controlo de país terceiro, etc.).»;
f)
A secção 2.2.6.1 é alterada do seguinte modo:
i)
O primeiro parágrafo do ponto DDP_029 passa a ter a seguinte redação:
«O campo de dados da mensagem “Positive Response Transfer Data Overview” fornece os seguintes dados, segundo a ordem indicada, sob o SID 76 Hex e o TREP 01 ou 21 Hex e com uma divisão e uma contagem adequadas das submensagens:»;
ii)
O título «Estrutura de dados da geração 1» passa a ter a seguinte redação:
«Estrutura de dados da geração 1 (TREP 01 Hex)»;
iii)
O título «Estrutura de dados da geração 2» passa a ter a seguinte redação:
«Estrutura de dados da geração 2 (TREP 21 Hex)».
g)
A secção 2.2.6.2 é alterada do seguinte modo:
i)
O primeiro parágrafo do ponto DDP_030 passa a ter a seguinte redação:
«O campo de dados da mensagem “Positive Response Transfer Data Activities” fornece os seguintes dados, segundo a ordem indicada, sob o SID 76 Hex e o TREP 02 ou 22 Hex e com uma divisão e uma contagem adequadas das submensagens:»;
ii)
O título «Estrutura de dados da geração 1» passa a ter a seguinte redação:
«Estrutura de dados da geração 1 (TREP 02 Hex)»;
iii)
O título «Estrutura de dados da geração 2» passa a ter a seguinte redação:
«Estrutura de dados da geração 2 (TREP 22 Hex)»;
iv)
A rubrica VuGNSSCDRecordArray, subordinada ao título «Estrutura de dados da geração 2 (TREP 22 Hex)», passa a ter a seguinte redação:
«
Posições GNSS do veículo quando o tempo de condução acumulado do veículo atingir um múltiplo de três horas. Se o perfil estiver vazio, é enviado um cabeçalho da matriz com noOfRecords = 0.»
h)
A secção 2.2.6.3 é alterada do seguinte modo:
i)
O primeiro parágrafo do ponto DDP_031 passa a ter a seguinte redação:
«O campo de dados da mensagem “Positive Response Transfer Data Events and Faults” fornece os seguintes dados, segundo a ordem indicada, sob o SID 76 Hex e o TREP 03 ou 23 Hex e com uma divisão e uma contagem adequadas das submensagens:»;
ii)
O título «Estrutura de dados da geração 1» passa a ter a seguinte redação:
«Estrutura de dados da geração 1 (TREP 03 Hex)»;
iii)
O título «Estrutura de dados da geração 2» passa a ter a seguinte redação:
«Estrutura de dados da geração 2 (TREP 23 Hex)»;
iv)
A rubrica VuTimeAdjustmentGNSSRecordArray, subordinada ao título «Estrutura de dados da geração 2 (TREP 23 Hex)», é suprimida;
i)
A secção 2.2.6.4 é alterada do seguinte modo:
i)
O primeiro parágrafo do ponto DDP_032 passa a ter a seguinte redação:
«O campo de dados da mensagem “Positive Response Transfer Data Detailed Speed” fornece os seguintes dados, segundo a ordem indicada, sob o SID 76 Hex e o TREP 04 ou 24 Hex e com uma divisão e uma contagem adequadas das submensagens:»;
ii)
O título «Estrutura de dados da geração 1» passa a ter a seguinte redação:
«Estrutura de dados da geração 1 (TREP 04)»;
iii)
O título «Estrutura de dados da geração 2» passa a ter a seguinte redação:
«Estrutura de dados da geração 2 (TREP 24)»;
j)
A secção 2.2.6.5 é alterada do seguinte modo:
i)
O primeiro parágrafo do ponto DDP_033 passa a ter a seguinte redação:
«O campo de dados da mensagem “Positive Response Transfer Data Technical Data” fornece os seguintes dados, segundo a ordem indicada, sob o SID 76 Hex e o TREP 05 ou 25 Hex e com divisão e contagem adequadas das submensagens:»;
ii)
O título «Estrutura de dados da geração 1» passa a ter a seguinte redação:
«Estrutura de dados da geração 1 (TREP 05)»;
iii)
O título «Estrutura de dados da geração 2» passa a ter a seguinte redação:
«Estrutura de dados da geração 2 (TREP 25)»;
k)
Na secção 3.3, o ponto DDP_035 passa a ter a seguinte redação:
«DDP_035
O descarregamento de um cartão tacográfico inclui as seguintes fases:
—
Descarregamento da informação comum do cartão para os EF
e
. Esta informação é opcional e não é securizada com uma assinatura digital.
—
(para cartões tacográficos de primeira e segunda geração) Descarregamento dos EF dentro do DF
:
—
Descarregamento do
e do
dos EF. Esta informação não é securizada com uma assinatura digital.
É obrigatório descarregar estes ficheiros por cada sessão de descarregamento.
—
Descarregamento dos outros EF de dados de aplicação (dentro do DF
) com exceção do EF
. Esta informação é securizada com uma assinatura digital, utilizando os Mecanismos comuns de segurança, Parte A do apêndice 11.
—
É obrigatório descarregar pelo menos a
e a
dos EF para cada sessão de descarregamento.
—
No descarregamento de um cartão de condutor é também obrigatório descarregar os seguintes EF:
(apenas para cartões tacográficos de segunda geração) Exceto quando um descarregamento de um cartão de condutor inserido numa VU é efetuado durante um controlo do condutor por uma autoridade de controlo de um país terceiro, utilizando um cartão de controlo de primeira geração, descarregar os EF dentro do
DF:
—
Descarregar o CardSignCertificate, CA_Certificate e Link_Certificate (se existirem) dos EF. Esta informação não é securizada com uma assinatura digital.
— É obrigatório descarregar estes ficheiros por cada sessão de descarregamento.
—
Descarregar os outros EF de dados de aplicação (dentro do
DF) exceto EF
. Esta informação é securizada com uma assinatura digital, utilizando os Mecanismos comuns de segurança, Parte B do apêndice 11.
—
É obrigatório descarregar pelo menos a
e a
dos EF para cada sessão de descarregamento.
—
No descarregamento de um cartão de condutor é também obrigatório descarregar os seguintes EF:
Ao descarregar um cartão de condutor, atualizar a data
no EF
, no
e, quando aplicável, nos DF
.
—
Ao descarregar um cartão de oficina, reinicializar o contador de calibração no EF
no
e, quando aplicável, nos DF
.
—
Ao descarregar um cartão de oficina, o EF
no
e, quando aplicável, nos DF
não devem ser descarregados.»;
l)
Na secção 3.3.2, o primeiro parágrafo do ponto DDP_037 passa a ter a seguinte redação:
«A sequência de descarregamento dos EF ICC, IC, Card_Certificate (ou CardSignCertificate para o DF Tachograph_G2), CA_Certificate e Link_Certificate (apenas para o DF Tachograph_G2) é a seguinte:»;
m)
Na secção 3.3.3, o quadro passa a ter a seguinte redação:
«Cartão
Dir
IDE/IFD
Significado/Observações
Select File
OK
Perform Hash of File
—
Calcula o valor hash sobre o conteúdo dos dados do ficheiro selecionado, utilizando o algoritmo prescrito nos termos do apêndice 11, parte A ou B. Este comando não é um ISO-Command.
Calcular Hash of File e memorizar valor Hash temporariamente
OK
Read Binary
Se o ficheiro contiver mais dados do que o tampão do leitor ou o cartão aceitar, o comando tem de ser repetido até todo o ficheiro ter sido lido.
Dados do ficheiro
OK
Memorizar no ESM dados recebidos
de acordo com 3.4 Formato de memorização dos dados
PSO Compute Digital Signature
Executar operação de segurança «Compute Digital Signature» utilizando o valor Hash temporariamente memorizado
Assinatura
OK
Juntar os dados aos anteriormente memorizados no ESM
de acordo com 3.4 Formato de memorização dos dados»
n)
Na secção 3.4.2, o ponto DDP_046 passa a ter a seguinte redação:
«DDP_046
Uma assinatura é memorizada como o objeto TLV imediatamente a seguir ao objeto TLV que contém os dados do ficheiro.
Definição
Significado
Comprimento
FID (2 Bytes) || “00”
Marcador para EF (FID) no
DF ou para informação comum do cartão
3 bytes
FID (2 Bytes) || “01”
Marcador para assinatura do EF (FID) no
DF
3 bytes
FID (2 Bytes) || “02”
Marcador para EF (FID) no
DF
3 bytes
FID (2 Bytes) || “03”
Marcador para assinatura do EF (FID) no
DF
3 bytes
xx xx
Comprimento do campo de valor
2 bytes
Exemplo dos dados num ficheiro de descarregamento para um ESM:
Marcador
Comprimento
Valor
—
Dados do EF ICC
—
Dados do EF Card_Certificate
—
...
Dados do EF
(no
DF)
Assinatura do EF
(no
DF)
Dados do EF
no
DF
Assinatura do EF
no
DF»
o)
No capítulo 4, o ponto DDP_049 passa a ter a seguinte redação:
«DDP_049
Cartões de condutor de primeira geração: Os dados devem ser descarregados utilizando-se o protocolo de descarregamento de dados de primeira geração e os dados descarregados devem possuir o mesmo formato do que aqueles que foram descarregados a partir de uma unidade-veículo de primeira geração.
Cartões de condutor de segunda geração: A VU descarrega então todo o cartão, ficheiro a ficheiro, em conformidade com o protocolo de descarregamento do cartão, definido na secção 3, e encaminha todos os dados recebidos do cartão para o IDE dentro do formato adequado TLV do ficheiro (ver 3.4.2) e encapsulados dentro de uma mensagem “Positive Response Transfer Data”.»;
34)
Na secção 2 do apêndice 8, o parágrafo após a indicação «Referências» passa a ter a seguinte redação:
«ISO 14230-2: Road Vehicles — Diagnostic Systems — Keyword Protocol 2000 — Part 2: Data Link Layer.
First edition: 1999.»;
35)
O apêndice 9 é alterado do seguinte modo:
a)
No índice, a secção 6 passa a ter a seguinte redação:
«6.
ENSAIOS DO SISTEMA DE COMUNICAÇÃO À DISTÂNCIA»;
b)
Na secção 1.1, o primeiro travessão passa a ter a seguinte redação:
«—
uma certificação de segurança, baseada em especificações de critérios comuns, em relação a uma meta de segurança totalmente compatível com o apêndice 10 do presente anexo,»;
c)
Na secção 2, o quadro relativo aos ensaios de funcionalidade da unidade-veículo passa a ter a seguinte redação:
«N.o
Ensaio
Descrição
Requisitos correlatos
1
Exame administrativo
1.1
Documentação
Adequação da documentação
1.2
Resultados dos ensaios do fabricante
Resultados do ensaio efetuado pelo fabricante durante a integração.
Demonstrações em papel.
88, 89,91
2
Inspeção visual
2.1
Conformidade com a documentação
2.2
Identificação/marcações
224 a 226
2.3
Materiais
219 a 223
2.4
Selagem
398, 401 a 405
2.5
Interfaces externas
3
Ensaios de funcionalidade
3.1
Funções disponíveis
02, 03, 04, 05, 07, 382
3.2
Modos de funcionamento
09 a 11*, 134, 135
3.3
Direitos de acesso a funções e a dados
12* 13*, 382, 383, 386 a 389
3.4
Controlo da inserção e da retirada de cartões
15, 16, 17, 18, 19*, 20*, 134
3.5
Medição da velocidade e da distância
21 a 31
3.6
Medição do tempo (ensaio efetuado a 20 °C)
38 a 43
3.7
Controlo das atividades do condutor
44 a 53, 134
3.8
Controlo da situação de condução
54, 55, 134
3.9
Entradas efetuadas manualmente
56 a 62
3.10
Gestão dos bloqueamentos da empresa
63 a 68
3.11
Vigilância das atividades de controlo
69, 70
3.12
Deteção de incidentes e/ou falhas
71 a 88134
3.13
Dados de identificação do aparelho
93*, 94*, 97, 100
3.14
Dados relativos à inserção e à retirada de cartões de condutor
102* a 104*
3.15
Dados relativos à atividade de condutor
105* a 107*
3.16
Dados dos locais e posições
108* a 112*
3.17
Dados do conta-quilómetros
113* a 115*
3.18
Dados detalhados da velocidade
116*
3.19
Dados relativos a incidentes
117*
3.20
Dados relativos a falhas
118*
3.21
Dados relativos à calibração
119* a 121*
3.22
Dados relativos ao ajustamento da hora
124*, 125*
3.23
Dados relativos à atividade de controlo
126*, 127*
3.24
Dados relativos aos bloqueamentos da empresa
128*
3.25
Dados relativos à atividade de descarregamento
129*
3.26
Dados relativos às condições especiais
130*, 131*
3.27
Registo e memorização de dados nos cartões tacográficos
136, 137, 138*, 139*, 141*, 142, 143
144, 145, 146*, 147*, 148*, 149, 150
3.28
Visualização
90, 134
151 to 168,
PIC_001, DIS_001
3.29
Impressão
90, 134
169 to 181, PIC_001, PRT_001 to PRT_014
3.30
Alerta
134, 182 to 191,
PIC_001
3.31
Descarregamento de dados para meios externos
90, 134, 192 to 196
3.32
Comunicação à distância para controlos de estrada seletivos
197 to 199
3.33
Transmissão ou saída de dados para dispositivos externos adicionais
200, 201
3.34
Calibração
202 a 206*, 383, 384, 386 a 391
3.35
Controlo de calibração de estrada
207 to 209
3.36
Ajustamento do tempo
210 a 212*
3.37
Não interferência de funções adicionais
06, 425
3.38
Interface do sensor de movimentos
02, 122
3.39
Módulo GNSS externo
03, 123
3.40
Verificar se a VU deteta, regista e memoriza o(s) incidente(s) e/ou falha(s) definidos pelo fabricante da VU quando um sensor de movimentos emparelhado reage a campos magnéticos que perturbam a deteção do movimento do veículo.
217
3.41
Parâmetros de domínio normalizados e de sequência de cifras
CSM_48, CSM_50
4
Ensaios ambientais
4.1
Temperatura
Verificar funcionalidade por meio de:
Ensaio de acordo com a norma ISO 16750-4, capítulo 5.1.1.2: Low temperature operation test (72 h a -20°C)
Este ensaio refere-se à norma IEC 60068-2-1: Environmental testing – Part 2-1: Tests – Test A: Cold
Ensaio de acordo com a norma ISO 16750-4: secção 5.1.2.2: High temperature operation test (72 h a 70 °C)
Este ensaio refere-se à norma IEC 60068-2-2: Basic environmental testing procedures;
Ensaio de acordo com a norma ISO 16750-4: secção 5.3.2: Rapid change of temperature with specified transition duration (-20 °C/70 °C, 20 ciclos; duração do ensaio 2 horas a cada temperatura)
Pode ser efetuado um conjunto reduzido de ensaios (entre os definidos na secção 3 deste quadro) à temperatura mais baixa, à temperatura mais alta e durante os ciclos de temperatura
213
4.2
Humidade
Verificar se a unidade-veículo suporta variações cíclicas de humidade (ensaio térmico) através de IEC 60068-2-30, ensaio Db, seis ciclos de 24 horas, variando cada temperatura de +25 °C a + 55 °C e com humidade relativa de 97 % a + 25 °C e de 93 % a + +55 °C
214
4.3
Mecânica
1.
Vibrações sinusoidais.
Verificar se a unidade-veículo suporta vibrações sinusoidais com as seguintes características:
deslocamento constante entre 5 e 11 Hz: pico de 10 mm
aceleração constante entre 11 e 300 Hz: 5 g
Este requisito é verificado por meio da norma IEC 60068-2-6, ensaio Fc, com a duração mínima de 3 × 12 horas (12 horas por eixo)
A norma ISO 16750-3 não exige ensaio de vibração sinusoidal em dispositivos localizados na cabina do veículo separada.
2.
Vibrações aleatórias:
Ensaio de acordo com a norma ISO 16750-3: secção 4.1.2.8: Test VIII: Commercial vehicle, decoupled vehicle cab
Ensaio de vibração aleatória, 10...2000 Hz, RMS vertical 21,3 m/s2, RMS longitudinal 11,8 m/s2, RMS lateral 13,1 m/s2, 3 eixos, 32 h por eixo, incluindo o ciclo de temperatura -20 °C ... 70 °C.
Este ensaio refere-se à norma IEC 60068-2-64: Environmental testing – Part 2-64: Tests – Test Fh: Vibration, broadband random and guidance
3.
Choques:
choque mecânico com 3 g de meio seio, de acordo com a norma ISO 16750.
Os dois ensaios supra são executados sobre duas amostras distintas do tipo de equipamento em ensaio.
219
4.4
Proteção contra água e corpos estranhos
Ensaio de acordo com a norma ISO 20653: Road vehicles – Degree of protection (IP code) – Protection of electrical equipment against foreign objects, water and access (Sem alterações nos parâmetros); valor mínimo IP 40
220, 221
4.5
Proteção contra sobretensão
Verificar se a unidade-veículo suporta as seguintes tensões de alimentação:
Versões de 24 V
:
34 V a +40 °C, 1 hora
Versões de 12 V
:
17 V a +40 °C, 1 hora
(ISO 16750-2)
216
4.6
Proteção contra polaridade inversa
Verificar se a unidade-veículo suporta uma inversão na alimentação elétrica
(ISO 16750-2)
216
4.7
Proteção contra curto-circuito
Verificar se os sinais de entrada-saída estão protegidos contra curtos-circuitos na alimentação elétrica e na terra
(ISO 16750-2)
216
5
Ensaios de CEM
5.1
Emissões radiadas e suscetibilidade
Conformidade com o Regulamento ECE R10
218
5.2
Descarga eletrostática
Conformidade com a norma ISO 10605: 2008 +
Retificação técnica: 2010 +
AMD1: 2014: +/- 4 kV para contacto e +/- 8 kV para descarga de ar
218
5.3
Suscetibilidade do transitório conduzido em relação à alimentação elétrica
Para versões de 24 V: conformidade com a norma ISO 7637-2 + Regulamento ECE n.o 10 rev. 3:
impulso 1a: Vs = - 450 V Ri = 50 ohms
impulso 2 a: Vs = - 37 V Ri = 2 ohms
impulso 2b: Vs = - 20 V Ri = 0,05 ohms
impulso 3 a: Vs = - 150 V Ri = 50 ohms
impulso 3b: Vs = - 150 V Ri = 50 ohms
impulso 4: Vs = - 16 V Va = - 12 V t6 = 100 ms
impulso 5: Vs = - 120 V Ri = 2,2 ohms td = 250 ms
Para versões de 12 V: conformidade com a norma ISO 7637-1 - Regulamento ECE n.o 10 rev. 3:
impulso 1: Vs = - 75 V Ri = 10 ohms
impulso 2 a: Vs = - 37 V Ri = 2 ohms
impulso 2b: Vs = - 10 V Ri = 0,05 ohms
impulso 3 a: Vs = - 112 V Ri = 50 ohms
impulso 3b: Vs = - 75 V Ri = 50 ohms
impulso 4: Vs = - 6 V Va = - 5 V t6 = 15 ms
impulso 5: Vs = - 65 V Ri = 3ohms td = 100 ms
O ensaio do impulso 5 só é efetuado em unidades-veículo destinadas a veículos sem proteção externa comum contra descarga.
Relativamente a propostas de descarga, consultar a norma ISO 16750-2, 4.a edição, capítulo 4.6.4.
218»
d)
A secção 6 passa a ter a seguinte redação:
«6. ENSAIO DO SISTEMA DE COMUNICAÇÃO À DISTÂNCIA»
«N.o
Ensaio
Descrição
Requisitos correlatos
1.
Exame administrativo
1.1
Documentação
Adequação da documentação
2.
Inspeção visual
2.1.
Conformidade com a documentação
2.2.
Identificação/marcações
225, 226
2,3
Materiais
219 to 223
3.
Ensaios de funcionalidade
3.1
Comunicação à distância para controlos de estrada seletivos
4, 197 to 199,
3.2
Registo e memorização de dados na memória
91
3.3
Comunicação com a unidade-veículo
Apêndice 14 DSC_66 a DSC_70, DSC_71 a DSC_76
4.
Ensaios ambientais
4.1
Temperatura
Verificar funcionalidade por meio de:
Ensaio de acordo com a norma ISO 16750-4, capítulo 5.1.1.2: Low temperature operation test (72 h a-20 °C)
Este ensaio refere-se à norma IEC 60068-2-1: Environmental testing – Part 2-1: Tests – Test A: Cold
Ensaio de acordo com a norma ISO 16750-4: capítulo 5.1.2.2: High temperature operation test (72 h a 70 °C)
Este ensaio refere-se à norma IEC 60068-2-2: Basic environmental testing procedures; part 2: tests;
Ensaio de acordo com a norma ISO 16750-4: capítulo 5.3.2: Rapid change of temperature with specified transition duration (-20 °C/70 °C, 20 ciclos; duração do ensaio 1 hora a cada temperatura)
Pode ser efetuado um conjunto reduzido de ensaios (entre os definidos na secção 3 deste quadro) à temperatura mais baixa, à temperatura mais alta e durante os ciclos de temperatura
213
4.2
Proteção contra água e corpos estranhos
Ensaio de acordo com a norma ISO 20653: Road vehicles – Degree of protection (IP code) – Protection of electrical equipment against foreign objects, water and access (valor visado IP40)
220, 221
5.
Ensaios de CEM
5.1
Emissões radiadas e suscetibilidade
Conformidade com o Regulamento ECE R10
218
5.2
Descarga eletrostática
Conformidade com a norma ISO 10605: 2008 + Retificação técnica: 2010 + AMD1: 2014: +/- 4 kV para contacto e +/- 8 kV para descarga de ar
218
5.3
Suscetibilidade do transitório conduzido em relação à alimentação elétrica
Para versões de 24 V: conformidade com a norma ISO 7637-2 + Regulamento ECE n.o 10 rev. 3:
impulso 1a: Vs = - 450 V Ri = 50 ohms
impulso 2 a: Vs = + 37 V Ri = 2 ohms
impulso 2b: Vs = + 20 V Ri = 0,05 ohms
impulso 3 a: Vs = - 150 V Ri = 50 ohms
impulso 3b: Vs = + 150 V Ri = 50 ohms
impulso 4: Vs = - 16 V Va = -12 V t6 = 100ms
impulso 5: Vs = + 120 V Ri = 2,2 ohms td = 250ms
Para versões de 12 V: conformidade com a norma ISO 7637-1 + Regulamento ECE n.o 10 rev. 3:
impulso 1: Vs = - 75 V Ri = 10 ohms
impulso 2 a: Vs = + 37 V Ri = 2 ohms
impulso 2b: Vs = + 10 V Ri = 0,05 ohms
impulso 3 a: Vs = - 112 V Ri = 50 ohms
impulso 3b: Vs = + 75 V Ri = 50 ohms
impulso 4: Vs = - 6 V Va = -5 V t6 = 15ms
impulso 5: Vs = + 65 V Ri = 3ohms td = 100ms
O ensaio do impulso 5 só é efetuado em unidades-veículo destinadas a veículos sem proteção externa comum contra descarga.
Relativamente a propostas de descarga, consultar a norma ISO 16750-2, 4.a edição, capítulo 4.6.4.
218»
e)
Na secção 8, o quadro sobre os ensaios de interoperabilidade passa a ter a seguinte redação:
«N.o
Ensaio
Descrição
8.1
Ensaios de interoperabilidade entre unidades-veículo e cartões tacográficos
1
Autenticação mútua
Verificar se funciona normalmente a autenticação mútua entre a unidade-veículo e o cartão tacográfico
2
Ensaios de leitura/escrita
Encenar uma atividade típica na unidade-veículo. O cenário deve ser adaptado ao tipo de cartão em ensaio e envolver escritas em tantos EF quantos os possíveis no cartão
Por meio de um descarregamento da unidade-veículo, verificar se todos os registos correspondentes foram executados corretamente
Por meio de um descarregamento do cartão, verificar se todos os registos correspondentes foram executados corretamente
Por meio de impressões diárias, verificar se todos os registos correspondentes podem ser lidos corretamente
8.2
Ensaios de interoperabilidade entre unidades-veículo e sensores de movimento
1
Emparelhamento
Verificar se funciona normalmente o emparelhamento entre as unidades-veículo e os sensores de movimento
2
Ensaios de atividade
Encenar uma atividade típica no sensor de movimento. O cenário deve implicar uma atividade normal e criar tantos incidentes ou falhas quantos os possíveis.
Por meio de um descarregamento da unidade-veículo, verificar se todos os registos correspondentes foram executados corretamente
Por meio de um descarregamento do cartão, verificar se todos os registos correspondentes foram executados corretamente
Por meio de uma impressão diária do cartão, verificar se todos os registos correspondentes podem ser lidos corretamente
8.3
Ensaios de interoperabilidade entre as unidades-veículo e os módulos GNSS externos (quando aplicável)
1
Autenticação mútua
Verificar se funciona normalmente a autenticação mútua (acoplamento) entre a unidade-veículo e o módulo GNSS externo.
2
Ensaios de atividade
O cenário deve implicar uma atividade normal e criar tantos incidentes ou falhas quantos os possíveis.
Por meio de um descarregamento da unidade-veículo, verificar se todos os registos correspondentes foram executados corretamente
Por meio de um descarregamento do cartão, verificar se todos os registos correspondentes foram executados corretamente
Por meio de uma impressão diária do cartão, verificar se todos os registos correspondentes podem ser lidos corretamente»
36)
O apêndice 11 é alterado do seguinte modo:
a)
Na secção 8.2.3, o ponto CSM_49 passa a ter a seguinte redação:
«CSM_49
Unidades-veículo, cartões tacográficos e módulos GNSS externos aceitam os algoritmos SHA-256, SHA-384 e SHA-512 especificados em [SHS].»;
b)
Na secção 9.1.2, o primeiro parágrafo do ponto CSM_58 passa a ter a seguinte redação:
«CSM_58
Sempre que cria um novo par de chaves de raiz europeia, a ERCA cria um certificado de ligação para a nova chave pública europeia e assina-o com a chave privada europeia anterior. O período de validade do certificado de ligação é de 17 anos e 3 meses. (esquema 1, na secção 9.1.7).»;
c)
Na secção 9.1.4, o ponto CSM_72 passa a ter a seguinte redação:
«CSM_72
Para cada unidade-veículo, são criados dois pares de chaves ECC originais, denominados VU_MA e VU_Sign. Esta função é assegurada pelos fabricantes de VU. Sempre que for criado um par de chaves de VU, a parte que cria a chave envia a chave pública à MSCA do país de residência, a fim de obter o correspondente certificado de VU, assinado pela MSCA. Somente a unidade-veículo utiliza a chave privada.»;
d)
A secção 9.1.5 é alterado do seguinte modo:
i)
O ponto CSM_83 passa a ter a seguinte redação:
«CSM_83
Para cada cartão tacográfico é criado um par de chaves ECC original, denominado Card_MA. Para cada cartão de condutor e de oficina é criado adicionalmente um segundo par de chaves ECC original, denominado Card_Sign. Esta função pode ser assegurada pelos fabricantes ou personalizadores dos cartões. Sempre que for criado um par de chaves de cartão, a parte que cria a chave envia a chave pública à MSCA do país de residência, a fim de obter o correspondente certificado de cartão, assinado pela MSCA. A chave privada é utilizada somente pelo cartão tacográfico.»;
ii)
O ponto CSM_88 passa a ter a seguinte redação:
«CSM_88
O período de validade de um certificado Card_MA é o seguinte:
—
Para cartões de condutor: 5 anos,
—
Para cartões de empresa: 5 anos,
—
Para cartões de controlo: 2 anos,
—
Para cartões de oficina: 1 ano»;
iii)
Ao ponto CSM_91 são aditados os seguintes parágrafos:
«—
Além disso, para os cartões de controlo, os cartões de empresa e os cartões de oficina apenas, e apenas se tais cartões tiverem sido emitidos durante os primeiros três meses do período de validade de um novo certificado EUR: o certificado EUR de duas gerações, se existir.
Nota respeitante ao último travessão: Por exemplo, nos primeiros três meses do certificado ERCA(3) (ver Figura 1), os cartões referidos devem incluir o certificado ERCA(1). Tal é necessário para assegurar que esses cartões possam ser utilizados para descarregar dados das VU ERCA(1), cuja duração normal de 15 anos e período de 3 meses de descarregamento de dados expiram durante estes meses; Ver último travessão do requisito 13) do anexo IC.»;
e)
A secção 9.1.6 é alterada do seguinte modo:
i)
O ponto CSM_93 passa a ter a seguinte redação:
«CSM_93
Para cada módulo GNSS externo é criado um par de chaves ECC original, denominado EGF_MA. Esta função é assegurada pelos fabricantes de módulos GNSS externos. Sempre que for criado um par de chaves EGF_MA, a parte que cria a chave envia a chave pública à MSCA do país de residência, a fim de obter o correspondente certificado EGF_MA, assinado pela MSCA. A chave privada é utilizada somente pelo módulo GNSS externo.»;
ii)
O ponto CSM_95 passa a ter a seguinte redação:
«CSM_95
O módulo GNSS externo utiliza o seu par de chaves EGF_MA, que consiste na chave privada EGF_MA.SK e na chave pública EGF_MA.PK, exclusivamente para efetuar a autenticação mútua e a concordância de chave de sessão em relação às unidades-veículo, em conformidade com a secção 11.4 do presente apêndice.»;
f)
A secção 9.1.7 é alterada do seguinte modo:
i)
O esquema 1 é substituído pelo esquema seguinte:
Esquema 1
Emissão e utilização de certificados de raiz ERCA, certificados de ligação ERCA, certificados MSCA e certificados de equipamento ou aparelho de gerações diferentes
Second generation ERCA certificate and certificates based on it
Third generation ERCA certificate and certificates based on it
First generation ERCA certificate and certificates based on it
anos
anos
anos
ii)
O ponto 6 das Notas ao esquema 1 passa a ter a seguinte redação:
«6.
Para poupar espaço, a diferença no período de validade entre os certificados Card_MA e Card_Sign é apresentada somente para a primeira geração.»;
g)
A secção 9.2.1.1 é alterada do seguinte modo:
i)
No ponto CSM_106, o primeiro travessão passa a ter a seguinte redação:
«—
Para chaves de segurança do sensor de movimentos de 128 bits: CV = ‘B6 44 2C 45 0E F8 D3 62 0B 7A 8A 97 91 E4 5D 83’»;
ii)
No ponto CSM_107, o primeiro parágrafo passa a ter a seguinte redação:
«Cada fabricante de sensores de movimentos cria uma chave de emparelhamento KP aleatória e original para cada sensor de movimentos e envia cada chave de emparelhamento à respetiva autoridade de certificação do Estado-Membro. A MSCA encripta cada chave de emparelhamento individualmente com a chave de segurança do sensor de movimentos KM e devolve a chave encriptada ao fabricante do sensor de movimentos. Relativamente a cada chave encriptada, a MSCA comunica ao fabricante do sensor de movimentos o número de versão da chave KM associada.»;
iii)
O ponto CSM_108 passa a ter a seguinte redação:
«CSM_108
Cada fabricante de sensores de movimentos cria um número de série único para cada sensor de movimentos e envia todos os números de série à respetiva autoridade de certificação do Estado-Membro. A MSCA encripta cada número de série individualmente com a chave de identificação KID e devolve o número de série encriptado ao fabricante do sensor de movimentos. Relativamente a cada número de série encriptado, a MSCA comunica ao fabricante do sensor de movimentos o número de versão da chave KID associada.»;
h)
A secção 9.2.2.1 é alterada do seguinte modo:
i)
O ponto CSM_123 passa a ter a seguinte redação:
«CSM_123
Relativamente a todas as unidades-veículo: O fabricante de unidades-veículo cria um número de série de VU único e envia-o à autoridade de certificação do respetivo Estado-Membro, num pedido de obtenção de um conjunto de duas chaves DSRC específicas da VU. O número de série da VU tem o tipo de dados
.
Nota:
—
O referido número de série da VU deve ser idêntico ao elemento vuSerialNumber da VuIdentification, ver apêndice 1 e à referência do titular do certificado nos certificados da VU.
—
O número de série da VU pode não ser conhecido no momento em que um fabricante de unidades-veículo solicite as chaves DSRC específicas da VU. Nesse caso, o fabricante de VU envia, em vez disso, o ID de pedido de certificado único que utilizou quando solicitou os certificados da VU; Ver CSM_153. Esse ID de pedido de certificado deve, por conseguinte, ser igual à referência do titular do certificado nos certificados da VU.»;
ii)
No ponto CSM_124, o requisito de informação constante do passo 2 passa a ter a seguinte redação:
«info = número de série da VU, conforme especificado no CSM_123»;
iii)
O ponto CSM_128 passa a ter a seguinte redação:
«CSM_128
A MSCA mantém registos de todas as chaves DSRC específicas da VU que criou, os respetivos números de versão e o número de série da VU ou ID de pedido de certificado utilizado para os obter.»;
i)
Na secção 9.3.1, o primeiro parágrafo do ponto CSM_135 passa a ter a seguinte redação:
«De acordo com a norma ISO 8825-1, utilizar-se-ão as regras distintas de codificação para codificar os objetos de dados dentro dos certificados. O quadro 4 mostra a codificação de todo o certificado, incluindo marcadores e comprimento (bytes).»;
j)
Na secção 9.3.2.3, o ponto CSM_141 passa a ter a seguinte redação:
«CSM_141
Utiliza-se a autorização do titular do certificado para identificar o tipo de certificado. Consiste nos seis bytes mais significativos do ID da aplicação tacográfica, concatenados com o tipo de aparelho, que indica o tipo de aparelho ao qual se destina o certificado. No caso de um certificado de VU, um certificado de cartão de condutor ou um certificado de cartão de oficina, o tipo de aparelho também é utilizado para destrinçar um certificado de autenticação mútua de um certificado para criação de assinaturas digitais (ver secção 9.1 e apêndice 1, tipo de dados EquipmentType).»;
k)
Na secção 9.3.2.5, é aditado o seguinte parágrafo ao ponto CSM_146:
«
Nota: Para um certificado do cartão, o valor do CHR deve ser igual ao valor do cardExtendedSerialNumber no EF_ICC; ver apêndice 2. Para um certificado EGF, o valor do CHR deve ser igual ao valor do sensorGNSSSerialNumber no EF_ICC; ver apêndice 14. Para um certificado de VU, o valor do CHR deve ser igual ao elemento vuSerialNumber da VuIdentification, ver apêndice 1, exceto se o fabricante não conhecer o número de série específico do fabricante no momento em que o certificado é pedido.»;
l)
Na secção 9.3.2.6, o ponto CSM_148 passa a ter a seguinte redação:
«CSM_148
A data de vigência do certificado indica a data e a hora de início do período de validade do certificado.»;
m)
A secção 9.3.3 é alterada do seguinte modo:
i)
No ponto CSM_151, o primeiro parágrafo passa a ter a seguinte redação:
«Ao pedir um certificado, a MSCA deve enviar à ERCA os seguintes dados:»;
ii)
O ponto CSM_153 passa a ter a seguinte redação:
«CSM_153
Num pedido de certificado a uma MSCA, para permitir que esta crie a referência do titular do novo certificado do equipamento, o fabricante do equipamento ou aparelho deve enviar os dados a seguir indicados:
—
Se for conhecido (ver CSM_154), número de série do equipamento, único para o fabricante, para o tipo do equipamento e para o mês de fabrico; caso contrário, um identificador de pedido de certificado único.
—
Mês e ano de fabrico do equipamento ou de pedido do certificado.
O fabricante assegura que estes dados estão corretos e que o certificado devolvido pela MSCA é inserido no equipamento a que se destina.»;
n)
A secção 10.2.1 é alterada do seguinte modo:
i)
No ponto CSM_157, o texto anterior às notas do esquema 4 passa a ter a seguinte redação:
«As unidades-veículo utilizam o protocolo descrito no esquema 4 para verificarem a cadeia de certificados dos cartões tacográficos. Para cada certificado lido a partir do cartão, a VU verifica se o campo relativo à autorização do titular do certificado (CHA) está correto:
—
O campo CHA do certificado do cartão deve indicar um certificado de cartão de autenticação mútua (ver apêndice 1, tipo de dados EquipmentType).
—
O CHA do certificado Card.CA deve indicar uma MSCA.
—
O CHA do certificado Card.Link deve indicar uma ERCA.»;
ii)
No ponto CSM_159, é aditada a seguinte frase:
«Enquanto a memorização de todos os outros tipos de certificado é facultativa, a VU deve obrigatoriamente memorizar um novo certificado de ligação apresentado por um cartão.»;
o)
A secção 10.2.2 é alterada do seguinte modo:
i)
No ponto CSM_161, o texto anterior ao esquema 5 passa a ter a seguinte redação:
«Os cartões tacográficos utilizam o protocolo descrito no esquema 5 para a verificação da cadeia de certificados da VU. Para cada certificado apresentado pela VU, o cartão verifica se o campo relativo à autorização do titular do certificado (CHA) está correto:
—
O CHA do certificado VU.Link deve indicar uma ERCA.
—
O CHA do certificado VU.CA deve indicar uma MSCA.
—
O campo CHA do certificado da VU deve indicar um certificado da VU de autenticação mútua (ver apêndice 1, tipo de dados EquipmentType).»;
ii)
O ponto CSM_165 passa a ter a seguinte redação:
«CSM_165
Se o comando MSE: Set AT tiver êxito, o cartão define o VU.PK indicado, para utilização posterior durante a autenticação do veículo, e memoriza temporariamente Comp(VU.PKeph). Caso dois ou mais comandos MSE: Set AT com êxito sejam enviados antes de ser efetuada a concordância de chave de sessão, o cartão memoriza apenas o último Comp(VU.PKeph) recebido. O cartão reinicializa Comp(VU.PKeph) após um comando GENERAL AUTHENTICATE bem-sucedido.»;
p)
A secção 10.3 é alterada do seguinte modo:
i)
O primeiro parágrafo do ponto CSM_170 passa a ter a seguinte redação:
«Ao lado do desafio do cartão, a VU inclui na assinatura a referência do titular do certificado retirada do certificado do cartão.»;
ii)
No ponto CSM_171, o esquema 6 passa a ter a seguinte redação:
Esquema 6
Protocolo de autenticação da VU
iii)
O ponto CSM_174 passa a ter a seguinte redação:
«CSM_174
Ao receber a assinatura da VU no comando EXTERNAL AUTHENTICATE, o cartão
—
Calcula o testemunho de autenticação mediante a concatenação Card.CHR, o desafio do cartão rcard e o identificador da chave pública efémera da VU Comp(VU.PKeph),
—
Verifica a assinatura da VU utilizando o algoritmo ECDSA, que utiliza o algoritmo de hash ligado ao tamanho da chave do par de chaves VU_MA da VU, em conformidade com o requisito CSM_50, em combinação com o VU.PK e o testemunho de autenticação calculado.»;
q)
Na secção 10.4, o ponto CSM_176 é alterado do seguinte modo:
i)
o ponto 2 passa a ter a seguinte redação:
«2.
A VU envia para o cartão o ponto público VU.PKeph do seu par de chaves efémeras. O ponto público deve ser convertido numa cadeia de octetos, em conformidade com a Orientação Técnica TR-03111. Deve utilizar-se o formato de codificação não compactado. Tal como explicado em CSM_164, a VU criou esse par de chaves efémeras antes da verificação da cadeia de certificado da VU. A VU enviou o identificador da chave pública efémera Comp(VU.PKeph) para o cartão, que o memorizou.»;
ii)
o ponto 6 passa a ter a seguinte redação:
«6.
Utilizando KMAC, o cartão calcula um testemunho de autenticação sobre o identificador de ponto público efémero da VU: TPICC = CMAC(KMAC, VU.PKeph). O ponto público deve revestir o formato utilizado pela VU (ver ponto 2 supra). O cartão envia NPICC e TPICC para a unidade-veículo.»;
r)
Na secção 10.5.2, o ponto CSM_191 passa a ter a seguinte redação:
«CSM_191
Qualquer objeto de dados a encriptar é preenchido de acordo com a norma ISO 7816-4, mediante a utilização do indicador de conteúdo de preenchimento “01”. Relativamente ao cálculo do MAC, os objetos de dados na APDU são preenchidos de acordo com a norma ISO 7816-4.
Nota: O preenchimento para envio seguro de mensagens é efetuado sempre pelo nível de envio seguro de mensagens e não pelos algoritmos CMAC ou CBC.
Síntese e exemplos
Uma APDU de comando com envio seguro de mensagens aplicado terá a estrutura seguinte, consoante a caixa do comando não seguro correspondente (DO é objeto de dados):
Caixa 1
:
CLA INS P1 P2 || Lc' || DO ‘8E’ || Le
Caixa 2
:
CLA INS P1 P2 || Lc' || DO ‘97’ || DO ‘8E’ || Le
Caixa 3 (byte INS par)
:
CLA INS P1 P2 || Lc' || DO ‘81’ || DO ‘8E’ || Le
Caixa 3 (byte INS ímpar)
:
CLA INS P1 P2 || Lc' || DO ‘B3’ || DO ‘8E’ || Le
Caixa 4 (byte INS par)
:
CLA INS P1 P2 || Lc' || DO ‘81’ || DO ‘97’ || DO ‘8E’ || Le
Caixa 4 (byte INS ímpar)
:
CLA INS P1 P2 || Lc' || DO ‘B3’ || DO ‘97’ || DO ‘8E’ || Le
onde Le = ‘00’ ou ‘00 00’, consoante se utilizem campos de comprimento curto ou campos de comprimento alargado; ver norma ISO 7816-4.
Uma APDU de resposta, com envio seguro de mensagens aplicado, tem a seguinte estrutura, consoante a caixa do comando não seguro correspondente (DO é objeto de dados):
Caixa 1 ou 3
:
DO ‘99’ || DO ‘8E’ || SW1SW2
Caixa 2 ou 4 (byte INS par) sem encriptação
:
DO ‘81’ || DO ‘99’ || DO ‘8E’ || SW1SW2
Caixa 2 ou 4 (byte INS par) com encriptação
:
DO ‘87’ || DO ‘99’ || DO ‘8E’ || SW1SW2
Caixa 2 ou 4 (byte INS ímpar) sem encriptação
:
DO ‘B3’ || DO ‘99’ || DO ‘8E’ || SW1SW2
Nota: A caixa 2 ou 4 (byte INS ímpar) com encriptação nunca é utilizada na comunicação entre uma VU e um cartão.
Seguem-se três exemplos de transformações da APDU para comandos com código INS par. O esquema 8 apresenta uma APDU de comando da caixa 4 autenticada, o esquema 9 apresenta uma APDU de resposta da caixa 1/caixa 3 autenticada e o esquema 10 apresenta uma APDU de resposta da caixa 2/caixa 4 encriptada e autenticada.
Esquema 8
Transformação de uma APDU de comando da caixa 4 autenticada
Esquema 9
Transformação de uma APDU de resposta da caixa 1/caixa 3 autenticada
Esquema 10
Transformação de uma APDU de resposta da caixa 2/caixa 4
»
s)
Na secção 10.5.3, o ponto CSM_193 passa a ter a seguinte redação:
«CSM_193
O cartão tacográfico interrompe uma sessão de envio seguro de mensagens contínua se e só se ocorrer uma das seguintes condições:
—
recebe uma APDU de comando simples,
—
deteta um erro de envio seguro de mensagens numa APDU de comando:
—
está ausente um (esperado) objeto de dados do envio seguro de mensagens, está incorreta a ordem dos objetos de dados ou está incluído um objeto de dados desconhecido,
—
está incorreto um objeto de dados do envio seguro de mensagens: por exemplo, o valor MAC está incorreto ou a estrutura TLV está incorreta,
—
é desligado da energia elétrica ou reinicializado,
—
a VU inicia o processo da sua autenticação,
—
é atingido o limite para o número de comandos e respostas associados na sessão atual. Em relação a um determinado cartão, esse limite é definido pelo fabricante, tendo em conta os requisitos de segurança do equipamento informático utilizado, com um valor máximo de 240 comandos SM e respostas associadas por sessão»;
t)
A secção 11.3.2 é alterada do seguinte modo:
i)
O primeiro parágrafo do ponto CSM_208 passa a ter a seguinte redação:
Não diz respeito à versão portuguesa.
ii)
O ponto CSM_210 passa a ter a seguinte redação:
Não diz respeito à versão portuguesa.
u)
Na secção 11.3.3, o primeiro parágrafo do ponto CSM_211 passa a ter a seguinte redação:
«Durante o funcionamento normal, uma unidade-veículo e um EGF utilizam o protocolo descrito no esquema 11 para verificar a validade temporal do certificado EGF_MA memorizado e para definir a chave pública VU_MA para autenticação subsequente da VU. Durante o funcionamento normal, não têm lugar verificações mútuas adicionais do certificado.»;
v)
Na secção 12.3, o quadro 6 passa a ter a seguinte redação:
«Quadro 6
Número de bytes de dados de texto simples e encriptados por instrução definida na norma ISO 16844-3
Instruções
Pedido / resposta
Descrição dos dados
N.o de bytes de dados de texto simples, de acordo com
a norma ISO 16844-3
N.o de bytes de dados de texto simples que utilizam chaves AES
N.o de bytes de dados encriptados ao utilizar chaves AES com comprimento em bits
128
192
256
10
Pedido
Dados de autenticação + número de ficheiro
8
8
16
16
16
11
Resposta
Dados de autenticação + conteúdo do ficheiro
16 ou 32, consoante o ficheiro
16 or32 consoante o ficheiro
32 / 48
32 / 48
32 / 48
41
Pedido
Número de série MoS
8
8
16
16
16
41
Resposta
Chave de emparelhamento
16
16 / 24 / 32
16
32
32
42
Pedido
Chave de sessão
16
16 / 24 / 32
16
32
32
43
Pedido
Informações do emparelhamento
24
24
32
32
32
50
Resposta
Informações do emparelhamento
24
24
32
32
32
70
Pedido
Dados de autenticação
8
8
16
16
16
80
Resposta
Valor do contador MoS + dados autenticados
8
8
16
16
16»
w)
Na secção 13.1, o requisito relativo ao número de série da VU constante do ponto CSM_224 passa a ter a seguinte redação:
«Número de série da VU
número de série da VU ou ID de pedido de certificado (tipo de dados VuSerialNumber ou CertificateRequestID) – ver CSM_123»;
x)
Na secção 13.3, o segundo travessão do ponto CSM_228 passa a ter a seguinte redação:
«2.
O cartão de controlo utiliza a chave de segurança DSRC indicada em combinação com o número de série da VU ou com o ID de pedido de certificado nos dados de segurança DSRC, para derivar as chaves DSRC específicas da VU K_VUDSRC_ENC e K_VUDSRC_MAC, em conformidade com o requisito CSM_124.»;
y)
A secção 14.3 é alterada do seguinte modo:
i)
No ponto CSM_234, o texto anterior às notas do esquema 13 passa a ter a seguinte redação:
«Um IDE pode executar a verificação de uma assinatura em dados descarregados por si próprio ou utilizar um cartão de controlo para esse efeito. Caso utilize um cartão de controlo, a verificação da assinatura ocorre como mostra o esquema 13. Para verificar a validade temporal de um certificado apresentado pelo IDE, o cartão de controlo utiliza o seu relógio interno, em conformidade com o requisito CSM_167. O cartão de controlo atualiza a sua hora se a data de vigência de um certificado «fonte de tempo válida» autêntico for mais recente do que a hora atual do cartão. Como fonte de tempo válida, o cartão aceita apenas os seguintes certificados:
—
Certificados de ligação ERCA da segunda geração
—
Certificados MSCA da segunda geração
—
Certificados VU_Sign ou Card_Sign da segunda geração emitidos pelo mesmo país do próprio certificado dos cartões do cartão de controlo.
Caso realize a verificação da própria assinatura, o IDE verifica a autenticidade e a validade de todos os certificados, na cadeia de certificado no ficheiro de dados e verifica a assinatura na sequência de dados do esquema de assinatura definido em DSS. Em ambos os casos, para cada certificado lido a partir do ficheiro de dados, é necessário verificar se o campo da autorização do titular do certificado (CHA) está correto:
—
O campo CHA do certificado de EQT deve indicar um certificado da VU ou de cartão (consoante o que for aplicável) para assinatura (ver apêndice 1, tipo de dados EquipmentType).
—
O CHA do certificado EQT.CA deve indicar uma MSCA.
—
O CHA do certificado EQT.Link deve indicar uma ERCA.»;
ii)
O esquema 13 é substituído pelo esquema seguinte:
«
Esquema 13
Protocolo de verificação da assinatura num ficheiro de dados descarregados
»
37)
O apêndice 12 é alterado do seguinte modo:
a)
O capítulo 3 é alterado do seguinte modo:
i)
No ponto GNS_4, o segundo parágrafo após a figura 2 passa a ter a seguinte redação:
«A resolução da posição baseia-se no formato da frase RMC atrás descrita. A primeira parte dos campos 3) e 5) serve para representar os graus. O resto serve para representar os minutos, com três casas decimais. Portanto, a resolução é de 1/1000 de minuto ou 1/60000 de grau (porque um minuto é 1/60 de um grau).»;
ii)
O ponto GNS_5 passa a ter a seguinte redação:
«GNS_5
A unidade-veículo memoriza na sua base de dados as informações de posição relativas à latitude e à longitude, com uma resolução de 1/10 de minuto ou 1/600 de grau, conforme refere o apêndice 1 relativamente a GeoCoordinates de tipo.
A VU pode utilizar o comando GPS DOP e satélites ativos (GSA) para determinar e registar a disponibilidade e a exatidão do sinal. O comando HDOP é utilizado especialmente para fornecer uma indicação do nível de exatidão dos dados de localização registados (ver 4.2.2). A VU memoriza o valor da diluição de precisão horizontal (HDOP) calculado como o mínimo dos valores HDOP recolhidos nos sistemas GNSS disponíveis.
O Id GNSS indica o Id NMEA correspondente para cada sistema de aumento com recurso a satélites (SBAS) GNSS.
Figura 3
Estrutura da frase GSA
»
iii)
O ponto GNS_6 passa a ter a seguinte redação:
«GNS_6
A frase GSA deve ser memorizada com o número de registo “02” a “06”»;
b)
O capítulo 4.2.1 é alterado do seguinte modo:
i)
O ponto GNS_16 passa a ter a seguinte redação:
Não diz respeito à versão portuguesa.
ii)
O ponto GNS_18 passa a ter a seguinte redação:
«GNS_18
Em relação às funções 1 — “recolha e distribuição de dados GNSS”, 2 — “recolha dos dados de configuração do módulo GNSS externo” e 3 — “protocolo de gestão”, o emissor-recetor seguro GNSS deve simular um cartão inteligente com uma arquitetura de sistema de ficheiros composta por um ficheiro principal (MF), um ficheiro dedicado (DF) com o identificador de aplicação especificado no apêndice 1, secção 6.2 (‘FF 44 54 45 47 4D’) e com três EF que possuem certificados e um ficheiro elementar único (EF.EGF) com identificador de ficheiro igual a ‘2F2F’, conforme consta do quadro 1.»;
iii)
O ponto GNS_20 passa a ter a seguinte redação:
«GNS_20
O emissor-recetor seguro GNSS deve utilizar uma memória para guardar os dados e ser capaz de executar, pelo menos, 20 milhões de ciclos de escrita/leitura. À parte este aspeto, a conceção e a aplicação internas do emissor-recetor seguro GNSS são deixadas ao critério dos fabricantes.
O mapeamento de números e dados de registo consta do quadro 1. De referir que há cinco frases GSA para o sistema de aumento com recurso a satélites (SBAS) GNSS.»;
c)
No capítulo 4.2.2, o ponto 5 do requisito GNS_23 passa a ter a seguinte redação:
«5.
O processador da VU verifica os dados recebidos extraindo a informação (por exemplo, latitude, longitude, hora) da frase RMC NMEA. A frase RMC NMEA inclui a informação se a posição for válida. Se a posição não for válida, os dados de localização ainda não estão disponíveis e não podem ser utilizados para registar a posição do veículo. Se a posição for válida, o processador da VU extrai também os valores de HDOP de frases GSA NMEA e calcula o valor mínimo nos sistemas de satélite disponíveis (ou seja, quando a determinação de posição está disponível).»;
d)
No capítulo 4.4.1, o ponto GNS_28 passa a ter a seguinte redação:
«GNS_28
Se não conseguir comunicar com o módulo GNSS externo acoplado durante mais de 20 minutos seguidos, a VU cria e regista um incidente do tipo EventFaultType com o valor de enumeração ‘0E’H Falha de comunicação com o módulo GNSS externo e com o período de tempo definido para a hora atual. O incidente só será criado se se verificarem as duas condições seguintes: a) o tacógrafo inteligente não está no modo de calibração; b) o veículo está em movimento. Neste contexto, desencadeia-se um erro de comunicação quando o emissor-recetor seguro da VU não recebe mensagem de resposta após uma mensagem de pedido descrita em 4.2.»;
e)
Na secção 4.4.2, o ponto GNS_29 passa a ter a seguinte redação:
«GNS_29
Se o módulo GNSS externo tiver sido violado, o emissor-recetor seguro GNSS apaga toda a sua memória, incluindo material criptográfico. Conforme descrito em GNS_25 e GNS_26, a VU deteta adulteração se a resposta tiver estatuto ‘6690’. A VU cria então um incidente do tipo EventFaultType com o valor de enumeração ‘19’H deteção de adulteração de GNSS. Em alternativa, o módulo GNSS externo poderá não voltar a responder a qualquer pedido externo.»;
f)
Na secção 4.4.3, o ponto GNS_30 passa a ter a seguinte redação:
«GNS_30
Se o emissor-recetor seguro GNSS não receber dados do recetor GNSS durante mais de 3 horas seguidas, o emissor-recetor seguro GNSS cria uma mensagem de resposta para o comando READ RECORD com número RECORD igual a ‘01’, com um campo de dados de 12 bytes, todos definidos para 0xFF. Após a receção da mensagem de resposta com este valor do campo de dados, a VU cria e regista um incidente do tipo EventFaultType com o valor de enumeração ‘0D’H incidente Ausência de informação sobre a posição do recetor GNSS com um período de tempo igual ao valor atual da hora apenas se se verificarem as duas condições seguintes: a) o tacógrafo inteligente não está no modo de calibração; b) o veículo está em movimento.»;
g)
Na secção 4.4.4, o texto do ponto GNS_31 até à figura 4 passa a ter a seguinte redação:
«Se detetar que o certificado EGF utilizado para autenticação mútua já não é válido, a VU cria e regista um incidente do aparelho de controlo de tipo EventFaultType com o valor de enumeração
“1B”H certificado do módulo GNSS externo expirado com um período de tempo igual ao valor atual da hora. A VU continua a utilizar os dados de posição GNSS recebidos.»;
h)
Na secção 5.2.1, o ponto GNS_34 passa a ter a seguinte redação:
«GNS_34
Se não receber dados do recetor GNSS durante mais de 3 horas seguidas, a VU cria e regista um incidente do tipo EventFaultType com o valor de enumeração ‘0D’H Ausência de informação sobre a posição do recetor GNSS com um período de tempo igual ao valor atual da hora apenas se se verificarem as duas condições seguintes: a) o tacógrafo inteligente não está no modo de calibração; b) o veículo está em movimento.»;
i)
A secção 6 passa a ter a seguinte redação:
«6. CONFLITO DE TEMPO GNSS
Se detetar uma discrepância de mais de 1 minuto entre o tempo da função de medição do tempo da unidade-veículo e o tempo proveniente do recetor GNSS, a VU regista um incidente do tipo EventFaultType com o valor de enumeração ‘0B’H conflito de tempo (GNSS versus relógio interno da VU). Após a produção de um incidente de conflito de tempo, a VU não verifica a discrepância de tempo para as 12 horas seguintes. O incidente não se produz se o recetor GNSS não tiver detetado qualquer sinal GNSS válido nos últimos 30 dias.»;
38)
O apêndice 13 é alterado do seguinte modo:
a)
Na secção 2, o quarto parágrafo passa a ter a seguinte redação:
«Para esclarecimento, o presente apêndice não especifica:
—
O funcionamento e a gestão da recolha dos dados na VU (a especificar noutras secções do Regulamento ou então tratar-se-á de uma função de conceção de produto).
—
A forma de apresentação dos dados recolhidos para aplicações alojadas no dispositivo externo.
—
Disposições de segurança de dados sobre o que fornece o Bluetooth® (como encriptação) relativamente ao conteúdo dos dados [a especificar noutras secções do Regulamento (Apêndice 11 — Mecanismos comuns de segurança)].
—
Os protocolos Bluetooth® utilizados pela interface ITS.»;
b)
Na secção 4.2, o terceiro parágrafo passa a ter a seguinte redação:
Não diz respeito à versão portuguesa.
c)
A secção 4.3 é alterada do seguinte modo:
i)
O primeiro parágrafo passa a ter a seguinte redação:
«Por motivos de segurança, a VU requer um sistema de autorização de código PIN separado do emparelhamento por Bluetooth. Todas as VU devem ser capazes de criar códigos PIN para fins de autenticação, compostos por quatro dígitos, pelo menos. Sempre que um dispositivo externo emparelhar com a VU, tem de fornecer o código PIN correto antes de receber quaisquer dados.»;
ii)
A seguir ao quadro 1, o terceiro parágrafo passa a ter a seguinte redação:
«Embora o fabricante possa oferecer a possibilidade de alterar o código PIN, diretamente através da VU, o código PUC não é alterável. A alteração do código PIN, quando possível, requer a introdução do código PIN atual diretamente na VU.»;
d)
Na secção 4.4, o segundo parágrafo a seguir à rubrica «Campo de dados» passa a ter a seguinte redação:
«Se os dados a tratar ultrapassarem o espaço disponível numa mensagem, serão divididos em várias submensagens. Cada submensagem deve ter o mesmo cabeçalho e o mesmo SID, mas conterá um contador de 2 bytes, contracorrente (CC) e contador de máx. (CM), para indicar o número da submensagem. Para efeitos de verificar erros e interromper, o dispositivo de receção acusa cada uma das submensagens. O dispositivo de receção pode aceitar a submensagem, pedir a sua retransmissão, pedir o recomeço ao dispositivo de receção ou interromper a transmissão.»;
e)
O anexo 1 é alterado do seguinte modo:
i)
O título passa a ter a seguinte redação:
«1) LISTA DE DADOS DISPONÍVEIS ATRAVÉS DA INTERFACE ITS»;
ii)
É inserido o seguinte texto no quadro constante do ponto 3, após a rubrica «Ausência de informações sobre a posição do recetor GNSS»:
«Erro de comunicação com o módulo GNSS externo
—
o incidente mais longo de cada um dos últimos 10 dias de ocorrência,
—
os 5 incidentes mais longos dos últimos 365 dias.
—
data e hora do início do incidente,
—
data e hora do final do incidente,
—
tipo, número, Estado-Membro emissor e geração de qualquer cartão inserido no início e/ou no final do incidente,
—
número de incidentes similares nesse dia.»
iii)
No ponto 5, é aditado o seguinte travessão:
«—
Falha da interface ITS (quando aplicável)»;
f)
As especificações ASN.1 constantes do anexo 3 são alteradas do seguinte modo:
i)
São aditadas as seguintes linhas 206a a 206e após a linha 206:
A rubrica 5.5 constante do índice passa a ter a seguinte redação:
«5.5 Apoio à Diretiva (UE) 2015/719 … 490»;
b)
No ponto 2, o terceiro parágrafo passa a ter a seguinte redação:
«Neste cenário, o tempo disponível para a comunicação é limitado, porque a comunicação é orientada e com uma conceção de curto alcance. Além disso, os mesmos meios de comunicação destinados à monitorização tacográfica à distância (RTM) podem ser igualmente utilizados pelas autoridades de controlo para outras aplicações (como os pesos e as dimensões máximos dos veículos pesados de mercadorias, definidos na Diretiva (UE) 2015/719) e essas operações podem ser distintas ou sequenciais, ao critério das autoridades de controlo competentes.»;
c)
A secção 5.1 é alterada do seguinte modo:
i)
No ponto DSC_19, o décimo segundo travessão passa a ter a seguinte redação:
«—
A antena DSRC-VU deve ser posicionada num local onde otimize a comunicação DSRC entre o veículo e a antena do lado da estrada, estando esta instalada a 15 m de distância à frente do veículo e a 2 m de altura, para apontar ao centro horizontal e vertical do para-brisas. Nos veículos ligeiros, é adequada a parte superior do para-brisas. Em todos os demais veículos, a antena DSRC deve ser instalada quer perto da parte inferior quer superior do para-brisas.»;
ii)
No ponto DSC_22, o primeiro parágrafo passa a ter a seguinte redação:
«O fator forma da antena não está definido e deve ser uma decisão comercial, desde que a DSRC-VU montada satisfaça os requisitos de conformidade definidos na secção 5. A antena é posicionada conforme determinado em DSC_19 e aceita eficientemente os casos de utilização descritos em 4.1.2 e 4.1.3.»;
d)
Na secção 5.4.3, a sequência 7 passa a ter a seguinte redação:
Não diz respeito à versão portuguesa.
e)
Na secção 5.4.4, a definição do módulo ASN.1 constante do ponto DCS_40 é alterada do seguinte modo:
«tp15638VehicleRegistrationPlate LPN – Vehicle Registration Plate as per EN 155091»
»
ii)
É aditada a seguinte nota de rodapé 1:
«1.
Se um LPN contiver um AlphabetIndicator LatinAlphabetNo2 ou latinCyrillicAlphabet, os carateres especiais são remapeados na unidade de inquérito rodoviária através de regras especiais em conformidade com o anexo E da norma ISO/DIS 14 906,2»;
iii)
O expoente 2 é suprimido da linha onde se define Timestamp of current record;
Na secção 5.4.5, o elemento RTM12 constante do quadro 14.3 passa a ter a seguinte redação:
«RTM12
Sensor Fault
The VU shall generate an integer value for data element RTM12.
The VU shall assign to the variable sensorFault a value of:
—
1 if an event of type ‘35H’ Sensor fault has been recorded in the last 10 days,
—
2 if an event of type GNSS receiver fault (either internal or external with enum values ‘36’H or ‘37’ H) has been recorded in the last 10 days.
—
3 if an event of type ‘0E’H Communication error with the external GNSS facility event has been recorded in the last 10 days.
—
4 If both Sensor Fault and GNSS receiver faults have been recorded in the last 10 days
—
5 If both Sensor Fault and Communication error with the external GNSS facility event have been recorded in the last 10 days
—
6 If both GNSS receiver fault and Communication error with the external GNSS facility event have been recorded in the last 10 days
—
7 If all three sensor faults, have been recorded in the last 10 days ELSE it shall assign a value of 0 if no events have been recorded in the last 10 days
–sensor fault one octet as per data dictionary
»
g)
Na secção 5.4.6, o ponto DSC_43 passa a ter a seguinte redação:
«DSC_43
Relativamente a todos os intercâmbios DSRC, os dados devem ser codificados utilizando PER (regras de codificação compactadas) NÃO ALINHADAS, exceto
e
, que são codificados utilizando OER (regras de codificação de octetos) definidas na norma ISO/IEC 8825-7, Rec. ITU-T X.696.»;
h)
Na secção 5.4.7, na quarta coluna do quadro 14.9, o texto da célula que descreve
passa a ter a seguinte redação:
«Identificador de objeto da norma seguida (parte e versão). Exemplo: ISO (1) Standard (0) TARV (15638) part9(9) Version1 (1).
O primeiro octeto é 06H, o identificador de objeto. O segundo octeto é 06H, o seu comprimento. Os 6 octetos subsequentes codificam o identificador de objeto do exemplo.»;
i)
As secções 5.5 e 5.5.1 passam a ter a seguinte redação:
«5.5. Apoio à Diretiva (UE) 2015/719
5.5.1. Panorâmica
DSC_59
Em cumprimento da Diretiva (UE) 2015/719, relativa aos pesos e dimensões máximos dos veículos pesados de mercadorias, o protocolo de transação para descarregamento de dados OWS através da ligação da interface DSRC de 5,8 GHz é o mesmo utilizado para os dados RTM (ver 5.4.1). A única diferença é que o identificador de objeto relativo à norma TARV se refere à norma ISO 15638 (TARV), parte 20, relativa a WOB/OWS.»;
j)
Na secção 5.6.1, a alínea a) do ponto DSC_68 passa a ter a seguinte redação:
«a)
A fim de que possam ser contratados fornecedores diferentes para o fornecimento de VU e DSRC-VU e, na verdade, diferentes lotes de DSRC-VU, a conexão entre a VU e a DSRC-VU não interna à VU deve ser uma conexão-padrão aberta. A VU deve conectar-se à DSRC-VU»;
k)
Na secção 5.7.1, o ponto DSC_77 passa a ter a seguinte redação:
«DSC_77
Os dados devem ser fornecidos, já protegidos, pela função VUSM à DSRC-VU. O VUSM verifica se os dados registados na DSRC-VU foram registados corretamente. O registo e a comunicação de erros na transferência de dados da VU para a memória da DSRC-VU são registados com o tipo EventFaultType e o valor de enumeração definido como falha de comunicação ‘0C’H com o módulo de comunicação à distância juntamente com o período de tempo.»;
40)
O apêndice 15 é alterado do seguinte modo:
a)
Na secção 2.2, o primeiro parágrafo passa a ter a seguinte redação:
«Entende-se que os cartões tacográficos da primeira geração são interoperáveis com as unidades-veículo da primeira geração (em conformidade com o anexo IB do Regulamento (CEE) n.o 3821/85, ao passo que os cartões tacográficos da segunda geração são interoperáveis com as unidades-veículo da segunda geração (em conformidade com o anexo IC do presente regulamento). Aplicam-se, além disso, os requisitos infra.»;
b)
Na secção 2.4.1, o ponto MIG_11 é alterado do seguinte modo:
i)
O primeiro travessão passa a ter a seguinte redação:
«—
cartões inteligentes e cartões com circuito integrado EF não assinados (facultativos),»;
ii)
O terceiro travessão passa a ter a seguinte redação:
«—
os outros EF de dados da aplicação (dentro do DF Tachograph) solicitados pelo protocolo de descarregamento do cartão da primeira geração; esta informação deve ser protegida com uma assinatura digital, de acordo com os mecanismos de segurança da primeira geração.
O descarregamento não inclui EF de dados da aplicação presentes apenas em cartões de condutor (e de oficina) da segunda geração (EF de dados da aplicação dentro do DF Tachograph_G2).»;
c)
Na secção 2.4.3, os pontos MIG_014 e MIG_015 passam a ter a seguinte redação:
«MIG_014
Fora do quadro do controlo dos condutores pelas autoridades de controlo de países terceiros, os dados são descarregados de unidades-veículo da segunda geração que utilizam mecanismos de segurança da segunda geração e o protocolo de descarregamento de dados definido no apêndice 7 do presente anexo.
MIG_015
Para permitir o controlo dos condutores por autoridades não pertencentes à UE, poderá ainda ser igualmente possível descarregar dados de unidades-veículo da segunda geração utilizando mecanismos de segurança da primeira geração. Os dados descarregados devem, então, ter o mesmo formato que os dados descarregados de uma unidade-veículo da primeira geração. Esta funcionalidade pode ser selecionada por meio de comandos no menu.»;
ANEXO II
O anexo II do Regulamento (UE) 2016/799 é alterado do seguinte modo:
1)
No capítulo I, o ponto 1, alínea b), passa a ter a seguinte redação:
«b)
o número de homologação, correspondente ao número do certificado de homologação atribuído ao protótipo do aparelho de controlo ou à folha de registo ou cartão tacográfico, colocado na proximidade daquele retângulo.»;
2)
No capítulo III, o ponto 5 passa a ter a seguinte redação:
«5.
Data da apresentação para homologação …»;
3)
No Capítulo IV, o ponto 5 passa a ter a seguinte redação:
In force
