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) 2021/1228 of 16 July 2021 amending Implementing Regulation (EU) 2016/799 as regards the requirements for the construction, testing, installation, operation and repair of smart tachographs and their components (Text with EEA relevance)
Regulamento de Execução (UE) 2021/1228 da Comissão de 16 de julho de 2021 que altera o Regulamento de Execução (UE) 2016/799 no respeitante aos requisitos para construção, ensaio, instalação, funcionamento e reparação de tacógrafos inteligentes e seus componentes (Texto relevante para efeitos do EEE)
Regulamento de Execução (UE) 2021/1228 da Comissão de 16 de julho de 2021 que altera o Regulamento de Execução (UE) 2016/799 no respeitante aos requisitos para construção, ensaio, instalação, funcionamento e reparação de tacógrafos inteligentes e seus componentes (Texto relevante para efeitos do EEE)
C/2021/5125
JO L 273 de 30.7.2021, pp. 1–140
(BG, ES, CS, DA, DE, ET, EL, EN, FR, GA, HR, IT, LV, LT, HU, MT, NL, PL, PT, RO, SK, SL, FI, SV)
In force: This act has been changed. Current consolidated version: 21/08/2023
REGULAMENTO DE EXECUÇÃO (UE) 2021/1228 DA COMISSÃO
de 16 de julho de 2021
que altera o Regulamento de Execução (UE) 2016/799 no respeitante aos requisitos para construção, ensaio, instalação, funcionamento e reparação de tacógrafos inteligentes 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,
Considerando o seguinte:
(1)
O Regulamento (UE) n.o 165/2014 introduziu os tacógrafos inteligentes, 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 com sistemas de transporte inteligentes.
(2)
Os requisitos técnicos para a construção, o ensaio, a instalação, o funcionamento e a reparação de tacógrafos e seus componentes estão previstos no Regulamento de Execução (UE) 2016/799 da Comissão (2).
(3)
O Regulamento (UE) n.o 165/2014 e o Regulamento (CE) n.o 561/2006 do Parlamento Europeu e do Conselho (3) foram alterados pelo Regulamento (UE) 2020/1054 do Parlamento Europeu e do Conselho (4). O Regulamento (UE) 2020/1054 exige a aplicação de características adicionais no tacógrafo inteligente. Consequentemente, ao alterar o Regulamento (UE) 2016/799, deve ser definida uma nova versão do tacógrafo inteligente.
(4)
Nos termos do artigo 8.o, n.o 1, do Regulamento (UE) n.o 165/2014, a posição do veículo é automaticamente registada de cada vez que o veículo atravessa a fronteira de um Estado-Membro e de cada vez que o veículo efetua operações de carga ou descarga.
(5)
A interface com sistemas de transporte inteligentes, que é facultativa na versão do tacógrafo inteligente aplicada a partir de 15 de junho de 2019, deve ser obrigatória na nova versão do tacógrafo inteligente.
(6)
A nova versão do tacógrafo inteligente deve estar preparada para autenticar o sinal do satélite Galileu assim que este último estiver operacional.
(7)
A fim de evitar a substituição física do aparelho de controlo sempre que for adotada uma modificação às especificações técnicas do tacógrafo, é necessário garantir a possibilidade de introduzir futuras funcionalidades no tacógrafo, bem como de melhorar essas funcionalidades, através de atualizações do software.
(8)
O Regulamento (UE) 2016/799 permite a instalação de um adaptador entre o sensor de movimentos e o tacógrafo para veículos que, apesar de terem um peso inferior a 3,5 toneladas, possam por vezes ultrapassar esse limiar, por exemplo, quando atrelados a um reboque. Na sequência da alteração do Regulamento (CE) n.o 561/2006, a obrigação de instalar um tacógrafo foi alargada aos veículos com peso superior a 2,5 toneladas. A instalação obrigatória do tacógrafo inteligente em veículos comerciais ligeiros torna necessário aumentar o nível de segurança proporcionado pelo adaptador mediante a instalação de um sensor interno no tacógrafo, que seja independente do sinal do sensor de movimentos.
(9)
As medidas previstas no presente regulamento estão em conformidade com o parecer do comité instituído pelo artigo 42.o, n.o 1, do Regulamento (UE) n.o 165/2014,
ADOTOU O PRESENTE REGULAMENTO:
Artigo 1.o
O anexo IC do Regulamento (UE) 2016/799 é alterado em conformidade com o anexo 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 é aplicável a partir de 21 de agosto de 2023.
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 dá execução ao 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) Regulamento (CE) n.o 561/2006 do Parlamento Europeu e do Conselho, de 15 de março de 2006, relativo à harmonização de determinadas disposições em matéria social no domínio dos transportes rodoviários, que altera os Regulamentos (CEE) n.o 3821/85 e (CEE) n.o 2135/98 do Conselho e revoga o Regulamento (CEE) n.o 3820/85 do Conselho (JO L 102 de 11.4.2006, p. 1).
(4) Regulamento (UE) 2020/1054 do Parlamento Europeu e do Conselho, de 15 de julho de 2020, que altera o Regulamento (CE) n.o 561/2006 no que diz respeito aos requisitos mínimos em matéria de tempos máximos de condução diária e semanal, à duração mínima das pausas e dos períodos de repouso diário e semanal e o Regulamento (UE) n.o 165/2014 no que diz respeito ao posicionamento por meio de tacógrafos (JO L 249 de 31.7.2020, p. 1).
ANEXO
O anexo IC do Regulamento de Execução (UE) 2016/799 é alterado do seguinte modo:
(1)
O índice é alterado do seguinte modo:
(a)
É inserido o seguinte ponto 3.6.4:
«3.6.4
Introdução de operações de carga/descarga»;
(b)
É inserido o seguinte ponto 3.9.18:
«3.9.18
Incidente de anomalia no GNSS»;
(c)
São inseridos os seguintes pontos 3.12.17, 3.12.18 e 3.12.19:
«3.12.17
Travessia de fronteiras
3.12.18
Operações de carga/descarga
3.12.19
Mapa digital»;
(d)
O ponto 3.20 passa a ter a seguinte redação:
«3.20
Intercâmbio de dados com dispositivos externos adicionais»;
(e)
São inseridos os seguintes pontos 3.27 e 3.28:
«3.27
Controlo da travessia de fronteiras
3.28
Atualização de software»;
(f)
É inserido o seguinte ponto 4.5.3.2.1.1:
«4.5.3.2.1.1
Identificação da aplicação adicional (não acessível na versão 1 das unidades-veículo da segunda geração)»;
(g)
São inseridos os seguintes pontos 4.5.3.2.17 a 4.5.3.2.22:
«4.5.3.2.17
Estatuto de autenticação de posições relacionadas com locais de início e/ou final dos períodos de trabalho diário (não acessível na versão 1 das unidades-veículo da segunda geração)
4.5.3.2.18
Estatuto de autenticação de posições em que são atingidas três horas de tempo de condução acumulado (não acessível na versão 1 das unidades-veículo da segunda geração)
4.5.3.2.19
Travessia de fronteiras (não acessível na versão 1 das unidades-veículo da segunda geração)
4.5.3.2.20
Operações de carga/descarga (não acessível na versão 1 das unidades-veículo da segunda geração)
4.5.3.2.21
Entradas do tipo de carga (não acessível na versão 1 das unidades-veículo da segunda geração)
4.5.3.2.22
Configurações da VU (unidade-veículo) (não acessível na versão 1 das unidades-veículo da segunda geração)»;
(h)
É inserido o seguinte ponto 4.5.4.2.1.1:
«4.5.4.2.1.1
Identificação da aplicação adicional (não acessível na versão 1 das unidades-veículo da segunda geração)»;
(i)
São inseridos os seguintes pontos 4.5.4.2.16 a 4.5.4.2.22:
«4.5.4.2.16
Estatuto de autenticação de posições relacionadas com locais de início e/ou final dos períodos de trabalho diário (não acessível na versão 1 das unidades-veículo da segunda geração)
4.5.4.2.17
Estatuto de autenticação de posições em que são atingidas três horas de tempo de condução acumulado (não acessível na versão 1 das unidades-veículo da segunda geração)
4.5.4.2.18
Travessia de fronteiras (não acessível na versão 1 das unidades-veículo da segunda geração)
4.5.4.2.19
Operações de carga/descarga (não acessíveis na versão 1 das unidades-veículo da segunda geração)
4.5.4.2.20
Entradas do tipo de carga (não acessíveis na versão 1 das unidades-veículo da segunda geração)
4.5.4.2.21
Dados adicionais relativos à calibração (não acessíveis na versão 1 das unidades-veículo da segunda geração)
4.5.4.2.22
Configurações da VU (não acessíveis na versão 1 das unidades-veículo da segunda geração)»;
(j)
É inserido o seguinte ponto 4.5.5.2.1.1 após o ponto 4.5.5.2.1:
«4.5.5.2.1.1
Identificação da aplicação adicional (não acessível na versão 1 das unidades-veículo da segunda geração)»;
(k)
É inserido o seguinte ponto 4.5.5.2.6:
«4.5.5.2.6
Configurações da VU (não acessível na versão 1 das unidades-veículo da segunda geração)»;
(l)
É inserido o seguinte ponto 4.5.6.2.1.1 a seguir ao ponto 4.5.6.2.1:
«4.5.6.2.1.1
Identificação da aplicação adicional (não acessível na versão 1 das unidades-veículo da segunda geração)»;
(m)
É inserido o seguinte ponto 4.5.6.2.6:
«4.5.6.2.6
Configurações da VU (não acessível na versão 1 das unidades-veículo da segunda geração)»;
(2)
O texto introdutório antes da lista de apêndices passa a ter a seguinte redação:
«INTRODUÇÃO
O presente anexo contém os requisitos destinados aos aparelhos de controlo e cartões tacográficos da segunda geração.
Estão a ser instalados, desde 15 de junho de 2019, aparelhos de controlo da segunda geração nos veículos matriculados pela primeira vez na União e a ser emitidos cartões tacográficos da segunda geração.
A fim de implementar de forma harmoniosa o sistema tacográfico da segunda geração, os cartões tacográficos da segunda geração foram concebidos para serem também utilizados nas unidades-veículo da primeira geração construídas de acordo com o anexo IB do Regulamento (CEE) n.o 3821/85.
Reciprocamente, os cartões tacográficos da primeira geração podem ser utilizados nas unidades-veículo da segunda geração. No entanto, as unidades-veículo da segunda geração só podem ser calibradas utilizando cartões de oficina da segunda geração.
Os requisitos respeitantes à interoperabilidade entre os sistemas tacográficos da primeira e da segunda geração encontram-se especificados no presente anexo. Neste sentido, o apêndice 15 contém informações adicionais sobre a gestão da coexistência entre ambas as gerações.
Além disso, graças à implementação de novas funções, como a utilização da Autenticação de Mensagens de Navegação de Sinal Aberto do Galileo, a deteção da travessia de fronteiras, a introdução de operações de carga/descarga, e também graças à necessidade de aumentar a capacidade do cartão de condutor para 56 dias de atividade de condução, o presente regulamento introduz os requisitos técnicos para a segunda versão dos aparelhos de controlo e dos cartões tacográficos da segunda geração.»;
(3)
A secção 1 é alterada do seguinte modo:
(a)
A alínea f) passa a ter a seguinte redação:
«f)
"Calibração de um tacógrafo inteligente",
a atualização ou confirmação dos parâmetros do veículo a guardar na memória de dados. Os parâmetros do veículo compreendem a identificação [VIN (número de identificação do veículo), VRN (número de matrícula do veículo) e Estado-Membro de matrícula] e as características do veículo (w, k, l, medida dos pneumáticos, ponto de regulação do dispositivo de limitação da velocidade quando aplicável, hora UTC no momento, valor do conta-quilómetros no momento e tipo de carga por defeito); durante a calibração de um aparelho de controlo, também devem ser guardados na memória de dados os tipos e os identificadores de todos os selos relevantes de homologação do tipo em vigor;
qualquer atualização ou confirmação apenas da hora UTC será considerada um ajustamento do tempo e não uma calibração, desde que não esteja em contradição com o requisito 409, enunciado no ponto 6.4;
a calibração de um aparelho de controlo é feita por intermédio de um cartão de oficina.»
(b)
A alínea g) passa a ter a seguinte redação:
«g)
"Número do cartão",
um conjunto de 16 carateres alfanuméricos que identificam inequivocamente um cartão tacográfico dentro de um Estado-Membro. O número do cartão inclui uma identificação que consiste na identificação de um condutor ou na identificação do proprietário de um cartão, juntamente com um índice de série, um índice de substituição e um índice de renovação do cartão;
por conseguinte, o cartão é identificado inequivocamente pelo seu número e pelo código do Estado-Membro emissor;»;
(c)
As alíneas i) e j) passam a ter a seguinte redação:
«i)
"Índice de renovação do cartão",
o 16.o caráter alfanumérico do número de um cartão, que sobe uma unidade de cada vez que um cartão tacográfico, correspondente a uma determinada identificação, ou seja, identificação do condutor ou identificação do proprietário do cartão, juntamente com um índice de série, é renovado;»;
«j)
"Índice de substituição do cartão",
o 15.o caráter alfanumérico do número de um cartão, que sobe uma unidade de cada vez que um cartão tacográfico, correspondente a uma determinada identificação, ou seja, identificação do condutor ou identificação do proprietário do cartão, juntamente com um índice de série, é substituído;»;
(d)
A alínea ee) passa a ter a seguinte redação:
«ee)
"Cartão não válido",
cartão no qual foi detetada uma falha, cuja autenticação falhou, cuja data de início da validade não foi ainda alcançada ou cuja data de caducidade foi já ultrapassada;
um cartão é também considerado não válido pela unidade-veículo:
—
se um cartão com o mesmo Estado-Membro emissor, a mesma identificação, ou seja, a identificação do condutor ou a identificação do proprietário do cartão, juntamente com um índice de série, e um índice de renovação superior já tiver sido inserido na unidade-veículo, ou
—
se um cartão com o mesmo Estado-Membro emissor, a mesma identificação, ou seja, a identificação do condutor ou a identificação do proprietário do cartão, juntamente com um índice de série e um índice de renovação, mas com um índice de renovação superior, já tiver sido inserido na unidade-veículo;»;
(e)
A alínea ll) passa a ter a seguinte redação:
«ll)
"Sistema de comunicação à distância", «módulo 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;»;
(f)
A alínea n) passa a ter a seguinte redação:
«(nn)
"Renovação do cartão",
a emissão de um novo cartão tacográfico quando o existente atinge o prazo de validade ou acusa defeito e é devolvido à autoridade emissora;»;
(g)
A alínea pp) passa a ter a seguinte redação:
«(pp)
"Substituição do cartão",
emissão de um cartão tacográfico em substituição de um existente que tenha sido declarado extraviado, subtraído ou defeituoso e não tenha sido devolvido à autoridade emissora;»;
(h)
A alínea tt) passa a ter a seguinte redação:
«tt)
"Ajustamento do tempo",
um ajustamento da hora atual; este ajustamento pode ser automático, utilizando a hora indicada pelo recetor GNSS como referência, ou efetuado no modo de calibração;»;
(i)
Na alínea yy), o primeiro travessão 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 artigo 4.o do Regulamento (UE) 2018/858 do Parlamento Europeu e do Conselho (1),»;
(j)
A alínea aaa) passa a ter a seguinte redação:
«aaa)
Reservado para utilização futura;»;
(k)
A alínea ccc) passa a ter a seguinte redação:
«ccc)
"Data de produção",
a data definida no Regulamento (UE) n.o 165/2014, a partir da qual os veículos matriculados pela primeira vez devem estar equipados com um tacógrafo em conformidade com o presente regulamento.»;
(4)
O ponto 2.1 é alterado do seguinte modo:
(a)
O n.o 5 passa a ter a seguinte redação:
«(5)
A unidade-veículo pode incluir uma interface ITS especificada no apêndice 13.
O aparelho de controlo pode estar ligado a outros sistemas através de interfaces adicionais e/ou através da interface ITS.»;
(b)
No n.o 7, o último parágrafo passa a ter a seguinte redação:
«Tal é feito em conformidade com a legislação da União aplicável, relativa à proteção de dados, e com o artigo 7.o do Regulamento (UE) n.o 165/2014.»;
(5)
O ponto 2.2 é alterado do seguinte modo:
(a)
O sexto travessão passa a ter a seguinte redação:
«-
entradas efetuadas manualmente pelo condutor:
—
introdução do lugar de início e/ou final do período diário de trabalho,
—
introdução manual das atividades dos condutores e consentimento para interface ITS,
—
introdução de condições especiais,
—
introdução de operações de carga/descarga,»;
(b)
São aditados os seguintes travessões:
«-
controlo da travessia de fronteiras,
—
atualização de software.»;
(6)
O ponto 2.3 é alterado do seguinte modo:
(a)
No n.o 12, o quinto travessão passa a ter a seguinte redação:
«-
a função de descarregamento não é acessível no modo operacional, com as seguintes exceções:
a)
O disposto no requisito 193;
b)
Para descarregar um cartão de condutor quando nenhum outro tipo de cartão é inserido na VU.»;
(b)
O n.o 13 é alterado do seguinte modo:
i)
o segundo travessão passa a ter a seguinte redação:
«-
em modo de empresa, a saída de dados relativos ao condutor (requisitos 102, 105, 108, 133-A e 133-E) só pode concretizar-se quando se tratar de períodos em que não existe bloqueamento ou em que não estão bloqueados por outra empresa (identificada pelos primeiros 13 algarismos do número do seu cartão),»,
ii)
o quarto travessão passa a ter a seguinte redação:
«-
os dados pessoais registados e produzidos pelo tacógrafo ou pelos cartões tacográficos não devem ser transmitidos através da interface ITS da VU, a menos que se verifique o consentimento do condutor a quem se referem os dados.»;
(7)
O quarto travessão do ponto 2.4, n.o 14, passa a ter a seguinte redação:
«-
módulo GNSS externo (este perfil é necessário e aplicável somente para a variante do módulo GNSS externo).»;
(8)
O ponto 3.1 é alterado do seguinte modo:
(a)
O n.o 16 passa a ter a seguinte redação:
«16)
Após a introdução do cartão (ou da autenticação remota do cartão), o aparelho de controlo deteta se o cartão inserido é um cartão tacográfico válido de acordo com a definição da secção 1, alínea ee), e, nessa eventualidade, identifica o tipo e a geração do cartão.
A fim de verificar se já foi inserido um cartão, o aparelho de controlo utiliza os dados relativos ao cartão tacográfico memorizados na respetiva memória de dados, conforme estabelecido no requisito 133.»;
(b)
O n.o 20 passa a ter a seguinte redação:
«20)
A retirada dos cartões tacográficos deve funcionar unicamente com o veículo parado e depois de terem sido memorizados os dados pertinentes nos mesmos. A retirada do cartão exige uma ação positiva do utilizador.»;
(9)
O ponto 3.2 é alterado do seguinte modo:
(a)
Os n.os 26 e 27 passam a ter a seguinte redação:
«26)
Para detetar a manipulação dos dados relativos ao movimento, a informação do sensor de movimentos deve ser corroborada por informação de movimentos do veículo derivada do recetor GNSS e por outras fontes independentes do sensor de movimentos. Deve encontrar-se dentro da VU pelo menos outra fonte de movimento do veículo independente sem necessidade de uma interface externa.
27)
Esta função deve medir a posição do veículo, a fim de permitir o registo de:
—
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,
—
posições em que o veículo atravessou a fronteira de um país,
—
posições em que as operações de carga e descarga foram realizadas,
—
posições em que o condutor e/ou o ajudante termina o seu período diário de trabalho.»;
(b)
No ponto 3.2.1, é aditada a seguinte frase ao n.o 30:
«As tolerâncias não devem ser utilizadas para alterar intencionalmente a distância medida.»;
(c)
No ponto 3.2.2, o n.o 33 passa a ter a seguinte redação:
«33)
Para garantir uma tolerância máxima de ± 6 km/h na velocidade medida durante a utilização, e tendo em conta:
—
uma tolerância de ± 2 km/h para variações nos dados introduzidos (variações nos pneumáticos, etc.),
—
uma tolerância de ± 1 km/h para medições efetuadas durante a instalação ou as inspeções periódicas,
o aparelho de controlo, para velocidades entre 20 e 180 km/h e para coeficientes característicos entre 2 400 e 25 000 imp/km, deve medir a velocidade com uma tolerância de ± 1 km/h (a velocidade constante).
Nota: A resolução da memorização de dados introduz uma tolerância adicional de ± 0,5 km/h na velocidade memorizada pelo aparelho de controlo.»;
(d)
No ponto 3.2.3, o n.o 37 passa a ter a seguinte redação:
«37)
A posição absoluta é medida em coordenadas geográficas de latitude e longitude em graus e minutos, com uma resolução de 1/10 de minuto.»;
(10)
O ponto 3.3 é alterado do seguinte modo:
(a)
O n.o 41 passa a ter a seguinte redação:
«41)
A deriva de tempo deve ser de ± 1 segundo por dia, em condições de temperatura em conformidade com o requisito 213, na ausência de qualquer ajustamento do tempo.»;
(b)
São inseridos os seguintes novos n.os 41-A), 41-B) e 41-C):
«41-A)
A exatidão do tempo, quando o tempo é ajustado pelas oficinas de acordo com o requisito 212, deve ser de 3 segundos ou melhor.
41B)
A unidade-veículo deve incluir um contador de deriva que calcule a deriva de tempo máxima desde o último ajustamento do tempo em conformidade com o ponto 3.23. A deriva de tempo máxima deve ser definida pelo fabricante da unidade-veículo e não deve exceder 1 segundo por dia, conforme estabelecido no requisito 41.
41C)
O contador de deriva deve ser reposto em 1 segundo após cada ajustamento do tempo do aparelho de controlo de acordo com o ponto 3.23. Tal inclui:
—
ajustamentos automáticos do tempo,
—
ajustamentos do tempo efetuados no modo de calibração.»;
(11)
O ponto 3.6 é alterado do seguinte modo:
(a)
O ponto 3.6.1 é alterado do seguinte modo:
i)
os n.os 57 a 59 passam a ter a seguinte redação:
«57)
Os lugares são definidos como o país e, quando igualmente pertinente, a região.
58)
Após a retirada de um cartão de condutor (ou oficina), o aparelho de controlo apresenta o lugar atual do veículo com base na informação do GNSS e do mapa digital memorizado, em conformidade com o ponto 3.12.19, e pede que o titular do cartão confirme ou corrija manualmente o local.
59)
O lugar introduzido em conformidade com o requisito 58 é considerado o lugar em que termina o período diário de trabalho. É registado no cartão de condutor (ou oficina) pertinente como registo temporário e, como tal, pode ser sobreposto mais tarde.
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 requisito 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 requisito 61.
Nas seguintes condições, é sobreposta 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 requisito 61.»,
ii)
Ao n.o 60 é aditado o seguinte parágrafo:
«O aparelho de controlo apresenta o lugar atual do veículo com base na informação do GNSS e do(s) mapa(a) digital(is) memorizado(s), em conformidade com o ponto 3.12.19, e pede que o titular do cartão confirme ou corrija manualmente o local.»;
(b)
No ponto 3.6.2, o n.o 61 passa a ter a seguinte redação:
«61)
Ao ser inserido um cartão de condutor (ou de oficina), e somente nessa situação, o aparelho de controlo permite a introdução manual de atividades. A introdução manual de atividades deve ser executada utilizando a hora local e os valores do fuso horário (UTC com compensação) selecionados para a unidade-veículo.
Aquando da inserção do cartão de condutor ou de oficina, o titular do cartão recebe, a título recapitulativo, as seguintes informações:
—
data e hora da sua última retirada do cartão,
—
opcionalmente: a hora local compensada, selecionada para a unidade-veículo.
Aquando da primeira inserção de um dado cartão de condutor ou cartão de oficina, de momento desconhecido da unidade-veículo, o titular do cartão é convidado a manifestar o seu consentimento para a saída de dados pessoais relacionados com o tacógrafo através da interface ITS. A fim de verificar se já foi inserido um cartão, o aparelho de controlo utiliza os dados relativos ao cartão tacográfico memorizados na respetiva memória de dados, conforme estabelecido no requisito 133.
Desde que o cartão de condutor (ou de oficina) esteja inserido, o consentimento do condutor (ou da oficina) pode, a qualquer momento, ser ativado ou desativado por meio de comandos no menu.
Deve ser possível introduzir atividades, com as seguintes restrições:
—
o tipo de atividade será WORK (trabalho), AVAILABILITY (disponibilidade) ou BREAK/REST (pausa/repouso),
—
a hora de início e de final de cada atividade situar-se-á apenas dentro do período entre a última retirada e a atual inserção do cartão,
—
não é permitida a sobreposição mútua de atividades.
Deve ser possível introduzir entradas manualmente, se necessário, na primeira inserção de um cartão de condutor (ou de oficina) não utilizado anteriormente.
O procedimento para introdução manual de atividades deve incluir tantas etapas consecutivas quantas as necessárias para selecionar um tipo, uma hora de início e uma hora de final para cada atividade. Em qualquer momento do período entre a última retirada do cartão e a atual inserção do cartão, o titular do cartão deve ter a opção de não declarar qualquer atividade.
Durante a introdução manual associada à inserção do cartão, e quando aplicável, o titular do cartão deve ter a oportunidade de introduzir:
—
um lugar em que um período diário de trabalho anterior terminou, associado à hora pertinente (sobrepondo-se 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).
No caso do lugar em que tem início o atual período diário de trabalho introduzido na atual inserção do cartão, o aparelho de controlo apresenta o local atual do veículo com base na informação do GNSS e do(s) mapa(a) digital(is) memorizado(s), em conformidade com o ponto 3.12.19, e pede que o condutor confirme ou corrija manualmente o local.
Se o titular do cartão não introduzir nenhum lugar de início ou final do período de trabalho durante a introdução manual de dados, associada à inserção do cartão, tal é considerado com uma declaração de que o seu período de trabalho não se alterou desde a última retirada do cartão. A subsequente introdução de um local em que um período diário de trabalho anterior termina sobrepõe-se então à introdução temporária efetuada na última retirada do cartão.
Se for introduzido um local, este deve ser registado no cartão tacográfico pertinente.
A introdução manual pode ser interrompida se:
—
o cartão for retirado, ou
—
o veículo estiver em movimento e o cartão estiver na ranhura do condutor.
São permitidas interrupções adicionais (por exemplo, tempo esgotado após um determinado período de inatividade do utilizador). Se a introdução manual de dados for interrompida, o aparelho de controlo valida os dados completos já introduzidos relativamente ao lugar e à atividade (que tenham lugar ou hora inequívocos ou tenham tipo de atividade, hora de início e hora de final).
Se se inserir um segundo cartão de condutor ou de oficina enquanto está em curso a introdução manual de atividades para um cartão previamente inserido, é permitido terminar a introdução manual de dados para esse cartão anterior antes de se iniciar a introdução manual de dados para o segundo cartão.
O titular do cartão deve ter a opção de inserir dados manualmente de acordo com o seguinte procedimento mínimo:
—
introduzir manualmente, por ordem cronológica, as atividades relativas ao período que vai da última retirada até à atual inserção,
—
a hora de início da primeira atividade deve ser fixada com a hora de retirada do cartão. Em cada subsequente introdução de dados, a hora de início deve ser pré-fixada a fim de se seguir imediatamente à hora de final da precedente introdução de dados. Para cada atividade, devem ser selecionados o tipo e a hora de final.
O procedimento termina quando o tempo de final de uma atividade introduzida manualmente coincidir com o tempo de inserção do cartão.
O aparelho de controlo deve permitir que os condutores e as oficinas, em alternativa, introduzam manualmente dados que têm de ser introduzidos durante o procedimento através da interface ITS, especificada no apêndice 13, e opcionalmente através de outras interfaces.
O aparelho de controlo permite que o titular do cartão modifique atividades introduzidas manualmente até à validação por seleção de um comando específico. A partir de então, já não serão permitidas tais modificações.»
(c)
No ponto 3.6.3, o n.o 62 passa a ter a seguinte redação:
«62)
O aparelho de controlo deve permitir ao condutor introduzir, em tempo real, as duas seguintes condições especiais:
—
«OUT OF SCOPE» (fora de âmbito), com início e final,
—
«FERRY/TRAIN CROSSING» (travessia de batelão/comboio), com início e final.
Uma condição «FERRY/TRAIN CROSSING» não pode ocorrer se tiver sido aberta uma condição «OUT OF SCOPE». Se tiver sido aberta uma condição «OUT OF SCOPE», o aparelho de controlo não permite que os utilizadores introduzam um indicador de início de «FERRY/TRAIN CROSSING».
Uma condição «OUT OF SCOPE» que tenha sido aberta deve ser automaticamente fechada pelo aparelho de controlo se se inserir ou retirar um cartão de condutor.
Uma condição «OUT OF SCOPE» que tenha sido aberta inibirá os seguintes incidentes e alertas:
—
condução sem cartão adequado,
—
alertas associados ao tempo de condução contínua.
O condutor deve introduzir o indicador de início de «FERRY/TRAIN CROSSING» imediatamente após selecionar «BREAK/REST» no batelão ou comboio.
O aparelho de controlo deve terminar uma condição «FERRY/TRAIN CROSSING» aberta quando ocorrer qualquer uma das seguintes opções:
—
o condutor termina manualmente a condição «FERRY/TRAIN CROSSING», que deve ocorrer à chegada do batelão/comboio ao destino, antes de abandonar o batelão/comboio,
—
é aberta uma condição «OUT OF SCOPE»,
—
o condutor ejeta o seu cartão,
—
a atividade do condutor é calculada como DRIVING durante 1 minuto em conformidade com o ponto 3.4.
Se for efetuada a introdução de mais do que uma condição específica do mesmo tipo no intervalo de 1 minuto, só será mantida a última.»;
(d)
É aditado o ponto 3.6.4 seguinte:
«3.6.4
Introdução de operações de carga/descarga
62-A)
O aparelho de controlo permite que o condutor introduza e confirme em tempo real informações que indiquem que o veículo está a ser carregado, descarregado ou que estão a decorrer em simultâneo operações de carga/descarga.
Se for efetuada a introdução de mais do que uma operação de carga/descarga do mesmo tipo no intervalo de 1 minuto, só será mantida a última.»;
62-B)
As operações de carga, descarga ou de carga/descarga simultâneas são registadas como incidentes separados.
62-C)
As informações de carga/descarga são introduzidas antes de o veículo abandonar o local onde a operação de carga/descarga é realizada.»;
(12)
O ponto 3.9 é alterado do seguinte modo:
(a)
No ponto 3.9.12, o n.o 83 passa a ter a seguinte redação:
«83)
Este incidente produz-se, fora do modo de calibração, em caso de interrupção do fluxo normal de dados entre o sensor de movimentos e a unidade-veículo e/ou em caso de erro na integridade ou na autenticação de dados durante o intercâmbio destes entre o sensor de movimentos e a unidade-veículo. Este incidente produz-se igualmente, fora do modo de calibração, no caso de a velocidade calculada a partir dos impulsos do sensor de movimentos aumentar de 0 para mais de 40 km/h dentro de 1 segundo e se mantiver acima de 40 km/h durante pelo menos 3 segundos.»;
(b)
No ponto 3.9.13, o n.o 84 passa a ter a seguinte redação:
«84)
Este incidente produz-se, conforme especificado no apêndice 12, fora do modo de calibração, se as informações de movimento calculadas a partir do sensor de movimento forem contrariadas por informações de movimento calculadas a partir do recetor GNSS interno ou a partir do módulo GNSS externo ou por outra(s) fonte(s) independente(s), em conformidade com o requisito 26. Este incidente não se produz durante uma travessia de batelão/comboio.»;
(c)
No ponto 3.9.15, o n.o 86 passa a ter a seguinte redação:
«86)
Este incidente produz-se, fora do modo de calibração, quando a VU deteta uma discrepância entre o tempo da função de medição do tempo da unidade-veículo e o tempo proveniente das posições autenticadas transmitidas pelo recetor GNSS ou pelo módulo GNSS externo. É detetada uma «discrepância de tempo» se a diferença de tempo exceder ±3 segundos relativamente à exatidão temporal definida no requisito 41-A, este último aumentado pela deriva de tempo máxima por dia. Este incidente é registado juntamente com o valor do relógio interno da unidade-veículo do aparelho de controlo. A VU procede à verificação a fim de desencadear o incidente «conflito de tempo» imediatamente antes de reajustar automaticamente o seu relógio interno em conformidade com o requisito 211.»;
(d)
No ponto 3.9.17, o oitavo travessão passa a ter a seguinte redação:
«-
Falha da interface ITS.»;
(e)
É aditado o seguinte ponto:
«3.9.18
Incidente de «anomalia do GNSS»
88-A)
Este incidente produz-se, fora do modo de calibração, quando o recetor GNSS deteta um ataque ou quando a autenticação de mensagens de navegação tiver falhado, conforme especificado no apêndice 12. Após a produção de um incidente de anomalia do GNSS, a VU não gera outros incidentes de anomalia do GNSS durante os 10 minutos seguintes.»;
(13)
No ponto 3.10, a última linha do quadro passa a ter a seguinte redação:
«Interface ITS
Funcionamento correto»;
(14)
O ponto 3.12 é alterado do seguinte modo:
(a)
O primeiro parágrafo passa a ter a seguinte redação:
«Para efeitos do presente ponto,
—
define-se «365 dias» como 365 dias de atividade média do condutor num veículo. A atividade média por dia num veículo é definida como, pelo menos, 6 condutores ou ajudantes, 6 ciclos de inserção/retirada de cartão e 256 mudanças de atividade. Por conseguinte, «365 dias» inclui pelo menos 2190 condutores ou ajudantes, 2190 ciclos de inserção/retirada de cartão e 93 440 mudanças de atividade,
—
o número médio de entradas de locais por dia é definido como, pelo menos, 6 entradas em que o período diário de trabalho se inicia e 6 entradas em que o período diário de trabalho termina, de modo que «365 dias» inclua, pelo menos, 4380 entradas de locais,
—
o número médio de posições por dia quando o tempo de condução acumulado atinge um múltiplo de três horas é definido como, pelo menos, 6 posições, de modo que «365 dias» inclua pelo menos 2190 dessas posições,
—
o número médio de travessias de fronteiras por dia é definido como, pelo menos, 20 travessias, de modo que «365 dias» inclua pelo menos 7300 travessias de fronteiras,
—
o número médio de operações de carga/descarga é definido como, pelo menos, 25 operações (independentemente do tipo), de modo que «365 dias» inclua pelo menos 9125 operações de carga/descarga,
—
as medidas de tempo são registadas com uma resolução de 1 minuto, salvo indicação diversa,
—
os valores do conta-quilómetros são registados com uma resolução de 1 km,
—
as velocidades são registadas com uma resolução de 1 km/h,
—
as posições (latitudes e longitudes) são registadas em graus e minutos, com uma resolução de 1/10 de minuto, com a precisão GNSS e o momento de aquisição associados e com um indicador que denota se a posição foi autenticada.»;
(b)
O ponto 3.12.1.1 é alterado do seguinte modo:
i)
Ao n.o 93, é aditado o seguinte travessão:
«-
identificador da versão do mapa digital (requisito 133-L).»;
ii)
O n.o 94 passa a ter a seguinte redação:
«94)
Os dados de identificação da unidade-veículo são registados e memorizados definitivamente pelo seu fabricante, com exceção dos dados que podem ser alterados no caso de uma atualização do software nos termos do presente regulamento e de acordo com a capacidade de utilização de cartões tacográficos da primeira geração.»;
(c)
No ponto 3.12.1.2, o primeiro parágrafo do n.o 97 passa a ter a seguinte redação:
«97)
A unidade-veículo deve poder registar e memorizar na sua memória os seguintes dados relativos aos 20 emparelhamentos bem-sucedidos mais recentes dos sensores de movimentos (se, no espaço de um dia de calendário, ocorrerem vários emparelhamentos, serão armazenados apenas o primeiro e o último desse dia):»;
(d)
No ponto 3.12.1.3, o primeiro parágrafo do n.o 100 passa a ter a seguinte redação:
«100)
A unidade-veículo deve poder registar e memorizar na sua memória os seguintes dados relativos aos 20 emparelhamentos bem-sucedidos mais recentes dos módulos GNSS externos (se, no espaço de um dia de calendário, ocorrerem vários emparelhamentos, serão armazenados apenas o primeiro e o último desse dia).»;
(e)
O ponto 3.12.5 é alterado do seguinte modo:
i)
o n.o 110 é alterado do seguinte modo:
1)
O primeiro travessão passa a ter a seguinte redação:
«-
o número do cartão do condutor e/ou do ajudante e o Estado-Membro emissor do cartão»;
2)
É aditado o seguinte travessão:
«-
um indicador que denota se a posição foi autenticada.»;
ii)
é inserido o seguinte n.o 110-A):
«110-A)
No caso dos locais em que o período diário de trabalho tem início ou termina, introduzidos durante o procedimento de introdução manual de dados aquando da inserção do cartão, de acordo com o requisito 61, o valor do conta-quilómetros e a posição atuais do veículo são memorizados.»;
(f)
No ponto 3.12.8, o quadro do n.o 117 é alterado do seguinte modo:
i)
a quinta linha passa a ter a seguinte redação:
«Última sessão de cartão encerrada incorretamente
—
os 10 incidentes mais recentes,
—
data e hora de inserção do cartão,
—
tipo, número, Estado-Membro emissor e geração do cartão,
—
dados da última sessão, conforme leitura do cartão:
—
data e hora de inserção do cartão.»:
ii)
é aditada a seguinte linha:
«Anomalia do GNSS
—
os incidentes mais longos 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.»;
(g)
No ponto 3.12.10, são aditados ao n.o 120 os seguintes travessões:
«-
os números de série do sensor de movimentos., o módulo GNSS externo (caso exista) e o sistema externo de comunicação à distância (caso exista),
-
o tipo de carga por defeito associado ao veículo (carga de mercadorias ou passageiros),
-
o país em que a calibração foi realizada e a data e hora em que a posição utilizada para determinar esse país foram transmitidas pelo recetor GNSS.»;
(h)
São aditados os seguintes pontos:
«3.12.17 Travessia de fronteiras
133-A)
O aparelho de controlo regista e memoriza na sua memória as seguintes informações relativas à travessia de fronteiras:
—
o país de partida do veículo,
—
o país de chegada do veículo,
—
a posição em que o veículo atravessou a fronteira.
133-B)
Juntamente com os países e a posição, o aparelho de controlo deve registar e memorizar na sua memória os seguintes dados:
—
o número do cartão do condutor e/ou do ajudante e o Estado-Membro emissor do cartão,
—
a geração do cartão,
—
a precisão, data e hora do GNSS relacionadas,
—
um indicador que denota se a posição foi autenticada,
—
o valor do conta-quilómetros do veículo no momento da deteção da travessia da fronteira.
133-C)
A memória de dados deve poder guardar as travessias de fronteiras durante pelo menos 365 dias.
133D)
Quando se esgota a capacidade de memorização, os dados mais antigos são substituídos por dados mais recentes.
3.12.18 Operações de carga/descarga
133-E)
O aparelho de controlo regista e memoriza na sua memória de dados as seguintes informações relativas às operações de carga e descarga do veículo:
—
o tipo de operação (carga, descarga ou carga/descarga simultâneas),
—
a posição em que ocorreu a operação de carga/descarga.
133F)
Quando a posição do veículo não está disponível a partir do recetor GNSS no momento da operação de carga/descarga, o aparelho de controlo deve utilizar a última posição disponível, bem como data e hora correspondentes.
133-G)
Juntamente com o tipo de operação e a posição, o aparelho de controlo deve registar e memorizar na sua memória os seguintes dados:
—
o número do cartão do condutor e/ou do ajudante e o Estado-Membro emissor do cartão,
—
a geração do cartão,
—
a data e a hora da operação de carga/descarga,
—
a precisão, data e hora do GNSS relacionadas, se aplicável,
—
um indicador que denota se a posição foi autenticada,
—
o valor do conta-quilómetros do veículo.
133-H)
A memória de dados deve poder guardar durante pelo menos 365 dias de calendário as operações de carga/descarga.
133-I)
Quando se esgota a capacidade de memorização, os dados mais antigos são substituídos pelos dados mais recentes.
3.12.19 Mapa digital
133-J)
Para efeitos de registo da posição do veículo, sempre que ocorre a travessia da fronteira de um país, o aparelho de controlo memoriza um mapa digital na respetiva memória de dados.
133K)
A Comissão Europeia disponibilizará mapas digitais permitidos para apoiar a função de controlo das travessias de fronteiras do aparelho de controlo para descarregamento a partir de um sítio Web específico seguro sob diversos formatos.
133-L)
Está disponível no sítio Web, para cada um destes mapas, um identificador da versão e um valor de resumo.
133-M)
Os mapas apresentam:
—
um nível de definição correspondente ao nível 0 da NUTS, de acordo com a Nomenclatura Comum das Unidades Territoriais Estatísticas,
—
uma escala de 1:1 milhão.
133N)
Os fabricantes de tacógrafos selecionam um mapa a partir do sítio Web e descarregam-no de forma segura.
133-O)
Os fabricantes de tacógrafos apenas devem utilizar um mapa descarregado do sítio Web depois de verificarem a sua integridade com recurso ao valor de resumo do mapa.
133-P)
O mapa selecionado deve ser importado para o aparelho de controlo pelo respetivo fabricante, num formato adequado, mas a semântica do mapa importado não deve ser alterada.
133-Q)
O fabricante deve também memorizar o identificador da versão do mapa utilizado no aparelho de controlo.
133-R)
Deve ser possível atualizar ou substituir o mapa digital memorizado por um novo disponibilizado pela Comissão Europeia.
133-S)
As atualizações dos mapas digitais devem ser efetuadas utilizando os mecanismos de atualização de software instalados pelo fabricante, em cumprimento dos requisitos 226-D e 226-E, para que o aparelho de controlo possa verificar a autenticidade e a integridade de um novo mapa importado antes de o memorizar e de substituir o anterior.
133-T)
Os fabricantes de tacógrafos podem adicionar informações complementares ao mapa básico a que se refere o requisito 133-M, para outros fins diferentes do registo de travessias de fronteiras, nomeadamente as fronteiras de regiões da UE, desde que a semântica do mapa básico não seja alterada.»;
(15)
O ponto 3.13 é alterado do seguinte modo:
(a)
No n.o 134, o terceiro travessão passa a ter a seguinte redação:
«-
relativamente às semanas anterior e em curso, calcular o tempo de condução contínua do condutor, o tempo acumulado de pausas e o tempo acumulado de condução;»;
(b)
É aditado o seguinte n.o 135-A):
«135-A)
A estrutura na aplicação «TACHO_G2» depende da versão. Os cartões da versão 2 contêm ficheiros elementares complementares aos dos cartões da versão 1, em particular:
—
cartões de condutor e de oficina:
—
EF Places_Authentication deve conter o estatuto de autenticação das posições do veículo memorizadas em EF Places. É memorizado um selo temporal com cada estatuto de autenticação, que é exatamente o mesmo da data e hora da entrada de dados memorizada com a posição correspondente em EF Places.
—
EF Places_Authentication deve conter o estatuto de autenticação das posições do veículo memorizadas em EF Places. É memorizado um selo temporal com cada estatuto de autenticação, que é exatamente o mesmo da data e hora da entrada de dados memorizada com a posição correspondente em EF Places.
—
EF Border_Crossings, EF Load_Unload_Operations e EF Load_Type_Entries contêm os dados relativos a travessias de fronteiras, operações de carga/descarga e tipos de carga.
—
nos cartões de oficina:
—
EF Calibration_Add_Data contém dados de calibração complementares dos memorizados em EF Calibration. O valor da data e hora antigas e o número de identificação do veículo são memorizados com cada registo adicional dos dados relativos à calibração que serão exatamente iguais ao valor da data e hora antigas e ao número de identificação do veículo memorizados com os dados correspondentes relativos à calibração em EF Calibration.
—
em todos os cartões tacográficos:
—
EF VU_Configuration contém as definições específicas do tacógrafo do titular do cartão.
A unidade-veículo ignora qualquer estatuto de autenticação presente em EF Places_Authentication ou EF GNSS_Places_Authentication, quando não é detetada nenhuma posição do veículo com o mesmo selo temporal em EF Places ou EF GNSS_Places.
A unidade-veículo ignora o ficheiro elementar EF VU_Configuration em todos os cartões, na medida em que não tenham sido indicadas quaisquer regras específicas relativamente à utilização desse ficheiro elementar. Essas regras devem ser definidas através de uma alteração do anexo IC, que deve incluir a modificação ou eliminação do presente número.»;
(16)
O ponto 3.14 é alterado do seguinte modo:
(a)
O ponto 3.14.1 é alterado do seguinte modo:
i)
O n.o 140 passa a ter a seguinte redação:
«140)
Todos os incidentes e falhas não definidos para o aparelho de controlo da primeira geração não devem ser memorizados nos cartões de condutor e de oficina.»;
ii)
O n.o 143 passa a ter a seguinte redação:
«143)
Antes de libertar um cartão de condutor ou de oficina e depois de nele memorizar todos os dados de interesse, o aparelho de controlo restabelece os «dados da sessão do cartão».»;
(b)
O ponto 3.14.2 é alterado do seguinte modo:
i)
No n.o 144, é aditado o seguinte parágrafo:
«A estrutura na aplicação «TACHO_G2» depende da versão. Os cartões da versão 2 contêm ficheiros elementares complementares aos dos cartões da versão 1.»;
ii)
São inseridos os seguintes novos números 147-A) e 147-B):
«147-A)
Aquando da inserção de um cartão de condutor ou de oficina, o aparelho de controlo memoriza no cartão o tipo de carga por defeito do veículo.
147-B)
Aquando da inserção de um cartão de condutor ou de oficina e após o procedimento de introdução manual de dados, o aparelho de controlo verifica o último lugar em que o período diário de trabalho tem início ou termina memorizado no cartão. Este local pode ser temporário, conforme especificado no requisito 59. Caso este local se situe num país diferente do atual em que o veículo está localizado, o aparelho de controlo memoriza no cartão um registo de travessia de fronteira, com:
—
o país de partida do condutor: não disponível;
—
o país de chegada do condutor: o país atual em que o veículo está localizado;
—
a data e hora em que o condutor atravessou a fronteira: a hora de inserção do cartão;
—
a posição do condutor quando atravessou a fronteira: não disponível;
—
o valor do conta-quilómetros do veículo: não disponível.»;
iii)
É aditado o seguinte n.o 150-A):
«150-A)
A unidade-veículo ignora o ficheiro elementar EF VU_Configuration em todos os cartões, na medida em que não tenham sido indicadas quaisquer regras específicas relativamente à utilização desse ficheiro elementar. Essas regras devem ser definidas através de uma alteração do anexo IC, que deve incluir a modificação ou eliminação do presente número.»;
(17)
No ponto 3.15.4, o n.o 167 é alterado do seguinte modo:
(a)
O segundo travessão passa a ter a seguinte redação:
«-
o conteúdo de qualquer das impressões enumeradas no requisito 169 nos mesmos formatos das próprias impressões;»;
(b)
O quinto e o sexto travessões passam a ter a seguinte redação:
«-
o tempo acumulado de condução do condutor nas semanas anterior e em curso,
-
o tempo acumulado de condução do ajudante nas semanas anterior e em curso,»;
(c)
O oitavo, o nono e o décimo travessões passam a ter a seguinte redação:
«-
o tempo acumulado de condução do condutor na semana em curso,
-
o tempo acumulado de condução do ajudante no período de trabalho diário em curso,
-
o tempo acumulado de condução do ajudante no período de trabalho diário em curso.»;
(18)
O ponto 3.18 é alterado do seguinte modo:
(a)
O n.o 193 passa a ter a seguinte redação:
«193)
Complementarmente, e como função opcional, o aparelho de controlo deve, em qualquer modo de funcionamento, poder descarregar dados por intermédio de outra interface, para uma empresa autenticada através deste canal. Nesse caso, aplicar-se-ão ao descarregamento direitos de acesso aos dados em modo de empresa.»;
(b)
São aditados os seguintes números 196-A) e 196-B):
«196-A)
Uma empresa de transportes que utilize veículos equipados com aparelhos de controlo em conformidade com o presente anexo e se enquadrem no âmbito do Regulamento (CE) n.o 561/2006 devem assegurar que todos os dados sejam descarregados da unidade-veículo e dos cartões de condutor.
O prazo máximo dentro do qual os dados pertinentes devem ser descarregados não deve ser superior a:
—
90 dias para os dados da unidade-veículo,
—
28 dias para os dados do cartão de condutor.
196-B)
As empresas de transportes devem conservar os dados descarregados da unidade-veículo durante, pelo menos, doze meses após o registo.»;
(19)
No ponto 3.19, são aditados ao n.o 199 os seguintes travessões:
«-
posição do veículo,
-
uma indicação se o condutor pode atualmente violar os tempos de condução.»;
(20)
O ponto 3.20 é alterado do seguinte modo:
(a)
o título passa a ter a seguinte redação:
«3.20
Intercâmbio de dados com dispositivos externos adicionais»;
(b)
O n.o 200 passa a ter a seguinte redação:
«200)
Os aparelhos de controlo devem também estar equipados com uma interface ITS, em conformidade com o apêndice 13, que permita a utilização dos dados registados ou produzidos pelo tacógrafo ou pelos cartões tacográficos por um sistema externo.
No modo operacional, é necessário o consentimento do condutor para a transmissão de dados pessoais através da interface ITS. No entanto, o consentimento do condutor não se aplica aos dados do tacógrafo ou do cartão acedidos em modo de controlo, empresa ou calibração. Os dados e os direitos de acesso funcional para estes modos encontram-se especificados nos requisitos 12 e 13.
Aos dados ITS disponibilizados através dessa interface aplicam-se os requisitos seguintes:
—
os dados pessoais só estão disponíveis após ter sido dado o consentimento verificável do condutor, aceitando que os dados pessoais podem sair da rede do veículo.
Encontra-se especificado no apêndice 13 um conjunto de dados selecionados existentes que pode estar disponível através da interface ITS, bem como a classificação dos dados como pessoais ou não pessoais. Podem ser também emitidos dados para além do conjunto de dados indicado no apêndice 13. O fabricante da VU deve classificar esses dados como «pessoais» ou «não pessoais», sendo a autorização do condutor aplicável a esses dados classificada como «pessoal»;
—
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;
—
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.
Podem coexistir outras interfaces unidade-veículo, desde que cumpram integralmente os requisitos estabelecidos no apêndice 13 em termos de consentimento do condutor. O aparelho de controlo deve ter capacidade para comunicar o estado do consentimento do condutor a outras plataformas existentes na rede do veículo e a dispositivos externos.
No caso de dados pessoais injetados na rede do veículo, que sejam posteriormente tratados fora desta, não é da responsabilidade do fabricante do tacógrafo tornar esse tratamento de dados pessoais conforme à legislação da União aplicável relativa à proteção de dados.
A interface ITS deve ainda permitir a introdução de dados durante o procedimento de introdução manual de dados de acordo com o requisito 61 tanto para o condutor como para o ajudante.
A interface ITS pode também ser utilizada para introduzir informações adicionais, em tempo real, tais como:
—
seleção da atividade do condutor, de acordo com o requisito 46,
—
lugares, de acordo com o requisito 56,
—
condições específicas, de acordo com o requisito 62,
—
operações de carga/descarga, de acordo com o requisito 62-A.
Estas informações também podem ser introduzidas através de outras interfaces.»;
(c)
O n.o 201 passa a ter a seguinte redação:
«201)
A interface de ligação em série, conforme se especifica no anexo IB do Regulamento (CEE) n.o 3821/85, na sua última redação, pode continuar a equipar tacógrafos para compatibilidade interna. A ligação em série é classificada como uma parte da rede do veículo, de acordo com o requisito 200.»;
(21)
O ponto 3.21 é alterado do seguinte modo:
(a)
o n.o 202 é alterado do seguinte modo:
i)
o nono travessão passa a ter a seguinte redação:
«-
atualizar ou confirmar outros parâmetros conhecidos do aparelho de controlo: identificação do veículo, w, l, medida do pneumático e instalação do dispositivo de limitação da velocidade, quando aplicável e tipo de carga por defeito,»;
ii)
é aditado o seguinte travessão:
«-
memorizar automaticamente o país em que a calibração foi realizada e a data e hora em que a posição utilizada para determinar esse país foram transmitidas pelo recetor GNSS.»;
(b)
O n.o 205 passa a ter a seguinte redação:
«205)
O emparelhamento do módulo GNSS externo com a VU deve consistir, pelo menos, em:
—
atualizar os dados de instalação do módulo GNSS externo contidos no próprio módulo (conforme necessário);
—
copiar do módulo GNSS externo para a memória de dados da VU as informações de identificação necessárias, incluindo o número de série do módulo GNSS externo.»;
(22)
No ponto 3.22, é aditado o seguinte parágrafo ao n.o 209:
«Quando o modo de I/O da linha de sinal I/O de calibração está ativo, em conformidade com o presente requisito, o alerta «Condução sem cartão adequado» (requisito 75) não é emitido pela unidade-veículo.»;
(23)
O ponto 3.23 é alterado do seguinte modo:
(a)
O n.o 211 passa a ter a seguinte redação:
«211)
A hora do relógio interno da VU deve ser reajustada automaticamente a intervalos de tempo variáveis. O seguinte reajustamento automático da hora deve ser desencadeado entre 72 e 168 horas após o anterior e após a VU poder aceder à hora do GNSS através de uma mensagem de posição válida e autenticada, de acordo com o apêndice 12. No entanto, o ajustamento da hora nunca deve ser maior do que a deriva de tempo máxima acumulada por dia, conforme calculada pelo fabricante da VU, em conformidade com o requisito 41-B. Se a diferença entre a hora do relógio interno da VU e a hora do recetor GNSS for superior à deriva de tempo máxima acumulada por dia, o ajustamento da hora coloca o relógio interno da VU o mais próximo possível da hora do recetor GNSS. O ajustamento da hora só pode ser feito se a hora indicada pelo recetor GNSS for obtida usando mensagens de posição autenticadas, conforme estipulado no apêndice 12. A referência temporal para o ajustamento automático da hora do relógio interno da VU deve ser determinada pelo recetor GNSS.»;
(b)
O n.o 212 passa a ter a seguinte redação:
«212)
A função de ajustamento da hora deve permitir a ativação do ajustamento da hora atual, em modo de calibração.
As oficinas podem ajustar a hora:
—
inscrevendo um valor temporal na VU, utilizando o serviço WriteDataByIdentifier, em conformidade com a secção 6.2 do apêndice 8;
—
ou solicitando um alinhamento do relógio da VU com a hora indicada pelo recetor GNSS. Tal só pode ser feito se a hora indicada pelo recetor GNSS for obtida usando mensagens de posição autenticadas. Neste último caso, deve ser utilizado o serviço RoutineControl, em conformidade com a secção 8 do apêndice 8.»;
(24)
São inseridos os seguintes pontos 3.27 e 3.28:
«3.27
Controlo da travessia de fronteiras
226-A)
Esta função deteta quando o veículo atravessou a fronteira de um país, qual o país de saída e qual o país de entrada.
226-B)
A deteção da travessia de uma fronteira baseia-se na posição medida pelo aparelho de controlo e pelo mapa digital memorizado, em conformidade com o ponto 3.12.19.
226-C)
As travessias de fronteiras relacionadas com a presença de um veículo num país durante um período de tempo inferior a 120 segundos não são registadas.
3.28
Atualização de software
226-D)
A unidade-veículo deve incorporar uma função para a realização de atualizações de software sempre que tais atualizações não envolvam a disponibilidade de recursos de hardware adicionais, além dos recursos definidos no requisito 226-F, e as entidades homologadoras deem a sua autorização para as atualizações de software com base na unidade-veículo homologada existente, em conformidade com o artigo 12.o, n.o 5, do Regulamento (UE) n.o 165/2014.
226E)
A função de atualização de software deve ser concebida para suportar os seguintes recursos funcionais, sempre que sejam legalmente exigidos:
—
modificação das funções referidas na secção 2.2, exceto a própria função de atualização de software,
—
a adição de novas funções diretamente relacionadas com a aplicação da legislação da União em matéria de transporte rodoviário,
—
modificação dos modos de operação no ponto 2.3,
—
modificação da estrutura de ficheiros, como a adição de novos dados ou o aumento do tamanho do ficheiro,
—
implantação de atualizações corretivas para solucionar defeitos de software e de segurança ou ataques notificados às funções do aparelho de controlo.
226-F)
A unidade-veículo deve fornecer recursos de hardware gratuitos de pelo menos 35 % para software e dados necessários para a implementação do requisito 226-E e recursos de hardware gratuitos de pelo menos 65 % para a atualização do mapa digital com base nos recursos de hardware necessários para a versão do mapa NUTS 0 2021.»;
(25)
No ponto 4.1, a seguir ao n.o 235, a imagem «Modelo de cartão tacográfico comunitário», o verso do cartão de controlo passa a ter a seguinte redação:
«
»;
(26)
O ponto 4.5 é alterado do seguinte modo:
(a)
O n.o 246 passa a ter a seguinte redação:
«246)
Podem ser memorizados quaisquer dados adicionais nos cartões tacográficos desde que a memorização desses dados cumpra a legislação aplicável em matéria de proteção de dados.»;
(b)
No n.o 247, após o segundo travessão, é inserida a seguinte nota:
«Nota: a versão 2 dos cartões da segunda geração contém ficheiros elementares adicionais em DF Tachograph_G2.»;
(c)
O ponto 4.5.3.2 é alterado do seguinte modo:
i)
o título passa a ter a seguinte redação:
«4.5.3.2
Aplicação tacográfica da geração 2 (não acessível às unidades-veículo da primeira geração, acessível às versões 1 e 2 das unidades-veículo da segunda geração)»;
ii)
é inserido o seguinte ponto 4.5.3.2.1.1 a seguir ao ponto 4.5.3.2.1:
«4.5.3.2.1.1
Identificação da aplicação adicional (não acessível na versão 1 das unidades-veículo da segunda geração);
278-A)
O cartão de condutor deve poder memorizar dados de identificação da aplicação adicionais, apenas aplicável à versão 2.»;
iii)
no ponto 4.5.3.2.7, o n.o 287 passa a ter a seguinte redação:
«287)
O cartão de condutor deve poder memorizar os dados relativos aos 12 incidentes mais recentes de cada um dos tipos (ou seja, os dados relativos a 132 incidentes)».
iv)
no ponto 4.5.3.2.8, o n.o 290 passa a ter a seguinte redação:
«290)
O cartão de condutor deve poder memorizar os dados relativos às 24 falhas mais recentes de cada um dos tipos (ou seja, os dados relativos a 48 falhas).»;
v)
no ponto 4.5.3.2.9, o n.o 292 passa a ter a seguinte redação:
«292)
A memória do cartão de condutor deve poder guardar os dados relativos à atividade do condutor durante 56 dias (para efeitos deste requisito, define-se atividade média de um condutor como 117 mudanças de atividade por dia).»;
vi)
no ponto 4.5.3.2.10, o n.o 295 passa a ter a seguinte redação:
«295)
O cartão de condutor deve poder memorizar 200 registos deste tipo.»;
vii)
no ponto 4.5.3.2.11, o n.o 297 passa a ter a seguinte redação:
«297)
O cartão de condutor deve poder guardar 112 registos deste tipo.»;
viii)
no ponto 4.5.3.2.14, o n.o 302 passa a ter a seguinte redação:
«302)
O cartão de condutor deve poder memorizar 112 registos deste tipo.»;
ix)
no ponto 4.5.3.2.15, o n.o 304 passa a ter a seguinte redação:
«304)
O cartão de condutor deve poder memorizar 200 registos deste tipo.»;
x)
no ponto 4.5.3.2.16, o n.o 306 passa a ter a seguinte redação:
«306)
O cartão de condutor deve poder memorizar 336 registos deste tipo.»;
xi)
são aditados os seguintes pontos 4.5.3.2.17 a 4.5.3.2.22:
«4.5.3.2.17
Estatuto de autenticação de posições relacionadas com locais de início e/ou final dos períodos de trabalho diário (não acessível na versão 1 das unidades-veículo da segunda geração)
306-A)
O cartão de condutor deve poder memorizar dados adicionais relativos aos locais, introduzidos pelo condutor, em que se iniciam e/ou terminam os períodos de trabalho diário, de acordo com o ponto 4.5.3.2.11:
—
a data e hora de introdução dos dados, exatamente correspondentes à mesma data e hora introduzidas em EF Places no DF Tachograph_G2,
—
um indicador que denota se a posição foi autenticada.
306-B)
A memória do cartão de condutor deve poder guardar 112 registos deste tipo.
4.5.3.2.18
Estatuto de autenticação de posições em que são atingidas três horas de tempo de condução acumulado (não acessível na versão 1 das unidades-veículo da segunda geração)
306-C)
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, de acordo com o ponto 4.5.3.2.16:
—
a data e hora em que o tempo de condução acumulado atinge um múltiplo de três horas, exatamente correspondentes à mesma data e hora memorizadas em EF GNSS_Places no DF Tachograph_G2,
—
um indicador que denota se a posição foi autenticada.
306-D)
O cartão de condutor deve poder memorizar 336 registos deste tipo.
4.5.3.2.19
Travessia de fronteiras (não acessível na versão 1 das unidades-veículo da segunda geração)
306-E)
O cartão de condutor deve poder memorizar os seguintes dados relativos à travessia de fronteiras aquando da inserção do cartão, de acordo com o requisito 147-B, ou com o cartão já inserido:
—
o país de partida do veículo,
—
o país de chegada do veículo,
—
a data e hora em que o condutor atravessou a fronteira,
—
a posição do veículo quando atravessou a fronteira,
—
a precisão GNSS,
—
um indicador que denota se a posição foi autenticada,
—
o valor do conta-quilómetros do veículo.
306-F)
A memória do cartão de condutor deve poder guardar 1 120 registos deste tipo.
4.5.3.2.20
Operações de carga/descarga (não acessíveis na versão 1 das unidades-veículo da segunda geração)
306-G)
O cartão de condutor deve poder memorizar os seguintes dados relativos a operações de carga/descarga:
—
tipo de operação (carga, descarga ou carga/descarga simultâneas),
—
a data e a hora da operação de carga/descarga,
—
a posição do veículo,
—
a precisão GNSS, data e hora no momento de determinação da posição,
—
um indicador que denota se a posição foi autenticada,
—
o valor do conta-quilómetros do veículo.
306-H)
O cartão de condutor deve poder memorizar 1 624 operações de carga/descarga.
4.5.3.2.21
Entradas do tipo de carga (não acessíveis na versão 1 das unidades-veículo da segunda geração)
306-I)
O cartão de condutor deve poder memorizar os seguintes dados relativos a operações de carga/descarga introduzidas automaticamente pela VU em cada inserção do cartão:
—
o tipo de carga introduzido (mercadorias ou passageiros),
—
a data e a hora da introdução.
306-J)
O cartão de condutor deve poder memorizar 336 registos deste tipo.
4.5.3.2.22
Configurações da VU (não acessível na versão 1 das unidades-veículo da segunda geração)
306-K)
O cartão de condutor deve poder memorizar as definições específicas do tacógrafo do titular do cartão.
306-L)
A capacidade de memória do cartão de condutor para as definições específicas do tacógrafo do titular do cartão é de 3 072 bytes.»;
(d)
O ponto 4.5.4.2 é alterado do seguinte modo:
i)
o título passa a ter a seguinte redação:
«4.5.4.2
Aplicação tacográfica da geração 2 (não acessível às unidades-veículo da primeira geração, acessível às versões 1 e 2 das unidades-veículo da segunda geração)»,
ii)
é inserido o seguinte ponto 4.5.4.2.1.1 a seguir ao ponto 4.5.4.2.1:
«4.5.4.2.1.1
Identificação da aplicação adicional (não acessível na versão 1 das unidades-veículo da segunda geração);
330-A)
O cartão de oficina deve poder memorizar dados de identificação da aplicação adicionais apenas aplicáveis à versão 2.»,
iii)
no ponto 4.5.4.2.6, o n.o 338 passa a ter a seguinte redação:
«338)
O cartão de oficina deve poder memorizar 255 registos deste tipo.»;
iv)
no ponto 4.5.4.2.8, o n.o 344 passa a ter a seguinte redação:
«344)
O cartão de oficina deve poder guardar os dados relativos à atividade de condutor durante 1 dia contendo 240 mudanças de atividade.»,
v)
no ponto 4.5.4.2.9, o n.o 346 passa a ter a seguinte redação:
«346)
O cartão de oficina deve poder memorizar 8 registos deste tipo.»,
vi)
o ponto 4.5.4.2.10 passa a ter a seguinte redação:
«4.5.4.2.10
Locais e posições de início e/ou final dos períodos de trabalho diário
347)
O cartão de oficina deve poder memorizar os locais e posições de início e/ou final dos períodos de trabalho diário de modo idêntico a um cartão de condutor.
348)
O cartão de oficina deve poder memorizar 4 pares de registos deste tipo.»,
vii)
no ponto 4.5.4.2.13, o n.o 352 passa a ter a seguinte redação:
«352)
O cartão de oficina deve poder memorizar 8 registos deste tipo.»,
viii)
no ponto 44.5.4.2.14, o n.o 354 passa a ter a seguinte redação:
«354)
O cartão de oficina deve poder memorizar 24 registos deste tipo.»,
ix)
no ponto 4.5.4.2.15, o n.o 356 passa a ter a seguinte redação:
«356)
O cartão de oficina deve poder memorizar 4 registos deste tipo.»,
x)
são aditados os seguintes pontos 4.5.4.2.16 a 4.5.4.2.22:
«4.5.4.2.16
Estatuto de autenticação de posições relacionadas com locais de início e/ou final dos períodos de trabalho diário (não acessível na versão 1 das unidades-veículo da segunda geração)
356-A)
O cartão de oficina deve poder memorizar dados adicionais relativos aos locais de início e/ou ao final dos períodos de trabalho diário de modo idêntico a um cartão de condutor.
356-B)
O cartão de oficina deve poder memorizar 4 pares de registos deste tipo.
4.5.4.2.17
Estatuto de autenticação de posições em que são atingidas três horas de tempo de condução acumulado (não acessível na versão 1 das unidades-veículo da segunda geração)
356-C)
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, de modo idêntico a um cartão de condutor.
356-D)
O cartão de oficina deve poder memorizar 24 registos deste tipo.
4.5.4.2.18
Travessia de fronteiras (não acessível na versão 1 das unidades-veículo da segunda geração)
356-E)
O cartão de oficina deve poder memorizar os dados relativos à travessia de fronteiras de modo idêntico a um cartão de condutor.
356-F)
A memória do cartão de oficina deve poder guardar 4 registos deste tipo.
4.5.4.2.19
Operações de carga/descarga (não acessíveis na versão 1 das unidades-veículo da segunda geração)
356-G)
O cartão de oficina deve poder memorizar os dados relativos às operações de carga/descarga de modo idêntico a um cartão de condutor.
356-H)
O cartão de oficina deve poder memorizar 8 operações de carga, descarga ou de carga/descarga simultâneas.
4.5.4.2.20
Entradas do tipo de carga (não acessíveis na versão 1 das unidades-veículo da segunda geração)
356-I)
O cartão de oficina deve poder memorizar as entradas do tipo de carga de modo idêntico a um cartão de condutor.
356-J)
O cartão de oficina deve poder memorizar 4 registos deste tipo.
4.5.4.2.21
Dados adicionais relativos à calibração (não acessíveis na versão 1 das unidades-veículo da segunda geração)
356-K)
O cartão de oficina deve poder memorizar dados de calibração adicionais apenas aplicáveis à versão 2:
—
a data e hora antigas e o número de identificação do veículo, exatamente correspondentes aos mesmos valores memorizados em EF Calibration no DF Tachograph_G2,
—
o tipo de carga por defeito introduzido durante esta calibração,
—
o país em que a calibração foi realizada e a data e hora em que a posição utilizada para determinar esse país foram transmitidas pelo recetor GNSS.
356-L)
O cartão de oficina deve poder memorizar 255 registos deste tipo.
4.5.4.2.22
Configurações da VU (não acessível na versão 1 das unidades-veículo da segunda geração)
356-M)
O cartão de oficina deve poder memorizar as definições específicas do tacógrafo do titular do cartão.
356-N)
A capacidade de memória do cartão de oficina para as definições específicas do tacógrafo do titular do cartão é de 3 072 bytes.»;
(e)
O ponto 4.5.5 é alterado do seguinte modo:
i)
no ponto 4.5.5.1.5, o segundo travessão passa a ter a seguinte redação:
«-
tipo do controlo (visualização e/ou impressão e/ou descarregamento da VU e/ou descarregamento do cartão),»,
ii)
é inserido o seguinte ponto 4.5.5.2.1.1 a seguir ao ponto 4.5.5.2.1:
«4.5.5.2.1.1
Identificação da aplicação adicional (não acessível na versão 1 das unidades-veículo da segunda geração);
363-A)
O cartão de controlo deve poder memorizar dados de identificação da aplicação adicionais apenas aplicáveis à versão 2.»;
iii)
a seguir ao ponto 4.5.5.2.5, é inserido o seguinte ponto:
«4.5.5.2.6
Configurações da VU (não acessível na versão 1 das unidades-veículo da segunda geração)
368-A)
O cartão de controlo deve poder memorizar as definições específicas do tacógrafo do titular do cartão.
368-B)
A capacidade de memória do cartão de controlo para as definições específicas do tacógrafo do titular do cartão é de 3 072 bytes.»;
(f)
O ponto 4.5.6.2 é alterado do seguinte modo:
i)
a seguir ao ponto 4.5.6.2.1, é inserido o seguinte ponto:
«4.5.6.2.1.1
Identificação da aplicação adicional (não acessível na versão 1 das unidades-veículo da segunda geração);
375-A)
O cartão de empresa deve poder memorizar dados de identificação da aplicação adicionais apenas aplicáveis à versão 2.»,
ii)
é aditado o seguinte ponto 4.5.6.2.6:
«4.5.6.2.6
Configurações da VU (não acessível na versão 1 das unidades-veículo da segunda geração)
380-A)
O cartão de empresa deve poder memorizar as definições específicas do tacógrafo do titular do cartão.
380-B)
A capacidade de memória do cartão de empresa para as definições específicas do tacógrafo do titular do cartão é de 3 072 bytes.»;
(27)
O ponto 5 é alterado do seguinte modo:
(a)
O ponto 5.1 é alterado do seguinte modo:
i)
o n.o 383 passa a ter a seguinte redação:
«383)
Antes da ativação, o aparelho de controlo não deve registar nem memorizar os dados a que se referem os requisitos 102 a 133, inclusive. No entanto, antes da ativação, o aparelho de controlo pode registar e memorizar os incidentes de tentativa de violação da segurança, de acordo com o requisito 117, e as falhas do aparelho de controlo, de acordo com o requisito 118.»,
ii)
o n.o 392 passa a ter a seguinte redação:
«392)
À instalação deve seguir-se uma calibração. A primeira calibração pode não incluir necessariamente a introdução da identificação de matrícula do veículo (VRN e Estado-Membro), se a oficina aprovada que executa essa calibração não tiver conhecimento do mesmo. Nessas circunstâncias, deve ser possível, ao proprietário do veículo, e apenas neste momento, introduzir o VRN e o Estado-Membro utilizando o seu cartão de empresa antes da utilização do veículo para os fins abrangidos pelo Regulamento (CE) n.o 561/2006 (por exemplo, utilizando comandos através de uma estrutura de menus adequada da interface homem/máquina da unidade-veículo). A atualização ou confirmação desta introdução de dados apenas será possível utilizando um cartão de oficina.»;
(b)
O ponto 5.2 é alterado do seguinte modo:
i)
O primeiro parágrafo do n.o 395 passa a ter a seguinte redação:
«Uma vez verificado o aparelho de controlo aquando da instalação, deve afixar-se no mesmo uma placa de instalação gravada ou impressa, que seja claramente visível e facilmente acessível. Nos casos em que tal não seja possível, a placa deve ser afixada no pilar «B» do veículo de modo a ser claramente visível. Em veículos que não tenham pilar «B», afixa-se a placa de instalação na zona da porta do veículo, devendo, em todos os casos, ficar claramente visível.»,
ii)
o n.o 396 é alterado do seguinte modo:
(1)
O décimo travessão passa a ter a seguinte redação:
«-
o número de série do sistema de comunicação à distância, caso exista;»;
(2)
É aditado o seguinte décimo sexto travessão:
«-
o tipo de carga por defeito associado ao veículo.»;
(28)
O ponto 6.4 é alterado do seguinte modo:
(a)
o n.o 409 passa a ter a seguinte redação:
«409)
Devem ser feitas inspeções periódicas aos aparelhos instalados nos veículos após qualquer reparação dos aparelhos, após qualquer alteração do coeficiente característico do veículo ou do perímetro efetivo dos pneus das rodas, se a hora UTC do aparelho de controlo apresentar desfasamentos superiores a 5 minutos ou se o VRN for alterado, e pelo menos uma vez no prazo de dois anos (24 meses) após a última inspeção.»;
(b)
Ao n.o 410, é aditado o seguinte nono travessão:
«-
que o identificador da versão do mapa digital memorizado é o mais recente.»;
(c)
é inserido o seguinte n.o 410a:
«410-A)
Caso as autoridades nacionais competentes detetem alguma manipulação, o veículo pode ser enviado para uma oficina autorizada para uma recalibração do aparelho de controlo.»;
(29)
O ponto 8 é alterado do seguinte modo:
(a)
no ponto 8.1, os n.os 429 e 430 passam a ter a seguinte redação:
«429)
Os procedimentos de atualização in situ do software aplicado ao aparelho de controlo devem ser homologados pela autoridade que concedeu a homologação de tipo do aparelho de controlo. A atualização do software não deve alterar nem apagar dados memorizados no aparelho de controlo relativos às atividades dos condutores. A atualização do software só pode ser feita sob a responsabilidade do fabricante do aparelho.
430)
As homologações de tipo das modificações de software destinadas a atualizar um aparelho de controlo com prévia homologação de tipo não podem ser recusadas se as modificações se aplicarem apenas a funções não especificadas no presente anexo. Na atualização de software de um aparelho de controlo pode ser excluída a introdução de novos conjuntos de carateres, se não for tecnicamente viável.»;
(b)
O ponto 8.4 é alterado do seguinte modo:
i)
o n.o 443 passa a ter a seguinte redação:
«443)
Os ensaios de interoperabilidade de aparelhos de controlo ou de cartões tacográficos não podem ser realizados por laboratórios não aprovados na análise de vulnerabilidade da respetiva avaliação de segurança e numa avaliação funcional, exceto nas circunstâncias excecionais referidas no requisito 432.»;
ii)
o n.o 447 passa a ter a seguinte redação:
«447)
O certificado de interoperabilidade é emitido pelo laboratório ao fabricante apenas depois de todos os ensaios de interoperabilidade exigidos terem sido realizados com sucesso e depois de o fabricante comprovar que foram concedidos um certificado de funcionalidade válido e um certificado de segurança válido ao produto, exceto nas circunstâncias excecionais referidas no requisito 432.»;
(30)
O apêndice 1 é alterado do seguinte modo:
(a)
O índice é alterado do seguinte modo:
i)
são inseridos os seguintes pontos 2.11-A e 2.11-B:
«2.11-A.
CardBorderCrossing
2.11b.
CardBorderCrossingRecord’;
ii)
são inseridos os seguintes pontos 2.24-A, 2.24-B, 2.24-C e 2.24-D:
«2.24-A.
CardLoadTypeEntries
2.24-B.
CardLoadTypeEntryRecord
2.24-C.
CardLoadUnloadOperations
2.24-D.
CardLoadUnloadRecord»;
iii)
é inserido o seguinte ponto 2.26-A:
«2.26-A.
CardPlaceAuthDailyWorkPeriod»;
iv)
é inserido o seguinte ponto 2.48-A:
«2.48-A.
CompanyCardApplicationIdentificationV2»;
v)
é inserido o seguinte ponto 2.50-A:
«2.50-A.
ControlCardApplicationIdentificationV2»;
vi)
é inserido o seguinte ponto 2.60-A:
«2.60-A.
DownloadInterfaceVersion’;
vii)
é inserido o seguinte ponto 2.61-A:
«2.61-A.
DriverCardApplicationIdentificationV2»;
viii)
são inseridos os seguintes pontos 2.79-A, 2.79-B e 2.79-C:
«2.79-A.
GNSSAuthAccumulatedDriving
2.79-B.
GNSSAuthStatusADRecord
2.79-C.
GNSSPlaceAuthRecord»;
ix)
o ponto 2.84 passa a ter a seguinte redação:
«2.84.
Reservado para utilização futura»;
x)
é inserido o seguinte ponto 2.89-A:
«2.89-A.
LengthOfFollowingData»;
xi)
é inserido o seguinte ponto 2.90-A:
«2.90-A.
LoadType»;
xii)
é inserido o seguinte ponto 2.101-A:
«2.101-A.
NoOfBorderCrossingRecords»;
xiii)
é inserido o seguinte ponto 2.111-A:
«2.111-A.
NoOfLoadUnloadRecords»;
xiv)
é inserido o seguinte ponto 2.112-A:
‘2.112a.
NoOfLoadTypeEntryRecords»;
xv)
é inserido o seguinte ponto 2.114-A:
«2.114-A.
OperationType»;
xvi)
são inseridos os seguintes pontos 2.116-A e 2.116B:
«2.116-A.
PlaceAuthRecord
2.116-A.
PlaceAuthStatusRecord»;
xvii)
é inserido o seguinte ponto 2.117-A:
«2.117-A.
PositionAuthenticationStatus»;
xviii)
é inserido o seguinte ponto 2.158-A:
«2.158-A.
TachographCardsGen1Suppression»;
xix)
é inserido o seguinte ponto 2.166-A:
«2.166-A.
VehicleRegistrationIdentificationRecordArray»;
xx)
é inserido o seguinte ponto 2.185-A:
«2.185-A.
VuConfigurationLengthRange»;
xxi)
é inserido o seguinte ponto 2.192-A:
«2.192-A.
VuDigitalMapVersion»;
xxii)
são inseridos os seguintes pontos 2.203-A e 2.203B:
«2.203-A.
VuBorderCrossingRecord
2.203-B.
VuBorderCrossingRecordArray»;
xxiii)
é inserido o seguinte ponto 2.204-A:
«2.204-B.
VuGnssMaximalTimeDifference»;
xxiv)
são inseridos os seguintes pontos 2.208-A e 2.208-B:
«2.208-A.
VuLoadUnloadRecord
2.208-B.
VuLoadUnloadRecordArray»;
xxv)
é inserido o seguinte ponto 2.222-A:
«2.222-A.
VuRtcTime»;
xxvi)
são inserido os seguintes pontos 2.234-A, 2.234-B e 2.234-C:
«2.234-A.
WorkshopCardApplicationIdentificationV2
2.234-B.
WorkshopCardCalibrationAddData
2.234-C.
WorkshopCardCalibrationAddDataRecord»;
(b)
no ponto 2, o texto que precede o ponto 2.1 passa a ter a seguinte redação:
«Em todos os tipos de dados a seguir definidos, o valor por defeito relativo a um conteúdo "desconhecido" ou "não aplicável" consiste em preencher o elemento de dados com bytes ‘FF’Hex, salvo indicação em contrário.
Nas aplicações de geração 1 e geração 2 utilizam-se todos os tipos de dados, salvo indicação em contrário. São indicados os tipos de dados apenas utilizados nas aplicações da geração 2, versão 2.
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á seja conhecida pelo leitor. Os números dos requisitos do anexo IC referentes a tais tipos de dados abrangem tanto as aplicações da geração 1 como as da geração 2.
Os tipos de dados do cartão não definidos para os cartões da geração 1 não estão memorizados na aplicação da geração 1 dos cartões de geração 2. Nomeadamente:
—
os números da homologação de tipo memorizados na aplicação da primeira geração dos cartões da segunda geração são truncados para os 8 primeiros carateres, se necessário,
—
somente o «início de FERRY/TRAIN CROSSING» de uma condição específica de «FERRY/TRAIN CROSSING» é memorizado na aplicação da geração 1 dos cartões da geração 2.»;
(c)
são inseridos os seguintes pontos 2.11-A e 2.11-B:
«2.11-A.
CardBorderCrossings
Geração 2, versão 2:
Informação memorizada num cartão de condutor ou de oficina relativa à travessia de fronteiras do veículo, quando este tiver atravessado a fronteira de um país (requisitos 306-F e 356-F do anexo IC).
borderCrossingPointerNewestRecord é o índice do último registo atualizado de travessia de fronteiras.
Valor atribuído é o número correspondente ao numerador do registo de travessia de fronteiras, que começa por ‘0’ na primeira ocorrência do registo de travessia de fronteiras do cartão na estrutura.
cardBorderCrossingRecords é o conjunto de registos de travessia de fronteiras do cartão.
2.11b.
CardBorderCrossingRecord
Geração 2, versão 2:
Informação memorizada num cartão de condutor ou de oficina relativa à travessia de fronteiras do veículo, quando este tiver atravessado a fronteira de um país (requisitos. 147-B, 306-E e 356-E do anexo IC).
countryLeft é o país de partida do veículo, ou «sem informação disponível», de acordo com o requisito 147-B do anexo IC. «Resto do mundo» (código NationNumeric ‘FF’H) é utilizado quando a unidade-veículo não é capaz de determinar o país em que o veículo está localizado (por exemplo, o país atual não consta dos mapas digitais memorizados).
countryEntered é o país no qual o veículo entrou ou o país em que o veículo está localizado no momento da inserção do cartão. «Resto do mundo» (código NationNumeric ‘FF’H) é utilizado quando a unidade-veículo não é capaz de determinar o país em que o veículo está localizado (por exemplo, o país atual não consta dos mapas digitais memorizados).
gnssPlaceAuthRecord contém informações respeitantes à posição do veículo, quando a unidade-veículo deteta que o veículo atravessou a fronteira de um país, ou «sem informação disponível», de acordo com o requisito 147-B do anexo IC, e o respetivo estatuto de autenticação.
vehicleOdometerValue é o valor do conta-quilómetros, quando a unidade-veículo deteta que o veículo atravessou a fronteira de um país, ou «sem informação disponível», de acordo com o requisito 147-B do anexo IC.»;
(d)
são inseridos os seguintes pontos 2.24-A, 2.24-B, 2.24-C e 2.24-D:
«2.24-A.
CardLoadTypeEntries
Geração 2, versão 2:
Informação memorizada num cartão de condutor ou de oficina relativa aos dados do tipo de carga introduzidos numa unidade-veículo (requisitos 306-J e 356-J do anexo IC).
loadTypeEntryPointerNewestRecord é o índice do último registo atualizado de introdução do tipo de carga no cartão.
Valor atribuído: número correspondente ao numerador do registo de introdução do tipo de carga no cartão, que começa por '0' na primeira ocorrência do registo de introdução do tipo de carga no cartão na estrutura.
cardLoadTypeEntryRecords é o conjunto de registos que contêm a data e hora da introdução dos dados e o tipo de carga introduzido.
2.24-B.
CardLoadTypeEntryRecord
Geração 2, versão 2:
Informação memorizada num cartão de condutor ou de oficina relativa às mudanças do tipo de carga introduzidas quando o cartão é inserido numa unidade-veículo (requisitos 306-I e 356-I do anexo IC).
timeStamp é a data e hora em que o tipo de carga foi introduzido.
loadTypeEntered é o tipo de carga introduzido.
2.24-C.
CardLoadUnloadOperations
Geração 2, versão 2:
Informação memorizada num cartão de condutor ou de oficina relativa às operações de carga/descarga do veículo (requisitos 306-H e 356-H do anexo IC).
loadUnloadPointerNewestRecord é o índice do último registo atualizado de carga/descarga no cartão.
Valor atribuído: é o número correspondente ao numerador do registo de carga/descarga no cartão, que começa por ‘0’ na primeira ocorrência do registo de carga/descarga do cartão na estrutura.
cardLoadUnloadRecords é o conjunto de registos que contêm a indicação do tipo de operação realizada (carga, descarga ou carga e descarga simultâneas), a data e hora em que as operações de carga/descarga foram introduzidas, informação sobre a posição do veículo e o valor do conta-quilómetros do veículo.
2.24-D.
CardLoadUnloadRecord
Geração 2, versão 2:
Informação memorizada num cartão de condutor ou de oficina e relativa às operações de carga/descarga do veículo (requisitos 306-G e 356-G do anexo IC).
timeStamp é a data e hora no início da operação de carga/descarga.
operationType é o tipo de operação introduzido (carga, descarga ou carga/descarga simultâneas).
gnssPlaceAuthRecord contém informação relacionada com a posição do veículo.
vehicleOdometerValue é o valor do conta-quilómetros relacionado com o início da operação de carga/descarga.»;
(e)
é inserido o seguinte ponto 2.26-A:
«2.26-A.
CardPlaceAuthDailyWorkPeriod
Geração 2, versão 2:
Informação memorizada num cartão de condutor ou de oficina que indica o estatuto de autenticação dos locais onde se iniciam e/ou terminam os períodos de trabalho diário (requisitos 306-B e 356-B do anexo IC).
placeAuthPointerNewestRecord é o índice do último registo atualizado do estatuto de autenticação do local.
Valor atribuído: o número correspondente ao numerador do registo atualizado do estatuto de autenticação do local, que começa por ‘0’ na primeira ocorrência dos registos do estatuto de autenticação do local na estrutura.
placeAuthStatusRecords é o conjunto dos registos que contêm o estatuto de autenticação do local dos locais introduzidos».
(f)
no ponto 2.36, o texto correspondente à atribuição do valor «bbH» é substituído pelo seguinte:
‘
‘bb’HÍndice para alterações relativas à utilização dos elementos de dados definidos para a estrutura dada pelo byte elevado.
‘00’H para aplicações da geração 1
‘00’H para a versão 1 das aplicações da geração 2
‘01’H para a versão 2 das aplicações da geração 2»;
(g)
No ponto 2.40, o n.o entre o título e o código passa a ter a seguinte redação:
«Geração 2:
Informação memorizada num cartão de condutor ou de oficina relativa às unidades-veículos utilizadas pelo titular do cartão (requisitos. 304 e 352 do anexo IC)».
(h)
é inserido o seguinte ponto 2.48-A:
«2.48-A.
CompanyCardApplicationIdentificationV2
Geração 2, versão 2:
Informação memorizada num cartão de empresa relativa à identificação da aplicação do cartão (requisito 375-A do anexo IC).
lengthOfFollowingData é o número de bytes seguintes no registo.
vuConfigurationLengthRange é o número de bytes num cartão tacográfico, disponíveis para memorizar configurações da VU.»;
(i)
é inserido o seguinte ponto 2.50-A:
«2.50-A.
ControlCardApplicationIdentificationV2
Geração 2, versão 2:
Informação memorizada num cartão de controlo relativa à identificação da aplicação do cartão (requisito 363a do anexo IC).
lengthOfFollowingData é o número de bytes seguintes no registo.
vuConfigurationLengthRange é o número de bytes num cartão tacográfico, disponíveis para memorizar configurações da VU.»;
(j)
é inserido o seguinte ponto 2.60-A:
«2.60-A.
DownloadInterfaceVersion
Geração 2, versão 2:
Código que indica a versão da interface de descarregamento de uma unidade-veículo.
Valor atribuído: ‘aabb’H:
‘aa’H ‘00’H: não utilizado,
‘01’H: unidade-veículo da geração 2,
‘bb’H ‘00’H: não utilizado,
‘01’H: versão 2 da unidade-veículo da geração 2.»;
(k)
é inserido o seguinte ponto 2.61-A:
«2.61-A.
DriverCardApplicationIdentificationV2
Geração 2, versão 2:
Informação memorizada num cartão de condutor e relativa à identificação da aplicação do cartão (requisito 278-A do anexo IC).
lengthOfFollowingData é o número de bytes seguintes no registo.
noOfBorderCrossingRecords é o número de registos de travessia de fronteiras que o cartão de condutor pode memorizar.
noOfLoadUnloadRecords é o número de registos de carga/descarga que o cartão de condutor pode memorizar.
noOfLoadTypeEntryRecords é o número de registos de introdução do tipo de carga que o cartão de condutor pode memorizar.
vuConfigurationLengthRange é o número de bytes num cartão tacográfico, disponíveis para memorizar configurações da VU.»;
(l)
O ponto 2.63 passa a ter a seguinte redação:
«2.63.
DSRCSecurityData
Geração 2:
Relativamente à definição deste tipo de dados, ver o apêndice 11.»;
(m)
no ponto 2.66, o texto correspondente à geração 2 passa a ter a seguinte redação:
«Geração 2
Valor atribuído: em conformidade com a norma ISO/IEC 8824-1.»;
(n)
o ponto 2.70 é alterado do seguinte modo:
i)
o título correspondente à geração 2 passa a ter a seguinte redação:
«Geração 2, versão 1:»;
ii)
é aditado o seguinte texto:
«Geração 2, versão 2:
‘0x’H
Incidentes gerais,
‘00’H
Sem pormenores adicionais,
‘01’H
Inserção de cartão não válido,
‘02’H
Conflito de cartões,
‘03’H
Sobreposição de tempos,
‘04’H
condução sem cartão adequado,
‘05’H
Inserção de cartão durante a condução,
‘06’H
Última sessão de cartão encerrada incorretamente,
‘07’H
Excesso de velocidade,
‘08’H
Interrupção da alimentação energética,
‘09’H
Erro nos dados de movimento,
‘0A’H
Conflito relativo ao movimento do veículo,
‘0B’H
Conflito de tempo (GNSS versus relógio interno da VU),
‘0C’H
Erro de comunicação com o sistema de comunicação à distância,
‘0D’H
Ausência de informações sobre a posição do recetor GNSS,
‘0E’H
Erro de comunicação com o módulo GNSS externo,
‘0F’H
Anomalia do GNSS,
‘1x’H
Incidentes de tentativa de violação da segurança relativos à VU,
‘10’H
Sem pormenores adicionais,
‘11’H
Falha da autenticação do sensor de movimentos,
‘12’H
Falha da autenticação do cartão tacográfico,
‘13’H
Mudança não autorizada de sensor de movimentos,
‘14’H
Erro de integridade na entrada de dados relativos ao cartão,
‘15’H
Erro de integridade nos dados memorizados relativos a um utilizador,
‘16’H
Erro na transferência interna de dados,
‘17’H
Abertura não autorizada da caixa,
«‘18’H
Sabotagem do equipamento informático,
«‘19’H
Violação de deteção de GNSS,
‘1A’H
Falha de autenticação do módulo GNSS externo,
‘1B’H
Certificado do módulo GNSS externo expirado,
‘1C’H
Inconsistência entre os dados de movimento e os dados da atividade memorizada do condutor,
‘1D’H a ‘1F’H
RFU,
‘2x’H
Incidentes de tentativa de violação da segurança relativos ao sensor,
‘20’H
Sem pormenores adicionais,
‘21’H
Falha de autenticação,
‘22’H
Erro de integridade dos dados memorizados,
‘23’H
Erro na transferência interna de dados,
‘24’H
Abertura não autorizada da caixa,
‘25’H
Sabotagem do equipamento informático,
‘26’H a ‘2F’H
RFU,
‘3x’H
Falhas do aparelho de controlo,
‘30’H
Sem pormenores adicionais,
‘31’H
Falha interna da VU,
‘32’H
Falha da impressora,
‘33’H
Falha da visualização,
‘34’H
Falha do descarregamento,
‘35’H
Falha do sensor,
‘36’H
Recetor GNSS interno,
‘37’H
Módulo GNSS externo,
‘38’H
Sistema de comunicação à distância,
‘39’H
Interface ITS,
‘3A’H
Falha do sensor interno,
‘3B’H a ‘3F’H
RFU,
‘4x’H
Falhas do cartão,
‘40’H
Sem pormenores adicionais,
‘41’H a ‘4F’H
RFU,
‘50’H a ‘7F’H
RFU,
‘80’H a ‘FF’H
Específico do fabricante.»;
(o)
o ponto 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. Valor atribuído: consultar o registo na base de dados a gerir pela Comissão Europeia (ver https://dtc.jrc.ec.europa.eu).
sealIdentifier é um identificador destinado ao selo, que é único para o fabricante. Valor atribuído: número alfanumérico, único no domínio do fabricante, de acordo com a norma [ISO8859-1].»;
(p)
no ponto 2.76, o n.o entre o título e o código passa a ter a seguinte redação:
«Geração 2:
As coordenadas geográficas são codificadas como números inteiros. Estes números inteiros são múltiplos da codificação ±DDMM.M para a latitude e ±DDDMM.M para a longitude. Neste caso, ±DD ou ±DDD indica os graus e MM.M os minutos. A longitude e a latitude de uma posição desconhecida são representadas como Hex ‘7FFFFF’ (decimal 8388607).»;
(q)
são inseridos os seguintes pontos 2.79-A, 2.79-B e 2.79-C:
«2.79-A.
GNSSAuthAccumulatedDriving
Geração 2, versão 2:
Informação memorizada num cartão de condutor ou de oficina que indica o estatuto de autenticação das posições GNSS do veículo, se o tempo de condução acumulado atingir um múltiplo de três horas (requisitos 306-D e 356-D do anexo IC).
placeAuthPointerNewestRecord é o índice do último registo atualizado do estatuto de autenticação do local.
Valor atribuído é o número correspondente ao numerador do registo do estatuto de autenticação da posição GNSS, que começa por ‘0’ na primeira ocorrência do registo do estatuto de autenticação da posição GNSS na estrutura.
gnssAuthStatusADRecords é 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 o estatuto de autenticação da posição GNSS.
2.79-B.
GNSSAuthStatusADRecord
Geração 2, versão 2:
Informação memorizada num cartão de condutor ou de oficina que indica o estatuto de autenticação das posições GNSS do veículo, se o tempo de condução acumulado atingir um múltiplo de três horas (requisitos 306-C e 356-C do anexo IC). Outras informações relativas à própria posição GNSS são memorizadas num registo diferente (ver o ponto 2.79 GNSSAccumulatedDrivingRecord).
timeStamp é a data e hora em que o tempo de condução acumulado atinge um múltiplo de três horas (que é a mesma data e hora no GNSSAccumulatedDrivingRecord correspondente).
authenticationStatus é o estatuto de autenticação da posição GNSS quando o tempo de condução acumulado atinge um múltiplo de três horas.
2.79-C.
GNSSPlaceAuthRecord
Geração 2, versão 2:
Informação relacionada com a posição GNSS do veículo (requisitos 108, 109, 110, 296, 306-A, 306-C, 306-E, 306-G, 356-A, 356-C, 356-E e 356-G do anexo IC).
timeStamp é a data e a hora em que a posição GNSS do veículo foi determinada.
gnssAccuracy é a precisão dos dados de posição GNSS.
geoCoordinates é a localização registada com a utilização de GNSS.
authenticationStatus é o estatuto de autenticação da posição GNSS quando foi determinada.»;
(r)
o ponto 2.84 passa a ter a seguinte redação:
«2.84.
Reservado para utilização futura»;
(s)
é inserido o seguinte ponto 2.89-A:
«2.89-A.
LengthOfFollowingData
Geração 2, versão 2:
Indicador relativo ao comprimento para registos extensíveis.
Valor atribuído: ver o apêndice 2.»;
(t)
é inserido o seguinte ponto 2.90-A:
«2.90-A.
LoadType
Geração 2, versão 2:
Código que identifica um tipo de carga introduzido.
Valor atribuído:
‘00’H
Tipo de carga indefinido,
‘01’H
Mercadorias,
‘02’H
Passageiros,
‘03’H .. ‘FF’H
RFU.»;
(u)
é inserido o seguinte ponto 2.101-A:
‘2.101a.
NoOfBorderCrossingRecords
Geração 2, versão 2:
Número de registos de travessia de fronteiras que um cartão de condutor ou de oficina pode memorizar.
Valor atribuído: ver o apêndice 2.»;
(v)
é inserido o seguinte ponto 2.111-A:
«2.111-A.
NoOfLoadUnloadRecords
Geração 2, versão 2:
Número de registos de carga/descarga que um cartão pode memorizar.
Valor atribuído: ver o apêndice 2.»;
(w)
é inserido o seguinte ponto 2.112-A:
«2.112-A.
NoOfLoadTypeEntryRecords
Geração 2, versão 2:
Número de registos de introdução do tipo de carga que um cartão de condutor ou de oficina pode memorizar.
Valor atribuído: ver o apêndice 2.»;
(x)
é inserido o seguinte ponto 2.114-A:
«2.114-A.
OperationType
Geração 2, versão 2:
Código que identifica um tipo de operação introduzido.
Valor atribuído:
‘00’H
RFU,
‘01’H
Operação de carga,
‘02’H
Operação de descarga,
‘03’H
Operação de carga/descarga simultânea,
‘04’H .. ‘FF’H
RFU.»;
(y)
são inseridos os seguintes pontos 2.116-A e 2.116-B:
«2.116-A.
PlaceAuthRecord
Informação relativa a um local onde se inicia ou termina um período de trabalho diário (requisitos 108, 271, 296, 324 e 347 do anexo IC).
Geração 2, versão 2:
entryTime é uma data e hora relativa à entrada.
entryTypeDailyWorkPeriod é o tipo de entrada.
dailyWorkPeriodCountry é o país introduzido.
dailyWorkPeriodRegion é a região introduzida.
vehicleOdometerValue é o valor do conta-quilómetros no momento da introdução do local.
entryGNSSPlaceAuthRecord é a localização registada, o estatuto de autenticação do GNSS e a hora.
2.116-B.
PlaceAuthStatusRecord
Geração 2, versão 2:
Informação memorizada num cartão de condutor ou de oficina que indica o estatuto de autenticação dos locais onde se iniciam e/ou terminam os períodos de trabalho diário (requisitos 306-B e 356-B do anexo IC). Outras informações relativas ao próprio local são memorizadas num registo diferente (ver o ponto 2.117 PlaceRecord).
entryTime é uma data e hora relativa à entrada (que é a mesma data e hora do PlaceRecord correspondente).
authenticationStatus é o estatuto de autenticação da posição GNSS registada.»;
(z)
é inserido o seguinte ponto 2.117-A:
«2.117-A.
PositionAuthenticationStatus
Geração 2, versão 2:
Valor atribuído (ver o apêndice 12):
‘00’H
Não autenticado (ver o apêndice 12, requisito GNS_39),
‘01’H
Autenticado (ver o apêndice 12, requisito GNS_39),
‘02’H .. ‘FF’H
RFU.»;
(aa)
no ponto 2.120, os valores atribuídos ‘22’H a ‘7F’H passam a ter a seguinte redação:
«‘22’H
VuBorderCrossingRecord,
‘23’H
VuLoadUnloadRecord,
‘24’H
VehicleRegistrationIdentification,
‘25’H a ‘7F’H
RFU.»;
(bb)
é inserido o seguinte ponto 2.158-A:
«2.158-A.
TachographCardsGen1Suppression
Geração 2, versão 2:
Capacidade de uma VU de segunda geração para utilizar a primeira geração dos cartões de condutor, controlo e empresa (ver o apêndice 15, MIG_002).
Valor atribuído:
‘0000’H
A VU é capaz de utilizar a geração 1 dos cartões tacográficos (valor por defeito),
‘A5E3’H
A VU não é capaz de utilizar a geração 1 dos cartões tacográficos,
Todos os outros valores
Não utilizado.»;
(cc)
é inserido o seguinte ponto 2.166-A:
«2.166-A.
VehicleRegistrationIdentificationRecordArray
Geração 2, versão 2:
O número de matrícula do veículo, mais metadados utilizados no protocolo de descarregamento.
recordType indica o tipo de registo (VehicleRegistrationIdentification). Valor atribuído: ver RecordType.
recordSize é o tamanho de VehicleRegistrationIdentification, em bytes.
noOfRecords é o número de registos nos registos definidos.
records é o conjunto de números de matrícula dos veículos.»;
(dd)
no ponto 2.168, a primeira linha a seguir ao título passa a ter a seguinte redação:
«Geração 2, versão 1:»;
(ee)
o ponto 2.174 é alterado do seguinte modo:
i)
o título correspondente à geração 2 passa a ter a seguinte redação:
«Geração 2, versão 1:»;
ii)
é aditado o seguinte texto:
«Geração 2, versão 2:
Utiliza-se o seguinte elemento de dados, além dos utilizados na geração 1:
sensorSerialNumber é o número de série do sensor de movimentos emparelhado com a unidade-veículo no final da calibração,
sensorGNSSSerialNumber é o número de série do módulo GNSS externo acoplado à unidade-veículo no final da calibração (caso exista),
rcmSerialNumber é o número de série do sistema de comunicação à distância acoplado à unidade-veículo no final da calibração (caso exista),
sealDataVu fornece informações sobre os selos ligados a diferentes componentes do veículo.
byDefaultLoadType é o tipo de carga or defeito do veículo (apenas presente na versão 2).
calibrationCountry é o país em que a calibração foi realizada.
calibrationCountryTimestamp é a data e hora em que a posição utilizada para determinar o país em que a calibração foi realizada foi transmitida pelo recetor GNSS.»;
(ff)
é inserido o seguinte ponto 2.185-A:
«2.185-A.
VuConfigurationLengthRange
Geração 2, versão 2:
Número de bytes num cartão tacográfico, disponíveis para memorizar configurações da VU.
Valor atribuído: ver o apêndice 2.»;
(gg)
é inserido o seguinte ponto 2.192-A:
‘2.192a.
VuDigitalMapVersion
Geração 2, versão 2:
Versão do mapa digital memorizado na unidade-veículo (requisito 133-J do anexo IC).
Valor atribuído: tal como especificado no sítio Web específico seguro disponibilizado pela Comissão Europeia (requisito 133-K do anexo IC).»;
(hh)
o ponto 2.203 é alterado do seguinte modo:
i)
o título correspondente à geração 2 passa a ter a seguinte redação:
«Geração 2, versão 1:»;
ii)
é aditado o seguinte texto:
«Geração 2, versão 2:
Informação memorizada numa unidade-veículo 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).
Na geração 2, versão 2, em lugar de gnssPlaceRecord, é utilizado gnssPlaceAuthRecord, que contém adicionalmente o estatuto de autenticação.»;
(ii)
são inseridos os seguintes pontos 2.203-A e 2.203-B:
«2.203-A.
VuBorderCrossingRecord
Geração 2, versão 2:
Informação memorizada numa unidade-veículo relativa à travessia de fronteiras do veículo, quando este tiver atravessado a fronteira de um país (requisitos 133-A e 133-B do anexo IC).
cardNumberAndGenDriverSlot identifica o cartão, incluindo a sua geração, que se encontra inserido na ranhura do condutor.
cardNumberAndGenCodriverSlot identifica o cartão, incluindo a sua geração, que se encontra inserido na ranhura do ajudante.
countryLeft é o país de partida do veículo, baseado na última posição disponível antes de a travessia da fronteira ser detetada. «Resto do mundo» (código NationNumeric ‘FF’H) é utilizado quando a unidade-veículo não é capaz de determinar o país em que o veículo está localizado (por exemplo, o país atual não consta dos mapas digitais memorizados).
countryEntered é o país no qual o veículo entrou. «Resto do mundo» (código NationNumeric ‘FF’H) é utilizado quando a unidade-veículo não é capaz de determinar o país em que o veículo está localizado (por exemplo, o país atual não consta dos mapas digitais memorizados).
gnssPlaceAuthRecord contém informação relacionada com a posição do veículo, quando a travessia da fronteira foi detetada, e o respetivo estatuto de autenticação.
vehicleOdometerValue é o valor do conta-quilómetros, quando a unidade-veículo deteta que o veículo atravessou a fronteira de um país.
2.203-B.
VuBorderCrossingRecordArray
Geração 2, versão 2:
Informação memorizada numa unidade-veículo relativa às travessias de fronteiras do veículo (requisito 133-C do anexo IC).
recordType indica o tipo de registo (VuBorderCrossingRecord). Valor atribuído: ver RecordType.
recordSize é o tamanho de VuBorderCrossingRecord, em bytes.
noOfRecords é o número de registos nos registos definidos.
records é o conjunto de registos de travessias de fronteiras.»;
(jj)
é inserido o seguinte ponto 2.204-A:
«2.204-A.
VuGnssMaximalTimeDifference
Geração 2, versão 2:
A diferença máxima entre a hora real e a hora do relógio em tempo real da VU, com base na deriva de tempo máxima especificada no anexo IC, requisito 041, transmitida pela unidade-veículo a um módulo GNSS externo; ver o apêndice 12, requisito GNS_3g.
’;
(kk)
No ponto 2.205, o texto correspondente à geração 2 passa a ter a seguinte redação:
«Geração 2:
Utilizam-se os seguintes elementos de dados, além dos utilizados na geração 1:
vuGeneration identifica a geração da unidade-veículo.
vuAbility fornece informações sobre se a VU aceita cartões tacográficos da geração 1 ou não.
vuDigitalMapVersion é a versão do mapa digital memorizado na unidade-veículo (apenas presente na versão 2).»;
(ll)
são inseridos os seguintes pontos 2.208-A e 2.208-B:
«2.208-A.
VuLoadUnloadRecord
Geração 2, versão 2:
Informação memorizada na unidade-veículo relativa à operação de carga/descarga introduzida (requisitos 133-E, 133-F e 133-G do anexo IC).
timeStamp é a data e hora em que a operação de carga/descarga foi introduzida.
operationType é o tipo de operação introduzido (carga, descarga ou carga/descarga simultâneas).
cardNumberAndGenDriverSlot identifica o cartão, incluindo a sua geração, que se encontra inserido na ranhura do condutor.
cardNumberAndGenCodriverSlot identifica o cartão, incluindo a sua geração, que se encontra inserido na ranhura do ajudante.
gnssPlaceAuthRecord contém informação relacionada com a posição do veículo e o respetivo estatuto de autenticação.
vehicleOdometerValue é o valor do conta-quilómetros relacionado com a operação de carga/descarga.
2.208-B.
VuLoadUnloadRecordArray
Geração 2, versão 2:
Informação memorizada na unidade-veículo relativa a uma operação de carga/descarga introduzida (requisito 133-H do anexo IC).
recordType indica o tipo de registo (VuLoadUnloadRecord). Valor atribuído: ver RecordType.
recordSize é o tamanho de VuLoadUnloadRecord, em bytes.
noOfRecords é o número de registos nos registos definidos.
records é um conjunto de registos de operações de carga/descarga.»;
(mm)
o ponto 2.219 é alterado do seguinte modo:
i)
o título correspondente à geração 2 passa a ter a seguinte redação:
«Geração 2, versão 1:»;
ii)
é aditado o seguinte texto:
«Geração 2, versão 2:
Informação memorizada numa unidade-veículo relativa a um local onde um condutor inicia ou termina um período de trabalho diário (requisito 087 do anexo 1B e requisitos 108 e 110 do anexo 1C).
Em vez de placeRecord, a estrutura de dados versão 2 da geração 2 recorre ao elemento de dados seguinte:
placeAuthRecord contém a informação relativa ao local introduzido, à posição registada, ao estatuto de autenticação do GNSS e à hora de determinação da posição.»;
(nn)
a seguir ao ponto 2.222, é inserido o seguinte ponto:
«2.222-A.
VuRtcTime
Geração 2, versão 2:
A hora do relógio RTC da VU, transmitida pela VU a um módulo GNSS externo, ver o requisito GNS_3f do apêndice 12.
’;
(oo)
são inserido os seguintes pontos 2.234-A, 2.234-B e 2.234-C:
«2.234-A.
WorkshopCardApplicationIdentificationV2
Geração 2, versão 2:
Informação memorizada num cartão de oficina relativa à identificação da aplicação do cartão (requisito 330-A do anexo IC).
lengthOfFollowingData é o número de bytes seguintes no registo.
noOfBorderCrossingRecords é o número de registos de travessia de fronteiras que o cartão de oficina pode memorizar.
noOfLoadUnloadRecords é o número de registos de carga/descarga que o cartão de oficina pode memorizar.
noOfLoadTypeEntryRecords é o número de registos de introdução do tipo de carga que o cartão de oficina pode memorizar.
vuConfigurationLengthRange é o número de bytes num cartão tacográfico, disponíveis para memorizar configurações da VU.
2.234-B.
WorkshopCardCalibrationAddData
Geração 2, versão 2:
Informação memorizada num cartão de oficina relativa aos dados adicionais (ou seja, tipo de carga por defeito) introduzidos durante uma calibração (requisito 356l do anexo IC).
calibrationPointerNewestRecord é o índice do último registo atualizado de dados adicionais de calibração.
Valor atribuído é o número correspondente ao numerador do registo de dados adicionais de calibração, que começa por ‘0’ na primeira ocorrência do registo de dados adicionais de calibração na estrutura.
workshopCardCalibrationAddDataRecords é o conjunto de registos que contêm o valor da data e hora antigas, o valor de identificação do veículo e o tipo de carga or defeito do veículo.
2.234-C.
WorkshopCardCalibrationAddDataRecord
Geração 2, versão 2:
Informação memorizada num cartão de oficina relativa ao tipo de carga por defeito introduzido durante uma calibração (requisito 356-K do anexo IC).
oldTimeValue é o valor da data e hora antigos contido no WorkshopCardCalibrationRecord correspondente,
vehicleIdentificationNumber é o número de identificação do veículo, também contido no WorkshopCardCalibrationRecord correspondente,
byDefaultLoadType é o tipo de carga por defeito do veículo (apenas presente na versão 2).
calibrationCountry é o país em que a calibração foi realizada.
calibrationCountryTimestamp é a data e hora em que a posição utilizada para determinar este país foi transmitida pelo recetor GNSS.»;
(31)
O apêndice 2 é alterado do seguinte modo:
(a)
no ponto 2.5, a segunda frase do parágrafo TCS_09 passa a ter a seguinte redação:
«Estado de funcionamento durante a execução de comandos ou ações de interface com a unidade-veículo,»;
(b)
o ponto 3 é alterado do seguinte modo:
i)
no ponto 3.2.1, é eliminado o quarto travessão do parágrafo TCS_16.
ii)
o ponto 3.5.7.2 é alterado do seguinte modo:
(1)
O parágrafo TCS_86 passa a ter a seguinte redação:
«TCS_86
O comando pode ser executado no MF, no DF Tachograph e no DF Tachograph_G2 (ver também TCS_34).»;
(2)
Os parágrafos TCS_88 e TCS_89 passam a ter a seguinte redação:
«TCS_88
Às APDU de comprimento curto aplicam-se as disposições seguintes: o IFD utiliza o número mínimo necessário de APDU para transmitir a carga útil do comando e transmitir o número máximo de bytes na primeira APDU de comando. No entanto, o cartão deve aceitar qualquer valor de «Lc» até 255 bytes.
TCS_89 Às APDU de comprimento aumentado aplicam-se as disposições seguintes: se o certificado não couber numa única APDU, o cartão aceita o encadeamento de comando. O IFD utiliza o número mínimo necessário de APDU para transmitir a carga útil do comando e transmitir o número máximo de bytes na primeira APDU de comando. Se for necessário encadeamento, o cartão deve aceitar qualquer valor de «Lc» até à dimensão do comprimento aumentado indicado.
Nota: segundo o apêndice 11, o cartão memoriza o certificado ou os conteúdos relevantes do certificado e atualiza o respetivo currentAuthenticatedTime.
A estrutura da mensagem de resposta e as palavras de estatuto são as definidas em TCS_85.»;
iii)
no ponto 3.5.10, a última linha do quadro que figura no parágrafo TCS_101 é substituída pela seguinte:
«Le
1
‘00h’
Conforme a norma ISO/IEC 7816-4
»;
iv)
no ponto 3.5.16, a última linha do quadro que figura no parágrafo TCS_138 é substituída pela seguinte:
«Le
1
‘00h’
Conforme a norma ISO/IEC 7816-4
»;
(c)
o ponto 4 é alterado do seguinte modo:
i)
No parágrafo TCS_141, a segunda frase passa a ter a seguinte redação:
«Neste capítulo especificam-se os números máximo e mínimo de registos para as diferentes aplicações. Nos cartões de condutor e oficina da versão 2 da geração 2, a aplicação da geração 1 aceita o número máximo de registos especificado em TCS_150 e TCS_158.»;
ii)
no ponto 4.2.1, o quadro do parágrafo TCS_150 é alterado do seguinte modo:
(1)
A linha correspondente a cardIssuingAuthorityName passa a ter a seguinte redação:
«
»;
(2)
A linha correspondente a LastCardDownload passa a ter a seguinte redação:
«
»;
iii)
o ponto 4.2.2 é alterado do seguinte modo:
(1)
O parágrafo TCS_152 passa a ter a seguinte redação:
«TCS_152
Uma vez personalizada, a aplicação do cartão de condutor da geração 2 terá permanentemente a estrutura de ficheiro e as regras de acesso do ficheiro seguintes:
Notas:
—
ao SFID do identificador EF curto é atribuído um número decimal: por exemplo, o valor 30 corresponde a 11110 em binário.
—
EF Application_Identification_V2, EF Places_Authentication, EF GNSS_Places_Authentication, EF Border_Crossings, EF Load_Unload_Operations, EF VU_Configuration e EF Load_Type_Entries apenas estão presentes no cartão de condutor da versão 2 da geração 2.
—
cardStructureVersion em EF Application_Identification é igual a {01 01} para o cartão de condutor da versão 2 da geração 2, ao passo que era igual a {01 00} para o cartão de condutor da versão 1 da geração 2.
Neste quadro utilizam-se as abreviaturas seguintes para o controlo de acesso:
SC1
ALW OR SM-MAC-G2
SC5
Para o comando Read Binary com byte INS par: SM-C-MAC-G2 E SM-R-ENC-MAC-G2
Para o comando Read Binary com byte INS ímpar (quando aceite): NEV»;
(2)
O parágrafo TCS_154 passa a ter a seguinte redação:
«TCS_154
A aplicação para cartão de condutor da geração 2 tem a seguinte estrutura de dados:
»;
(3)
No parágrafo TCS_155, o quadro passa a ter a seguinte redação:
«
Mín.
Máx.
n1
NoOfEventsPerType
12
12
n2
NoOfFaultsPerType
24
24
n3
NoOfCardVehicleRecords
200
200
n4
NoOfCardPlaceRecords
112
112
n6
CardActivityLengthRange
13776 bytes
(56 dias * 117 mudanças de atividade)
13776 bytes
(56 dias * 117 mudanças de atividade)
n7
NoOfCardVehicleUnitRecords
200
200
n8
NoOfGNSSADRecords
336
336
n9
NoOfSpecificConditionRecords
112
112
n10
NoOfBorderCrossingRecords
1120
1120
n11
NoOfLoadUnloadRecords
1624
1624
n12
NoOfLoadTypeEntryRecords
336
336
n13
VuConfigurationLengthRange
3072 bytes
3072 bytes
»;
iv)
o ponto 4.3.2 é alterado do seguinte modo:
(1)
O parágrafo TCS_160 passa a ter a seguinte redação:
«TCS_160
Uma vez personalizada, a aplicação para cartão de oficina da geração 2 terá permanentemente a estrutura de ficheiro e as regras de acesso do ficheiro seguintes.
Notas:
—
ao SFID do identificador EF curto é atribuído um número decimal: por exemplo, o valor 30 corresponde a 11110 em binário.
—
EF Application_Identification_V2, EF Places_Authentication, EF GNSS_Places_Authentication, EF Border_Crossings, EF Load_Unload_Operations, EF VU_Configuration e EF Load_Type_Entries apenas estão presentes no cartão de oficina da versão 2 da geração 2.
—
cardStructureVersion em EF Application_Identification é igual a {01 01} para o cartão de oficina da versão 2 da geração 2, ao passo que era igual a {01 00} para o cartão de oficina da versão 1 da geração 2.
Neste quadro utilizam-se as abreviaturas seguintes para o controlo de acesso:
SC1
ALW OR SM-MAC-G2
SC5
Para o comando Read Binary com byte INS par: SM-C-MAC-G2 E SM-R-ENC-MAC-G2
Para o comando Read Binary com byte INS ímpar (quando aceite): NEV»;
(2)
No parágrafo TCS_162, o quadro passa a ter a seguinte redação:
«
»;
(3)
No parágrafo TCS_163, o quadro passa a ter a seguinte redação:
«
Mín.
Máx.
n1
NoOfEventsPerType
3
3
n2
NoOfFaultsPerType
6
6
n3
NoOfCardVehicleRecords
8
8
n4
NoOfCardPlaceRecords
8
8
n5
NoOfCalibrationRecords
255
255
n6
CardActivityLengthRange
492 bytes (1 dia * 240 mudanças de atividade)
492 bytes (1 dia *
240 mudanças de atividade)
n7
NoOfCardVehicleUnitRecords
8
8
n8
NoOfGNSSADRecords
24
24
n9
NoOfSpecificConditionRecords
4
4
n10
NoOfBorderCrossingRecords
4
4
n11
NoOfLoadUnloadRecords
8
8
n12
NoOfLoadTypeEntryRecords
4
4
n13
VuConfigurationLengthRange
3072 bytes
3072 bytes
»;
v)
o ponto 4.4.2 é alterado do seguinte modo:
(1)
O parágrafo TCS_168 passa a ter a seguinte redação:
«TCS_168
Uma vez personalizada, a aplicação para cartão de controlo da geração 2 terá permanentemente a estrutura de ficheiro e as regras de acesso do ficheiro seguintes.
Notas:
—
ao SFID do identificador EF curto é atribuído um número decimal: por exemplo, o valor 30 corresponde a 11110 em binário.
—
EF Application_Identification_V2 e EF VU_Configuration apenas estão presentes no cartão de controlo da versão 2 da geração 2,
—
cardStructureVersion em EF Application_Identification é igual a {01 01} para o cartão de controlo da versão 2 da geração 2, ao passo que era igual a {01 00} para o cartão de controlo da versão 1 da geração 2.
Neste quadro utilizam-se as abreviaturas seguintes para o controlo de acesso:
SC1
ALW OR SM-MAC-G2
SC5
Para o comando Read Binary com byte INS par: SM-C-MAC-G2 E SM-R-ENC-MAC-G2
Para o comando Read Binary com byte INS ímpar (quando aceite): NEV»;
(2)
No parágrafo TCS_170, o quadro passa a ter a seguinte redação:
«
»;
(3)
No parágrafo TCS_171, o quadro passa a ter a seguinte redação:
«
Mín.
Máx.
n7
NoOfControlActivityRecords
230
520
n13
VuConfigurationLengthRange
3072 bytes
3072 bytes
»;
vi)
o ponto 4.5.2 é alterado do seguinte modo:
(1)
O parágrafo TCS_176 passa a ter a seguinte redação:
«TCS_176
Uma vez personalizada, a aplicação para cartão de empresa da geração 2 terá permanentemente a estrutura de ficheiro e as regras de acesso do ficheiro seguintes.
Notas:
—
ao SFID do identificador EF curto é atribuído um número decimal: por exemplo, o valor 30 corresponde a 11110 em binário.
—
EF Application_Identification_V2 e EF VU_Configuration apenas estão presentes no cartão de empresa da versão 2 da geração 2,
—
cardStructureVersion em EF Application_Identification é igual a {01 01} para o cartão de empresa da versão 2 da geração 2, ao passo que era igual a {01 00} para o cartão de empresa da versão 1 da geração 2.
Neste quadro utilizam-se as abreviaturas seguintes para o controlo de acesso:
SC1
ALW OR SM-MAC-G2
SC5
Para o comando Read Binary com byte INS par: SM-C-MAC-G2 E SM-R-ENC-MAC-G2
Para o comando Read Binary com byte INS ímpar (quando aceite): NEV»;
(2)
No parágrafo TCS_178, o quadro passa a ter a seguinte redação:
«
»;
(3)
No parágrafo TCS_179, o quadro passa a ter a seguinte redação:
«
Mín.
Máx.
n8
NoOfCompanyActivityRecords
230
520
n13
VuConfigurationLengthRange
3072 bytes
3072 bytes
»;
(32)
O apêndice 3 é alterado do seguinte modo:
(a)
o ponto 1 é alterado do seguinte modo:
i)
o n.o relativo a condições específicas passa a ter a seguinte redação:
«
Condições específicas, introdução manual de dados
Fora de âmbito
Travessia de batelão/comboio
Operação de carga
Operação de descarga,
Operação de carga/descarga simultâneas,
Tipo de carga passageiros
Tipo de carga mercadorias,
Tipo de carga tipo de carga indefinido»;
ii)
Os pictogramas para diversos são alterados do seguinte modo:
(1)
O pictograma de segurança é substituído pelo seguinte:
«
Segurança/dados autenticados/selos»;
(2)
É aditado o seguinte pictograma:
«
Mapa digital/travessia de fronteiras»;
(b)
o ponto 2 é alterado do seguinte modo:
i)
são aditadas aos pictogramas para diversos as seguintes combinações de pictogramas:
«
Posição em que o veículo atravessou a fronteira entre dois países
Posição em que ocorreu uma operação de carga
Posição em que ocorreu uma operação de descarga
Posição em que ocorreu uma operação de carga/descarga simultâneas»;
ii)
são aditadas aos pictogramas para impressões as seguintes combinações de pictogramas:
«
Impressão do histórico de cartões inseridos»;
iii)
são aditadas aos pictogramas para incidentes as seguintes combinações de pictogramas:
«
Anomalia do GNSS»;
(33)
O apêndice 4 é alterado do seguinte modo:
(a)
no ponto 1, o parágrafo PRT_005 passa a ter a seguinte redação:
«PRT_005
Os campos relativos a dados em sequência são impressos com alinhamento à esquerda e, conforme necessário, preenchidos com espaços segundo o comprimento dos atributos dos dados ou truncados segundo o comprimento dos atributos dos dados. Os nomes e endereços podem ser impressos em duas linhas.»;
b)
o ponto 2 é alterado do seguinte modo:
i)
são aditados os seguintes travessões a seguir ao quadro e antes do parágrafo PRT_007:
«-
num bloco de dados, o texto após ‘pi=’ refere-se ao pictograma ou combinação de pictogramas correspondente definido no apêndice 3,
-
quando impresso após a longitude e a latitude de uma posição registada, ou após o selo temporal quando a posição foi determinada, o pictograma indica que esta posição foi calculada a partir de mensagens de navegação autenticadas,
-
* dados apenas disponíveis em tacógrafos da GEN2 (todas as versões),
-
** dados apenas disponíveis na GEN2, versão 2.»;
ii)
os blocos 2 e 3 passam a ter a seguinte redação:
«
Se se tratar de um cartão não pessoal, ao qual não se aplique apelido do titular, o nome impresso será o da empresa, da oficina ou do organismo de controlo».
iii)
antes do bloco 4, é eliminada a frase precedida de um asterisco.
iv)
após o bloco 4, é inserido o seguinte bloco:
«
»;
v)
o bloco 5 passa a ter a seguinte redação:
«
»;
vi)
antes do bloco 6, é eliminada a frase precedida de um asterisco.
vii)
após o bloco 8a, é inserido o seguinte bloco:
«
»;
viii)
o bloco 8.2 passa a ter a seguinte redação:
«
»;
ix)
o bloco 10.2 passa a ter a seguinte redação:
«
»;
x)
antes do bloco 11, é eliminada a frase precedida de um asterisco.
xi)
os blocos 11.4 e 11.5 passam a ter a seguinte redação:
«
»;
xii)
o bloco 14 passa a ter a seguinte redação:
«
»;
xiii)
o bloco 15.1 passa a ter a seguinte redação:
«
»;
xiv)
os blocos 16 e 16.1 passam a ter a seguinte redação:
«
16
Identificação GNSS*
»;
xv)
o bloco 17.1 passa a ter a seguinte redação:
«
O objetivo da calibração (p) é um código numérico que explica por que razão foram registados estes parâmetros de calibração, codificados segundo o elemento de dados CalibrationPurpose».
xvi)
o bloco 23 passa a ter a seguinte redação:
«
»
(c)
o ponto 3 é alterado do seguinte modo:
i)
no ponto 3,1, o parágrafo PRT_008 passa a ter a seguinte redação:
«PRT_008
As atividades de condutor, na impressão diária do cartão, devem respeitar o seguinte formato:
»;
ii)
no ponto 3.2, o parágrafo PRT_009 passa a ter a seguinte redação:
«PRT_009
As atividades de condutor, na impressão diária da VU, devem respeitar o seguinte formato:
»;
iii)
no ponto 3.5, o parágrafo PRT_012 passa a ter a seguinte redação:
«PRT_012
A impressão de dados técnicos deve respeitar o seguinte formato:
»;
iv)
no ponto 3.7, o parágrafo 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:
»;
(34)
O apêndice 7 é alterado do seguinte modo:
(a)
O índice é alterado do seguinte modo:
i)
os pontos 2.2.6.1 a 2.2.6.5 passam a ter a seguinte redação:
«2.2.6.1
Positive Response Transfer Data Download Interface Version (Versão da interface de descarregamento de dados de transferência de resposta positiva)
2.2.6.2
Positive Response Transfer Data Overview (Panorâmica de dados de transferência de resposta positiva)
2.2.6.3
Positive Response Transfer Data Activities (Atividades de dados de transferência de resposta positiva)
2.2.6.4
Positive Response Transfer Data Events and Faults (Incidentes e falhas de dados de transferência de resposta positiva)
2.2.6.5
Positive Response Transfer Data Detailed Speed (Velocidade detalhada de dados de transferência de resposta positiva)»;
ii)
é aditado o seguinte ponto:
«2.2.6.6
Positive Response Transfer Data Technical Data (Dados técnicos dos dados de transferência de resposta posiviva)»;
(b)
o ponto 2 é alterado do seguinte modo:
i)
no ponto 2.2.2, o quadro da estrutura da mensagem e as notas a seguir ao quadro passam a ter a seguinte redação:
«
Estrutura da mensagem
Máx. 4 Bytes
Máx. 255 Bytes
1 byte
Cabeçalho
Dados
Soma de teste
IDE ->
<- VU
FMT
TGT
SRC
LEN
SID
DS_ / TRTP
DATA
EC
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
Download interface version
80
EE
F0
02
36
00
96
Overview
80
EE
F0
02
36
01, 21 ou 31
EC
Activities
80
EE
F0
06
36
02, 22 ou 32
Date
EC
Events & Faults
80
EE
F0
02
36
03, 23 ou 33
Date
EC
Detailed Speed
80
EE
F0
02
36
04 ou 24
Date
EC
Technical Data
80
EE
F0
02
36
05, 25 ou 35
Date
EC
Card download
80
EE
F0
02 ou 03
36
06
Slot
CS
Positive Response Transfer Data
80
F0
EE
Len
76
TREP
Dados
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
Dados
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
Notas:
—
Sid Req = o SID do pedido correspondente.
—
TREP = o TRTP do pedido correspondente.
—
As células a negro indicam que nada é transmitido.
—
O termo «carregamento» (visto do IDE) é utilizado para compatibilidade com a norma ISO 14229. Significa o mesmo que «descarregamento» (visto da VU).
—
Contadores de submensagens potenciais de 2 bytes não figuram neste quadro.
—
Ranhura é o número da ranhura, quer seja «1» (cartão na ranhura do condutor) ou «2» (cartão na ranhura do ajudante)
—
Caso a ranhura não seja especificada, a VU seleciona a ranhura 1, se for inserido um cartão nesta ranhura e seleciona a ranhura 2 apenas quando esta é especificamente selecionada pelo utilizador.
—
O TRTP 24 é utilizado nos pedidos de descarregamento de dados da VU de tipo geração 2, versão 1 e versão 2.
—
Os TRTP 00, 31, 32, 33 e 35 são utilizados nos pedidos de descarregamento de dados da VU de tipo geração 2, versão 2.
—
Os TRTP 21, 22, 23 e 25 são utilizados nos pedidos de descarregamento de dados da VU de tipo geração 2, versão 1.
—
Os TRTP 01 a 05 são utilizados nos pedidos de descarregamento de dados da VU de tipo geração 1. Opcionalmente, podem ser aceites pelo tipo geração 2 da VU, mas apenas no âmbito do controlo dos condutores realizado por uma autoridade de controlo não europeia, utilizando um cartão de controlo da primeira geração.
—
Os TRPT 11 a 1F estão reservados para pedidos de descarregamento específicos do fabricante.»;
ii)
o ponto 2.2.2.9 é alterado do seguinte modo:
(1)
No parágrafo DDP_011, a segunda frase e o primeiro quadro passam a ter a seguinte redação:
«Há seis tipos de transferência de dados. No que toca ao descarregamento de dados da VU, podem ser utilizados dois valores diferentes de TRPT para cada tipo de transferência:
Tipo de transferência de dados
Valor TRTP para o descarregamento de dados
da VU de tipo geração 1
Valor TRTP para o descarregamento de dados
da VU de tipo geração 2, versão 1
Valor TRTP para o descarregamento de dados
da VU de tipo geração 2, versão 2
Versão da interface de descarregamento
Não utilizado
Não utilizado
00
Panorâmica
01
21
31
Atividades de uma data especificada
02
22
32
Incidentes e falhas
03
23
33
Velocidade detalhada
04
24
24
Dados técnicos
05
25
35
»;
(2)
O parágrafo 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, 21 ou 31), 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, 22 ou 32), a mensagem Transfer Data Request inclui a indicação do dia de calendário a descarregar (formato TimeReal)»;
iii)
no ponto 2.2.2.10, o texto antes dos travessões no parágrafo DDP_055 passa a ter a seguinte redação:
«DDP_055
No primeiro caso (TREP 01, 21 ou 31), 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:»;
iv)
no ponto 2.2.5.2, a figura 2 é substituída por:
«
Figura 2 Tratamento de erros por parte da VU
»;
v)
os pontos 2.2.6.1 a 2.2.6.5 passam a ter a seguinte redação:
«2.2.6.1
Positive Response Transfer Data Download Interface Version (Versão da interface de descarregamento de dados de transferência de resposta positiva)
DDP_028a
O campo de dados da mensagem «Positive Response Transfer Data Download Interface Version» fornece os seguintes dados, segundo a ordem indicada, sob o SID 76 Hex e o TREP 00 Hex:
«Estrutura de dados da geração 2, versão 2 (TREP 00 Hex)
Elemento de dados
Observação
DownloadInterfaceVersion
Geração e versão da VU: 02,02 Hex para a geração 2, versão 2.
Não aceite pela versão da geração 1 e da geração 2, versão 1, que responde negativamente (subfunção não aceite, ver DDP_018)
2.2.6.2
Positive Response Transfer Data Overview (Panorâmica de dados de transferência de resposta positiva)
DDP_029
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, 21 ou 31 Hex e com uma divisão e uma contagem adequadas das submensagens:
Estrutura de dados da geração 1 (TREP 01 Hex)
Elemento de dados
Observação
MemberStateCertificate
Certificados de segurança da VU
VUCertificate
VehicleIdentificationNumber
Identificação do veículo
VehicleRegistrationIdentification
CurrentDateTime
Data e hora atuais da VU
VuDownloadablePeriod
Período descarregável
CardSlotsStatus
Tipo de cartões inseridos na VU
VuDownloadActivityData
Descarregamento prévio da VU
VuCompanyLocksData
Todos os bloqueios de empresa memorizados. Se o perfil estiver vazio, é enviado apenas noOfLocks = 0.
VuControlActivityData
Todos os registos de controlo memorizados na VU. Se o perfil estiver vazio, é enviado apenas noOfControls = 0
Signature
Assinatura RSA de todos os dados (exceto certificados) a partir de VehicleIdentificationNumber para baixo até ao último byte do último VuControlActivityData.
Estrutura de dados da geração 2, versão 1 (TREP 21 Hex)
Elemento de dados
Observação
MemberStateCertificateRecordArray
Certificado do Estado-Membro
VUCertificateRecordArray
Certificado da VU
VehicleIdentificationNumberRecordArray
Identificação do veículo
VehicleRegistrationIdentificationRecordArray
Número de matrícula do veículo
CurrentDateTimeRecordArray
Data e hora atuais da VU
VuDownloadablePeriodRecordArray
Período descarregável
CardSlotsStatusRecordArray
Tipo de cartões inseridos na VU
VuDownloadActivityDataRecordArray
Descarregamento prévio da VU
VuCompanyLocksRecordArray
Todos os bloqueios de empresa memorizados. Se o perfil estiver vazio, é enviado um cabeçalho da matriz com noOfRecords = 0
VuControlActivityRecordArray
Todos os registos de controlo memorizados na VU. Se o perfil estiver vazio, é enviado um cabeçalho da matriz com noOfRecords = 0
SignatureRecordArray
Assinatura ECC de todos os dados precedentes, com exceção dos certificados.
Estrutura de dados da geração 2, versão 2 (TREP 31 Hex)
Elemento de dados
Observação
MemberStateCertificateRecordArray
Certificado do Estado-Membro
VUCertificateRecordArray
Certificado da VU
VehicleIdentificationNumberRecordArray
Identificação do veículo
VehicleRegistrationNumberRecordArray
Número de matrícula do veículo
CurrentDateTimeRecordArray
Data e hora atuais da VU
VuDownloadablePeriodRecordArray
Período descarregável
CardSlotsStatusRecordArray
Tipo de cartões inseridos na VU
VuDownloadActivityDataRecordArray
Descarregamento prévio da VU
VuCompanyLocksRecordArray
Todos os bloqueios de empresa memorizados. Se o perfil estiver vazio, é enviado um cabeçalho da matriz com noOfRecords = 0
VuControlActivityRecordArray
Todos os registos de controlo memorizados na VU. Se o perfil estiver vazio, é enviado um cabeçalho da matriz com noOfRecords = 0
SignatureRecordArray
Assinatura ECC de todos os dados precedentes, com exceção dos certificados.
2.2.6.3
Positive Response Transfer Data Activities (Atividades de dados de transferência de resposta positiva)
DDP_030
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, 22 ou 32 Hex e com uma divisão e uma contagem adequadas das submensagens:
Estrutura de dados da geração 1 (TREP 02 Hex)
Elemento de dados
Observação
TimeReal
Data do dia descarregado
OdometerValueMidnight
Conta-quilómetros no final do dia descarregado
VuCardIWData
Dados dos ciclos de inserção e retirada de cartões.
—
Se este perfil não tiver dados disponíveis, é enviado apenas noOfVuCardIWRecords = 0.
—
Se um VuCardIWRecord se encontrar a 00:00 (inserção do cartão no dia anterior) ou a 24:00 (retirada do cartão no dia seguinte) deve aparecer integralmente nos dois dias em causa.
VuActivityDailyData
Situação das ranhuras às 00:00 e mudanças de atividade registadas em relação ao dia descarregado.
VuPlaceDailyWorkPeriodData
Dados relacionados com locais registados em relação ao dia descarregado. Se o perfil estiver vazio, é enviado apenas noOfPlaceRecords = 0.
VuSpecificConditionData
Dados relativos às condições específicas, registados em relação ao dia descarregado. Se o perfil estiver vazio, é enviado apenas noOfSpecificConditionRecords = 0
Signature
Assinatura RSA de todos os dados a partir de TimeReal para baixo até ao último byte do último registo das condições específicas.
Estrutura de dados da geração 2, versão 1 (TREP 22 Hex)
Elemento de dados
Observação
DateOfDayDownloadedRecordArray
Data do dia descarregado
OdometerValueMidnightRecordArray
Conta-quilómetros no final do dia descarregado
VuCardIWRecordArray
Dados dos ciclos de inserção e retirada de cartões.
—
Se este perfil não tiver dados disponíveis, é enviado um cabeçalho da matriz com noOfRecords = 0.
—
Se um VuCardIWRecord se encontrar a 00:00 (inserção do cartão no dia anterior) ou a 24:00 (retirada do cartão no dia seguinte) deve aparecer integralmente nos dois dias em causa.
VuActivityDailyRecordArray
Situação das ranhuras às 00:00 e mudanças de atividade registadas em relação ao dia descarregado.
VuPlaceDailyWorkPeriodRecordArray
Dados relacionados com locais registados em relação ao dia descarregado. Se o perfil estiver vazio, é enviado um cabeçalho da matriz com noOfRecords = 0
VuGNSSADRecordArray
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
VuSpecificConditionRecordArray
Dados relativos às condições específicas, registados em relação ao dia descarregado. Se o perfil estiver vazio, é enviado um cabeçalho da matriz com noOfRecords = 0
SignatureRecordArray
Assinatura ECC de todos os dados precedentes.
Estrutura de dados da geração 2, versão 2 (TREP 32 Hex)
Elemento de dados
Observação
DateOfDayDownloadedRecordArray
Data do dia descarregado
OdometerValueMidnightRecordArray
Conta-quilómetros no final do dia descarregado
VuCardIWRecordArray
Dados dos ciclos de inserção e retirada de cartões.
—
Se este perfil não tiver dados disponíveis, é enviado um cabeçalho da matriz com noOfRecords = 0.
—
Se um VuCardIWRecord se encontrar a 00:00 (inserção do cartão no dia anterior) ou a 24:00 (retirada do cartão no dia seguinte) deve aparecer integralmente nos dois dias em causa.
VuActivityDailyRecordArray
Situação das ranhuras às 00:00 e mudanças de atividade registadas em relação ao dia descarregado.
VuPlaceDailyWorkPeriodRecordArray
Dados relacionados com locais registados em relação ao dia descarregado. Se o perfil estiver vazio, é enviado um cabeçalho da matriz com noOfRecords = 0
VuGNSSADRecordArray
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
VuSpecificConditionRecordArray
Dados relativos às condições específicas, registados em relação ao dia descarregado. Se o perfil estiver vazio, é enviado um cabeçalho da matriz com noOfRecords = 0
VuBorderCrossingRecordArray
Travessias de fronteiras em relação ao dia descarregado. Se o perfil estiver vazio, é enviado um cabeçalho da matriz com noOfRecords = 0
VuLoadUnloadRecordArray
Operações de carga/descarga em relação ao dia descarregado. Se o perfil estiver vazio, é enviado um cabeçalho da matriz com noOfRecords = 0
SignatureRecordArray
Assinatura ECC de todos os dados precedentes.
2.2.6.4
Positive Response Transfer Data Events and Faults (Incidentes e falhas de dados de transferência de resposta positiva)
DDP_031
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, 23 ou 33 Hex e com uma divisão e uma contagem adequadas das submensagens:
Estrutura de dados da geração 1 (TREP 03 Hex)
Elemento de dados
Observação
VuFaultData
Todas as falhas memorizadas ou em curso na VU.
Se o perfil estiver vazio, é enviado apenas noOfVuFaults = 0.
VuEventData
Todos os incidentes (exceto o excesso de velocidade) memorizados ou em curso na VU.
Se o perfil estiver vazio, é enviado apenas noOfVuEvents = 0.
VuOverSpeedingControlData
Dados relativos ao último controlo do excesso de velocidade (valor por defeito se não existirem dados).
VuOverSpeedingEventData
Todos os incidentes de excesso de velocidade memorizados na VU.
Se o perfil estiver vazio, é enviado apenas noOfVuOverSpeedingEvents = 0.
VuTimeAdjustmentData
Todos os incidentes de ajuste de tempo memorizados na VU (fora do enquadramento de uma calibração completa).
Se o perfil estiver vazio, é enviado apenas noOfVuTimeAdjRecords = 0.
Signature
Assinatura RSA de todos os dados a partir de noOfVuFaults para baixo até ao último byte do último registo de ajuste de tempo
Estrutura de dados da geração 2, versão 1 (TREP 23 Hex)
Elemento de dados
Observação
VuFaultRecordArray
Todas as falhas memorizadas ou em curso na VU.
Se o perfil estiver vazio, é enviado um cabeçalho da matriz com noOfRecords = 0
VuEventRecordArray
Todos os incidentes (exceto o excesso de velocidade) memorizados ou em curso na VU.
Se o perfil estiver vazio, é enviado um cabeçalho da matriz com noOfRecords = 0
VuOverSpeedingControlDataRecordArray
Dados relativos ao último controlo do excesso de velocidade (valor por defeito se não existirem dados).
VuOverSpeedingEventRecordArray
Todos os incidentes de excesso de velocidade memorizados na VU.
Se o perfil estiver vazio, é enviado um cabeçalho da matriz com noOfRecords = 0
VuTimeAdjustmentRecordArray
Todos os incidentes de ajuste de tempo memorizados na VU (fora do enquadramento de uma calibração completa).
Se o perfil estiver vazio, é enviado um cabeçalho da matriz com noOfRecords = 0
SignatureRecordArray
Assinatura ECC de todos os dados precedentes.
Estrutura de dados da geração 2, versão 2 (TREP 33 Hex)
Elemento de dados
Observação
VuFaultRecordArray
Todas as falhas memorizadas ou em curso na VU.
Se o perfil estiver vazio, é enviado um cabeçalho da matriz com noOfRecords = 0
VuEventRecordArray
Todos os incidentes (exceto o excesso de velocidade) memorizados ou em curso na VU.
Se o perfil estiver vazio, é enviado um cabeçalho da matriz com noOfRecords = 0
VuOverSpeedingControlDataRecordArray
Dados relativos ao último controlo do excesso de velocidade (valor por defeito se não existirem dados).
VuOverSpeedingEventRecordArray
Todos os incidentes de excesso de velocidade memorizados na VU.
Se o perfil estiver vazio, é enviado um cabeçalho da matriz com noOfRecords = 0
VuTimeAdjustmentRecordArray
Todos os incidentes de ajuste de tempo memorizados na VU (fora do enquadramento de uma calibração completa).
Se o perfil estiver vazio, é enviado um cabeçalho da matriz com noOfRecords = 0
SignatureRecordArray
Assinatura ECC de todos os dados precedentes.
2.2.6.5
Positive Response Transfer Data Detailed Speed (Velocidade detalhada de dados de transferência de resposta positiva)
DDP_032
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:
Estrutura de dados da geração 1 (TREP 04 Hex)
Elemento de dados
Observação
VuDetailedSpeedData
Toda a velocidade detalhada memorizada na VU (um bloco de velocidade por minuto durante o qual o veículo esteve em movimento)
60 valores de velocidade por minuto (um por segundo).
Signature
Assinatura RSA de todos os dados a partir de noOfSpeedBlocks para baixo até ao último byte do último bloco de velocidade.
Estrutura de dados da geração 2 (TREP 24 Hex)
Elemento de dados
Observação
VuDetailedSpeedBlockRecordArray
Toda a velocidade detalhada memorizada na VU (um bloco de velocidade por minuto durante o qual o veículo esteve em movimento)
60 valores de velocidade por minuto (um por segundo).
SignatureRecordArray
Assinatura ECC de todos os dados precedentes.
»;
vi)
é aditado o seguinte ponto:
«2.2.6.6
Positive Response Transfer Data Technical Data (Dados técnicos dos dados de transferência de resposta positiva)
DDP_033
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, 25 ou 35 Hex e com divisão e contagem adequadas das submensagens:
Estrutura de dados da geração 1 (TREP 05 Hex)
Elemento de dados
Observação
VuIdentification
SensorPaired
VuCalibrationData
Todos os registos de calibração memorizados na VU.
Signature
Assinatura RSA de todos os dados a partir de vuManufacturerName para baixo até ao último byte do último VuCalibrationRecord.
Estrutura de dados da geração 2, versão 1 (TREP 25 Hex)
Elemento de dados
Observação
VuIdentificationRecordArray
VuSensorPairedRecordArray
Todos os emparelhamentos de EM memorizados na VU
VuSensorExternalGNSSCoupledRecordArray
Todos os acoplamentos do módulo GNSS externo memorizados na VU
VuCalibrationRecordArray
Todos os registos de calibração memorizados na VU.
VuCardRecordArray
Todos os dados de inserção do cartão memorizados na VU.
VuITSConsentRecordArray
VuPowerSupplyInterruptionRecordArray
SignatureRecordArray
Assinatura ECC de todos os dados precedentes.
Estrutura de dados da geração 2, versão 2 (TREP 35 Hex)
Elemento de dados
Observação
VuIdentificationRecordArray
VuSensorPairedRecordArray
Todos os emparelhamentos de EM memorizados na VU
VuSensorExternalGNSSCoupledRecordArray
Todos os acoplamentos do módulo GNSS externo memorizados na VU
VuCalibrationRecordArray
Todos os registos de calibração memorizados na VU.
VuCardRecordArray
Todos os dados de inserção do cartão memorizados na VU.
VuITSConsentRecordArray
VuPowerSupplyInterruptionRecordArray
SignatureRecordArray
Assinatura ECC de todos os dados precedentes.
»;
(c)
no ponto 3.3, o parágrafo 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 ICC e IC. Esta informação é opcional e não é securizada com uma assinatura digital.
—
Para os cartões tacográficos da primeira e segunda gerações
—
Descarregar os EF em Tachograph DF:
—
Descarregar o Card_Certificate e o CA_Certificate dos EF. Esta informação não é securizada com uma assinatura digital.
É obrigatório descarregar estes ficheiros para cada sessão de descarregamento.
—
Descarregar os outros EF de dados de aplicação (no Tachograph DF) com exceção do EF Card_Download. 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 Application_Identification e a Identification dos EF para cada sessão de descarregamento.
—
No descarregamento de um cartão de condutor é também obrigatório descarregar os seguintes EF:
—
Events_Data,
—
Faults_Data,
—
Driver_Activity_Data,
—
Vehicles_Used,
—
Places,
—
Control_Activity_Data,
—
Specific_Conditions.
—
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 no Tachograph_G2 DF:
—
Descarregar o CardSignCertificate, CA_Certificate e Link_Certificate dos EF. Esta informação não é securizada com uma assinatura digital.
—
É obrigatório descarregar estes ficheiros para cada sessão de descarregamento.
—
Descarregar os outros EF de dados de aplicação (no Tachograph_G2 DF) exceto EF Card_Download. 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 Application_Identification, a Application_Identification_V2 (se existir) e a Identification dos EF para cada sessão de descarregamento.
—
No descarregamento de um cartão de condutor é também obrigatório descarregar os seguintes EF:
—
Events_Data,
—
Faults_Data,
—
Driver_Activity_Data,
—
Vehicles_Used,
—
Places,
—
Control_Activity_Data,
—
Specific_Conditions,
—
VehicleUnits_Used,
—
GNSS_Places,
—
Places_Authentication, se existir,
—
GNSS_Places_Authentication, se existir,
—
Border_Crossings, se existir,
—
Load_Unload_Operations, se existir,
—
Load_Type_Entries, se existir.
—
Ao descarregar um cartão de condutor, atualizar a data LastCardDownload no EF Card_Download, no Tachograph e, quando aplicável, nos Tachograph_G2 DF.
—
Ao descarregar um cartão de oficina, reinicializar o contador de calibração no EF Card_Download no Tachograph e, quando aplicável, nos Tachograph_G2 DF.
—
Ao descarregar um cartão de oficina, o EF Sensor_Installation_Data no Tachograph e, quando aplicável, nos Tachograph_G2 DF não deve ser descarregado.»;
(35)
O apêndice 8 é alterado do seguinte modo:
(a)
o índice é alterado do seguinte modo:
i)
os pontos 8, 8.1 e 8.2 passam a ter a seguinte redação:
«8.
SERVIÇO ROUTINECONTROL (AJUSTAMENTO DO TEMPO)
8.1.
Descrição da mensagem
8.2.
Formato da mensagem»;
ii)
são aditados os seguintes pontos 9, 9.1 e 9.2:
«9.
FORMATOS DOS DATARECORDS
9.1.
Gamas de parâmetros transmitidos
9.2.
Formatos dos dataRecords»;
(b)
no ponto 3.1, é aditada ao quadro 1 a seguinte linha:
«
Sessões de diagnóstico
RoutineControl
8
31
»;
(c)
o ponto 6.1.3, o parágrafo CPR_053 passa a ter a seguinte redação:
«CPR_053
Os valores recordDataIdentifier definidos pelo presente documento figuram no quadro infra.
O quadro recordDataIdentifier consiste em quatro colunas e múltiplas linhas:
—
A 1.a coluna (Hex) inclui o «valor hex» atribuído ao recordDataIdentifier especificado na 3.a coluna.
—
A 2.a coluna (Elemento de dados) especifica o elemento do apêndice 1 no qual se baseia o recordDataIdentifier (é por vezes necessária transcodificação).
—
A 3.a coluna (Descrição) especifica o nome do recordDataIdentifier correspondente.
—
A 4.a coluna (Direitos de acesso) especifica os direitos de acesso a este recordDataIdentifier.
—
A 5.a coluna (Mnemónica) especifica a mnemónica deste recordDataIdentifier.
Quadro 28
Valores de definição do recordDataIdentifier
Hex
Elemento de dados
Nome do recordDataIdentifier
(ver formato na secção 8.2)
Direitos de acesso
(Read/Write)
Mnemónica
F90B
CurrentDateTime
TimeDate
R/W
RDI_TD
F912
HighResOdometer
HighResolutionTotalVehicleDistance
R/W
RDI_HRTVD
F918
K-ConstantOfRecordingEquipment
Kfactor
R/W
RDI_KF
F91C
L-TyreCircumference
LfactorTyreCircumference
R/W
RDI_LF
F91D
W-VehicleCharacteristicConstant
WvehicleCharacteristicFactor
R/W
RDI_WVCF
F921
TyreSize
TyreSize
R/W
RDI_TS
F922
nextCalibrationDate
NextCalibrationDate
R/W
RDI_NCD
F92C
SpeedAuthorised
SpeedAuthorised
R/W
RDI_SA
F97D
vehicleRegistrationNation
RegisteringMemberState
R/W
RDI_RMS
F97E
VehicleRegistrationNumber
VehicleRegistrationNumber
R/W
RDI_ VRN
F190
VehicleIdentificationNumber
VIN
R/W
RDI_ VIN
F9D0
SensorSerialNumber
MotionSensorSerialNumber
R
RDI_SSN
F9D1
RemoteCommunicationModuleSerialNumber
RemoteCommunicationFacilitySerialNumber
R
RDI_RCSN
F9D2
SensorGNSSSerialNumber
ExternalGNSSFacilitySerialNumber
R
RDI_GSSN
F9D3
SealDataVu
SmartTachographSealsSerialNumber
R/W
RDI_SDV
F9D4
VuSerialNumber
VuSerialNumber
R
RDI_VSN
F9D5
ByDefaultLoadType
ByDefaultLoadType
R/W
RDI_BDLT
F9D6
TachographCardsGen1Suppression
TachographCardsGen1Suppression
R/W
RDI_TCG1S
F9D7
VehiclePosition
VehiclePosition
R
RDI_VP
F9D8
LastCalibrationCountry
CalibrationCountry
R
RDI_CC
»;
(d)
o ponto 8 passa a ter a seguinte redação:
«8.
SERVIÇO ROUTINECONTROL (AJUSTAMENTO DO TEMPO)
8.1.
Descrição da mensagem
CPR_065a
O serviço RoutineControl (ajustamento do tempo) oferece a possibilidade de ativar um alinhamento do relógio da VU com a hora transmitida pelo recetor GNSS.
Para o serviço RoutineControl (ajustamento do tempo), a execução da VU deve estar no modo de CALIBRAÇÃO.
Condição prévia: garantir que a VU seja capaz de receber mensagens de posição autenticadas do recetor GNSS.
Desde que o ajustamento do tempo esteja em curso, a VU responde ao pedido RoutineControl, subfunção requestRoutineResults, com routineInfo = 0x78.
Nota: o ajustamento do tempo pode demorar algum tempo. O dispositivo de teste diagnóstico pede o estado do ajustamento do tempo utilizando a subfunção requestRoutineResults.
8.2.
Formato da mensagem
CPR_065b
Os formatos das mensagens para o serviço RoutineControl (ajustamento do tempo) e respetivas primitivas são especificados nos quadros seguintes:
Quadro 37-A
RoutineControl, Mensagem de Pedido de rotina (TimeAdjustment), subfunção startRoutine
n.o do byte
Nome do parâmetro
Valor hex
Mnemónica
#1
Byte de formato — endereçamento físico
80
FMT
#2
Byte de endereço-alvo
EE
TGT
#3
Byte de endereço-fonte
tt
SRC
#4
Byte adicional de comprimento
xx
LEN
#5
RoutineControl Request Sid (Sid de pedido de controlo de rotina)
31
RC
#6
routineControlType = [startRoutine]
01
RCTP_STR
#7 e #8
routineIdentifier = [TimeAdjustment]
0100
RI_TA
#9
Soma de teste
00-FF
CS
Quadro 37-B:
RoutineControl, rotina (TimeAdjustment), subfunção startRoutine, Mensagem de Resposta Positiva
n.o do byte
Nome do parâmetro
Valor hex
Mnemónica
#1
Byte de formato — endereçamento físico
80
FMT
#2
Byte de endereço-alvo
tt
TGT
#3
Byte de endereço-fonte
EE
SRC
#4
Byte adicional de comprimento
xx
LEN
#5
RoutineControl Positive Response Sid
71
RCPR
#6
routineControlType = [startRoutine]
01
RCTP_STR
#7 e #8
routineIdentifier= [TimeAdjustment]
0100
RI_TA
#9
Soma de teste
00-FF
CS
Quadro 37-C:
RoutineControl, Mensagem de Pedido de rotina (TimeAdjustment), subfunção requestRoutineResults
n.o do byte
Nome do parâmetro
Valor hex
Mnemónica
#1
Byte de formato — endereçamento físico
80
FMT
#2
Byte de endereço-alvo
EE
TGT
#3
Byte de endereço-fonte
tt
SRC
#4
Byte adicional de comprimento
xx
LEN
#5
RoutineControl Request Sid (Sid de pedido de controlo de rotina)
31
RC
#6
routineControlType = [requestRoutineResults]
03
RCTP_RRR
#7 e #8
routineIdentifier= [TimeAdjustment]
0100
RI_TA
#9
Soma de teste
00-FF
CS
Quadro 37-D:
RoutineControl, rotina (TimeAdjustment), subfunção requestRoutineResults, Mensagem de Resposta Positiva
n.o do byte
Nome do parâmetro
Valor hex
Mnemónica
#1
Byte de formato — endereçamento físico
80
FMT
#2
Byte de endereço-alvo
tt
TGT
#3
Byte de endereço-fonte
EE
SRC
#4
Byte adicional de comprimento
xx
LEN
#5
RoutineControl Positive Response Sid (Sid de resposta positiva de controlo de rotina)
71
RCPR
#6
routineControlType = [requestRoutineResults]
03
RCTP_RRR
#7 e #8
routineIdentifier= [TimeAdjustment]
0100
RI_TA
#9
routineInfo (ver o quadro 37-F)
XX
RINF_TA
#10
routineStatusRecord[] = routineStatus#1 (ver o quadro 37-G)
XX
RS_TA
#11
Soma de teste
00-FF
CS
Quadro 37-E:
RoutineControl, rotina (TimeAdjustment), Mensagem de Resposta Negativa
n.o do byte
Nome do parâmetro
Valor hex
Mnemónica
#1
Byte de formato — endereçamento físico
80
FMT
#2
Byte de endereço-alvo
tt
TGT
#3
Byte de endereço-fonte
EE
SRC
#4
Byte adicional de comprimento
03
LEN
#5
negativeResponse Service Id (Id de Serviço de resposta negativa)
regras gerais a aplicar às gamas dos parâmetros transmitidos pela unidade-veículo ao dispositivo de teste,
—
formatos a utilizar na transferência de dados através dos serviços de transmissão de dados, descritos na secção 6.
CPR_067
Todos os parâmetros identificados devem ser suportados pela VU.
CPR_068
Os dados transmitidos pela VU ao dispositivo de teste em resposta a uma mensagem de pedido devem ser do tipo medido (ou seja, valor atual do parâmetro pedido, tal como o mede ou observa a VU).
9.1.
Gamas de parâmetros transmitidos
CPR_069
O quadro 38 define as gamas utilizadas para determinar a validade de um parâmetro transmitido.
CPR_070
Os valores da gama «error indicator» (indicador de erro) servem para a unidade-veículo indicar imediatamente que não estão de momento disponíveis dados paramétricos válidos, devido a erro de algum tipo no tacógrafo.
CPR_071
Os valores da gama «not available» (indisponível) servem para a unidade-veículo transmitir uma mensagem contendo um parâmetro não disponível ou não suportado no módulo em questão. Os valores da gama «not requested» (não pedido) servem para um dispositivo transmitir uma mensagem de comando e identificar esses parâmetros quando não for esperada resposta do dispositivo recetor.
CPR_072
Se a falha de um componente impedir a transmissão de dados válidos relativos a um parâmetro, deve ser utilizado o indicador de erro descrito no quadro 38 em vez dos dados relativos a esse parâmetro. No entanto, se o dado medido ou calculado tiver produzido um valor válido mas excedendo a gama definida para o parâmetro, não se deve utilizar o indicador de erro. Os dados serão transmitidos utilizando o valor adequado, mínimo ou máximo, do parâmetro.
Quadro 38
Gamas de dataRecords
Nome da gama
1 byte
(Valor hex)
2 bytes
(Valor hex)
4 bytes
(Valor hex)
ASCII
Sinal válido
00 a FA
0000 a FAFF
00000000 a FAFFFFFF
1 a 254
Indicador específico do parâmetro
FB
FB00 a FBFF
FB000000 a FBFFFFFF
nenhum
Gama reservada para futuros bits de indicador
FC a FD
FC00 a FDFF
FC000000 a FDFFFFFF
nenhum
Indicador de erro
FE
FE00 a FEFF
FE000000 a FEFFFFFF
0
Indisponível ou não pedido
FF
FF00 a FFFF
FF000000 a FFFFFFFF
FF
CPR_073
No caso dos parâmetros codificados em ASCII, o caráter «*» é reservado como delimitador.
9.2.
Formatos dos dataRecords
Do quadro 39 ao quadro 42, referem-se os formatos a utilizar pelos serviços ReadDataByIdentifier e WriteDataByIdentifier.
CPR_074
O quadro 39 indica o comprimento, a resolução e a gama de funcionamento de cada parâmetro identificado pelo seu recordDataIdentifier:
Quadro 39
Formato dos dataRecords
Nome do parâmetro
Comprimento dos dados (bytes)
Resolução
Gama de funcionamento
TimeDate
8
Ver informações no quadro 40
HighResolutionTotalVehicleDistance
4
ganho de 5 m/bit, deslocamento de 0 m
0 a +21 055 406 km
Kfactor
2
ganho de 0,001 imp./m/bit, deslocamento de 0
0 a 64255 imp./m
LfactorTyreCircumference
2
ganho de 0,125 10-3m/bit, deslocamento de 0
0 a 8,031 m
WvehicleCharacteristicFactor
2
ganho de 0,001 imp./m/bit, deslocamento de 0
0 a 64255 imp./m
TyreSize
15
ASCII
ASCII
NextCalibrationDate
3
Ver informações no quadro 41
SpeedAuthorised
2
ganho de 1/256km/h/bit, deslocamento de 0
0 a 250996 km/h
RegisteringMemberState
3
ASCII
ASCII
VehicleRegistrationNumber
14
Ver informações no quadro 42
VIN
17
ASCII
ASCII
SealDataVu
55
Ver informações no quadro 43
ByDefaultLoadType
1
Ver informações no quadro 44
VuSerialNumber
8
Ver informações no quadro 45
SensorSerialNumber
8
Ver informações no quadro 45
SensorGNSSSerialNumber
8
Ver informações no quadro 45
RemoteCommunicationModuleSerialNumber
8
Ver informações no quadro 45
TachographCardsGen1Suppression
2
Ver informações no quadro 46
VehiclePosition
14
Ver informações no quadro 47
CalibrationCountry
3
ASCII
NationAlpha conforme definido no apêndice 1
CPR_075
O quadro 40 especifica os formatos dos diferentes bytes do parâmetro TimeDate:
Quadro 40
Formato detalhado do parâmetro TimeDate (valor # F90B do recordDataIdentifier)
Byte
Definição de parâmetros
Resolução
Gama de funcionamento
1
Segundos
ganho de 0,25 s/bit, deslocamento de 0 s
0 a 59,75 s
2
Minutos
ganho de 1 min/bit, deslocamento de 0 min
0 a 59 min
3
Horas
ganho de 1 h/bit, deslocamento de 0 h
0 a 23 h
4
Mês
ganho de 1 mês/bit, deslocamento de 0 meses
1 a 12 meses
5
Dia
ganho 0,25 dias/bit, deslocamento 0 dias (ver a NOTA a seguir ao quadro 41)
0,25 a 31,75 dias
6
Ano
ganho de 1 ano/bit, deslocamento de +1985 anos
(ver a NOTA a seguir ao quadro 41)
1985 a 2235 anos
7
Deslocamento local em minutos
ganho de 1 min/bit, deslocamento de -125 min
-59 a +59 min
8
Deslocamento local em horas
ganho de 1 h/bit, deslocamento de -125 h
0 a +23 h
CPR_076
O quadro 41 especifica os formatos dos diferentes bytes do parâmetro NextCalibrationDate:
Quadro 41
Formato detalhado do parâmetro NextCalibrationDate (valor # F922 do recordDataIdentifier)
Byte
Definição de parâmetros
Resolução
Gama de funcionamento
1
Mês
ganho de 1 mês/bit, deslocamento de 0 meses
1 a 12 meses
2
Dia
ganho 0,25 dia/bit, deslocamento 0 dias (ver a NOTA infra)
0,25 a 31,75 dias
3
Ano
ganho de 1 ano/bit, deslocamento de +1985 anos
(ver NOTA infra)
1985 a 2235 anos
NOTA relativa à utilização do parâmetro «Dia»:
1)
O valor 0 para a data é nulo. Os valores 1, 2, 3 e 4 são utilizados para identificar o primeiro dia do mês; os valores 5, 6, 7 e 8 identificam o segundo dia do mês; e assim sucessivamente.
2)
Este parâmetro não influi no parâmetro «Horas» nem o altera.
NOTA relativa à utilização do parâmetro «Ano»:
O valor 0 para o ano identifica o ano de 1985; o valor 1 identifica o ano de 1986; e assim sucessivamente.
CPR_078
O quadro 42 indica os formatos dos diversos bytes do parâmetro VehicleRegistrationNumber:
Quadro 42
Formato detalhado do parâmetro VehicleRegistrationNumber (valor # F97E do recordDataIdentifier)
Byte
Definição de parâmetros
Resolução
Gama de funcionamento
1
Code Page (conforme definido no apêndice 1)
não aplicável
VehicleRegistrationNumber
2 – 14
VehicleRegistrationNumber (conforme definido no apêndice 1)
não aplicável
VehicleRegistrationNumber
CPR_090
O quadro 43 especifica os formatos dos diferentes bytes do parâmetro sealDataVu:
Quadro 43
Formato detalhado do parâmetro sealDataVu (valor # F9D3 do recordDataIdentifier)
Byte
Definição de parâmetros
Resolução
Gama de funcionamento
1 – 11
sealRecord1. Formato SealRecord conforme definido no apêndice 1.
não aplicável
SealRecord
12 - 22
sealRecord2. Formato SealRecord conforme definido no apêndice 1.
não aplicável
SealRecord
23 – 33
sealRecord3. Formato SealRecord conforme definido no apêndice 1.
não aplicável
SealRecord
34 – 44
sealRecord4. Formato SealRecord conforme definido no apêndice 1.
não aplicável
SealRecord
45 – 55
sealRecord5. Formato SealRecord conforme definido no apêndice 1.
não aplicável
SealRecord
NOTA: Se houver menos de cinco selos disponíveis, o valor de EquipmentType em todos os sealRecords não utilizados deve ser fixado em 15, isto é, não utilizado.
CPR_091
O quadro 44 especifica os formatos dos diferentes bytes do parâmetro ByDefaultLoadType:
Quadro 44
Formato detalhado do parâmetro ByDefaultLoadType (valor # F9D5 do recordDataIdentifier)
Byte
Definição de parâmetros
Resolução
Gama de funcionamento
1
loadType
'00'H: Tipo de carga indefinido;
'01'H: Mercadorias
'02'H: Passageiros
não aplicável
'00'H a '02'H
CPR_092
O quadro 45 indica os formatos dos diversos bytes dos parâmetros VuSerialNumber, SensorSerialNumber, SensorGNSSSerialNumber e RemoteCommunicationModuleSerialNumber:
Quadro 45
Formato pormenorizado de VuSerialNumber, SensorSerialNumber, SensorGNSSSerialNumber e RemoteCommunicationModuleSerialNumber (valores # F9D4, F9D0, F9D2, F9D1 do recordDataIdentifier)
Byte
Definição de parâmetros
Resolução
Gama de funcionamento
1
VuSerialNumber, SensorSerialNumber, SensorGNSSSerialNumber and RemoteCommunicationModuleSerialNumber:
Formato ExtendedSerialNumber conforme definido no apêndice 1.
não aplicável
ExtendedSerialNumber
CPR_093
O quadro 46 indica os formatos dos diversos bytes do parâmetro TachographCardsGen1Suppression:
Quadro 46
Formato detalhado do parâmetro TachographCardsGen1Suppression (valor # F9D6 do recordDataIdentifier)
Byte
Definição de parâmetros
Resolução
Gama de funcionamento
1-2
TachographCardsGen1Suppression. Formato TachographCardsGen1Suppression conforme definido no apêndice 1.
não aplicável
'0000'H, 'A5E3'H
CPR_094
O quadro 47 indica os formatos dos diversos bytes do parâmetro VehiclePosition:
Quadro 47
Formato detalhado do parâmetro VehiclePosition (valor # F9D7 do recordDataIdentifier)
Byte
Definição de parâmetros
Resolução
Gama de funcionamento
1 - 4
O selo temporal da posição do veículo foi determinado.
Não aplicável
TimeReal
5
Precisão GNSS
Não aplicável
GNSSAccuracy
6 - 11
Posição do veículo
Não aplicável
GeoCoordinates
12
Estatuto de autenticação
Não aplicável
PositionAuthenticationStatus
13
País atual
Não aplicável
NationNumeric
14
Região atual
Não aplicável
RegionNumeric
Nota: após a atualização da posição do veículo, a atualização do país e região atuais pode ser retardada.»;
(36)
O apêndice 9 é alterado do seguinte modo:
(a)
no índice, é aditado o seguinte ponto 9:
«9.
ENSAIOS DA OSNMA»;
(b)
o ponto 1 é alterado do seguinte modo:
i)
no ponto 1.1, é aditado o seguinte parágrafo:
«A autoridade dos Estados-Membros encarregada dos ensaios de funcionalidade de uma unidade-veículo ou de um módulo GNSS externo deve certificar-se de que o recetor GNSS integrado passou com sucesso os ensaios da OSNMA especificados no presente apêndice. Estes ensaios são considerados parte dos ensaios de funcionalidade da unidade-veículo ou do módulo GNSS externo.»;
ii)
no ponto 1.2, é aditada a seguinte referência:
«RGODP
JRC Technical Report - Receiver guidelines for OSNMA data processing (Relatório Técnico do JRC – Diretrizes relativas ao recetor para o tratamento de dados da OSNMA)»;
(c)
no ponto 2, as linhas 3.1 a 3.41 passam a ter a seguinte redação:
«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, da posição e da distância
21 a 37
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 do condutor
56 a 62c
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 88a, 134
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 ou de oficina
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 do tempo
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
Dados relativos aos cartões tacográficos
132*, 133*
3.28
Travessia de fronteiras
133a* a 133d*
3.29
Operação de carga/descarga
133e* a 133i*
3.30
Mapa digital
133j* a 133t*
3.31
Registo e memorização de dados nos cartões tacográficos
Comunicação à distância para controlos de estrada seletivos
197 a 199
3.37
Intercâmbio de dados com dispositivos externos adicionais
200, 201
3.38
Calibração
202 a 206*, 383, 384, 386 a 391
3.39
Controlo de calibração de estrada
207 a 209
3.40
Ajustamento do tempo
210 a 212*
3.41
Controlo da travessia de fronteiras
226a a 226c
3.42
Atualização de software
226d a 226f
3.43
Não interferência de funções adicionais
06, 425
3.44
Interface do sensor de movimentos
02, 122
3.45
Módulo GNSS externo
03, 123
3.46
Verificar se a VU deteta, regista e memoriza o(s)incidente(s)e/oufalha(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.47
Parâmetros de domínio normalizados e de sequência de cifras
CSM_48, CSM_50»;
(d)
é aditado o seguinte ponto 9:
«9.
ENSAIOS DA OSNMA
9.1.
Introdução
Este capítulo descreve os ensaios destinados a comprovar a implementação correta da OSNMA no recetor GNSS. Uma vez que a autenticação do sinal de satélite é realizada exclusivamente pelo receptor GNSS com independência de qualquer outro componente do tacógrafo, os ensaios descritos neste capítulo podem ser realizados no recetor GNSS como um elemento autónomo. Neste caso, o fabricante do tacógrafo deve apresentar um relatório às entidades homologadoras com dados sobre o desenvolvimento e os resultados dos ensaios realizados sob a responsabilidade do fabricante do recetor GNSS.
9.2
Condições aplicáveis
—
Os critérios de aprovação/reprovação nos ensaios da OSNMA são considerados válidos apenas para as condições de ensaio identificadas.
—
Os critérios podem ser revistos no momento da declaração do serviço OSNMA do Galileo e considerando os compromissos de desempenho do serviço associados.
9.3.
Definições e acrónimos
9.3.1
Definições
Arranque a frio/morno/quente do GNSS
:
refere-se à condição de arranque de um recetor GNSS com base na disponibilidade de tempo (T), almanaque (A) e efeméride (E) atuais, posição (P):
—
Arranque a frio do GNSS: nenhum
—
Arranque a morno do GNSS: T, A, P
—
Arranque a quente do GNSS: T, A, E, P
Arranque a frio/morno/quente da OSNMA
:
refere-se à condição de arranque da função OSNMA com base na disponibilidade da informação da Chave Pública (P) e da DSM-KROOT (K) (conforme definido nas diretrizes relativas ao recetor OSNMA referidas no apêndice 12):
—
Arranque a frio da OSNMA: nenhum
—
Arranque a morno da OSNMA: P
—
Arranque a quente da OSNMA: P, K
9.3.2
Acrónimos
ADKD
Authentication Data & Key Delay (Dados de autenticação e tempo de resposta da chave)
DSM-KROOT
Digital Signature Message KROOT (Mensagem de assinatura digital KROOT)
GNSS
Global Navigation Satellite System (Sistema Global de Navegação por Satélite)
KROOT
Root Key of the TESLA key chain (Chave-raiz da sequência de chaves de TESLA)
MAC
Message Authentication Code (Código de autenticação de mensagens)
NMACK
Number of MAC & key blocks (Número de MAC e blocos de chaves [por cada 30 segundos])
OSNMA
Galileo Open Service Navigation Message Authentication (Autenticação de mensagens de navegação do serviço aberto Galileo)
SLMAC
Slow MAC (MAC lento)
TESLA
Timed Efficient Stream Loss-tolerant Authentication (Autenticação eficiente temporizada tolerante a perdas de fluxo [protocolo utilizado na OSNMA])
9.4.
Equipamento para a geração de sinais GNSS
A geração dos sinais GNSS pode ser realizada usando um gerador de sinais GNSS multiconstelação que suporte a transmissão de mensagens OSNMA. Alternativamente, pode ser utilizado um reprodutor de sinal de radiofrequência capaz de reproduzir amostras de sinal GNSS a partir de ficheiros. A profundidade de bits e a taxa de amostragem típicas são, respetivamente, I/Q de 4 bits e 10 MHz.
Assume-se que o receptor GNSS tem interfaces para comandar a limpeza da memória do recetor (a fim de apagar independentemente a chave pública, a KROOT, as informações do relógio, as informações de posição, a efeméride e o almanaque), de modo a definir a realização da hora local do recetor para o requisito de verificação de tempo da OSNMA e para carregar as informações criptográficas. Estes comandos podem ser limitados para fins de ensaio e, por conseguinte, podem não estar disponíveis para a operação nominal do recetor.
9.5
Condições de teste
9.5.1
Condições do GNSS
Os sinais do GNSS simulados ou reproduzidos têm as seguintes características:
—
Cenário estático do recetor do utilizador;
—
Pelo menos constelações GPS e Galileo;
—
Frequência E1/L1;
—
Pelo menos 4 satélites Galileo com ângulo de elevação superior a 5o;
—
Duração conforme necessário para cada ensaio;
—
Efemérides de navegação constantes dos satélites durante o ensaio.
9.5.2
Condições da OSNMA
A mensagem da OSNMA transmitida no sinal RF tem as seguintes características:
—
Uma mensagem HKROOT com estatuto de OSNMA fixado em Operacional ou Ensaio e uma DMS-KROOT de 8 blocos para a cadeia em vigor;
—
Pelo menos 4 satélites Galileo que transmitem a OSNMA;
—
Uma mensagem MACK com um bloco MACK (ou seja, NMACK=1) e, pelo menos, uma ADKD=0 e uma ADKD=12 por satélite e bloco MACK;
—
Um tamanho de marcador de 40 bits;
—
O comprimento mínimo do marcador equivalente conforme exigido nas diretrizes relativas ao recetor OSNMA (atualmente 80 bits).
Exceto quando indicado, a realização do tempo do recetor interno deve ser conhecida com precisão suficiente e devidamente alinhada com o tempo simulado. Tal garante o cumprimento do requisito de sincronização de tempo inicial da OSNMA para cada condição de ensaio, ou seja, a sincronização nominal para todos, exceto o ensaio SLMAC. Consultar as diretrizes relativas ao recetor OSNMA para obter mais informações sobre a inicialização do tempo.
De notar que os critérios de aprovação/reprovação identificados são conservadores e não representam o desempenho esperado da OSNMA do Galileo.
9.6.
Especificação dos ensaios
N.o
Teste
Descrição
Requisitos correlatos
1.
Exame administrativo
1.1
Documentação
Adequação da documentação
2
Ensaios gerais
2.1
Arranque a quente da OSNMA
Objetivo: verificar se o recetor GNSS calcula uma posição com OSMNA após um arranque a quente.
Procedimento:
O recetor GNSS arranca nas condições de arranque a quente do GNSS e OSNMA e adquire os sinais dos satélites Galileo visíveis.
O recetor autentica os dados de navegação Galileo com OSNMA (ADKD = 0) e fornece uma posição com dados autenticados.
Critérios de aprovação/reprovação: o recetor calcula uma definição de posição autenticada dentro de 160 segundos.
Apêndice 12,
GNS_3b
2.2
Arranque a morno da OSNMA
Objetivo: verificar se o recetor GNSS calcula uma posição com OSMNA após um arranque a morno.
Procedimento:
Antes de iniciar o teste, as efemérides e as informações KROOT devem ser apagadas da memória do recetor GNSS para forçar um arranque a morno do GNSS e da OSNMA.
O recetor GNSS arranca e adquire os sinais dos satélites Galileo visíveis.
A DSM-KROOT é recebida e verificada.
O recetor autentica os dados de navegação Galileo com OSNMA (ADKD = 0) e fornece uma posição com dados autenticados.
Critérios de aprovação/reprovação: o recetor calcula uma definição de posição autenticada dentro de 430 segundos.
Apêndice 12,
GNS_3b
2.3
Arranque a morno da OSNMA com SLMAC
Objetivo: verificar se o recetor GNSS calcula uma posição com OSMNA após um arranque a morno com uma inicialização da hora que requer o modo SLMAC, conforme definido nas diretrizes relativas ao recetor OSNMA.
Procedimento:
A realização do tempo interno do recetor deve ser configurada de forma a ter uma incerteza de tempo inicial de um valor entre 2 e 2,5 minutos para que, de acordo com as diretrizes relativas ao recetor OSNMA, o modo MAC lento seja ativado.
Antes de iniciar os testes, as efemérides e as informações KROOT devem ser apagadas da memória do recetor GNSS para forçar um arranque a morno do GNSS e da OSNMA.
O recetor GNSS arranca e adquire os sinais dos satélites Galileo visíveis.
A DSM-KROOT é recebida e verificada.
O recetor autentica os dados de navegação Galileo apenas com MAC lento da OSNMA (ADKD = 12) e fornece uma posição com dados autenticados.
Critérios de aprovação/reprovação: o recetor calcula uma definição de posição autenticada dentro de 730 segundos.
Apêndice 12,
GNS_3b
2.4
Arranque a quente da OSNMA com sinal reproduzido
Objetivo: verificar se o recetor GNSS deteta um sinal reproduzido.
Procedimento:
O recetor GNSS arranca nas condições de arranque a quente do GNSS e OSNMA e adquire os sinais dos satélites Galileo visíveis.
O recetor autentica os dados de navegação Galileo com OSNMA (ADKD = 0) e fornece uma posição com dados autenticados.
Assim que fornece a solução PVT com dados autenticados, o recetor é desligado.
É simulado um sinal reproduzido com um atraso de 40 segundos em relação ao anterior e o recetor é ligado.
O recetor deteta que o tempo do sistema Galileo a partir do tempo do sinal no espaço e a realização do tempo local não cumprem o requisito de sincronização e interrompe o tratamento dos dados OSNMA conforme definido nas diretrizes relativas ao recetor OSNMA.
Critérios de aprovação/reprovação: o recetor deteta a reprodução e não calcula uma posição válida autenticada desde o início da reprodução até ao final do ensaio.
Apêndice 12,
GNS_3b
2.5
Arranque a quente da OSNMA com dados falsos
Objetivo: verificar se a OSNMA deteta dados falsos.
Procedimento:
O recetor GNSS arranca em condições de arranque a quente do GNSS e da OSNMA.
O recetor GNSS deve poder adquirir o sinal de todos os satélites Galileo visíveis e verificar a autenticidade das respetivas mensagens de navegação através da OSNMA.
Pelo menos um bit dos dados de efemérides fornecidos por cada satélite Galileo não corresponde aos dados originais e autenticados, mas a mensagem Galileo I/NAV deve ser coerente, incluindo CRC.
Critérios de aprovação/reprovação: o recetor deteta os dados falsos dentro de 160 segundos e não calcula uma posição válida autenticada até ao final do ensaio.
Apêndice 12,
GNS_3b
»;
(37)
O apêndice 12 é alterado do seguinte modo:
(a)
O índice é alterado do seguinte modo:
i)
é inserido o seguinte ponto 1.1.1 a seguir ao ponto 1.1:
«1.1.1
Referências»;
ii)
o ponto 2 passa a ter a seguinte redação:
«2.
CARACTERÍSTICAS BÁSICAS DO RECETOR GNSS»;
iii)
o ponto 3 passa a ter a seguinte redação:
«3.
FRASES INDICADAS PELO RECETOR GNSS»;
iv)
são inseridos os seguintes pontos 4.2.4. e 4.2.5:
«4.2.4
Estrutura do comando WriteRecord
4.2.5
Outros comandos»;
v)
o ponto 5.2 passa a ter a seguinte redação:
«5.2.
Transferência de informações do recetor GNSS para a VU»;
vi)
é suprimido o ponto 5.2.1;
vii)
são inseridos os seguintes pontos 5.3 e 5.4.1:
«5.3.
Transferência de informações da VU para o recetor GNSS
5.4.
Tratamento de erros
5.4.1
Ausência de informações sobre a posição do recetor GNSS»;
viii)
os pontos 6 e 7 passam a ter a seguinte redação:
«6.
TRATAMENTO E REGISTO DE DADOS DE POSIÇÃO PELA VU
7.
CONFLITO DE TEMPO GNSS»;
ix)
é aditado o seguinte ponto 8:
«8.
CONFLITO RELATIVO AO MOVIMENTO DO VEÍCULO»;
(b)
O ponto 1 é alterado do seguinte modo:
i)
o texto que precede a figura 1 passa a ter a seguinte redação:
«1. INTRODUÇÃO
O presente apêndice estabelece os requisitos técnicos para o recetor GNSS e os dados GNSS utilizados pela unidade-veículo, incluindo os protocolos a aplicar para garantir a transferência correta e segura de dados das informações de posicionamento.
1.1. Âmbito de aplicação
GNS_1
A unidade-veículo recolhe dados de localização de, pelo menos, uma rede satélite GNSS.
Conforme se vê na figura 1, a unidade-veículo pode ser com ou sem módulo GNSS externo:»;
ii)
é inserido o seguinte ponto 1.1.1 a seguir ao ponto 1.1:
«1.1.1
Referências
Nesta parte do presente apêndice, utilizam-se as seguintes referências:
NMEA
Norma de interface NMEA (Associação Nacional de Eletrónica para Aplicações Marítimas) 0183, V4.11»;
iii)
no ponto 1.2, são aditados os seguintes acrónimos:
«OSNMA
Autenticação de mensagens de navegação do serviço aberto Galileo
RTC
Relógio de tempo real
»;
(c)
o ponto 2 é alterado do seguinte modo:
i)
o título passa a ter a seguinte redação:
«2.
CARACTERÍSTICAS BÁSICAS DO RECETOR GNSS»;
ii)
O parágrafo GNS_3 passa a ter a seguinte redação:
«GNS_3
O recetor GNSS tem a capacidade para aceitar a autenticação de mensagens de navegação no serviço aberto do Galileo (OSNMA).»;
iii)
são aditados os seguintes parágrafos GNS_3a a GNS_3g:
«GNS_3a
O recetor GNSS deve realizar uma série de verificações de consistência a fim de confirmar que as medições calculadas pelo recetor GNSS com base nos dados da OSNMA resultaram nas informações corretas sobre a posição, a velocidade e os dados do veículo e não foram, por conseguinte, influenciadas por qualquer ataque externo, como mistificação. Estas verificações de consistência devem consistir, por exemplo, em:
—
deteção de emissões anormais de potência por meio da monitorização combinada do Controlo Automático de Ganho (CAG) e da relação portadora/densidade de ruído (C/N0),
—
consistência da medição de pseudodistância e consistência da medição Doppler ao longo do tempo, incluindo a deteção de saltos de medição abruptos,
—
técnicas de monitorização autónoma da integridade do recetor (RAIM), incluindo a deteção de medições inconsistentes com a posição estimada,
—
verificações de posição e velocidade, incluindo soluções de posição e velocidade anormais, saltos abruptos e comportamento inconsistente com a dinâmica do veículo,
—
consistência de tempo e frequência, incluindo saltos e derivas do relógio que não são consistentes com as características do relógio do recetor.
GNS_3b
A Comissão Europeia deve desenvolver e aprovar os seguintes documentos:
—
Um documento de controlo de interface do sinal no espaço (SIS ICD), especificando em pormenor a informação OSNMA transmitida no sinal Galileo.
—
Diretrizes relativas ao recetor OSNMA, indicando os requisitos e processos nos recetores para garantir uma implementação segura da OSNMA, bem como recomendações para melhorar o desempenho da OSNMA.
Os recetores GNSS instalados em tacógrafos, internos ou externos, devem ser construídos de acordo com o SIS ICD e as diretrizes relativas ao recetor OSNMA.
GNS_3c
O recetor GNSS deve fornecer mensagens de posição, denominadas mensagens de posição autenticadas no presente anexo e seus apêndices, as quais são elaboradas utilizando apenas satélites a partir dos quais a autenticidade das mensagens de navegação tenha sido verificada com sucesso.
GNS_3d
O recetor GNSS deve também fornecer mensagens de posição padrão, elaboradas a partir dos satélites visíveis, quer sejam autenticadas ou não.
GNS_3e
O recetor GNSS deve utilizar o relógio em tempo real (RTC) da VU como referência temporal para a sincronização da hora necessária para a OSNMA.
GNS_3f
A hora RTC da VU deve ser fornecida ao recetor GNSS pela VU.
GNS_3g
A deriva máxima de tempo especificada no requisito 41 do anexo IC deve ser fornecida ao recetor GNSS pela VU, juntamente com a hora RTC da VU.»;
(d)
o ponto 3 passa a ter a seguinte redação:
«3.
FRASES INDICADAS PELO RECETOR GNSS
Esta secção descreve as frases utilizadas no funcionamento do tacógrafo inteligente para transmitir mensagens de posição padrão e autenticadas. Esta secção aplica-se à configuração do tacógrafo inteligente com ou sem um módulo GNSS externo.
GNS_4
Os dados de posição padrão baseiam-se nos dados GNSS específicos mínimos recomendados (RMC) da frase NMEA, que contêm as informações de posição (latitude, longitude), as horas em formato UTC (hhmmss.ss) e a velocidade no solo em nós, mais valores adicionais.
Formato da frase RMC (segundo a norma NMEA V4.11):
O estado indica se o sinal GNSS está disponível. Enquanto o valor do estado não estiver fixado em «A», os dados recebidos (por exemplo, relativos à hora, à latitude ou à longitude) não podem ser utilizados para registar a posição do veículo na VU.
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/1 000 de minuto ou 1/60 000 de grau (porque um minuto é 1/60 de um grau).
GNS_4a
Os dados de autenticação da posição baseiam-se numa frase do tipo NMEA, Dados específicos mínimos autenticados (AMC), que contém as informações de posição (latitude, longitude), as horas em formato UTC (hhmmss.ss) e a velocidade no solo em nós, mais valores adicionais.
O formato da frase AMC é o seguinte (segundo a norma NMEA V4.11, exceto para o valor número 2):
Estatuto, A = posição autenticada (estabelecida utilizando pelo menos 4 satélites a partir dos quais a autenticidade das mensagens de navegação foi verificada com sucesso), J = interferência ou O = outro ataque GNSS na ausência de autenticação falhada de mensagens de navegação (por verificações de consistência implementadas de acordo com GNS_3a), F = autenticação falhada de mensagens de navegação (conforme detetado pelas verificações da OSNMA especificadas nos documentos referidos em GNS_3b), V = nulo (a posição autenticada não está disponível por qualquer outro motivo)
3)
Latitude
4)
N ou S
5)
Longitude
6)
E ou O
7)
Velocidade no solo em nós
8)
Rota corrigida, graus verdadeiros
9)
Data, ddmmaa
10)
Variação magnética, graus
11)
E ou O
12)
Modo Indicador FAA
13)
Estatuto de navegação
14)
Soma de teste
O estatuto de navegação é facultativo e pode não estar presente na frase AMC.
O estatuto indica se uma posição GNSS autenticada está disponível, se foi detetado um ataque aos sinais do GNSS, se a autenticação das mensagens de navegação falhou ou se a posição do GNSS é nula. Enquanto o valor do estatuto não estiver fixado em A, os dados recebidos (por exemplo, relativos às horas, à latitude ou à longitude) são considerados não válidos e não podem ser utilizados para registar a posição do veículo na VU. Quando o valor do estatuto está fixado em «J» (interferência), «O» (outro ataque ao GNSS) ou «F» (autenticação das mensagens de navegação falhada), é registado um incidente de anomalia do GNSS na VU, conforme definido no anexo IC e no apêndice 1 (EventFaultCode).
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), de acordo com a norma NMEA V4.11, para determinar e registar a disponibilidade e a exatidão do sinal das posições padrão. 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 GNSS Id. indica o NMEA Id. correspondente para cada constelação e sistema de aumento com recurso a satélites (SBAS) do GNSS.
Figura 4 Estrutura da frase GSA (posições básicas)
ID do 1.o satélite utilizado para determinar posição
4)
ID do 2.o satélite utilizado para determinar posição
…
14)
ID do 12.o satélite utilizado para determinar posição
15)
PDOP
16)
HDOP
17)
VDOP
18)
ID do Sistema
19)
Soma de teste
A ID do Sistema é facultativa e pode não estar presente na frase ASA.
De igual modo, a VU pode utilizar o comando de satélites ativos autenticados (ASA) da frase do tipo NMEA para determinar e registar a disponibilidade e a exatidão do sinal das posições autenticadas. Os valores 1 a 18 são definidos na norma NMEA V4.11.
Figura 5 Estrutura da frase ASA (posições autenticadas)
ID do 1.o satélite utilizado para determinar posição
4)
ID do 2.o satélite utilizado para determinar posição
…
14)
ID do 12.o satélite utilizado para determinar posição
15)
PDOP
16)
HDOP
17)
VDOP
18)
ID do Sistema
19)
Soma de teste
A ID do Sistema é facultativa e pode não estar presente na frase ASA.
GNS_6
Quando um módulo GNSS externo é utilizado, a frase GSA é memorizada no emissor-recetor seguro GNSS com os números de registo «02» a «06» e a frase ASA é memorizada com os números de registo «12» a «16».
GNS_7
O tamanho máximo das frases (por exemplo, GSA, AMC, GSA, ASA ou outras), que podem ser utilizadas para a calibração do comando «ler registo» é de 85 bytes (ver o quadro 1)».
e)
o ponto 4 é alterado do seguinte modo:
i)
no ponto 4.1.1, o parágrafo GNS_9 é alterado do seguinte modo:
(1)
O texto que precede a alínea b) passa a ter a seguinte redação:
«GNS_9
O módulo GNSS externo tem os seguintes componentes (ver figura 6):
a)
Um recetor GNSS comercial para fornecer os dados de posição, através da interface de dados GNSS. Por exemplo, a interface de dados GNSS pode ter a normalização NMEA V4.11, em que o recetor GNSS age como um transmissor e transmite frases NMEA ao emissor-recetor seguro GNSS na frequência de 1 Hz para o conjunto pré-definido de frases NMEA e do tipo NMEA, que deve incluir pelo menos as frases RMC, AMC, GSA e ASA. A implementação da interface de dados GNSS é uma escolha dos fabricantes do módulo GNSS externo.»;
2)
A alínea c) passa a ter a seguinte redação:
«c)
Um sistema de invólucro com a função de deteção de adulteração, que envolve o recetor GNSS e o emissor-recetor seguro GNSS. A função de deteção de adulteração deve aplicar as medidas de proteção da segurança exigidas no perfil de proteção dos tacógrafos inteligentes».
ii)
o ponto 4.2.1 é alterado do seguinte modo:
(1)
O parágrafo GNS_14 passa a ter a seguinte redação:
«GNS_14
O protocolo de comunicação entre o módulo GNSS externo e a unidade-veículo deve aceitar as seguintes funções:
1.
A recolha e distribuição de dados GNSS (por exemplo, posição, temporização, velocidade),
2.
A recolha dos dados de configuração do módulo GNSS externo,
3.
O protocolo de gestão para aceitar o acoplamento, a autenticação mútua e a concordância de chave de sessão entre o módulo GNSS externo e a VU,
4.
A transmissão para o módulo GNSS externo da hora RTC da VU e da diferença máxima entre a hora verdadeira e a hora RTC da VU.»;
(2)
É inserido o seguinte parágrafo a seguir ao parágrafo GNS_18:
«GNS_18a
Em relação à função 4) a transmissão para o módulo GNSS externo da hora RTC da VU e da diferença máxima entre a hora verdadeira e a hora RTC daVU, o emissor-recetor seguro GNSS deve utilizar um EF (EF VU) no mesmo DF com o identificador de ficheiro igual a '2F30' conforme descrito no quadro 1.»;
(3)
É inserido o seguinte parágrafo a seguir ao parágrafo GNS_19:
«GNS_19a
O emissor-recetor seguro GNSS deve memorizar os dados provenientes da VU no EF VU. Trata-se de um ficheiro de registo linear de comprimento variável com um identificador igual a ‘2F30’ em formato hexadecimal.»;
(4)
No parágrafo GNS_20, a segunda frase passa a ter a seguinte redação:
«GNS_20
O emissor-recetor seguro GNSS utiliza uma memória para memorizar os dados e poder executar tantos ciclos de leitura/escrita quantos os necessários durante uma vida de pelo menos 15 anos. À parte este aspeto, a conceção e a aplicação internas do emissor-recetor seguro GNSS são deixadas ao critério dos fabricantes.»;
(5)
No GNS_21, o quadro 1 passa a ter a seguinte redação:
«
Quadro 1
Estrutura do ficheiro
Condições de acesso
Ficheiro
File ID
Read
Atualizar
Encriptado
MF
3F00
EF.ICC
0002
ALW
NEV
(pela VU)
N.o
DF GNSS Facility
0501
ALW
NEV
N.o
EF EGF_MACertificate
C100
ALW
NEV
N.o
EF CA_Certificate
C108
ALW
NEV
N.o
EF Link_Certificate
C109
ALW
NEV
N.o
EF EGF
2F2F
SM-MAC
NEV
(pela VU)
N.o
EF VU
2F30
SM-MAC
SM-MAC
N.o
Ficheiro/elemento de dados
n.o de registo
Tamanho (bytes)
Valores por defeito
Mín.
Máx.
MF
552
1031
EF.ICC
sensorGNSSSerialNumber
8
8
DF GNSS Facility
612
1023
EF EGF_MACertificate
204
341
EGFCertificate
204
341
{00..00}
EF CA_Certificate
204
341
MemberStateCertificate
204
341
{00..00}
EF Link_Certificate
204
341
LinkCertificate
204
341
{00..00}
EF EGF
Frase RMC NMEA
'01'
85
85
1.a frase GSA NMEA
'02'
85
85
2.a frase GSA NMEA
'03'
85
85
3.a frase GSA NMEA
'04'
85
85
4.a frase GSA NMEA
'05'
85
85
5.a frase GSA NMEA
'06'
85
85
Número de série alargado do módulo GNSS externo definido no apêndice 1 como SensorGNSSSerialNumber.
'07'
8
8
Identificador do sistema operativo do emissor-recetor seguro GNSS definido no apêndice 1 como SensorOSIdentifier.
'08'
2
2
Número de homologação de tipo do módulo GNSS externo definido no apêndice 1 como SensorExternalGNSSApprovalNumber.
'09'
16
16
Identificador do componente de segurança do módulo GNSS externo definido no apêndice 1 como SensorExternalGNSSSCIdentifier.
'10'
8
8
Frase AMC
'11'
85
85
1.a frase ASA
'12'
85
85
2.a frase ASA
'13'
85
85
3.a frase ASA
'14'
85
85
4.a frase ASA
'15'
85
85
5.a frase ASA
'16'
85
85
RFU – Reservado para utilização futura
De ‘17’ a ‘FD’
EF VU
VuRtcTime (ver o apêndice 1)
'01'
4
4
{00..00}
VuGnssMaximalTimeDifference (ver o apêndice 1)
'02'
2
2
{00..00}
»;
iii)
o ponto 4.2.2 é alterado do seguinte modo:
(1)
No parágrafo GNS_22, a segunda frase passa a ter a seguinte redação:
«GNS_22
A transferência segura dos dados de posição GNSS, da hora RTC da VU e da diferença máxima entre a hora verdadeira e a hora RTC da VU só é permitida nas seguintes condições:»;
(2)
O parágrafo GNS_23 passa a ter a seguinte redação:
«GNS_23
Com uma periodicidade de T segundos, em que T é um valor inferior ou igual a 20, salvo se ocorrer o acoplamento ou a autenticação mútua e a concordância de chave de sessão, a VU pede ao módulo GNSS externo a informação de posição segundo a seguinte sequência:
1.
A VU pede dados de posição ao módulo GNSS externo, bem como dados de diluição de precisão (das frases GSA e ASA). O emissor-recetor seguro da VU utiliza os comandos SELECT (Selecionar) e READ RECORD(S) (Ler registo[(s)] (norma ISO/IEC 7816-4:2013) no modo apenas de autenticação do envio seguro de mensagens descrito na secção 11.5 do apêndice 11, com o identificador de ficheiro «2F2F» e o número RECORD igual a «01» para a frase RMC NMEA, ‘02’, ‘03’, ‘04’, ‘05’, ‘06’ para a frase GSA NMEA, ‘11’ para a frase AMC e ‘12’,’13’,’14’,’15’,’16’ para a frase ASA.
2.
Os dados recebidos relativos à última posição são memorizados no EF com o identificador ‘2F2F’ e os registos descritos no quadro 1, no emissor-recetor seguro GNSS, à medida que este recebe dados NMEA com uma frequência de, pelo menos, 1 Hz proveniente do recetor GNSS por meio da interface de dados GNSS.
3.
O emissor-recetor seguro GNSS envia a resposta ao emissor-recetor seguro da VU utilizando a mensagem de resposta APDU no modo apenas de autenticação do envio seguro de mensagens descrito na secção 11.5 do apêndice 11.
4.
O emissor-recetor seguro da VU verifica a autenticidade e a integridade da resposta recebida. Se o resultado for positivo, os dados de posição são transferidos para o processador da VU por meio da interface de dados GNSS.
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 não autenticada for válida. Se a posição não autenticada 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).
6.
O processador da VU extrai também a informação (por exemplo, latitude, longitude, hora) da frase AMC. A frase AMC inclui a informação se a posição autenticada não for válida ou o sinal do GNSS tiver sido atacado. Se a posição for válida, o processador da VU extrai também os valores de HDOP de frases ASA 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).
GNS_23a
A VU escreve também a hora RTC da VU e a diferença de tempo máxima entre a hora verdadeira e a hora RTC da VU se necessário, utilizando os comandos SELECT (Selecionar) e WRITE RECORD(S) (Escrever registo[(s)] (norma ISO/IEC 7816-4: 2013) no modo apenas de autenticação do envio seguro de mensagens conforme descrito na secção 11.5 do apêndice 11 com o identificador de ficheiro «2F30» e o número RECORD igual a '01' para VuRtcTime e '02' para MaximalTimeDifference. ’;
iv)
o ponto 4.2.3 é alterado do seguinte modo:
(1)
No parágrafo GNS_26, os quarto e quinto travessões passam a ter a seguinte redação:
«-
Se o registo não for encontrado, o emissor-recetor seguro GNSS devolve ‘6A 83’.
-
Se o módulo GNSS externo tiver detetado adulteração, deve devolver as palavras de estatuto ‘6690’».
(2)
O parágrafo GNS_27 é suprimido.
v)
são inseridos os seguintes pontos 4.2.4. e 4.2.5:
«4.2.4
Estrutura do comando WriteRecord
A presente secção descreve em pormenor a estrutura do comando Read Record (Ler registo). O envio seguro de mensagens (modo apenas de autenticação) é adicionado conforme descrito no apêndice 11 (Mecanismos comuns de segurança).
GNS_26a
O comando deve aceitar o modo apenas de autenticação do envio seguro de mensagens (ver apêndice 11).
GNS_26b
Mensagem de comando
Byte
Comprimento
Valor
Descrição
CLA
1
‘0Ch’
Pedido envio seguro de mensagens.
INS
1
‘D2h’
Escrever registo
P1
1
‘XXh’
Número de registo (‘00’ faz referência ao registo atual)
P2
1
‘04h’
Escrever o registo com o número do registo indicado em P1
Dados
X
‘XXh’
Dados
GNS_26c
O registo referenciado em P1 torna-se o registo atual.
Byte
Comprimento
Valor
Descrição
SW
2
‘XXXXh’
Palavras de estatuto (SW1, SW2)
—
Se o comando tiver êxito, o emissor-recetor seguro GNSS devolve ‘
9000
’.
—
Se o ficheiro atual não for orientado para o registo, o emissor-recetor seguro GNSS devolve ‘
6981
’.
—
Se o comando for utilizado com P1 = ‘00’, mas não houver nenhum EF atual, o emissor-recetor seguro GNSS devolve ‘
6986
’ (comando não permitido).
—
Se o registo não for encontrado, o emissor-recetor seguro GNSS devolve ‘
6A83
’.
—
Se o módulo GNSS externo tiver detetado adulteração, devolve as palavras de estatuto ‘
6690
’.
4.2.5
Outros comandos
GNS_27
O emissor-recetor seguro GNSS deve aceitar os comandos de tacógrafo da geração 2 a seguir indicados, especificados no apêndice 2:
Comando
Referência
Select (Selecionar)
Apêndice 2, capítulo 3.5.1
Read Binary (Ler binário)
Apêndice 2, capítulo 3.5.2
Get Challenge (Obter desafio)
Apêndice 2, capítulo 3.5.4
PSO: Verify Certificate (Verificar certificado)
Apêndice 2, capítulo 3.5.7
External Authenticate (Externo autenticar)
Apêndice 2, capítulo 3.5.9
General Authenticate (Geral autenticar)
Apêndice 2, capítulo 3.5.10
MSE:SET
Apêndice 2, capítulo 3.5.11
»;
vi)
o ponto 4.4.1, o parágrafo GNS_28 passa a ter a seguinte redação:
«GNS_28
Um erro de comunicação com o incidente do módulo GNSS externo é registrado na VU, conforme definido no requisito 82 do anexo IC e no apêndice 1 (EventFaultType). Neste contexto, desencadeia-se um erro de comunicação quando o emissor-recetor seguro da VU não recebe uma mensagem de resposta após uma mensagem de pedido conforme descrito em 4.2.»;
vii)
o ponto 4.4.2, o parágrafo 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 assegura que todo o material criptográfico fique indisponível. Conforme descrito em GNS_25 e GNS_26, a VU deteta adulteração se a resposta tiver estatuto ‘6690’. A VU gera e regista então um incidente de tentativa de violação da segurança, conforme definido no requisito 85 do anexo IC e no apêndice 1 (EventFaultType para deteção de adulteração do GNSS). Em alternativa, o módulo GNSS externo pode responder aos pedidos da VU sem o envio seguro de mensagens seguras e com o estatuto '6A88'».
viii)
o ponto 4.4.3, o parágrafo GNS_30 passa a ter a seguinte redação:
«GNS_30
Se não receber dados do recetor GNSS, 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 gera e regista uma ausência de informações de posição do incidente do recetor GNSS, conforme definido no requisito 81 do anexo IC e no apêndice 1 (EventFaultType).»;
ix)
o ponto 4.4.4 é alterado do seguinte modo:
(1)
O parágrafo GNS_31 passa a ter a seguinte redação:
«GNS_31
Se detetar que o certificado EGF utilizado para autenticação mútua deixou de ser válido, a VU gera e regista um incidente de tentativa de violação da segurança, conforme definido no requisito 85 do anexo IC e no apêndice 1 (EventFaultType para certificado do módulo GNSS externo expirado). A VU continua a utilizar os dados de posição GNSS recebidos.»;
(2)
O título da figura 4 passa a ter a seguinte redação:
«
Figura 6
Esquema do módulo GNSS externo
»;
(f)
o ponto 5 é alterado do seguinte modo:
i)
no ponto 5.1, o parágrafo GNS_32 passa a ter a seguinte redação:
«GNS_32
Para transmitir dados de posição, DOP e satélites, o recetor GNSS funciona como transmissor e transmite frases NMEA ou do tipo NMEA ao processador da VU, que funciona como ouvinte, com uma frequência de 1/10 Hz ou mais rápida para o conjunto predefinido de frases, que deve incluir, pelo menos, as frases RMC, GSA, AMC e ASA. Em alternativa, o processador da VU e o recetor GNSS interno podem utilizar outros formatos de dados para o intercâmbio dos dados contidos nas frases NMEA ou do tipo NMEA, especificadas em GNS_4, GNS_4a e GNS_5.»;
ii)
o ponto 5.2 passa a ter a seguinte redação:
«5.2.
Transferência de informações do recetor GNSS para a VU
GNS_34
O processador da VU verifica os dados recebidos extraindo a informação (por exemplo, latitude, longitude, hora) da frase RMC NMEA e da frase AMC.
GNS_35
A frase RMC NMEA inclui a informação se a posição não autenticada for válida. Se a posição não autenticada não for válida, os dados de posição não estão disponíveis e não podem ser utilizados para registar a posição do veículo. Se a posição não autenticada for válida, o processador da VU extrai também os valores HDOP da GSA NMEA.
GNS_36
O processador da VU extrai também a informação (por exemplo, latitude, longitude, hora) da frase AMC. A frase AMC inclui a informação se a posição não autenticada for válida de acordo com GNS_4a. Se a posição não autenticada for válida, o processador da VU extrai também os valores HDOP das frases ASA.
5.3.
Transferência de informações da VU para o recetor GNSS
GNS_37
O processador da VU transmite ao recetor GNSS a hora RTC da VU e a diferença máxima entre a hora verdadeira e a hora RTC da VU, de acordo com GNS_3f e GNS_3g.
5.4.
Tratamento de erros
5.4.1
Ausência de informações sobre a posição do recetor GNSS
GNS_38
A VU gera e regista uma ausência de informações de posição do incidente do recetor GNSS, conforme definido no requisito 81 do anexo IC e no apêndice 1 (EventFaultType).»;
(g)
Os pontos 6 e 7 passam a ter a seguinte redação:
«6.
TRATAMENTO E REGISTO DE DADOS DE POSIÇÃO PELA VU
Esta secção aplica-se à configuração do tacógrafo inteligente com ou sem um módulo GNSS externo. alvo,
GNS_39
Os dados de posição são memorizados na VU, juntamente com um indicador que denota se a posição foi autenticada. Quando os dados de posição precisam de ser registados na VU, aplicam-se as regras seguintes:
a)
Se ambas as posições autenticadas e padrão forem válidas e consistentes, a posição padrão e a respetiva precisão são registadas na VU e o indicador deve ser fixado em «autenticada».
b)
Se ambas as posições autenticadas e padrão forem válidas, mas não consistentes, a VU memoriza a posição autenticada e a respetiva precisão, e o indicador deve ser fixado em «autenticada».
c)
Se a posição autenticada for válida e a posição padrão não for válida, a VU regista a posição autenticada e a respetiva precisão, e o indicador deve ser fixado em «autenticada».
d)
Se a posição padrão for válida e a posição autenticada não for válida, a VU regista a posição padrão e a respetiva precisão, e o indicador deve ser fixado em «não autenticada».
As posições autenticadas e padrão são consideradas consistentes, conforme ilustrado na figura 7, quando a posição autenticada horizontal figura num círculo centrado na posição padrão horizontal, cujo raio resulta do arredondamento para o número inteiro superior mais próximo do valor de R_H calculado de acordo com a seguinte fórmula:
R_H = 1,74 • σUERE • HDOP
na qual:
—
R_H é o raio relativo de um círculo em redor da posição horizontal estimada, em metros. Trata-se de um indicador que é utilizado para verificar a coerência entre as posições padrão e autenticadas.
—
incluindo ambientes urbanos. É utilizado um valor constante de σ - σUERE é o desvio padrão para o erro de faixa equivalente do utilizador (UERE), que modela todos os erros de medição para a aplicação- UERE = 10 metros.
—
HDOP é a diluição de precisão horizontal calculada pelo recetor GNSS.
—
σUERE . HDOP é a estimativa do erro médio quadrático no domínio horizontal-
Figura 7 Posições autenticadas e padrão consistentes (não autenticadas)
GNS_40
Quando o valor do estatuto numa frase AMC recebida é fixado em «J»' ou «O» ou «F» de acordo com o requisito GNS_4a, a VU gera e regista um incidente de anomalia do GNSS, conforme definido no requisito 88-A do anexo IC e no apêndice 1 (EventFaultType). A unidade-veículo pode realizar verificações adicionais antes de memorizar um incidente de anomalia do GNSS após a receção de uma definição «J» ou «O».
7.
CONFLITO DE TEMPO GNSS
GNS_41
Se a VU detetar uma discrepância entre o tempo da função de medição do tempo da unidade-veículo e o tempo proveniente dos sinais GNSS, deve gerar e registar um incidente de conflito de tempo, conforme definido no requisito 86 do anexo IC e no apêndice 1 (EventFaultType).»;
(h)
é aditado o seguinte ponto 8:
«8.
CONFLITO RELATIVO AO MOVIMENTO DO VEÍCULO
GNS_42
A VU aciona e regista um incidente de conflito relativo ao movimento do veículo, de acordo com o requisito 84 do anexo IC, caso as informações de movimento calculadas a partir do sensor de movimentos sejam contraditas por informações de movimento calculadas a partir do recetor GNSS interno, do módulo GNSS externo ou por outra(s) fonte(s) de movimento independente(s) conforme estabelecido no requisito 26 do anexo IC.
O incidente de conflito relativo ao movimento do veículo é acionado mediante a ocorrência de uma das seguintes condições de acionamento:
Condição de acionamento 1:
Deve ser utilizado o valor médio aparado das diferenças de velocidade entre estas fontes, quando a informação de posição do recetor GNSS estiver disponível e quando a ignição do veículo for ligada, conforme especificado a seguir:
—
no máximo de 10 em 10 segundos, calcula-se o valor absoluto da diferença entre a velocidade do veículo, estimada com base no GNSS, e a estimada com base no sensor de movimentos.
—
para calcular o valor médio aparado, devem utilizar-se todos os valores calculados num intervalo de tempo que inclua os últimos cinco minutos de movimento.
—
o valor médio aparado é calculado como média de 80 % dos valores remanescentes, depois de se eliminarem os mais elevados em valor absoluto.
O incidente de conflito relativo ao movimento do veículo é acionado se o valor médio aparado for superior a 10 km/h durante cinco minutos contínuos de movimento do veículo. (Nota: recorre-se ao valor médio aparado relativo aos últimos 5 minutos para atenuar o risco de medições discrepantes e de valores transitórios).
Para o cálculo da média aparada, o veículo é considerado em movimento, se pelo menos um valor da velocidade do veículo estimado quer a partir do sensor de movimentos, quer a partir do recetor GNSS não for igual a zero.
Condição de acionamento 2:
O incidente de conflito relativo ao movimento do veículo também deve ser acionado se a seguinte condição for verdadeira:
GnssDistance é a distância entre a posição atual do veículo e a anterior, ambas obtidas a partir de mensagens de posição autenticadas válidas, sem considerar a altura,
—
OdometerDifference é a diferença entre o valor atual do conta-quilómetros e o valor do conta-quilómetros correspondente à mensagem de posição autenticada válida anterior,
—
OdometerToleranceFactor é igual a 1.1 (fator de tolerância mais pessimista para todas as tolerâncias de medição do conta-quilómetros do veículo),
—
GnssTolerance é igual a 1 km (tolerância do GNSS mais pessimista),
—
Minimum (SlipDistanceUpperLimit; (OdometerDifference * SlipFactor)) é o valor mínimo entre:
—
SlipDistanceUpperLimit que é igual a 10 km (limite superior do percurso de escorregamento causado por efeitos de escorregamento durante a travagem),
—
e OdometerDifference * SlipFactor, em que SlipFactor é igual a 0,2 (influência máxima dos efeitos de escorregamento durante a travagem),
—
FerryTrainDistance é calculado como: FerryTrainDistance = 200km/h * tFerryTrain, em que tFerryTrain é a soma das durações em horas das travessias de batelão/comboio no intervalo de tempo considerado. A duração de uma travessia de batelão/comboio é definida como a diferença de tempo entre o respetivo indicador final e inicial.
As verificações anteriores devem ser realizadas de 15 em 15 minutos se os dados de posição necessários estiverem disponíveis; caso contrário, assim que os dados de posição se tornarem disponíveis.
Para esta condição de acionamento:
—
a data e hora do início do incidente devem ser iguais à data e hora em que a mensagem de posição anterior foi recebida,
—
a data e hora do final do incidente devem ser iguais à data e hora em que a condição verificada se torna novamente falsa.
Condição de acionamento 3:
A unidade-veículo encontra uma discrepância que consiste na não deteção pelo sensor de movimentos de nenhum movimento e na deteção pela fonte de movimento independente de movimento durante um período específico. As condições para registar uma discrepância, bem como o período de deteção da discrepância, devem ser estabelecidos pelo fabricante da unidade-veículo, embora a discrepância deva detetada, no máximo, dentro de três horas.»;
(38)
O apêndice 13 passa a ter a seguinte redação:
«Apêndice 13
INTERFACE ITS
ÍNDICE
1.
INTRODUÇÃO
1.1.
Âmbito de aplicação
1.2.
Acrónimos e definições
22.
NORMAS DE REFERÊNCIA
3.
PRINCÍPIOS DE FUNCIONAMENTO DA INTERFACE
3.1.
Tecnologia da comunicação
3.2.
Serviços disponíveis
3.3.
Acesso através da interface ITS
3.4.
Dados disponíveis e necessidade do consentimento do condutor
4.
LISTA DE DADOS DISPONÍVEIS ATRAVÉS DA INTERFACE ITS E CLASSIFICAÇÃO COMO PESSOAIS/NÃO PESSOAIS
1. INTRODUÇÃO
1.1. Âmbito de aplicação
ITS_01
O presente apêndice especifica os fundamentos da comunicação através da interface do tacógrafo com os sistemas de transporte inteligentes (ITS), solicitados nos artigos 10.o e 11.o do Regulamento (UE) n.o 165/2014.
ITS_02
A interface ITS deve permitir a obtenção de dados do tacógrafo, a utilização de serviços do tacógrafo, bem como a transmissão de dados ao tacógrafo, por dispositivos externos.
Também podem ser utilizadas outras interfaces do tacógrafo (por exemplo, CAN bus) para esse fim.
Este apêndice não especifica:
—
o modo como os dados fornecidos através da interface ITS são recolhidos e geridos no âmbito do tacógrafo,
—
a forma de apresentação dos dados recolhidos para aplicações alojadas no dispositivo externo,
—
a especificação de segurança de ITS além do que o Bluetooth® fornece,
—
os protocolos Bluetooth® utilizados pela interface ITS.
1.2. Acrónimos e definições
No presente apêndice utilizam-se os seguintes acrónimos e definições, que lhe são específicos:
GNSS
Global Navigation Satellite System (Sistema Global de Navegação por Satélite)
ITS
Intelligent Transport System (Sistema de Transporte Inteligente)
OSI
Open Systems Interconnection (Interligação de Sistemas Abertos)
VU
Vehicle Unit (Unidade-veículo)
Órgão ITS
um dispositivo ou aplicação externa que utiliza a interface ITS da VU.
2. NORMAS DE REFERÊNCIA
ITS_03
A especificação definida no presente apêndice refere-se à totalidade ou a partes dos regulamentos e normas a seguir indicados e deles depende. O clausulado do presente apêndice especifica as normas pertinentes ou cláusulas pertinentes das normas. Em caso de contradição, prevalecem as cláusulas do presente apêndice.
As normas referidas no presente apêndice são as seguintes:
ISO/IEC7498-1:1994,"Information technology - Open Systems Interconnection - Basic Reference Model: The Basic Model" (Tecnologia da informação - Interligação de Sistemas Abertos - Modelo de Referência Básico, o Modelo Básico).
3. PRINCÍPIOS DE FUNCIONAMENTO DA INTERFACE
ITS_04
A VU tem a responsabilidade de manter atualizados e guardar os dados tacográficos transmitidos através da interface ITS, sem qualquer envolvimento da interface ITS.
3.1. Tecnologia da comunicação
ITS_05
A comunicação através da interface ITS deve ser realizada via interface Bluetooth® e ser compatível com Bluetooth® Low Energy (Bluetooth® de baixo consumo) de acordo com a versão 5.0 do Bluetooth ou mais recente.
ITS_06
A comunicação entre a VU e o órgão ITS deve ser estabelecida após a conclusão do processo de emparelhamento do Bluetooth®.
ITS_07
Deve ser estabelecida uma comunicação segura e criptografada entre a VU e o órgão ITS, de acordo com os mecanismos de especificação do Bluetooth®. O presente apêndice não especifica mecanismos de encriptação ou outros mecanismos de segurança além do que o Bluetooth® fornece.
ITS_08
O Bluetooth® utiliza um modelo servidor/cliente para controlar a transmissão de dados entre dispositivos, em que a VU é o servidor e o órgão ITS é o cliente.
3.2. Serviços disponíveis
ITS_09
Os dados a transmitir através da interface ITS em conformidade com o ponto 4 devem ser disponibilizados através dos serviços especificados nos apêndices 7 e 8. Além disso, a VU deve disponibilizar ao órgão ITS os serviços necessários para a introdução manual de dados de acordo com o requisito 61 do anexo IC e, opcionalmente, para outras introduções de dados em tempo real.
ITS_10
Quando a interface de descarregamento é utilizada através do conector da frente, a VU não fornece os serviços de descarregamento especificados no apêndice 7 por via da ligação Bluetooth® do ITS.
ITS_11
Quando a interface de calibração é utilizada através do conector da frente, a VU não fornece os serviços de calibração especificados no apêndice 8 por via da ligação Bluetooth® do ITS.
3.3. Acesso através da interface ITS
ITS_12
A interface ITS permite um acesso sem fios a todos os serviços especificados no apêndice 7 e no apêndice 8 em substituição da ligação por cabo ao conector da frente para a calibração e o descarregamento especificados no apêndice 6.
ITS_13
A VU disponibiliza a interface ITS ao utilizador de acordo com a combinação de cartões tacográficos válidos inseridos na VU, conforme especificado no quadro 1.
Quadro 1
Disponibilidade da interface ITS em função do tipo de cartão inserido no tacógrafo
Disponibilidade da interface ITS
Ranhura do condutor
Ausência de cartão
Cartão de condutor
Cartão de controlo
Cartão de oficina
Cartão de empresa
Ranhura do ajudante
Ausência de cartão
Não disponível
Disponível
Disponível
Disponível
Disponível
Cartão de condutor
Disponível
Disponível
Disponível
Disponível
Disponível
Cartão de controlo
Disponível
Disponível
Disponível
Não disponível
Não disponível
Cartão de oficina
Disponível
Disponível
Não disponível
Disponível
Não disponível
Cartão de empresa
Disponível
Disponível
Não disponível
Não disponível
Disponível
ITS_14
Após um emparelhamento ITS Bluetooth® bem-sucedido, a VU atribui a ligação ITS Bluetooth® ao cartão tacográfico específico inserido de acordo com o quadro 2:
Quadro 2
Atribuição da ligação ITS em função do tipo de cartão inserido no tacógrafo
Se um cartão tacográfico for retirado, a VU termina a ligação ITS Bluetooth® que está atribuída a este cartão.
ITS_16
A VU deve suportar a ligação ITS a pelo menos um órgão ITS e pode suportar ligações a vários órgãos ITS ao mesmo tempo.
ITS_17
Os direitos de acesso aos dados e serviços disponibilizados através da interface ITS devem cumprir os requisitos 12 e 13 do anexo IC, para além do consentimento do condutor especificado na secção 3.4 deste apêndice.
3.4. Dados disponíveis e necessidade do consentimento do condutor
ITS_18
Todos os dados do tacógrafo disponíveis através dos serviços referidos no ponto 3.3 devem ser classificados como pessoais ou não pessoais em relação ao condutor, ao ajudante ou a ambos.
ITS_19
Pelo menos a lista de dados classificados como obrigatórios na secção 4 deve ser disponibilizada através da interface ITS.
ITS_20
Os dados na secção 4 classificados como «pessoais» só são acessíveis mediante consentimento do condutor, aceitando-se, por conseguinte, que os dados pessoais possam sair da rede do veículo, exceto no caso previsto no requisito ITS_25, para o qual o consentimento do condutor não é necessário.
ITS_21
Os dados adicionais aos recolhidos no ponto 4 e considerados obrigatórios podem ser disponibilizados através da interface ITS. Os dados adicionais que não estão incluídos no ponto 4 devem ser classificados como «pessoais» ou «não pessoais» pelo fabricante da VU, sendo pedido o consentimento do condutor para os dados que foram classificados como pessoais, exceto no caso previsto no requisito ITS_25, para o qual o consentimento do condutor não é necessário.
ITS_22
Após a inserção de um cartão de condutor desconhecido da VU, o titular do cartão será solicitado pelo tacógrafo a introduzir o consentimento para a transmissão dos dados pessoais emitidos através da interface ITS, em conformidade com o requisito 61 do anexo IC.
ITS_23
O estado de consentimento (ativado/desativado) é registado na memória de dados da unidade-veículo.
ITS_24
No caso de vários condutores, são partilhados com a interface ITS apenas os dados pessoais relativos aos condutores que deram o seu consentimento. Por exemplo, no caso de uma equipa de condutores, se apenas o condutor tiver dado o seu consentimento, os dados pessoais relacionados com o ajudante não devem ser acessíveis.
ITS_25
Quando a VU se encontrar nos modos de controlo, empresa ou calibração, os direitos de acesso através da interface ITS devem ser geridos de acordo com os requisitos 12 e 13 do anexo IC, não sendo, portanto, necessária a autorização do condutor.
4. LISTA DE DADOS DISPONÍVEIS ATRAVÉS DA INTERFACE ITS E CLASSIFICAÇÃO COMO PESSOAIS/NÃO PESSOAIS
Nome dos dados
Formato dos dados
Fonte
Classificação recomendada (pessoais/não pessoais)
Consentimento quanto à disponibilidade dos dados
Disponibilidade
condutor
ajudante
VehicleIdentificationNumber
Apêndice 8
VU
não pessoais
não pessoais
não é necessário o consentimento
obrigatória
CalibrationDate
ISO 16844-7
VU
não pessoais
não pessoais
não é necessário o consentimento
obrigatória
TachographVehicleSpeed
ISO 16844-7
VU
pessoais
N/A
consentimento do condutor
obrigatória
Driver1WorkingState
ISO 16844-7
VU
pessoais
N/A
consentimento do condutor
obrigatória
Driver2WorkingState
ISO 16844-7
VU
N/A
pessoais
consentimento do ajudante
obrigatória
DriveRecognize
ISO 16844-7
VU
não pessoais
não pessoais
não é necessário o consentimento
obrigatória
Driver1TimeRelatedStates
ISO 16844-7
VU
pessoais
N/A
consentimento do condutor
obrigatória
Driver2TimeRelatedStates
ISO 16844-7
VU
N/A
pessoais
consentimento do ajudante
obrigatória
DriverCardDriver1
ISO 16844-7
VU
pessoais
N/A
consentimento do condutor
obrigatória
DriverCardDriver2
ISO 16844-7
VU
N/A
pessoais
consentimento do ajudante
obrigatória
OverSpeed
ISO 16844-7
VU
pessoais
N/A
consentimento do condutor
obrigatória
TimeDate
Apêndice 8
VU
não pessoais
não pessoais
não é necessário o consentimento
obrigatória
HighResolutionTotalVehicleDistance
ISO 16844-7
VU
não pessoais
não pessoais
não é necessário o consentimento
obrigatória
HighResolutionTripDistance
ISO 16844-7
VU
não pessoais
não pessoais
não é necessário o consentimento
obrigatória
ServiceComponentIdentification
ISO 16844-7
VU
não pessoais
não pessoais
não é necessário o consentimento
obrigatória
ServiceDelayCalendarTimeBased
ISO 16844-7
VU
não pessoais
não pessoais
não é necessário o consentimento
obrigatória
Driver1Identification
ISO 16844-7
Cartão de condutor
pessoais
N/A
consentimento do condutor
obrigatória
Driver2Identification
ISO 16844-7
Cartão de condutor
N/A
pessoais
consentimento do ajudante
obrigatória
NextCalibrationDate
Apêndice 8
VU
não pessoais
não pessoais
não é necessário o consentimento
obrigatória
Driver1ContinuousDrivingTime
ISO 16844-7
VU
pessoais
N/A
consentimento do condutor
obrigatória
Driver2ContinuousDrivingTime
ISO 16844-7
VU
N/A
pessoais
consentimento do ajudante
obrigatória
Driver1CumulativeBreakTime
ISO 16844-7
VU
pessoais
N/A
consentimento do condutor
obrigatória
Driver2CumulativeBreakTime
ISO 16844-7
VU
N/A
pessoais
consentimento do ajudante
obrigatória
Driver1CurrentDurationOfSelectedActivity
ISO 16844-7
VU
pessoais
N/A
consentimento do condutor
obrigatória
Driver2CurrentDurationOfSelectedActivity
ISO 16844-7
VU
N/A
pessoais
consentimento do ajudante
obrigatória
SpeedAuthorised
Apêndice 8
VU
não pessoais
não pessoais
não é necessário o consentimento
obrigatória
TachographCardSlot1
ISO 16844-7
VU
não pessoais
N/A
não é necessário o consentimento
obrigatória
TachographCardSlot2
ISO 16844-7
VU
N/A
não pessoais
não é necessário o consentimento
obrigatória
Driver1Name
ISO 16844-7
Cartão de condutor
pessoais
N/A
consentimento do condutor
obrigatória
Driver2Name
ISO 16844-7
Cartão de condutor
N/A
pessoais
consentimento do ajudante
obrigatória
OutOfScopeCondition
ISO 16844-7
VU
não pessoais
não pessoais
não é necessário o consentimento
obrigatória
ModeOfOperation
ISO 16844-7
VU
não pessoais
não pessoais
não é necessário o consentimento
obrigatória
Driver1CumulatedDrivingTimePreviousAndCurrentWeek
ISO 16844-7
VU
pessoais
N/A
consentimento do condutor
obrigatória
Driver2CumulatedDrivingTimePreviousAndCurrentWeek
ISO 16844-7
VU
N/A
pessoais
consentimento do ajudante
obrigatória
EngineSpeed
ISO 16844-7
VU
pessoais
N/A
consentimento do condutor
facultativa
RegisteringMemberState
Apêndice 8
VU
não pessoais
não pessoais
não é necessário o consentimento
obrigatória
VehicleRegistrationNumber
Apêndice 8
VU
não pessoais
não pessoais
não é necessário o consentimento
obrigatória
Driver1EndOfLastDailyRestPeriod
ISO 16844-7
VU
pessoais
N/A
consentimento do condutor
facultativa
Driver2EndOfLastDailyRestPeriod
ISO 16844-7
VU
N/A
pessoais
consentimento do ajudante
facultativa
Driver1EndOfLastWeeklyRestPeriod
ISO 16844-7
VU
pessoais
N/A
consentimento do condutor
facultativa
Driver2EndOfLastWeeklyRestPeriod
ISO 16844-7
VU
N/A
pessoais
consentimento do ajudante
facultativa
Driver1EndOfSecondLastWeeklyRestPeriod
ISO 16844-7
VU
pessoais
N/A
consentimento do condutor
facultativa
Driver2EndOfSecondLastWeeklyRestPeriod
ISO 16844-7
VU
N/A
Pessoais
consentimento do ajudante
facultativa
Driver1TimeLastLoadUnloadOperation
ISO 16844-7
VU
pessoais
N/A
consentimento do condutor
facultativa
Driver2TimeLastLoadUnloadOperation
ISO 16844-7
VU
N/A
pessoais
consentimento do ajudante
facultativa
Driver1CurrentDailyDrivingTime
ISO 16844-7
VU
pessoais
N/A
consentimento do condutor
facultativa
Driver2CurrentDailyDrivingTime
ISO 16844-7
VU
N/A
pessoais
consentimento do ajudante
facultativa
Driver1CurrentWeeklyDrivingTime
ISO 16844-7
VU
pessoais
N/A
consentimento do condutor
facultativa
Driver2CurrentWeeklyDrivingTime
ISO 16844-7
VU
N/A
pessoais
consentimento do ajudante
facultativa
Driver1TimeLeftUntilNewDailyRestPeriod
ISO 16844-7
VU
pessoais
N/A
consentimento do condutor
facultativa
Driver2TimeLeftUntilNewDailyRestPeriod
ISO 16844-7
VU
N/A
pessoais
consentimento do ajudante
facultativa
Driver1CardExpiryDate
ISO 16844-7
Cartão de condutor
pessoais
N/A
consentimento do condutor
facultativa
Driver2CardExpiryDate
ISO 16844-7
Cartão de condutor
N/A
pessoais
consentimento do ajudante
facultativa
Driver1CardNextMandatoryDownloadDate
ISO 16844-7
VU
pessoais
N/A
consentimento do condutor
facultativa
Driver2CardNextMandatoryDownloadDate
ISO 16844-7
VU
N/A
pessoais
consentimento do ajudante
facultativa
TachographNextMandatoryDownloadDate
ISO 16844-7
VU
não pessoais
não pessoais
não é necessário o consentimento
facultativa
Driver1TimeLeftUntilNewWeeklyRestPeriod
ISO 16844-7
VU
pessoais
N/A
consentimento do condutor
facultativa
Driver2TimeLeftUntilNewWeeklyRestPeriod
ISO 16844-7
VU
N/A
pessoais
consentimento do ajudante
facultativa
Driver1NumberOfTimes9hDailyDrivingTimesExceeded
ISO 16844-7
VU
pessoais
N/A
consentimento do condutor
facultativa
Driver2NumberOfTimes9hDailyDrivingTimesExceeded
ISO 16844-7
VU
N/A
pessoais
consentimento do ajudante
facultativa
Driver1CumulativeUninterruptedRestTime
ISO 16844-7
VU
pessoais
N/A
consentimento do condutor
facultativa
Driver2CumulativeUninterruptedRestTime
ISO 16844-7
VU
N/A
pessoais
consentimento do ajudante
facultativa
Driver1MinimumDailyRest
ISO 16844-7
VU
pessoais
N/A
consentimento do condutor
facultativa
Driver2MinimumDailyRest
ISO 16844-7
VU
N/A
pessoais
consentimento do ajudante
facultativa
Driver1MinimumWeeklyRest
ISO 16844-7
VU
pessoais
N/A
consentimento do condutor
facultativa
Driver2MinimumWeeklyRest
ISO 16844-7
VU
N/A
pessoais
consentimento do ajudante
facultativa
Driver1MaximumDailyPeriod
ISO 16844-7
VU
pessoais
N/A
consentimento do condutor
facultativa
Driver2MaximumDailyPeriod
ISO 16844-7
VU
N/A
pessoais
consentimento do ajudante
facultativa
Driver1MaximumDailyDrivingTime
ISO 16844-7
VU
pessoais
N/A
consentimento do condutor
facultativa
Driver2MaximumDailyDrivingTime
ISO 16844-7
VU
N/A
pessoais
consentimento do ajudante
facultativa
Driver1NumberOfUsedReducedDailyRestPeriods
ISO 16844-7
VU
pessoais
N/A
consentimento do condutor
facultativa
Driver2NumberOfUsedReducedDailyRestPeriods
ISO 16844-7
VU
N/A
pessoais
consentimento do ajudante
facultativa
Driver1RemainingCurrentDrivingTime
ISO 16844-7
VU
pessoais
N/A
consentimento do condutor
facultativa
Driver2RemainingCurrentDrivingTime
ISO 16844-7
VU
N/A
pessoais
consentimento do ajudante
facultativa
VehiclePosition
Apêndice 8
VU
pessoais
pessoais
consentimento do condutor e do ajudante
obrigatória
ByDefaultLoadType
Apêndice 8
VU
pessoais
pessoais
consentimento do condutor e do ajudante
obrigatória
»;
(39)
O apêndice 14 é alterado do seguinte modo:
(a)
no índice, é inserido o seguinte ponto a seguir ao ponto 5.4.8:
«5.5
Reservado para utilização futura»;
(b)
no ponto 4.1.1.5, o parágrafo DCS_17 passa a ter a seguinte redação:
«DSC_17
Os dados de segurança (DSRCSecurityData), compreendendo os dados exigidos pelo REDCR para concluir a sua capacidade de decifrar os dados, são fornecidos conforme define o apêndice 11 «Mecanismos comuns de segurança», para memorização temporária na DSRC-VU como a versão atual de DSRCSecurityData, na forma definida na secção 5.4.4. do presente apêndice.»;
(c)
o ponto 5 é alterado do seguinte modo:
i)
no ponto 5.4.4, a sequência TachographPayload na definição do módulo ASN.1 para os dados DSRC na aplicação RTM, passa a ter a seguinte redação:
«
»;
ii)
no ponto 5.4.5, o quadro 14.3 passa a ter a seguinte redação:
«
Quadro 14.3
Elementos de RtmData, ações realizadas e definições
(1)
Elemento de dados RTM
(2)
Ação realizada pela VU
(3)
Definição de dados ASN.1
RTM1
Placa de matrícula
do veículo
A VU define o valor do elemento de dados RTM1 tp15638VehicleRegistrationPlate a partir do valor registado do tipo de dados
VehicleRegistrationIdentification como definido no apêndice 1 VehicleRegistrationIdentification
Placa de matrícula do veículo expressa numa sequência de carateres
tp15638VehicleRegistrationPlate LPN, --Placa de matrícula
do veículo utilizando a estrutura de dados da ISO 14906, mas com a seguinte limitação para a aplicação RTM:
a SEQUÊNCIA começa com o código do país, seguido de um indicador alfabético, seguido do próprio número da placa,
que é sempre de 14 octetos (preenchida com zeros), de forma que o comprimento do tipo de LPN seja sempre de 17 octetos (não é necessária determinante de comprimento), dos quais 14 correspondem ao número «real» da placa.
RTM2
Incidente de velocidade
A VU gera um valor
booleano para o elemento de dados RTM2
tp15638SpeedingEvent.
O valor de tp15638SpeedingEvent é calculado pela VU a partir dos incidentes de excesso de velocidade registados na VU nos últimos 10 dias, conforme definido no anexo IC.
1 (TRUE): se o incidente de excesso de velocidade mais recente tiver terminado nos últimos 10 dias ou continuar a verificar-se;
0 (FALSE): em qualquer outro caso.
tp15638SpeedingEvent BOOLEAN,
RTM3
Condução sem
cartão válido
A VU gera um valor
booleano para o elemento de dados RTM3
tp15638DrivingWithoutValidCard.
A VU atribui um valor TRUE à variável tp15638DrivingWithoutValidCard se pelo menos um incidente de condução sem um cartão apropriado tiver sido registado na VU nos últimos 10 dias, conforme definido no anexo IC.
1 (TRUE): se o incidente de condução mais recente sem um cartão apropriado tiver terminado nos últimos 10 dias ou continuar a verificar-se;
0 (FALSE): em qualquer outro caso.
tp15638DrivingWithoutValidCard
BOOLEAN,
RTM4
Cartão de condutor válido
A VU gera um valor booleano para o elemento de dados RTM4
tp15638DriverCard com base no cartão de condutor válido inserido na ranhura do condutor.
1 (TRUE): se não estiver presente nenhum cartão de condutor válido na ranhura do condutor da VU;
0 (FALSE): se estiver presente um cartão de condutor válido na ranhura do condutor da VU;
tp15638DriverCard BOOLEAN,
RTM5
Inserção do cartão durante
a condução
A VU gera um valor booleano para o elemento de dados RTM5 tp15638CardInsertion.
A VU atribui um valor TRUE à variável tp15638CardInsertion se pelo menos um incidente de inserção de cartão durante a condução tiver sido registado na VU nos últimos 10 dias, conforme definido no anexo IC.
1 (TRUE): se o incidente mais recente de inserção de cartão durante a condução tiver ocorrido nos últimos 10 dias;
0 (FALSE): em qualquer outro caso.
tp15638CardInsertion BOOLEAN,
RTM6
Erro nos dados de movimento
A VU gera um valor
booleano para o elemento de dados RTM6
A VU atribui um valor TRUE à variável tp15638MotionDataError se pelo menos um incidente de inserção de erro nos dados de movimento tiver sido registado na VU nos últimos 10 dias, conforme definido no anexo IC.
1 (TRUE): se o incidente mais recente de erro nos dados de movimento tiver terminado nos últimos 10 dias ou continuar a verificar-se;
0 (FALSE): em qualquer outro caso.
tp15638MotionDataError BOOLEAN,
RTM7
Conflito relativo ao
movimento do veículo
A VU gera um valor
booleano para o elemento de dados RTM7
A VU atribui um valor TRUE à variável tp15638VehicleMotionConflict se pelo menos um incidente de conflito relativo ao movimento do veículo tiver sido registado na VU nos últimos 10 dias.
1 (TRUE): se o incidente mais recente de conflito relativo ao movimento do veículo tiver terminado nos últimos 10 dias ou continuar a verificar-se;
0 (FALSE): em qualquer outro caso.
tp15638VehicleMotionConflict
BOOLEAN,
RTM8
2.o cartão de condutor
A VU gera um valor
booleano para o elemento de dados RTM8 com base no anexo IC (Driver Activity Data CREW e CO-DRIVER).
Se um cartão de ajudante válido estiver presente, a VU fixa o valor de RTM8 em TRUE.
1 (TRUE): se um cartão de ajudante válido estiver presente na VU
2 (FALSE): se não estiver presente na VU nenhum cartão de ajudante válido.
tp156382ndDriverCard BOOLEAN,
RTM9
Atividade em curso
A VU gera um valor
booleano para o elemento de dados RTM9
Se a atividade em curso for registada na VU como qualquer uma atividade diferente de «DRIVING», conforme definido no anexo IC, a VU fixa a variável em TRUE.
1 (TRUE): outra atividade
selecionada;
0 (FALSE): condução selecionada
tp15638CurrentActivityDriving
BOOLEAN
RTM10
Última sessão encerrada
A VU gera um valor booleano para o elemento de dados RTM10.
Se a última sessão do cartão não tiver sido corretamente encerrada, conforme definido no anexo IC, a VU fixa o valor de RTM10 em TRUE.
1 (TRUE): pelo menos um dos cartões inseridos acionou um incidente «última sessão do cartão encerrada incorretamente»;
0 (FALSE): nenhum dos cartões inseridos acionou um incidente «última sessão do cartão encerrada incorretamente».
tp15638LastSessionClosed
BOOLEAN
RTM11
Alimentação energética,
Interrupção
A VU gera um valor
booleano para o elemento de dados RTM11
A VU atribui um valor para a variável tp15638PowerSupplyInterruption igual ao número de incidentes de interrupção da alimentação energética memorizados na VU nos últimos 10 dias, conforme definido no anexo IC.
Se não tiver sido registado nenhum incidente de interrupção da alimentação energética na VU nos últimos 10 dias, esta fixa o valor de RTM11 em 0.
Número de incidentes de interrupção da alimentação energética registados nos últimos 10 dias.
tp15638PowerSupplyInterruption
INTEGER (0..127),
RTM12
Falha do sensor
A VU gera um valor inteiro para o elemento de dados RTM12.
A VU atribui à variável sensorFault um valor de:
—
1 se um incidente do tipo ‘35’ H falha do
sensor tiver terminado durante os últimos 10 dias ou continuar a verificar-se.
—
2 se um incidente do tipo falha do recetor GNSS (interno ou externo com valores de enumeração ‘36’H ou
‘37’H) tiver terminado durante os últimos 10 dias ou continuar a verificar-se.
—
3 se um incidente do tipo '0E'H Erro de comunicação com incidente do módulo GNSS externo tiver terminado durante os últimos 10 dias ou continuar a verificar-se.
—
4 Se as falhas do sensor e do recetor GNSS tiverem terminado durante os últimos 10 dias ou continuarem a verificar-se.
—
5 Se a falha do sensor e o erro de comunicação com o incidente do módulo GNSS externo tiverem terminado durante os últimos 10 dias ou continuarem a verificar-se.
—
6 Se a falha do recetor GNSS e o erro de comunicação com o incidente do módulo GNSS externo tiverem terminado durante os últimos 10 dias ou continuarem a verificar-se.
—
7 Se as três falhas do sensor tiverem terminado durante os últimos 10 dias ou continuarem a verificar-se.
Se nenhum incidente tiver terminado durante os últimos 10 dias ou continuar a verificar-se, a VU deve fixar o valor de RTM12 em 0.
- falha do sensor um octeto de acordo com o dicionário de dados
tp15638SensorFault INTEGER (0..255),
RTM13
Ajustamento do tempo
A VU gera um valor inteiro (timeReal do apêndice 1) para o elemento de dados RTM13 com base na presença de dados de ajustamento do tempo, conforme definido no anexo IC.
A VU deve fixar o valor de RTM13 na hora em que ocorreu o último incidente de dados de ajustamento.
Se nenhum incidente de ajustamento do tempo, conforme definido no anexo IC, estiver presente nos dados da VU, esta fixa o valor de RTM13 em 0.
oldTimeValue do mais recente ajustamento do tempo
tp15638TimeAdjustment
INTEGER(0..4294967295),
RTM14
Tentativa de violação da
segurança
A VU gera um valor inteiro (timeReal do apêndice 1) para o elemento de dados RTM14 com base na presença de dados de ajustamento do tempo, conforme definido no anexo IC.
A VU define o valor da hora da tentativa mais recente de violação da segurança registada pela VU.
Se nenhum incidente de tentativa de violação da segurança, conforme definido no anexo IC, estiver presente nos dados da VU, esta fixa o valor de RTM14 em 0.
Hora de início do incidente mais recente de tentativa de violação da segurança.
tp15638LatestBreachAttempt
INTEGER(0..4294967295),
RTM15
Última calibração
A VU gera um valor inteiro (timeReal do apêndice 1) para o elemento de dados RTM15 com base na presença de dados de ajustamento do tempo, conforme definido no anexo IC.
A VU fixa o valor de
RTM15 no oldTimeValue do mais recente registo da calibração.
Se não tiver havido calibração, a VU fixa o valor de RTM15 em 0.
oldTimeValue do mais recente registo da calibração.
tp15638LastCalibrationData
INTEGER(0..4294967295),
RTM16
Calibração anterior
A VU gera um valor inteiro (timeReal do apêndice 1) para o elemento de dados RTM16 com base no registo da calibração anterior à última calibração.
A VU fixa o valor de
RTM16 no oldTimeValue do registo de calibração anterior à última calibração.
Se não tiver havido calibração anterior, a VU fixa o valor de RTM16 em 0.
oldTimeValue do registo da calibração anterior ao registo da calibração mais recente.
tp15638PrevCalibrationData
INTEGER(0..4294967295),
RTM17
Data de ligação do
tacógrafo
A VU gera um valor inteiro (timeReal do apêndice 1) para o elemento de dados RTM17.
A VU fixa o valor de RTM17 na data da primeira calibração da VU no veículo atual.
A VU extrai estes dados de VuCalibrationData (apêndice 1) dos vuCalibrationRecords com CalibrationPurpose igual a: ‘03’H
Se não tiver havido calibração anterior, a VU fixa o valor de RTM17 em 0.
Data da primeira calibração da VU no veículo atual.
tp15638DateTachoConnected
INTEGER(0..4294967295),
RTM18
Velocidade atual:
A VU gera um valor
booleano para o elemento de dados RTM18
A VU fixa o valor de RTM18 na última velocidade atual registada no momento da atualização mais recente de RtmData.
Última atualização atual registada
tp15638CurrentSpeed INTEGER (0..255),
RTM19
Selo temporal
A VU gera um valor inteiro para o elemento de dados RTM19 (timeReal do apêndice 1)..
A VU fixa o valor de RTM19 no momento da atualização mais recente de RtmData.
Selo temporal do registo
TachographPayload atual
tp15638Timestamp
INTEGER(0..4294967295),
RTM20
Hora em que a mais recente posição autenticada do veículo ficou disponível
A VU gera um valor inteiro (timeReal do apêndice 1) para o elemento de dados RTM20.
A VU fixa o valor de RTM20 na hora em que a mais recente posição autenticada do veículo ficou disponível a partir do recetor GNSS.
Se nunca tiver estado disponível uma posição autenticada do veículo a partir do recetor GNSS, a VU fixa o valor de RTM20 em 0.
Selo temporal da mais recente posição autenticada do veículo
tp15638LatestAuthenticatedPosition
INTEGER(0..4294967295),
RTM21
Tempo de condução contínuo
A VU gera um valor inteiro para o elemento de dados RTM21.
A VU fixa o valor de RTM21 no tempo de condução contínuo do condutor em curso.
Tempo de condução contínua do condutor, codificado como um valor inteiro.
Comprimento: 1 byte
Resolução: 2 minutos/bit
Sem deslocamento
Intervalo de dados: 0 a 250
Um valor de 250 indica que o tempo de condução contínua do condutor é igual ou superior a 500 minutos.
Os valores 251 a 254 não são utilizados.
O valor 255 indica que a informação não está disponível.
tp15638ContinuousDrivingTime INTEGER(0..255),
RTM22
Tempo diário de condução mais longo para o turno RTM em curso e anterior, calculado de acordo com a adenda ao apêndice 14.
A VU gera um valor inteiro para o elemento de dados RTM22.
A VU fixa o valor de RTM22 no mais longo dos dois tempos diários de condução do condutor, que é o turno RTM em curso ou o anterior.
Tempo diário de condução do condutor, codificado como um valor inteiro.
Comprimento: 1 byte
Resolução: 4 minutos/bit
Sem deslocamento
Intervalo de dados: 0 a 250
Um valor de 250 indica que o tempo diário de condução do condutor é igual ou superior a 1 000 minutos.
Os valores 251 a 254 não são utilizados.
O valor 255 indica que a informação não está disponível.
tp15638DailyDrivingTimeShift INTEGER(0..255),
RTM23
Tempo diário de condução mais longo para o turno RTM em curso e anterior, calculado de acordo com a adenda ao apêndice 14.
A VU gera um valor inteiro para o elemento de dados RTM23.
A VU fixa o valor de RTM23 no tempo diário de condução mais longo do condutor, que é o turno RTM em curso ou qualquer turno concluído com início ou fim na semana em curso.
Tempo diário de condução do condutor, codificado como um valor inteiro.
Comprimento: 1 byte
Resolução: 4 minutos/bit
Sem deslocamento
Intervalo de dados: 0 a 250
Um valor de 250 indica que o tempo diário de condução do condutor é igual ou superior a 1 000 minutos.
Os valores 251 a 254 não são utilizados.
O valor 255 indica que a informação não está disponível.
tp15638DailyDrivingTimeWeek INTEGER(0..255),
RTM24
Tempo semanal de condução, calculado de acordo com a adenda ao apêndice 14
A VU gera um valor inteiro para o elemento de dados RTM24.
A VU fixa o valor de RTM24 no tempo semanal de condução do condutor.
Tempo semanal de condução do condutor, codificado como um valor inteiro.
Comprimento: 1 byte
Resolução: 20 minutos/bit
Sem deslocamento
Intervalo de dados: 0 a 250
Um valor de 250 indica que o tempo semanal de condução do condutor é igual ou superior a 5 000 minutos.
Os valores 251 a 254 não são utilizados.
O valor 255 indica que a informação não está disponível.
tp15638WeeklyDrivingTime INTEGER(0..255),
RTM25
Tempo quinzenal de condução mais longo, calculado de acordo com a adenda ao apêndice 14.
A VU gera um valor inteiro para o elemento de dados RTM25.
A VU fixa o valor de RTM25 no tempo quinzenal de condução do condutor.
Tempo quinzenal de condução do condutor, codificado como um valor inteiro.
Comprimento: 1 byte
Resolução: 30 minutos/bit
Sem deslocamento
Intervalo de dados: 0 a 250
Um valor de 250 indica que o tempo quinzenal de condução do condutor é igual ou superior a 7 500 minutos.
Os valores 251 a 254 não são utilizados.
O valor 255 indica que a informação não está disponível.
tp15638FortnightlyDrivingTime INTEGER(0..255),
Nota: RTM22, RTM23, RTM24 e RTM25 são calculados de acordo com a adenda ao presente apêndice»;
iii)
no ponto 5.4.7, o quadro 14.9 passa a ter a seguinte redação:
«Quadro 14.9
Inicialização — exemplo de conteúdos da estrutura VST
n.o de octetos
Atributo/campo
Bits no octeto
Descrição
1
FLAG
0111 1110
Início do indicador
2
Private LID
xxxx xxxx
Endereço de ligação da DSRC-VU específica
3
xxxx xxxx
4
xxxx xxxx
5
xxxx xxxx
6
MAC Control field
1100 0000
PDU de comando
7
LLC Control field
0000 0011
Comando da IU
8
Fragmentation header
1xxx x001
Sem fragmentação
9
VST
SEQUENCE {
Fill BIT STRING (SIZE(4))
1001
Resposta de inicialização
0000
Não utilizada e fixada em 0
10
Profile INTEGER (0..127,...)
Aplicações SEQUÊNCIA DE {
0000 0000
Sem extensão. Exemplo de perfil 0
Sem extensão, 1 aplicação
11
0000 0001
12
SEQUENCE {
OPTION indicator
OPTION indicator
AID DSRCApplicationEntityID
1
EID presente
1
Parâmetro presente
00 0010
Sem extensão. AID= 2 Carga e frota
13
EID Dsrc-EID
xxxx xxxx
Definido na OBU e identificando a instância de aplicação.
14
Parameter Container {
0000 0010
Sem extensão, Escolha de contentor = 02,
Cadeia de octetos
15
0000 0110
Sem extensão, Comprimento da marca de contexto Rtm = 6
16
Rtm-ContextMark ::= SEQUENCE {
StandardIdentifier
0000 0101
O primeiro octeto é 05H, o seu comprimento.
Os 5 octetos subsequentes codificam o identificador de objeto da norma seguida (parte e versão).
{Norma ISO (1) (0) TARV (15638) parte 9(9) Versão 2 (2)}
17
standardIdentifier
0010 1000
18
1111 1010
19
0001 0110
20
0000 1001
21
0000 0010
22
ObeConfiguration Sequence {
OPTION indicator
0
ObeStatus não presente
EquipmentClass INTEGER (0..32767)
xxx xxxx
Este campo é utilizado para ostentar
23
xxxx xxxx
as indicações do fabricante relativas à versão de software/hardware da interface DSRC
24
ManufacturerId INTEGER (0..65535)
xxxx xxxx
Identificador do fabricante da DSRC-VU conforme descrito no registo ISO 14816
25
xxxx xxxx
26
FCS
xxxx xxxx
Sequência de controlo de trama
27
xxxx xxxx
28
Flag
0111 1110
Indicador de fecho
»;
iv)
é inserido o ponto 5.5 com a seguinte redação:
«5.5
Reservado para utilização futura»;
v)
no ponto 5.7, os parágrafos DSC_77 e DSC_78 passam 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 incidente do módulo de comunicação à distância juntamente com o selo temporal. O VUSM verifica se os dados foram transmitidos com sucesso à DSRC-VU.
DSC_78
Reservado para utilização futura.»;
(d)
é aditada a seguinte adenda:
«ADENDA
Regras para o cálculo do tempo diário, semanal e quinzenal de condução
1.
Regras de cálculo básicas
A VU deve calcular o tempo diário de condução, o tempo semanal de condução e o tempo quinzenal de condução utilizando dados relevantes memorizados num cartão de condutor (ou de oficina) inserido na ranhura do condutor (ranhura 1, leitor de cartão n.o 1) da unidade-veículo, bem como as atividades do condutor selecionadas enquanto este cartão está inserido na VU.
Os tempos de condução não são calculados sem o cartão de condutor (ou de oficina) estar inserido.
O(s) período(s) DESCONHECIDO(S) surgido(s) durante o período de tempo necessário para os cálculos é(são) integrado(s) em PAUSA/REPOUSO.
Os períodos DESCONHECIDOS e as atividades de duração negativa (ou seja, o início da atividade ocorre mais tarde do que o final da atividade), devido a sobreposições de tempo entre duas VU diferentes ou devido a ajustamento do tempo, não são tidos em consideração.
As atividades registadas no cartão de condutor correspondentes a períodos «FORA DE ÂMBITO», de acordo com a definição gg) do anexo IC, devem ser interpretadas da seguinte forma:
—
PAUSA/REPOUSO deve ser calculado como «PAUSA» ou «REPOUSO»
—
TRABALHO e CONDUÇÃO devem ser considerados como «TRABALHO»
—
DISPONIBILIDADE deve ser considerada como «DISPONIBILIDADE»
No âmbito desta adenda, a VU assume um período de repouso diário no início dos registos de atividades do cartão.
2.
Conceitos
Os conceitos seguintes aplicam-se exclusivamente ao presente apêndice e destinam-se a especificar o cálculo dos tempos de condução pela VU e a sua ulterior transmissão pelo sistema de comunicação à distância.
a)
«Turno RTM» é o período entre o final de um período de descanso diário e o final do período de descanso diário imediatamente seguinte.
A VU inicia um novo turno RTM após o termo de um período de descanso diário.
O turno RTM em curso é o período desde o final do último período de descanso diário;
b)
«tempo de condução acumulado»: soma da duração de todas as atividades de CONDUÇÃO do condutor durante um período quando não em FORA DE ÂMBITO;
c)
«tempo diário de condução»: tempo de condução acumulado num turno RTM;
d)
«tempo semanal de condução»: tempo de condução acumulado na semana em curso;
e)
«período de repouso contínuo»: qualquer período ininterrupto de PAUSA/REPOUSO;
f)
«tempo quinzenal de condução»: o tempo de condução acumulado na semana anterior e na semana em curso;
g)
«período de repouso diário»: um período de PAUSA/REPOUSO, que pode ser
—
um período regular de repouso diário,
—
um período de repouso diário dividido ou
—
um período de repouso diário reduzido
No contexto do apêndice 14, quando uma VU calcula os períodos de repouso semanais, esses períodos de repouso semanais são considerados períodos de repouso diários;
h)
«período de repouso diário regular»: período de repouso contínuo de, pelo menos, 11 horas.
A título de exceção, quando uma condição TRAVESSIA DE BATELÃO/COMBOIO está ativa, o período de repouso diário regular pode ser interrompido no máximo duas vezes por atividades que não sejam o repouso, com uma duração acumulada máxima de uma hora, ou seja, o período de repouso diário regular contendo o(s) período(s) de travessia de batelão/comboio podem ser divididos em duas ou três partes. A VU calcula então um período de repouso diário regular quando o tempo de repouso acumulado calculado de acordo com o ponto 3 for de, pelo menos, 11 horas.
Quando um período de repouso diário regular tiver sido interrompido, a VU:
—
não deve incorporar a atividade de condução encontrada durante essas interrupções para o cálculo do tempo diário de condução, e
—
inicia um novo turno RTM no final do período de repouso diário que foi interrompido.
i)
«período de repouso diário reduzido»: período de repouso contínuo de, pelo menos, 9 horas, mas menos de 11 horas;
j)
«período de repouso diário dividido»: um período de repouso diário dividido em duas partes:
—
a primeira parte é um período de repouso contínuo de, pelo menos, 3 horas, mas menos de 9,
—
a segunda parte é um período de repouso contínuo de, pelo menos, 9 horas.
A título de exceção, quando uma condição TRAVESSIA DE BATELÃO/COMBOIO está ativa durante uma ou ambas as partes de um período de repouso diário dividido, o período de repouso diário dividido pode ser interrompido no máximo duas vezes por outras atividades com a duração acumulada máxima de uma hora, ou seja:
—
a primeira parte do período de repouso diário dividido pode ser interrompida uma ou duas vezes, ou
—
a segunda parte do período de repouso diário dividido pode ser interrompida uma ou duas vezes, ou
—
a primeira parte do período de repouso diário dividido pode ser interrompida uma vez e a segunda parte do período de repouso diário dividido pode ser interrompida uma vez.
A VU calcula então um período de repouso diário regular quando o tempo de repouso acumulado calculado de acordo com o ponto 3 for:
—
de, pelo menos, três horas, mas menos de 11 horas, para o primeiro período de repouso e de, pelo menos, 9 horas para o segundo período de repouso, quando o primeiro período de repouso tiver sido interrompido por TRAVESSIA DE BATELÃO/COMBOIO.
—
de, pelo menos, três horas, mas menos de 9 horas, para o primeiro período de repouso e de, pelo menos, 9 horas para o segundo período de repouso, quando o primeiro período de repouso tiver sido interrompido por TRAVESSIA DE BATELÃO/COMBOIO.
Quando o período de repouso diário dividido é interrompido, a VU:
—
não deve incorporar a atividade de condução encontrada durante essas interrupções para o cálculo do tempo diário de condução, e
—
inicia um novo turno RTM no final do período de repouso diário dividido que foi interrompido;
k)
«semana» é o período em hora UTC entre as 00.00 horas de segunda-feira e as 24.00 horas de domingo;
3.
Cálculo do período de repouso quando foi interrompido devido a travessia de batelão/comboio
Para o cálculo do período de repouso quando este for interrompido devido a travessia de batelão/comboio, a VU deve calcular o tempo de repouso acumulado de acordo com as seguintes etapas:
a)
Etapa 1
A VU deteta interrupções do tempo de repouso ocorridas antes da ativação do indicador TRAVESSIA DE BATELÃO/COMBOIO (INÍCIO), de acordo com a figura 3 e, se for o caso, a figura 4, e avalia para cada interrupção detetada se as seguintes condições foram cumpridas:
—
a interrupção faz com que a duração total das interrupções detetadas, incluindo, se for caso disso, as interrupções ocorridas durante a primeira parte de um período de repouso diário dividido devido a travessia de batelão/comboio, exceda mais de uma hora no total,
—
a interrupção faz com que a duração total das interrupções detetadas, incluindo, se for caso disso, as interrupções ocorridas durante a primeira parte de um período de repouso diário dividido devido a travessia de batelão/comboio, seja superior a duas,
—
há uma «Introdução do local onde os períodos de trabalho diários terminam» memorizado após o termo da interrupção.
Se nenhuma das condições anteriores for satisfeita, o período de repouso contínuo que precede imediatamente a interrupção é adicionado ao tempo de repouso acumulado.
Se, pelo menos, uma das condições acima for satisfeita, a VU deve interromper o cálculo do tempo de repouso acumulado de acordo com a etapa 2 ou detetar interrupções no tempo de repouso ocorridas após o indicador TRAVESSIA DE BATELÃO/COMBOIO (INÍCIO) de acordo com a etapa 3.
b)
Etapa 2
Para cada interrupção detetada de acordo com a etapa 1, a VU avalia se o cálculo do tempo de repouso acumulado deve terminar. A VU interrompe o processo de cálculo quando dois períodos de repouso contínuos, que ocorram antes da ativação do indicador TRAVESSIA DE BATELÃO/COMBOIO (INÍCIO), foram adicionados ao tempo de repouso acumulado, incluindo, se for caso disso, os períodos de repouso adicionados na primeira parte de um período de repouso diário dividido também interrompido por travessia de batelão/comboio. Caso contrário, a VU deve prosseguir de acordo com a etapa 3.
c)
Etapa 3
Se após a execução da etapa 2 a VU continuar a calcular o tempo de repouso acumulado, a VU deteta interrupções ocorridas após a desativação da condição TRAVESSIA DE BATELÃO/COMBOIO, de acordo com a figura 3 e, se for caso disso, a figura 4.
Para cada interrupção encontrada, a VU avalia se a interrupção faz com que o tempo acumulado de todas as interrupções detetadas exceda mais de uma hora no total, caso em que o cálculo do período de repouso acumulado deve terminar no final do período de repouso contínuo anterior à interrupção. Caso contrário, os períodos de repouso contínuos ocorridos após as respetivas interrupções devem ser adicionados ao cálculo do período de repouso diário até que a condição na etapa 4 seja satisfeita.
d)
Etapa 4
O cálculo do tempo de repouso acumulado deve terminar quando a VU tiver adicionado, em resultado das etapas 1 e 3, um máximo de dois períodos de repouso contínuos ao período de repouso para o qual a condição TRAVESSIA DE BATELÃO/COMBOIO é ativada, incluindo, se for caso disso, interrupções ocorridas durante a primeira parte de um período de repouso diário dividido devido a travessia de batelão/comboio.
4.
Cálculo dos tempos diários, semanais e quinzenais de condução
A VU deve calcular o(s) tempo(s) diário(s) de condução para os turnos RTM anterior e em curso. O tempo de condução ocorrido durante as interrupções dos períodos de repouso diário não é adicionado ao cálculo do tempo diário de condução, quando tais interrupções se devam a travessia de batelão/comboio e os requisitos previstos nas alíneas h) e j) do ponto 2 e o ponto 3 forem cumpridos. No entanto, na medida em que a VU não tenha calculado um período de repouso diário regular ou dividido completo de acordo com o ponto 3, os tempos de condução ocorridos durante as interrupções são adicionados ao tempo diário de condução para o turno RTM em curso.
A VU também calcula os tempos semanais e quinzenais de condução. O tempo de condução ocorrido durante as interrupções dos períodos de repouso diário devido àa travessia de batelão/comboio é adicionado ao cálculo dos tempos semanais e quinzenais de condução.
»;
(40)
O apêndice 15 é alterado do seguinte modo:
(a)
o título passa a ter a seguinte redação:
«Apêndice 15
MIGRAÇÃO: GESTÃO DA COEXISTÊNCIA DE GERAÇÕES E VERSÕES DE APARELHOS
»;
(b)
O índice é alterado do seguinte modo:
i)
o ponto 2.2 passa a ter a seguinte redação:
«2.2.
Interoperabilidade entre VU e cartões»;
ii)
é aditado o seguinte ponto 5:
«5.
REGISTO DE TRAVESSIAS DE FRONTEIRAS NOS TACÓGRAFOS DA PRIMEIRA GERAÇÃO E DA PRIMEIRA VERSÃO DA SEGUNDA GERAÇÃO»;
(c)
os pontos 2 a 4 passam a ter a seguinte redação:
«2.
DISPOSIÇÕES GERAIS
2.1.
Síntese da transição
A introdução do presente anexo apresenta uma síntese da transição entre os sistemas tacográficos da primeira e da segunda gerações e da introdução da segunda versão dos aparelhos de controlo e dos cartões tacográficos da segunda geração.
Além das disposições desta introdução, convém ter em conta as seguintes informações:
—
os sensores de movimentos da primeira geração não são interoperáveis com nenhuma versão das unidades-veículo da segunda geração,
—
apenas podem ser instalados sensores de movimentos da segunda geração em veículos equipados com qualquer versão de unidades-veículo da segunda geração,
—
o equipamento de descarregamento de dados e de calibração tem de aceitar a utilização de ambas as gerações ou versões dos aparelhos de controlo e dos cartões tacográficos.
2.2.
Interoperabilidade entre VU e cartões
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] e qualquer versão dos cartões tacográficos da segunda geração é interoperável com qualquer versão das unidades-veículo da segunda geração (em conformidade com o anexo IC do presente regulamento). Aplicam-se, além disso, os requisitos infra.
MIG_001
Salvo o disposto nos requisitos MIG_004 e MIG_005, os cartões tacográficos da primeira geração podem continuar a ser utilizados em qualquer versão das unidades-veículo da segunda geração até ao termo da sua validade. Porém, os titulares dos cartões podem pedir a sua substituição por cartões tacográficos da segunda geração, logo que disponíveis.
MIG_002
As unidades-veículo da segunda geração devem poder utilizar qualquer cartão válido da primeira geração inserido de condutor, de controlo ou de empresa.
MIG_003
Esta funcionalidade pode ser suprimida definitivamente nessas unidades-veículo pelas oficinas, de modo que os cartões tacográficos da primeira geração deixem de ser aceites. Tal só pode ser efetuado depois de a Comissão Europeia lançar um procedimento com o objetivo de solicitar às oficinas que o façam, por exemplo, durante cada inspeção periódica do tacógrafo.
MIG_004
Nas unidades-veículo da segunda geração só é possível utilizar cartões de oficina da segunda geração.
MIG_005
Para determinar o modo de funcionamento, qualquer versão das unidades-veículo da segunda geração atende apenas ao tipo dos cartões válidos inseridos, independentemente da geração ou versão a que correspondam.
MIG_006
Qualquer versão dos cartões tacográficos válidos da segunda geração deve poder ser utilizada em unidades-veículo da primeira geração, exatamente como os cartões tacográficos da primeira geração do mesmo tipo.
2.3.
Interoperabilidade entre VU e MS
Entende-se que os sensores de movimentos da primeira geração são interoperáveis com as unidades-veículo da primeira geração, ao passo que os sensores de movimentos da segunda geração são interoperáveis com qualquer versão das unidades-veículo da segunda geração. Aplicam-se, além disso, os requisitos infra.
MIG_007
Não é possível emparelhar nem utilizar qualquer versão das unidades-veículo da segunda geração com sensores de movimentos da primeira geração.
MIG_008
Os sensores de movimentos da segunda geração só podem ser emparelhados e utilizados com unidades-veículo da segunda geração, seja qual for a versão, ou com unidades-veículo de ambas as gerações.
2.4.
Interoperabilidade entre unidades-veículo, cartões tacográficos e equipamento de descarregamento de dados
MIG_009
O equipamento de descarregamento de dados pode ser compatível com unidades-veículo e cartões tacográficos de todas as gerações e versões.
2.4.1
Descarregamento direto do cartão pelo IDE
MIG_010
Os dados são descarregados pelo IDE a partir de cartões tacográficos de uma dada geração inseridos nos seus leitores de cartões, utilizando os mecanismos de segurança e o protocolo de descarregamento de dados dessa geração, sendo que os dados descarregados terão o formato definido para esta geração e versão.
MIG_011
Para permitir o controlo de condutores por autoridades não pertencentes à UE, é também possível descarregar cartões de condutor (e de oficina) da segunda geração, exatamente do mesmo modo que os cartões de condutor (e de oficina) da primeira geração. Esse descarregamento inclui:
—
cartões inteligentes e cartões com circuito integrado EF não assinados (facultativos),
—
Card_Certificate e CA_Certificate (primeira geração) EF não assinados,
—
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 na versão 1 ou na versão 2 dos cartões de condutor (e de oficina) da segunda geração (EF de dados da aplicação dentro do DF Tachograph_G2).
2.4.2
Descarregamento do cartão através de uma unidade-veículo
MIG_012
Os dados são descarregados de qualquer versão de um cartão da segunda geração inserido numa unidade-veículo da primeira geração que utiliza o protocolo de descarregamento de dados da primeira geração. O cartão responde aos comandos da unidade-veículo exatamente do mesmo modo que um cartão da primeira geração, e os dados descarregados têm o mesmo formato que os dados descarregados de um cartão da primeira geração.
MIG_013
Os dados são descarregados de um cartão da primeira geração inserido em qualquer versão de uma unidade-veículo da segunda geração que utiliza o protocolo de descarregamento de dados definido no apêndice 7 do presente anexo. A unidade-veículo envia comandos ao cartão exatamente do mesmo modo que uma unidade-veículo da primeira geração, e os dados descarregados devem respeitar o formato definido para cartões da primeira geração.
2.4.3
Descarregamento da unidade-veículo
MIG_014
Fora do quadro de 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 para a versão em causa.
MIG_015
Para permitir o controlo dos condutores por autoridades não pertencentes à UE, poderá ainda ser igualmente possível descarregar dados de qualquer versão das 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.
2.5.
Interoperabilidade entre VU e aparelhos de calibração
MIG_016
Os aparelhos de calibração devem poder executar a calibração de uma dada geração ou versão de tacógrafo, utilizando o protocolo de calibração dessa geração ou versão. Os aparelhos de calibração podem ser compatíveis com todas as gerações e versões de unidades-veículo.
3.
PRINCIPAIS ETAPAS DURANTE O PERÍODO ANTERIOR À DATA DE PRODUÇÃO
MIG_017
Os certificados e chaves de ensaio devem ser disponibilizados na data de publicação do presente anexo.
MIG_018
Os ensaios de interoperabilidade devem estar prontos a ter início com a versão 2 das unidades-veículo e a versão 2 dos cartões tacográficos, se solicitados pelos fabricantes, 15 meses (pelo menos) antes da data de produção.
MIG_019
Para a versão 2 dos tacógrafos, cartões tacográficos e sensores de movimentos da segunda geração, são utilizadas as mesmas chaves e os mesmos certificados que são utilizados para a versão 1 do equipamento da segunda geração.
MIG_020
Os Estados-Membros devem poder emitir a versão 2 dos cartões de oficina da segunda geração 1 mês (pelo menos) antes da data de produção.
MIG_021
Os Estados-Membros devem poder emitir todos os tipos de cartões tacográficos, na sua versão 2, da segunda geração 1 mês (pelo menos) antes da data de produção.
4.
DISPOSIÇÕES PARA O PERÍODO APÓS A DATA DE PRODUÇÃO
MIG_022
Com efeitos a partir da data de produção, os Estados-Membros emitirão apenas a versão 2 dos cartões tacográficos da segunda geração.
MIG_023
Os fabricantes de unidades-veículo ou de sensores de movimentos poderão produzir unidades-veículo ou sensores de movimentos da primeira geração enquanto este equipamento for utilizado no terreno, de modo a que os componentes com defeito possam ser substituídos.
MIG_023a
Com efeitos a partir da data de produção, a versão 1 com defeito das unidades-veículo ou dos módulos GNSS da segunda geração podem devem ser substituídos pela versão 2 das unidades-veículo ou dos módulos GNSS da segunda geração.
MIG_024
Os fabricantes de unidades-veículo ou de sensores de movimentos poderão solicitar e obter a manutenção da homologação de tipos já homologados de unidades-veículo ou de sensores de movimentos da primeira geração ou da versão 1 das unidades-veículo da segunda geração»;
(d)
é aditado o seguinte ponto 5:
«5.
REGISTO DE TRAVESSIAS DE FRONTEIRAS NOS TACÓGRAFOS DA PRIMEIRA GERAÇÃO E DA PRIMEIRA VERSÃO DA SEGUNDA GERAÇÃO
MIG_025
O símbolo do país e, se aplicável, da região em que o condutor entra depois de atravessar a fronteira de um Estado-Membro em aplicação do artigo 34.o, n.o 7, do Regulamento (UE) n.o 165/2014, devem ser introduzidos como lugar no qual termina o período diário de trabalho de acordo com a introdução manual do lugar, estabelecida nos requisitos 60 do anexo IC do Regulamento (UE) n.o 165/2014 e no requisito 50 do anexo IB do Regulamento (CEE) n.o 3821/85»;
(41)
no apêndice 16, o ponto ADA_012 passa a ter a seguinte redação:
«ADA_012
Se for caso disso, a interface dos dados do adaptador deve poder multiplicar ou dividir os impulsos de frequência de entrada da velocidade por um fator fixo, para adaptar o sinal a um valor na gama do fator k definida pelo presente anexo (2 400 a 25 000 impulsos/km). Esse fator fixo só pode ser programado pelo fabricante do adaptador e pela oficina homologada que o instala.»
(1) Regulamento (UE) 2018/858 do Parlamento Europeu e do Conselho, de 30 de maio de 2018, relativo à homologação e à fiscalização do mercado dos veículos a motor e seus reboques, e dos sistemas, componentes e unidades técnicas destinados a esses veículos, que altera os Regulamentos (CE) n.o 715/2007 e (CE) n.o 595/2009 e revoga a Diretiva 2007/46/CE (JO L 151 de 14.6.2018, p. 1).
(*1) A ligação ITS Bluetooth® deve ser atribuída ao cartão tacográfico na ranhura do condutor da VU.
(*2) O utilizador deve selecionar o cartão ao qual será atribuída a ligação ITS Bluetooth® (inserido na ranhura do condutor ou do ajudante).
In force: This act has been changed. Current consolidated version:
21/08/2023
