EUR-Lex Document 02016R0799-20230821

Este texto constitui um instrumento de documentação e não tem qualquer efeito jurídico. As Instituições da União não
assumem qualquer responsabilidade pelo respetivo conteúdo. As versões dos atos relevantes que fazem fé, incluindo os
respetivos preâmbulos, são as publicadas no Jornal Oficial da União Europeia e encontram-se disponíveis no EUR-Lex. É
possível aceder diretamente a esses textos oficiais através das ligações incluídas no presente documento
►B 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
(Texto relevante para efeitos do EEE)
(JO L 139 de 26.5.2016, p. 1)
Alterado por:
Jornal Oficial
n. o página data
►M1 Regulamento de Execução (UE) 2018/502 da Comissão de 28 de
fevereiro de 2018
L 85 1 28.3.2018
►M2 Regulamento de Execução (UE) 2020/158 da Comissão de 5 de
fevereiro de 2020
L 34 20 6.2.2020
►M3 Regulamento de Execução (UE) 2021/1228 da Comissão de 16 de julho
de 2021
L 273 1 30.7.2021
►M4 Regulamento de Execução (UE) 2023/980 da Comissão de 16 de maio
de 2023
L 134 28 22.5.2023
Retificado por:
►C1 Retificação, JO L 146 de 3.6.2016, p. 31 (2016/799)
►C2 Retificação, JO L 27 de 1.2.2017, p. 169 (2016/799)
►C3 Retificação, JO L 239 de 24.9.2018, p. 41 (2018/502)
02016R0799 — PT — 21.08.2023 — 003.002 — 1
02016R0799 — PT — 21.08.2023 — 003.002 — 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
(Texto relevante para efeitos do EEE)
Artigo 1. o
Objeto e âmbito de aplicação
1. O presente regulamento estabelece as disposições necessárias para
a aplicação uniforme dos seguintes aspetos, relativos aos tacógrafos:
a) registo da posição do veículo em certos pontos durante o período de
trabalho diário do condutor;
b) deteção rápida à distância de eventual manipulação ou uso indevido
de tacógrafos inteligentes;
c) interface com sistemas de transporte inteligentes;
d) os requisitos administrativos e técnicos para os procedimentos de
homologação de tacógrafos, incluindo os mecanismos de segurança.
▼M1
2. A construção, o ensaio, a instalação, a inspeção, o funcionamento
e a reparação de tacógrafos inteligentes e dos respetivos componentes
devem cumprir os requisitos técnicos constantes do anexo IC do pre­
sente regulamento.
3. No que respeita à construção, ao ensaio, à instalação, à inspeção,
ao funcionamento e à reparação, os tacógrafos, com exceção dos tacó­
grafos inteligentes, devem continuar a cumprir os requisitos do anexo I
do Regulamento (UE) n. o 165/2014 ou do anexo I-B do Regula­
mento (CEE) n. o 3821/85 do Conselho ( 1 ), consoante o que for aplicá­
vel.
▼B
4. Nos termos do artigo 10. o , alínea d) da Diretiva 96/53/CE, o
sistema de deteção rápida à distância deve também transmitir os dados
relativos aos pesos, fornecidos por um sistema interno de pesagem a
bordo, para efeitos de deteção precoce de fraudes.
▼M1
5. O presente regulamento não prejudica a aplicação da Diretiva
2014/53/UE do Parlamento Europeu e do Conselho ( 2 ).
▼B
Artigo 2. o
Definições
Para efeitos do presente regulamento, aplicam-se as definições estabe­
lecidas no artigo 2. o do Regulamento (UE) n. o 165/2014.
▼B
( 1 ) Regulamento (CEE) n. o 3821/85 do Conselho, de 20 de dezembro de 1985,
relativo à introdução de um aparelho de controlo no domínio dos transportes
rodoviários (JO L 370 de 31.12.1985, p. 8).
( 2 ) Diretiva 2014/53/UE do Parlamento Europeu e do Conselho, de 16 de abril
de 2014, relativa à harmonização da legislação dos Estados-Membros respei­
tante à disponibilização de equipamentos de rádio no mercado e que revoga a
Diretiva 1999/5/CE (JO L 153 de 22.5.2014, p. 62).
02016R0799 — PT — 21.08.2023 — 003.002 — 3
Aplicam-se igualmente as seguintes definições:
1) «tacógrafo digital» ou «tacógrafo da primeira geração»: tacógrafo
digital que não seja um tacógrafo inteligente;
2) «módulo GNSS externo»: módulo que contém o recetor GNSS
quando a unidade-veículo não é uma unidade única, bem como
outros componentes necessários à proteção da comunicação de da­
dos sobre a posição para o resto da unidade-veículo;
▼M1
3) «dossiê de fabrico»: o dossiê completo, em formato eletrónico ou
em papel, que contém todas as informações fornecidas pelo fabri­
cante ou pelo seu mandatário à autoridade de homologação para
efeitos da homologação de tacógrafos ou de componentes, in­
cluindo os certificados referidos no artigo 12. o , n. o 3, do Regula­
mento (UE) n. o 165/2014, o resultado dos ensaios definidos no
anexo IC do presente regulamento, assim como desenhos, fotogra­
fias e outros documentos pertinentes;
▼B
4) «dossier de homologação»: o dossier de fabrico, em formato ele­
trónico ou em papel, acompanhado de outros documentos adicio­
nados ao dossier de fabrico pela autoridade de homologação no
exercício das suas funções, incluindo, no termo do processo de
homologação, o certificado de homologação CE do tacógrafo ou
de um componente do tacógrafo;
5) «índice do dossier de homologação»: o documento com o conteúdo
numerado do dossier de homologação que identifica todas as partes
relevantes do presente dossier. O formato desse documento deve
distinguir as fases sucessivas no processo de homologação CE,
incluindo as datas de revisões e atualizações desse dossier;
6) «sistema de deteção rápida à distância»: o aparelho da
unidade-veículo que é utilizado para realizar os controlos rodoviá­
rios visados;
▼M1
7) «tacógrafo inteligente» ou «tacógrafo da segunda geração»: o tacó­
grafo digital que cumpre o prescrito nos artigos 8. o , 9. o e 10. o do
Regulamento (UE) n. o 165/2014, bem como no anexo IC do pre­
sente regulamento;
8) «componente do tacógrafo»: qualquer um dos seguintes elementos:
unidade-veículo, sensor de movimentos, cartão tacográfico, folha de
registo, módulo GNSS externo e sistema de deteção rápida à dis­
tância;
▼B
9) «autoridade de homologação»: a autoridade de um Estado-Membro
que tem competência para realizar a homologação do tacógrafo ou
dos seus componentes, o processo de autorização, a emissão e, se
for caso disso, a revogação dos certificados de homologação, agir
como ponto de contacto para as autoridades de homologação de
outros Estados-Membros e garantir que os fabricantes cumprem as
suas obrigações no que diz respeito à conformidade com o prescrito
no presente regulamento ;
▼M1
10) «unidade-veículo»: o tacógrafo, excluindo o sensor de movimentos
e os cabos que o ligam.
A unidade pode ser única ou consistir em diversas unidades distribuídas pelo
veículo, e inclui uma unidade de processamento, uma memória de dados,
uma função de medição do tempo, duas interfaces para cartões inteligentes
(condutor e ajudante), uma impressora, um ecrã de visualização, conectores
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 4
e instrumentos para a introdução de dados do utilizador, um recetor GNSS e
um módulo de comunicação à distância.
A unidade-veículo pode ser composta pelos seguintes componentes,
sujeitos a homologação:
— Unidade-veículo, de componente único (incluindo recetor
GNSS e módulo de comunicação à distância),
— Corpo principal da unidade-veículo (incluindo módulo de co­
municação à distância) e módulo GNSS externo,
— Corpo principal da unidade-veículo (incluindo recetor GNSS) e
módulo de comunicação à distância externo,
— Corpo principal da unidade-veículo, módulo GNSS externo e
módulo de comunicação à distância externo.
Caso a unidade-veículo consista em diversas unidades distribuídas
pelo veículo, o corpo principal da unidade-veículo é constituído
pela unidade que alberga a unidade de processamento, a memória
de dados e a função de medição do tempo.
O termo «unidade-veículo (VU)» é utilizado para «unidade-veí­
culo» ou para «corpo principal da unidade-veículo».
▼B
Artigo 3. o
Serviços baseados na localização
1. Os fabricantes devem garantir que os tacógrafos inteligentes são
compatíveis com os serviços de posicionamento fornecidos pelos siste­
mas Galileu e Serviço Europeu Complementar de Navegação Geoesta­
cionária («EGNOS»).
2. Além dos sistemas referidos no n. o 1, os fabricantes podem tam­
bém optar por garantir a compatibilidade com outros sistemas de nave­
gação por satélite.
Artigo 4. o
Procedimento para homologação de tacógrafos e componentes dos
tacógrafos
1. Os fabricantes ou seus mandatários devem apresentar o pedido de
homologação de um modelo de tacógrafo, de qualquer um dos seus
componentes ou de grupos de componentes às autoridades de homolo­
gação para esse efeito designadas por cada Estado-Membro. O pedido
compreende um dossier de fabrico que contém as informações relativas
a cada um dos componentes em questão, incluindo, se for caso disso, os
certificados de homologação de outros componentes necessários à con­
clusão do tacógrafo, bem como quaisquer outros documentos
pertinentes.
2. Os Estados-Membros devem conceder a homologação aos mode­
los de tacógrafo, de componente ou de grupo de componentes que
estejam em conformidade com os requisitos administrativos e técnicos
constantes do artigo 1. o , n. o 2 ou n. o 3, consoante o que for aplicável.
Nesse caso, a autoridade de homologação emite ao requerente um cer­
tificado de homologação conforme com o modelo estabelecido no
anexo II do presente regulamento.
3. A autoridade de homologação pode solicitar informações adicio­
nais ao fabricante (ou ao seu mandatário).
▼M1
02016R0799 — PT — 21.08.2023 — 003.002 — 5
4. O fabricante (ou o seu mandatário) deve disponibilizar às autori­
dades de homologação, bem como às entidades responsáveis pela emis­
são dos certificados referidos no artigo 12. o , n. o 3, do Regulamento (UE)
n. o 165/2014, os tacógrafos ou componentes de tacógrafos que sejam
necessários para permitir a condução satisfatória do procedimento de
homologação.
5. Sempre que o fabricante (ou o seu mandatário) visar a homologa­
ção de determinados componentes ou grupos de componentes de um
tacógrafo, deve fornecer às autoridades de homologação os outros com­
ponentes já homologados, bem como outras peças necessárias à cons­
trução integral do tacógrafo, a fim de que as autoridades de homologa­
ção realizem os ensaios necessários.
Artigo 5. o
Alterações às homologações
1. O fabricante (ou o seu mandatário) deve comunicar imediatamente
às autoridades de homologação que concederam a homologação original
qualquer alteração do software, do equipamento informático ou da na­
tureza dos materiais utilizados no fabrico do tacógrafo que estão regis­
tados no dossier de homologação e apresentar um pedido para a alte­
ração da homologação.
2. As autoridades de homologação podem rever ou prorrogar uma
homologação existente ou emitir uma nova homologação, de acordo
com a natureza e as características das alterações.
Se a autoridade de homologação considerar que as alterações do soft­
ware, do equipamento informático ou da natureza dos materiais utiliza­
dos no fabrico são pequenas, deve proceder a uma «revisão». Nesses
casos, deve emitir os documentos revistos do dossier de homologação,
indicando a natureza das alterações efetuadas e a data da sua homolo­
gação. Para cumprimento do presente requisito, será suficiente a versão
atualizada do dossier de homologação em forma consolidada, acompa­
nhada de uma descrição pormenorizada das alterações.
Se a autoridade de homologação considerar que as alterações do soft­
ware, do equipamento informático ou da natureza dos materiais utiliza­
dos no fabrico são substanciais, deve proceder a uma «prorrogação».
Nesses casos, pode solicitar novos ensaios e informar o fabricante (ou o
seu mandatário) em conformidade. Se os novos ensaios forem satisfa­
tórios, a autoridade de homologação deve emitir um certificado de
homologação revisto que contém um número relativo à prorrogação
concedida. O certificado de homologação deve mencionar o motivo
da prorrogação e a correspondente data de emissão.
3. O índice do dossier de homologação deve indicar a data da mais
recente prorrogação ou revisão da homologação ou a data da mais
recente consolidação da versão atualizada da homologação.
4. Se as alterações exigidas para o tacógrafo homologado ou para os
seus componentes homologados conduzirem à emissão de um novo
certificado de segurança ou interoperabilidade, será necessária nova
homologação.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 6
Artigo 6. 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 2 de março de 2016.
▼M1
No entanto, o anexo IC é aplicável a partir de 15 de junho de 2019,
com exceção do apêndice 16, que é aplicável a partir de 2 de março de
2016.
▼B
O presente regulamento é obrigatório em todos os seus elementos e
diretamente aplicável em todos os Estados-Membros.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 7
ANEXO IC
Condições de construção, ensaio, instalação e controlo
PREÂMBULO
1 DEFINIÇÕES
2 CARACTERÍSTICAS GERAIS E FUNÇÕES DO APARELHO
DE CONTROLO
2.1 Características gerais
2.2 Funções
2.3 Modos de funcionamento
2.4 Segurança
3 REQUISITOS DE CONSTRUÇÃO E FUNCIONAMENTO DO
APARELHO DE CONTROLO
3.1 Controlo da inserção e da retirada de cartões
3.2 Medição da velocidade, da posição e da distância
3.2.1 Medição da distância percorrida
3.2.2 Medição da velocidade
3.2.3 Medição da posição
3.3 Medição do tempo
3.4 Controlo das atividades do condutor
3.5 Controlo da situação de condução
3.6 Entradas dos condutores
3.6.1 Introdução do lugar de início e/ou de final do período diário de trabalho
3.6.2 Introdução manual das atividades dos condutores e consentimento
para interface ITS
3.6.3 Introdução de condições especiais
▼M3
3.6.4 Introdução de operações de carga/descarga
▼B
3.7 Gestão dos bloqueamentos da empresa
3.8 Vigilância das atividades de controlo
3.9 Deteção de incidentes e/ou falhas
3.9.1 Incidente «inserção de cartão não válido»
3.9.2 Incidente «conflito de cartões»
3.9.3 Incidente «sobreposição de tempos»
3.9.4 Incidente «condução sem cartão adequado»
3.9.5 Incidente «inserção de cartão durante a condução»
3.9.6 Incidente «última sessão de cartão encerrada incorretamente»
3.9.7 Incidente «excesso de velocidade»
3.9.8 Incidente «interrupção da alimentação energética»
3.9.9 Incidente «Erro de comunicação com o sistema de comunicação à
distância»
3.9.10 Incidente «Ausência de informações sobre a posição do recetor
GNSS»
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 8
3.9.11 Incidente «Erro de comunicação com o módulo GNSS externo»
3.9.12 Incidente «erro nos dados de movimento»
3.9.13 Incidente «Conflito relativo ao movimento do veículo»
3.9.14 Incidente «tentativa de violação da segurança»
3.9.15 Incidente «conflito de tempo»
3.9.16 Falha do «cartão»
3.9.17 Falha do «aparelho de controlo»
▼M3
3.9.18 Incidente de anomalia no GNSS
▼B
3.10 Ensaios incorporados e autoensaios
3.11 Leitura da memória de dados
3.12 Registo e memorização de dados na memória
3.12.1 Dados de identificação do aparelho
3.12.1.1 Dados de identificação da unidade-veículo
3.12.1.2 Dados de identificação do sensor de movimentos
3.12.1.3 Dados de identificação dos sistemas globais de navegação por
satélite
3.12.2 Chaves e certificados
3.12.3 Dados relativos à inserção e à retirada de cartões de condutor ou de
oficina
3.12.4 Dados relativos à atividade de condutor
▼M1
3.12.5 Locais e posições em que se iniciam e concluem os períodos
diários de trabalho e/ou em que são alcançados os períodos de
três horas de condução acumulados
▼B
3.12.6 Dados do conta-quilómetros
3.12.7 Dados relativos à velocidade
3.12.8 Dados relativos a incidentes
3.12.9 Dados relativos a falhas
3.12.10 Dados relativos à calibração
3.12.11 Dados relativos ao ajustamento do tempo
3.12.12 Dados relativos à atividade de controlo
3.12.13 Dados relativos aos bloqueamentos da empresa
3.12.14 Dados relativos à atividade de descarregamento
3.12.15 Dados relativos às condições especiais
3.12.16 Dados relativos ao cartão tacográfico
▼M3
3.12.17 Travessia de fronteiras
3.12.18 Operações de carga/descarga
3.12.19 Mapa digital
▼B
3.13 Leitura de cartões tacográficos
3.14 Registo e memorização de dados nos cartões tacográficos
3.14.1 Registo e memorização de dados nos cartões tacográficos de pri­
meira geração
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 9
3.14.2 Registo e memorização de dados nos cartões tacográficos da se­
gunda geração
3.15 Visualização
3.15.1 Visualização por defeito
3.15.2 Visualização de alerta
3.15.3 Acesso ao menu
3.15.4 Outras visualizações
3.16 Impressão
3.17 Alertas
3.18 Descarregamento de dados para meios externos
3.19 Comunicação à distância para controlos de estrada seletivos
▼M3
3.20 Intercâmbio de dados com dispositivos externos adicionais
▼B
3.21 Calibração
3.22 Controlo de calibração de estrada
3.23 Ajustamento do tempo
3.24 Características de desempenho
3.25 Materiais
3.26 Marcações
▼M3
3.27 Controlo da travessia de fronteiras
3.28 Atualização de software
▼B
4 REQUISITOS DE CONSTRUÇÃO E FUNCIONAMENTO DOS
CARTÕES TACOGRÁFICOS
4.1 Dados visíveis
4.2 Segurança
4.3 Normas
4.4 Especificações ambientais e elétricas
4.5 Armazenamento dos dados
4.5.1 Ficheiros elementares para identificação e gestão de cartões
4.5.2 Identificação do cartão IC
4.5.2.1 Identificação do chip
4.5.2.2 DIR (presente somente nos cartões tacográficos da segunda gera­
ção)
4.5.2.3 Informações ATR (condicionadas, presentes somente nos cartões
tacográficos da segunda geração)
4.5.2.4 Informação do aumento do comprimento (condicionado, presente
somente nos cartões tacográficos da segunda geração)
4.5.3 Cartão de condutor
4.5.3.1 Aplicação tacográfica (acessível às unidades-veículo das primeira e
segunda gerações)
4.5.3.1.1 Identificação da aplicação
4.5.3.1.2 Chaves e certificados
4.5.3.1.3 Identificação do cartão
4.5.3.1.4 Identificação do titular
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 10
4.5.3.1.5 Descarregamento do cartão
4.5.3.1.6 Elementos relativos à carta de condução
4.5.3.1.7 Dados relativos a incidentes
4.5.3.1.8 Dados relativos a falhas
4.5.3.1.9 Dados relativos à atividade de condutor
4.5.3.1.10 Dados relativos à utilização de veículos
4.5.3.1.11 Locais de início e/ou final dos períodos de trabalho diário
4.5.3.1.12 Dados relativos à sessão de cartão
4.5.3.1.13 Dados relativos à atividade de controlo
4.5.3.1.14 Dados relativos às condições especiais
4.5.3.2 Aplicação tacográfica da segunda geração (não acessível às
unidades-veículo de primeira geração)
4.5.3.2.1 Identificação da aplicação
▼M3
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)
▼B
4.5.3.2.2 Chaves e certificados
4.5.3.2.3 Identificação do cartão
4.5.3.2.4 Identificação do titular
4.5.3.2.5 Descarregamento do cartão
4.5.3.2.6 Elementos relativos à carta de condução
4.5.3.2.7 Dados relativos a incidentes
4.5.3.2.8 Dados relativos a falhas
4.5.3.2.9 Dados relativos à atividade de condutor
4.5.3.2.10 Dados relativos à utilização de veículos
4.5.3.2.11 Locais e posições de início e/ou final dos períodos de trabalho
diário
4.5.3.2.12 Dados relativos à sessão de cartão
4.5.3.2.13 Dados relativos à atividade de controlo
4.5.3.2.14 Dados relativos às condições especiais
4.5.3.2.15 Dados relativos à utilização de unidades-veículo
▼M1
4.5.3.2.16 Dados relativos à localização das três horas de condução acumula­
das
▼M3
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)
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 11
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)
▼B
4.5.4 Cartão de oficina
4.5.4.1 Aplicação tacográfica (acessível às unidades-veículo das primeira e
segunda gerações)
4.5.4.1.1 Identificação da aplicação
4.5.4.1.2 Chaves e certificados
4.5.4.1.3 Identificação do cartão
4.5.4.1.4 Identificação do titular
4.5.4.1.5 Descarregamento do cartão
4.5.4.1.6 Dados relativos à calibração e ao ajustamento do tempo
4.5.4.1.7 Dados relativos a incidentes e a falhas
4.5.4.1.8 Dados relativos à atividade de condutor
4.5.4.1.9 Dados relativos à utilização de veículos
4.5.4.1.10 Dados relativos ao início e/ou ao final dos períodos de trabalho
diário
4.5.4.1.11 Dados relativos à sessão de cartão
4.5.4.1.12 Dados relativos à atividade de controlo
4.5.4.1.13 Dados relativos às condições especiais
4.5.4.2 Aplicação tacográfica de segunda geração (não acessível às
unidades-veículo de primeira geração)
4.5.4.2.1 Identificação da aplicação
▼M3
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)
▼B
4.5.4.2.2 Chaves e certificados
4.5.4.2.3 Identificação do cartão
4.5.4.2.4 Identificação do titular
4.5.4.2.5 Descarregamento do cartão
4.5.4.2.6 Dados relativos à calibração e ao ajustamento do tempo
4.5.4.2.7 Dados relativos a incidentes e a falhas
4.5.4.2.8 Dados relativos à atividade de condutor
4.5.4.2.9 Dados relativos à utilização de veículos
4.5.4.2.10 Dados relativos ao início e/ou ao final dos períodos de trabalho
diário
4.5.4.2.11 Dados relativos à sessão de cartão
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 12
4.5.4.2.12 Dados relativos à atividade de controlo
4.5.4.2.13 Dados relativos à utilização de unidades-veículo
▼M1
4.5.4.2.14 Dados relativos à localização das três horas de condução acumula­
das
▼B
4.5.4.2.15 Dados relativos às condições especiais
▼M3
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)
▼B
4.5.5 Cartão de controlo
4.5.5.1 Aplicação tacográfica (acessível às unidades-veículo das primeira e
segunda gerações)
4.5.5.1.1 Identificação da aplicação
4.5.5.1.2 Chaves e certificados
4.5.5.1.3 Identificação do cartão
4.5.5.1.4 Identificação do titular
4.5.5.1.5 Dados relativos à atividade de controlo
4.5.5.2 Aplicação tacográfica G2 (não acessível a unidades-veículo da pri­
meira geração)
4.5.5.2.1 Identificação da aplicação
▼M3
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)
▼B
4.5.5.2.2 Chaves e certificados
4.5.5.2.3 Identificação do cartão
4.5.5.2.4 Identificação do titular
4.5.5.2.5 Dados relativos à atividade de controlo
▼M3
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)
▼B
4.5.6 Cartão de empresa
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 13
4.5.6.1 Aplicação tacográfica (acessível às unidades-veículo das primeira e
segunda gerações)
4.5.6.1.1 Identificação da aplicação
4.5.6.1.2 Chaves e certificados
4.5.6.1.3 Identificação do cartão
4.5.6.1.4 Identificação do titular
4.5.6.1.5 Dados relativos à atividade da empresa
4.5.6.2 Aplicação tacográfica G2 (não acessível a unidades-veículo da pri­
meira geração)
4.5.6.2.1 Identificação da aplicação
▼M3
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)
▼B
4.5.6.2.2 Chaves e certificados
4.5.6.2.3 Identificação do cartão
4.5.6.2.4 Identificação do titular
4.5.6.2.5 Dados relativos à atividade da empresa
▼M3
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)
▼B
5 INSTALAÇÃO DE APARELHO DE CONTROLO
5.1 Instalação
5.2 Placa de instalação
5.3 Selagem
6 VERIFICAÇÕES, INSPEÇÕES E REPARAÇÕES
6.1 Homologação de instaladores, oficinas e fabricantes de veículos
▼M1
6.2 Verificação de componentes novos ou reparados
▼B
6.3 Inspeção da instalação
6.4 Inspeções periódicas
6.5 Determinação dos erros
6.6 Reparações
7 EMISSÃO DE CARTÕES
8 HOMOLOGAÇÃO DE TIPO DOS APARELHOS DE CON­
TROLO E DOS CARTÕES TACOGRÁFICOS
8.1 Aspetos gerais
8.2 Certificado de segurança
8.3 Certificado de funcionalidade
8.4 Certificado de interoperabilidade
8.5 Certificado de homologação
8.6 Procedimento excecional: primeiros certificados de interoperabili­
dade para aparelhos de controlo e cartões tacográficos da segunda
geração
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 14
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.
▼B
Lista dos apêndices
Apêndice 1: DICIONÁRIO DE DADOS
Apêndice 2: ESPECIFICAÇÕES APLICÁVEIS AOS CARTÕES TACO­
GRÁFICOS
Apêndice 3: PICTOGRAMAS
Apêndice 4: IMPRESSÃO
Apêndice 5: VISUALIZAÇÃO
Apêndice 6: CONECTOR DA FRENTE PARA CALIBRAÇÃO E DES­
CARREGAMENTO
Apêndice 7: PROTOCOLOS APLICÁVEIS AO DESCARREGAMENTO
DE DADOS
Apêndice 8: PROTOCOLO APLICÁVEL À CALIBRAÇÃO
Apêndice 9: HOMOLOGAÇÃO DE TIPO E RELAÇÃO DOS ENSAIOS
MÍNIMOS EXIGIDOS
Apêndice 10: REQUISITOS DE SEGURANÇA
Apêndice 11: MECANISMOS COMUNS DE SEGURANÇA
Apêndice 12: POSICIONAMENTO BASEADO NO SISTEMA GLOBAL
DE NAVEGAÇÃO POR SATÉLITE (GNSS)
Apêndice 13: INTERFACE ITS
Apêndice 14: FUNÇÃO DE COMUNICAÇÃO À DISTÂNCIA
Apêndice 15: MIGRAÇÃO: GESTÃO DA COEXISTÊNCIA DE GERA­
ÇÕES DE APARELHOS
Apêndice 16: ADAPTADOR PARA VEÍCULOS DAS CATEGORIAS M1
E N1
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 15
1 DEFINIÇÕES
Para efeitos do disposto no presente anexo, entende-se por:
a) «Ativação»
a fase no decurso da qual o tacógrafo se torna plenamente
operacional e executa todas as funções, incluindo as de segu­
rança, por recurso a um cartão de oficina;
b) «Autenticação»
função destinada a estabelecer e verificar uma identidade
alegada;
c) «Autenticidade»
o facto de determinada informação provir de uma parte cuja
identidade pode ser verificada;
d) «Ensaio incorporado (BIT)»
o ensaio realizado a pedido, acionado por efeito do operador
ou de um mecanismo externo;
e) «Dia»
um dia, das 0 horas às 24 horas. Todos os dias se reportam à
hora UTC (tempo universal coordenado);
▼M3
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 com­
preendem 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;
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 identifi­
caçã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;
▼B
h) «Índice de série do cartão»
o 14. o caráter alfanumérico do número do cartão, destinado a
distinguir os diversos cartões tacográficos atribuídos a uma
empresa, a uma oficina ou a uma autoridade de controlo que
tenham direito a mais do que um. A empresa, oficina ou
autoridade de controlo é identificada inequivocamente pelos
primeiros 13 carateres do número do cartão;
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 16
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, corres­
pondente 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, corres­
pondente 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;
▼B
k) «Coeficiente característico do veículo»
característica numérica que dá o valor do sinal de saída emi­
tido pela peça prevista no veículo que faz a ligação deste ao
aparelho de controlo (na saída da caixa de velocidades ou nas
rodas do veículo, conforme os casos), sempre que o veículo
percorrer a distância de 1 quilómetro, medida em condições
normais de ensaio, conforme a definição constante do requisito
n. o 414. O coeficiente característico é expresso em impulsos
por quilómetro (w = … imp/km);
l) «Cartão de empresa»
cartão tacográfico emitido pelas autoridades de um
Estado-Membro a uma empresa de transporte rodoviário que
necessite de utilizar veículos equipados com tacógrafo, o qual
identifica a empresa de transporte e permite visualizar, descar­
regar e imprimir os dados memorizados no tacógrafo que te­
nham sido bloqueados por essa empresa de transporte;
m) «Constante do aparelho de controlo»
a característica numérica que dá o valor do sinal de entrada ne­
cessário para obter a indicação e o registo do percurso de uma
distância de 1 km; esta constante é expressa em impulsos por
quilómetro (k = … imp/km);
n) «Tempo de condução contínua», calculado no aparelho de
controlo do seguinte modo ( 1 )
somatório (calculado pelo aparelho de controlo) dos tempos de
condução acumulados por um condutor desde o final do seu
último período de AVAILABILITY (disponibilidade) ou
BREAK/REST (pausa/repouso) ou UNKNOWN ( 2 ) (desconhe­
cido) de 45 minutos ou mais [este período pode ter sido cin­
dido em conformidade com o Regulamento (CE) n. o 561/2006
do Parlamento Europeu e do Conselho ( 3 )]. Os cálculos têm
em conta, conforme necessário, atividades passadas registadas
no cartão do condutor. Se o condutor não tiver inserido o seu
cartão, os cálculos baseiam-se nos registos da memória de
dados relativos ao período durante o qual não houve inserção
e à correspondente faixa horária;
▼M3
( 1 ) Esta forma de calcular o tempo de condução contínua e o tempo acumulado de pausas
permite ao aparelho de controlo calcular o aviso de tempo de condução contínua. Não
prejudica a interpretação jurídica desses intervalos. Podem utilizar-se formas alternativas
de calcular o tempo de condução contínua e o tempo acumulado de pausas para substituir
estas definições se elas se tornarem obsoletas devido a atualizações noutra legislação
pertinente.
( 2 ) Os períodos UNKNOWN são aqueles em que o cartão do condutor não estava inserido
no aparelho de controlo e relativamente aos quais as atividades do condutor não foram
introduzidas manualmente.
( 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).
02016R0799 — PT — 21.08.2023 — 003.002 — 17
o) «Cartão de controlo»
cartão tacográfico emitido pelas autoridades de um
Estado-Membro a uma autoridade nacional responsável pelo
controlo, que identifica o organismo e, a título facultativo, o
agente de controlo e que permite o acesso aos dados registados
na memória ou nos cartões de condutor e, a título facultativo,
nos cartões de oficina, para efeitos de leitura, impressão e/ou
descarregamento;
deve igualmente dar acesso à função de controlo da calibração
de estrada e aos dados existentes do leitor de comunicação da
deteção rápida à distância;
p) «Tempo acumulado de pausas», calculado no aparelho de con­
trolo do seguinte modo ( 1 )
as pausas acumuladas no tempo de condução são calculadas
como o somatório dos tempos de AVAILABILITY, BREAK/
/REST ou UNKNOWN ( 2 ) de 15 minutos ou mais, desde o
final do último período de AVAILABILITY, BREAK/REST
ou UNKNOWN ( 2 ) de 45 minutos ou mais [este período pode
ter sido cindido em conformidade com o Regulamento (CE)
n. o 561/2006].
Os cálculos têm em conta, conforme necessário, atividades
passadas registadas no cartão do condutor. Os períodos desco­
nhecidos de duração negativa (em que o início é posterior ao
final), devidos a sobreposições de tempo entre dois aparelhos
de controlo distintos, não são tidos em conta para o cálculo.
Se o condutor não tiver inserido o seu cartão, os cálculos
baseiam-se nos registos da memória de dados relativos ao
período durante o qual não houve inserção e à correspondente
faixa horária;
q) «Memória de dados»
dispositivo eletrónico de memorização de dados, incorporado
no aparelho de controlo;
r) «Assinatura digital»
os dados apensos a um bloco de dados (ou transformação
criptográfica do mesmo), que permitem ao recetor comprovar
a autenticidade e a integridade do bloco de dados;
s) «Descarga»
cópia, juntamente com a assinatura digital, de uma parte ou de
um conjunto completo de ficheiros de dados registados na
memória da unidade-veículo ou na memória de um cartão
tacográfico, desde que este processo não altere nem suprima
nenhum dado armazenado;
▼B
( 1 ) Esta forma de calcular o tempo de condução contínua e o tempo acumulado de pausas
permite ao aparelho de controlo calcular o aviso de tempo de condução contínua. Não
prejudica a interpretação jurídica desses intervalos. Podem utilizar-se formas alternativas
de calcular o tempo de condução contínua e o tempo acumulado de pausas para substituir
estas definições se elas se tornarem obsoletas devido a atualizações noutra legislação
pertinente.
( 2 ) Os períodos UNKNOWN são aqueles em que o cartão do condutor não estava inserido
no aparelho de controlo e relativamente aos quais as atividades do condutor não foram
introduzidas manualmente.
02016R0799 — PT — 21.08.2023 — 003.002 — 18
Os fabricantes de unidades-veículo de tacógrafos inteligentes e
os fabricantes de aparelhos projetados e destinados ao descar­
regamento de ficheiros de dados devem tomar todas as medi­
das razoáveis para assegurar que o descarregamento desses
dados pode ser executado num tempo mínimo para as empre­
sas de transportes ou os condutores.
O descarregamento do ficheiro detalhado da velocidade pode
não ser necessário para determinar a conformidade com o
Regulamento (CE) n. o 561/2006, mas pode ser utilizado para
outros fins, como a investigação de acidentes;
t) «Cartão de condutor»
cartão tacográfico emitido pelas autoridades de um
Estado-Membro a um determinado condutor, que identifica o
condutor e permite memorizar os dados relativos às suas
atividades;
u) «Perímetro efetivo dos pneus das rodas»
média das distâncias percorridas por cada uma das rodas de
tração do veículo (rodas motoras) durante uma rotação com­
pleta. A medição destas distâncias deve ser feita nas condições
normais de ensaio, conforme a definição constante do requisito
n. o 414, e é expressa sob a forma: «l = … mm». Os fabrican­
tes dos veículos podem substituir a medição destas distâncias
por um cálculo teórico que tenha em conta a distribuição do
peso pelos eixos (veículo sem carga e em ordem normal de
marcha) ( 1 ). Os métodos para esse cálculo teórico estão sujei­
tos a aprovação por uma autoridade nacional competente e só
podem ser aplicados antes da ativação do tacógrafo;
v) «Incidente»
operação anormal, detetada pelo tacógrafo inteligente, que
pode resultar de uma tentativa de fraude;
w) «Módulo GNSS externo»
módulo que contém o recetor GNSS quando a unidade-veículo
não é uma unidade única, bem como outros componentes
necessários à proteção da comunicação de dados sobre a po­
sição para o resto da unidade-veículo;
x) «Falha»
operação anormal, detetada pelo tacógrafo inteligente, que
pode resultar de uma deficiência ou avaria do equipamento;
y) «Recetor GNSS»
dispositivo eletrónico que recebe e processa digitalmente os
sinais a partir de um ou mais sistemas globais de navegação
por satélite (GNSS), a fim de fornecer a posição, a velocidade
e informação sobre o tempo;
▼B
( 1 ) Regulamento (UE) n. o 1230/2012 da Comissão, de 12 de dezembro de 2012, que dá
execução ao Regulamento (CE) n. o 661/2009 do Parlamento Europeu e do Conselho no
que respeita aos requisitos de homologação para massas e dimensões dos veículos a
motor e seus reboques e altera a Diretiva 2007/46/CE do Parlamento Europeu e do
Conselho (JO L 353 de 21.12.2012, p. 31), na sua última redação.
02016R0799 — PT — 21.08.2023 — 003.002 — 19
z) «Instalação»
montagem de um tacógrafo num veículo;
aa) «Interoperabilidade»
capacidade dos sistemas e dos processos industriais que lhes
estão subjacentes para trocar dados e partilhar informações;
bb) «Interface»
instalação entre sistemas que fornece os meios de comunicação
através dos quais estes podem ligar-se e interagir;
cc) «Posição»
as coordenadas geográficas do veículo num determinado
momento;
dd) «Sensor de movimentos»
o componente do tacógrafo que emite um sinal representativo
da velocidade do veículo e/ou da distância percorrida;
▼M3
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;
▼B
ff) «Norma aberta»
norma definida num documento de especificação de normas
disponível gratuitamente ou a preço simbólico, passível de ser
copiada, distribuída ou utilizada gratuitamente ou contra paga­
mento simbólico;
gg) «Fora de âmbito»
situação em que não é exigível a utilização do aparelho de
controlo, nos termos do Regulamento (CE) n. o 561/2006;
hh) «Excesso de velocidade»
a ultrapassagem da velocidade máxima autorizada para o veí­
culo. Define-se como um período superior a 60 segundos du­
rante o qual a velocidade medida do veículo excede o limite
relativo à fixação do dispositivo de limitação da velocidade,
constante da Diretiva 92/6/CEE do Conselho ( 1 ), na sua última
redação;
▼B
( 1 ) Diretiva 92/6/CEE do Conselho, de 10 de fevereiro de 1992, relativa à instalação e
utilização de dispositivos de limitação de velocidade para certas categorias de veículos
a motor na Comunidade (JO L 57 de 2.3.1992, p. 27).
02016R0799 — PT — 21.08.2023 — 003.002 — 20
ii) «Inspeção periódica»
conjunto de operações destinadas a verificar se o tacógrafo
funciona corretamente, se as suas características de regulação
correspondem aos parâmetros do veículo e se não lhe foram
fixados dispositivos de manipulação;
jj) «Impressora»
componente do aparelho de controlo que exibe sob forma
impressa os dados memorizados;
kk) «Comunicação de deteção rápida à distância»
comunicação entre o sistema de comunicação de deteção rá­
pida à distância e o leitor de comunicação de deteção rápida à
distância, durante os controlos de estrada seletivos, com o
objetivo de detetar à distância eventuais manipulações ou uti­
lizações indevidas dos aparelhos de controlo;
▼M3
ll) «Sistema de comunicação à distância», «módulo de comuni­
cação à distância» ou «sistema de deteção rápida à distância»,
equipamento da unidade-veículo utilizado para controlos de
estrada seletivos;
▼B
mm) «Leitor de comunicação de deteção rápida à distância»
sistema utilizado pelos agentes de controlo para os controlos
de estrada seletivos;
▼M3
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;
▼B
oo) «Reparação»
qualquer reparação de um sensor de movimentos, de uma
unidade-veículo ou de um cabo que exige que a sua fonte
de alimentação energética seja desligada, ou desligada de ou­
tros componentes do tacógrafo, ou a abertura desse sensor ou
dessa unidade-veículo;
▼M3
pp) «Substituição do cartão»,
emissão de um cartão tacográfico em substituição de um exis­
tente que tenha sido declarado extraviado, subtraído ou defei­
tuoso e não tenha sido devolvido à autoridade emissora;
▼B
qq) «Certificação de segurança»
processo destinado a certificar, por um organismo de certifi­
cação de critérios comuns, se o aparelho (ou o componente) de
controlo ou o cartão tacográfico em investigação cumprem os
requisitos de segurança definidos nos perfis de proteção em
questão;
rr) «Autoensaio»
ensaio realizado cíclica e automaticamente pelo aparelho de
controlo, com vista a detetar falhas;
ss) «Medição de tempo»
registo digital permanente da data e do tempo universal
coordenado (UTC);
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 21
tt) «Ajustamento do tempo»,
um ajustamento da hora atual; este ajustamento pode ser au­
tomático, utilizando a hora indicada pelo recetor GNSS como
referência, ou efetuado no modo de calibração;
▼B
uu) «Medida do pneumático»
designação das dimensões dos pneumáticos (rodas motoras
externas), em conformidade com a Diretiva 92/23/CEE do
Conselho ( 1 ), na sua última redação;
vv) «Identificação do veículo»
números identificativos do veículo: número de matrícula do
veículo (VRN), com indicação do Estado-Membro de matrí­
cula, e número de identificação do veículo (VIN) ( 2 );
ww) «Semana»
intervalo utilizado pelo aparelho de controlo nos cálculos e
que vai das 00h00 UTC de segunda-feira às 24h00 UTC de
domingo;
xx) «Cartão de oficina»
cartão tacográfico emitido pelas autoridades de um
Estado-Membro a elementos designados de um fabricante ou
instalador de tacógrafos, de um fabricante de veículos ou de
uma oficina, aprovados por esse Estado-Membro, o qual iden­
tifica o titular do cartão e permite o ensaio, a calibração e a
ativação de tacógrafos e/ou o descarregamento a partir de
tacógrafos;
yy) «Adaptador»
dispositivo que fornece um sinal permanentemente representa­
tivo da velocidade do veículo e/ou da distância por ele per­
corrida, diferente do utilizado para a deteção de movimentos
independentes, e que é:
▼M3
— 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 ( 3 ),
▼B
— instalado onde não é mecanicamente possível instalar qual­
quer outro tipo de sensor de movimentos existente que, por
outro lado, cumpre o disposto no presente anexo e nos
seus apêndices 1 a 15;
▼M3
( 1 ) Diretiva 92/23/CEE do Conselho, de 31 de março de 1992, relativa aos pneumáticos dos
veículos a motor e seus reboques bem como à respectiva instalação nesses veículos
(JO L 129 de 14.5.1992, p. 95).
( 2 ) Diretiva 76/114/CEE do Conselho, de 18 de dezembro de 1975, relativa à aproximação
das legislações dos Estados-Membros respeitantes às chapas e inscrições regulamentares,
bem como à sua localização e modo de fixação no que respeita aos veículos a motor e
seus reboques (JO L 24 de 30.1.1976, p. 1).
( 3 ) 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).
02016R0799 — PT — 21.08.2023 — 003.002 — 22
— instalado entre a unidade-veículo e o ponto onde os impul­
sos velocidade/distância são gerados por sensores integra­
dos ou interfaces alternativas;
— visto de uma unidade-veículo, o comportamento do adap­
tador é idêntico ao que se verificará se à unidade-veículo
estiver ligado um sensor de movimentos que cumpra o
disposto no presente anexo e nos seus apêndices 1 a 16;
a utilização de um tal adaptador nos veículos acima referidos
deve permitir instalar e utilizar corretamente uma
unidade-veículo que cumpra todos os requisitos do presente
anexo,
nos veículos em causa, o tacógrafo inteligente inclui cabos, um
adaptador e uma unidade-veículo;
zz) Integridade dos dados:
precisão e consistência dos dados memorizados, indicada pela
ausência de qualquer alteração nos dados entre duas atualiza­
ções de um registo de dados. A integridade implica que os
dados sejam uma cópia exata da versão original: por exemplo,
não terem sido corrompidos no processo de escrita para — e
de leitura a partir de — um cartão tacográfico ou um equipa­
mento dedicado ou durante a transmissão através de qualquer
canal de comunicação;
▼M3
aaa) Reservado para utilização futura;
▼B
bbb) Sistema tacográfico inteligente:
aparelhos de controlo, cartões tacográficos e conjunto de todos
os equipamentos que interagem direta ou indiretamente durante
a sua construção, a sua instalação, a sua utilização, o seu
ensaio e o seu controlo, como cartões, leitor de comunicação
à distância e qualquer outro aparelho de descarregamento de
dados, análise de dados, calibração, geração, gestão ou produ­
ção de elementos de segurança, etc;
▼M3
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;
▼B
ddd) Perfil de proteção:
documento utilizado no âmbito do processo de certificação de
acordo com critérios comuns, que fornece especificações inde­
pendentes da aplicação dos requisitos da garantia de segurança
da informação;
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 23
eee) Precisão GNSS:
no contexto do registo da posição do sistema global de nave­
gação por satélite (GNSS) com tacógrafos, significa o valor da
Horizontal Dilution of Precision (HDOP) calculada como os
valores mínimos HDOP recolhidos nos sistemas GNSS
disponíveis ;
▼M1
fff) «Tempo de condução acumulado»:
um valor que representa o número total acumulado de minutos
de condução de um determinado veículo.
O valor tempo de condução acumulado constitui uma conta­
gem livre de todos os minutos considerados como tempo de
condução pelo controlo da função das atividades de condução
do aparelho de controlo e só é utilizado para ativar o registo
da posição do veículo cada vez que é alcançado um múltiplo
de três horas de tempo de condução acumulado. A acumulação
tem início no momento da ativação do equipamento de grava­
ção. Não é afetada por qualquer outra condição, como, por
exemplo, fora de alcance ou passagem de nível.
O valor tempo de condução acumulado não se destina a ser
afixado, impresso ou descarregado.
▼B
2 CARACTERÍSTICAS GERAIS E FUNÇÕES DO APARELHO DE
CONTROLO
2.1 Características gerais
O aparelho de controlo tem por função registar, memorizar, exibir,
imprimir e transmitir os dados relativos às atividades do condutor.
Os veículos equipados com aparelhos de controlo que cumpram o
disposto no presente anexo devem ter as funções de visualização da
velocidade e de conta-quilómetros incorporadas no aparelho de con­
trolo. Estas funções podem ser incluídas no aparelho de controlo.
1) O aparelho de controlo compreende os cabos de ligação, um
sensor de movimentos e uma unidade-veículo.
2) A interface entre os sensores de movimento e as
unidades-veículo deve cumprir o prescrito no apêndice 11.
3) A unidade-veículo deve estar ligada ao sistema global de
navegação por satélite, conforme especifica o apêndice 12.
4) A unidade-veículo deve comunicar com leitores de comu­
nicações de deteção rápida à distância, conforme especifica
o apêndice 14.
▼M3
5) A unidade-veículo pode incluir uma interface ITS especifi­
cada 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
02016R0799 — PT — 21.08.2023 — 003.002 — 24
6) A inclusão de funções ou dispositivos, homologados ou
não, no aparelho de controlo, ou a ligação de tais funções
ou dispositivos ao aparelho de controlo não deve interferir,
real ou potencialmente, com o seu funcionamento correto
nem com o disposto no regulamento.
Os utilizadores identificam-se relativamente ao aparelho de
controlo por intermédio de cartões tacográficos.
7) O aparelho de controlo proporciona direitos de acesso sele­
tivo aos dados e funções em conformidade com o tipo e/ou
a identidade do utilizador.
O aparelho de controlo regista e memoriza dados na sua memória,
no sistema de comunicação à distância e nos cartões tacográficos.
▼M3
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 Regula­
mento (UE) n. o 165/2014.
▼B
2.2 Funções
8) O aparelho de controlo deve assegurar as seguintes funções:
— controlo da inserção e da retirada de cartões,
— medição da velocidade, da distância e da posição,
— medição do tempo,
— controlo das atividades do condutor,
— controlo da situação de condução,
▼M3
— 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
— gestão dos bloqueamentos da empresa,
— vigilância das atividades de controlo,
— deteção de incidentes e/ou falhas,
— ensaios incorporados e autoensaios,
— leitura de dados memorizados na memória,
— registo e memorização de dados na memória,
— leitura de cartões tacográficos,
— registo e memorização de dados nos cartões tacográfi­
cos,
— visualização de dados,
— impressão,
— alertas,
— descarregamento de dados para meios externos,
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 25
— comunicação à distância para controlos de estrada
seletivos,
— dados de saída para sistemas adicionais,
— calibração,
— controlo de calibração de estrada,
— ajustamento do tempo ,
▼M3
— controlo da travessia de fronteiras,
— atualização de software.
▼B
2.3 Modos de funcionamento
9) O aparelho de controlo deve possuir quatro modos de
funcionamento:
— modo operacional,
— modo de controlo,
— modo de calibração,
— modo de empresa.
10) O aparelho de controlo deve passar para os modos de fun­
cionamento indicados no quadro infra, consoante os cartões
tacográficos válidos inseridos nas correspondentes interfa­
ces. Na determinação do modo de funcionamento, a geração
do cartão tacográfico é irrelevante, desde que o cartão in­
serido esteja válido. O cartão de oficina da primeira geração
deve ser sempre considerado como não válido quando in­
serido numa VU de segunda geração.
Modo de funcionamento
Ranhura do condutor
Ausência de cartão Cartão de condutor Cartão de controlo Cartão de oficina Cartão de empresa
R
an
hu
ra
d
o
aj
ud
an
te

Ausência de
cartão
Operacional Operacional Controlo Calibração Empresa
Cartão de con­
dutor
Operacional Operacional Controlo Calibração Empresa
Cartão de con­
trolo
Controlo Controlo Controlo (*) Operacional Operacional
Cartão de ofi­
cina
Calibração Calibração Operacional Calibração (*) Operacional
Cartão de em­
presa
Empresa Empresa Operacional Operacional Empresa (*)
(*) Nestas situações, o aparelho de controlo utiliza unicamente o cartão tacográfico inserido na ranhura do condutor.
11) O aparelho de controlo ignora cartões não válidos inseridos,
a menos que seja possível visualizar, imprimir ou descarre­
gar dados constantes de um cartão expirado.
12) Todas as funções enunciadas na secção 2.2 devem estar
operacionais em qualquer modo de funcionamento, com
as seguintes exceções:
— a função de calibração é acessível unicamente em modo
de calibração,
— a função de controlo da calibração de estrada é acessível
unicamente em modo de controlo,
— a função de gestão dos bloqueamentos da empresa é
acessível unicamente em modo de empresa,
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 26
— a função de vigilância das atividades de controlo é ope­
racional unicamente em modo de controlo,
▼M3
— 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 ne­
nhum outro tipo de cartão é inserido na VU.
▼B
13) O aparelho de controlo pode transmitir quaisquer dados para
o visor, para a impressora ou para interfaces externas, com
as seguintes exceções:
— em modo operacional, é apagada uma identificação pes­
soal (apelido e nome próprio) que não corresponda ao
cartão tacográfico inserido e, num número de cartão que
não corresponda ao cartão tacográfico inserido, são apa­
gados os carateres discordantes (da esquerda para a di­
reita),
▼M3
— 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 bloquea­
dos por outra empresa (identificada pelos primeiros 13
algarismos do número do seu cartão),
▼B
— se nenhum cartão tiver sido inserido no aparelho de
controlo, só pode ser dada saída aos dados do condutor
relativamente ao dia corrente e aos oito dias anteriores,
▼M3
— os dados pessoais registados e produzidos pelo tacó­
grafo ou pelos cartões tacográficos não devem ser trans­
mitidos através da interface ITS da VU, a menos que se
verifique o consentimento do condutor a quem se refe­
rem os dados.
▼M1
— as unidades-veículo têm um período normal de validade
do funcionamento de 15 anos, a começar na data de
vigência dos respetivos certificados, mas as
unidades-veículo podem ser utilizadas por mais 3 meses,
somente para descarregamento de dados.
▼B
2.4 Segurança
▼M1
O dispositivo de segurança do sistema visa proteger a memória
contra acesso e manipulação não autorizados dos dados, bem
como detetar tentativas nesse sentido, proteger a integridade e a
autenticidade dos dados intercambiados entre o sensor de movimen­
tos e a unidade-veículo, entre o aparelho de controlo e os cartões
tacográficos e entre a unidade-veículo e o módulo GNSS externo, se
existir, proteger a confidencialidade, a integridade e a autenticidade
dos dados intercambiados através da comunicação de deteção rápida
à distância para efeitos de controlo e verificar a integridade e a
autenticidade dos dados descarregados.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 27
14) A fim de obter a segurança do sistema, os componentes que
se seguem devem satisfazer os requisitos de segurança es­
pecificados nos respetivos perfis de proteção, exigidos no
apêndice 10:
— unidade-veículo,
— cartão tacográfico,
— sensor de movimentos,
▼M3
— módulo GNSS externo (este perfil é necessário e apli­
cável somente para a variante do módulo GNSS ex­
terno).
▼B
3 REQUISITOS DE CONSTRUÇÃO E FUNCIONAMENTO DO
APARELHO DE CONTROLO
3.1 Controlo da inserção e da retirada de cartões
15) O aparelho de controlo controla as interfaces dos cartões,
para detetar inserções e retiradas dos cartões.
▼M3
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 es­
tabelecido no requisito 133.
▼B
17) Os cartões tacográficos da primeira geração serão conside­
rados como não válidos pelo aparelho de controlo quando a
utilização de cartões tacográficos da primeira geração tiver
sido suprimida por uma oficina, em conformidade com o
apêndice 15 (req. MIG003).
18) Os cartões de oficina da primeira geração inseridos no apa­
relho de controlo da segunda geração serão considerados
não válidos.
19) O aparelho de controlo deve ser concebido de modo a que
os cartões tacográficos fiquem fixos quando inseridos cor­
retamente nas correspondentes interfaces.
▼M3
20) A retirada dos cartões tacográficos deve funcionar unica­
mente com o veículo parado e depois de terem sido memo­
rizados os dados pertinentes nos mesmos. A retirada do
cartão exige uma ação positiva do utilizador.
▼B
3.2 Medição da velocidade, da posição e da distância
21) O sensor de movimentos (possivelmente incorporado no
adaptador) é a principal fonte para a medição da velocidade
e da distância.
22) Esta função mede e fornece continuamente o valor do
conta-quilómetros correspondente à distância total percor­
rida pelo veículo utilizando os impulsos fornecidos pelo
sensor de movimentos.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 28
23) Esta função mede e fornece continuamente a velocidade do
veículo utilizando os impulsos fornecidos pelo sensor de
movimentos.
24) A função de medição da velocidade deve igualmente infor­
mar se o veículo está em movimento ou parado. O veículo é
considerado em movimento assim que, com base no sensor
de movimentos, a função deteta mais de 1 imp/seg durante
pelo menos 5 segundos — caso contrário, o veículo é con­
siderado parado.
25) Os dispositivos que exibem a velocidade (velocímetro) e a
distância total (conta-quilómetros), instalados em veículos
equipados com aparelhos de controlo que cumpram o dis­
posto no presente regulamento, devem cumprir os requisitos
relativos a tolerâncias máximas, constantes do presente
anexo (secções 3.2.1 e 3.2.2).
▼M3
26) Para detetar a manipulação dos dados relativos ao movi­
mento, a informação do sensor de movimentos deve ser
corroborada por informação de movimentos do veículo de­
rivada 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 indepen­
dente 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
3.2.1 Medição da distância percorrida
28) A distância percorrida pode ser medida de um dos seguintes
modos:
— acumulando quer os movimentos de marcha em frente
quer os de marcha atrás ou
— incluindo apenas os movimentos de marcha em frente.
29) O aparelho de controlo deve medir distâncias de 0 a
9 999 999,9 km.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 29
30) As distâncias medidas devem situar-se dentro das seguintes
tolerâncias (distâncias de pelo menos 1 000 m):
— ± 1 % antes da instalação,
— ± 2 % durante a instalação e a inspeção periódica,
— ± 4 % em uso.
▼M3
As tolerâncias não devem ser utilizadas para alterar inten­
cionalmente a distância medida.
▼B
31) A medição da distância deve ter uma resolução igual ou
superior a 0,1 km.
3.2.2 Medição da velocidade
32) O aparelho de controlo deve medir a velocidade de 0 a
220 km/h.
▼M3
33) Para garantir uma tolerância máxima de ± 6 km/h na velo­
cidade 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 memori­
zada pelo aparelho de controlo.
▼B
34) A velocidade deve ser medida corretamente, cumprindo as
tolerâncias normais, dentro de 2 segundos após ser consu­
mada uma mudança de velocidade a uma aceleração até
2 m/s 2 .
35) A medição da velocidade deve ter resolução igual ou supe­
rior a 1 km/h.
3.2.3 Medição da posição
36) O aparelho de controlo deve medir a posição absoluta do
veículo utilizando o recetor GNSS.
▼M3
37) A posição absoluta é medida em coordenadas geográficas
de latitude e longitude em graus e minutos, com uma reso­
lução de 1/10 de minuto.
▼B
3.3 Medição do tempo
38) Esta função deve medir permanentemente a data e a hora
UTC e fornecê-las sob formato digital.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 30
39) Os valores da data e da hora UTC serão utilizados para
datar dados no aparelho de controlo (registos, intercâmbio
de dados) e para todas as impressões indicadas no apêndice
4 («Impressão»).
40) Para efeitos de visualização da hora local, deve ser possível
modificar o valor exibido em saltos de meia hora. Apenas
são permitidas modificações do valor exibido em múltiplos
negativos ou positivos de meia hora;
▼M3
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.
41-A) A exatidão do tempo, quando o tempo é ajustado pelas
oficinas de acordo com o requisito 212, deve ser de 3 se­
gundos ou melhor.
41B) A unidade-veículo deve incluir um contador de deriva que
calcule a deriva de tempo máxima desde o último ajusta­
mento 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.
▼B
42) A medição do tempo deve ter uma resolução igual ou su­
perior a 1 segundo.
43) A medição do tempo não deve ser afetada por um corte
exterior na alimentação energética inferior a 12 meses, em
condições de homologação do tipo.
3.4 Controlo das atividades do condutor
44) Esta função deve acompanhar permanente e separadamente
as atividades de um condutor e de um ajudante.
45) Atividades de condutor: DRIVING (condução), WORK
(trabalho), AVAILABILITY (disponibilidade) ou BREAK/
/REST (pausa/repouso).
46) Deve ser possível ao condutor e/ou ao ajudante selecionar
manualmente WORK, AVAILABILITY ou BREAK/REST.
47) Com o veículo em movimento, é selecionada automatica­
mente a atividade DRIVING para o condutor e a atividade
AVAILABILITY para o ajudante.
48) Com o veículo parado, é selecionada automaticamente a
atividade WORK para o condutor.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 31
49) A primeira mudança de atividade para BREAK/REST ou
AVAILABILITY que ocorra dentro de 120 segundos após a
passagem automática para WORK, devido à paragem do
veículo, é considerada como tendo ocorrido no momento
da paragem do veículo (podendo, portanto, anular a passa­
gem para WORK).
▼B
50) Esta função transmite as mudanças de atividade às funções
de registo, com uma resolução de 1 minuto.
51) Se for registada uma atividade DRIVING dentro do minuto
imediatamente anterior a um dado intervalo de 1 minuto ou
dentro do minuto imediatamente posterior a ele, todo esse
intervalo de 1 minuto será considerado DRIVING.
52) Dado um intervalo de 1 minuto que não seja considerado
DRIVING nos termos do requisito n. o 51, todo esse inter­
valo será considerado como do mesmo tipo que a mais
longa atividade contínua ocorrida dentro dele (ou a última
de várias atividades igualmente longas).
53) Esta função deve também acompanhar permanentemente o
tempo de condução contínua e o tempo acumulado de pau­
sas do condutor.
3.5 Controlo da situação de condução
54) Esta função deve acompanhar permanente e automatica­
mente a situação da condução.
55) A situação de condução CREW (tripulação) é selecionada
quando dois cartões válidos de condutor são inseridos no
aparelho de controlo. Em qualquer outro caso, é selecionada
a situação de condução SINGLE (elemento só).
3.6 Entradas dos condutores
3.6.1 Introdução do lugar de início e/ou de final do período diário de
trabalho
56) Esta função permite introduzir os lugares em que se iniciam
e/ou concluem os períodos diários de trabalho, segundo o
condutor e/ou o ajudante.
▼M3
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 memori­
zado, 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 pe­
ríodo diário de trabalho durante a introdução manual
nos termos do requisito 61,
▼M1
02016R0799 — PT — 21.08.2023 — 003.002 — 32
— 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 tra­
balho tenha início ou termine durante a introdução ma­
nual nos termos do disposto no requisito 61.
▼B
60) Deve ser possível introduzir lugares de início e/ou final do
período diário de trabalho por meio de comandos nos me­
nus. Se se introduzir mais do que uma entrada desse tipo no
intervalo de um minuto, será mantido apenas o registo da
entrada relativa ao último lugar de início e ao último lugar
final introduzidos nesse intervalo.
▼M3
O aparelho de controlo apresenta o lugar atual do veículo
com base na informação do GNSS e do(s) mapa(a) digi­
tal(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
3.6.2 Introdução manual das atividades dos condutores e consentimento
para interface ITS
▼M3
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) selecio­
nados 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 con­
dutor ou cartão de oficina, de momento desconhecido da
unidade-veículo, o titular do cartão é convidado a manifes­
tar 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 me­
morizados na respetiva memória de dados, conforme esta­
belecido no requisito 133.
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 33
Desde que o cartão de condutor (ou de oficina) esteja inse­
rido, 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), AVAILABI­
LITY (disponibilidade) ou BREAK/REST (pausa/re­
pouso),
— 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 ne­
cessá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 oportuni­
dade 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 reti­
rada 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 apa­
relho 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 traba­
lho anterior termina sobrepõe-se então à introdução tempo­
rária efetuada na última retirada do cartão.
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 34
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 interrom­
pida, o aparelho de controlo valida os dados completos já
introduzidos relativamente ao lugar e à atividade (que te­
nham lugar ou hora inequívocos ou tenham tipo de ativi­
dade, 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 ma­
nualmente de acordo com o seguinte procedimento mínimo:
— introduzir manualmente, por ordem cronológica, as ati­
vidades 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é-fi­
xada 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é à vali­
dação por seleção de um comando específico. A partir de
então, já não serão permitidas tais modificações.
▼B
3.6.3 Introdução de condições especiais
▼M3
62) O aparelho de controlo deve permitir ao condutor introdu­
zir, 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.
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 35
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 utili­
zadores 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 selecio­
nar «BREAK/REST» no batelão ou comboio.
O aparelho de controlo deve terminar uma condição
«FERRY/TRAIN CROSSING» aberta quando ocorrer qual­
quer 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 bate­
lã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.
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 si­
multâ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/des­
carga é realizada.
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 36
3.7 Gestão dos bloqueamentos da empresa
63) Esta função deve permitir que a gestão dos bloqueamentos
efetuados por uma empresa restrinja a si o acesso aos dados
em modo de empresa.
64) Os bloqueamentos da empresa compreendem uma data/hora
de início (lock-in) e uma data/hora de cessação (lock-out),
associadas à identificação da empresa por intermédio do
número do seu cartão (no lock-in).
65) Os bloqueamentos só em tempo real podem ser desencadea­
dos (lock-in) ou cessados (lock-out).
66) A cessação do bloqueamento (lock-out) só será possível à
empresa que o tiver desencadeado (lock-in) (identificada
pelos primeiros treze algarismos do número do respetivo
cartão de empresa), ou,
67) O bloqueamento cessará automaticamente (lock-out) se ou­
tra empresa desencadear um bloqueamento (lock-in).
68) No caso de uma empresa desencadear um bloqueamento
(lock-in), tendo o bloqueamento anterior sido para a mesma
empresa, assume-se que o bloqueamento anterior não foi
«cessado» e ainda está «desencadeado».
3.8 Vigilância das atividades de controlo
69) Esta função deve vigiar as atividades DISPLAYING (visua­
lização), PRINTING (impressão), VU (unidade-veículo) e
DOWNLOADING (descarga) do cartão, bem como as ati­
vidades de controlo ROADSIDE CALIBRATION (calibra­
ção em estrada), em modo de controlo.
70) Esta função deve vigiar também as atividades OVER SPEE­
DING CONTROL (controlo de excesso de velocidade), em
modo de controlo. Considera-se que houve controlo de ex­
cesso de velocidade quando, em modo de controlo, é en­
viada a mensagem «excesso de velocidade» para a impres­
sora ou para o visor ou quando da memória de dados da
VU são descarregados «incidentes e falhas».
3.9 Deteção de incidentes e/ou falhas
71) Esta função deve detetar os seguintes incidentes e/ou falhas:
3.9.1 Incidente «inserção de cartão não válido»
72) Este incidente produz-se quando é inserido um cartão não
válido, quando é inserido um cartão de condutor já subs­
tituído e/ou quando expira o prazo de validade de um cartão
inserido.
3.9.2 Incidente «conflito de cartões»
73) Este incidente produz-se quando se verifica qualquer uma
das combinações entre cartões válidos assinaladas com X no
quadro seguinte:
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 37
Conflito de cartões
Ranhura do condutor
Ausência de car­
tão
Cartão de condu­
tor
Cartão de controlo Cartão de oficina Cartão de empresa
R
an
hu
ra
d
o
aj
ud
an
te
Ausência de cartão
Cartão de condutor X
Cartão de controlo X X X
Cartão de oficina X X X X
Cartão de empresa X X X
3.9.3 Incidente «sobreposição de tempos»
74) Este incidente produz-se quando a data/hora da última reti­
rada de um cartão de condutor, lida nesse cartão, é posterior
à data/hora atual do aparelho de controlo no qual o cartão
está inserido.
3.9.4 Incidente «condução sem cartão adequado»
75) Este incidente produz-se quando se verifica qualquer uma
das combinações entre cartões tacográficos assinaladas com
X no quadro seguinte, quando a atividade do condutor
muda para DRIVING ou quando há mudança no modo de
funcionamento sendo DRIVING a atividade do condutor:
Condução sem cartão adequado
Ranhura do condutor
Cartão ausente ou
não válido
Cartão de condu­
tor
Cartão de controlo Cartão de oficina Cartão de empresa
R
an
hu
ra
d
o
aj
ud
an
te

Cartão ausente ou
não-válido
X X X
Cartão de condutor X X X X
Cartão de controlo X X X X X
Cartão de oficina X X X X
Cartão de empresa X X X X X
3.9.5 Incidente «inserção de cartão durante a condução»
76) Este incidente produz-se quando é inserido um cartão taco­
gráfico em qualquer ranhura sendo DRIVING a atividade
do condutor.
3.9.6 Incidente «última sessão de cartão encerrada incorretamente»
77) Este incidente produz-se quando, na inserção de um cartão,
o aparelho de controlo deteta que, apesar do disposto na
secção 3.1, a anterior sessão não foi encerrada corretamente
(cartão retirado antes de nele terem sido registados todos os
dados importantes). Este incidente só se produz com cartões
de condutor ou de oficina.
3.9.7 Incidente «excesso de velocidade»
78) Este incidente produz-se em situações de excesso de
velocidade.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 38
3.9.8 Incidente «interrupção da alimentação energética»
79) Este incidente produz-se, fora do modo de calibração ou do
modo de controlo, se a alimentação energética do sensor de
movimentos e/ou da unidade-veículo for interrompida du­
rante mais de 200 milésimos de segundo. O limiar da in­
terrupção deve ser indicado pelo fabricante. A queda na
alimentação energética em consequência da colocação do
motor do veículo em marcha não deve acionar este
incidente.
3.9.9 Incidente «Erro de comunicação com o sistema de comunicação à
distância»
80) Este incidente produz-se, fora do modo de calibração,
quando o sistema de comunicação à distância não reconhece
a receção bem-sucedida de dados de comunicação à distân­
cia enviados a partir da unidade-veículo por mais de três
tentativas.
3.9.10 Incidente «Ausência de informações sobre a posição do recetor
GNSS»
81) Este incidente produz-se, fora do modo de calibração, em
caso de ausência de informações sobre a posição inicial do
recetor GNSS (interno ou externo) durante mais de três
horas de tempo de condução acumulado.
3.9.11 Incidente «Erro de comunicação com o módulo GNSS externo»
82) Este incidente produz-se, fora do modo de calibração, em
caso de interrupção da comunicação entre o módulo GNSS
externo e a unidade-veículo durante mais de 20 minutos
contínuos, estando o veículo em movimento.
3.9.12. Incidente «erro nos dados de movimento»
▼M3
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âm­
bio 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
3.9.13 Incidente «Conflito relativo ao movimento do veículo»
▼M3
84) Este incidente produz-se, conforme especificado no apên­
dice 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 calcula­
das 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.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 39
3.9.14 Incidente «tentativa de violação da segurança»
85) Este incidente produz-se perante qualquer outro incidente
que afete a segurança do sensor de movimentos e/ou da
unidade-veículo e/ou do módulo GNSS externo, em confor­
midade com o apêndice 10, fora do modo de calibração.
▼M1
3.9.15 Incidente «conflito de tempo»
▼M3
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 re­
cetor 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 desenca­
dear o incidente «conflito de tempo» imediatamente antes
de reajustar automaticamente o seu relógio interno em con­
formidade com o requisito 211.
▼B
3.9.16 Falha do «cartão»
87) Esta falha ocorre se se verificar algum defeito no cartão
tacográfico durante o funcionamento.
3.9.17 Falha do «aparelho de controlo»
88) Esta falha ocorre, fora do modo de calibração, perante qual­
quer das seguintes:
— Falha interna da VU
— Falha da impressora
— Falha do visor
— Falha do descarregamento
— Falha do sensor
— Falha do recetor GNSS ou do módulo GNSS externo
— Falha do sistema de comunicação à distância
▼M3
— Falha da interface ITS.
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, con­
forme 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.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 40
3.10 Ensaios incorporados e autoensaios
89) O aparelho de controlo deve detetar automaticamente falhas,
por meio de autoensaios e de ensaios incorporados, em
conformidade com o quadro seguinte:
Subconjunto a ensaiar Autoensaio Ensaio incorporado
Software Integridade
Memória de dados Acesso Acesso, integridade de
dados
Interfaces dos cartões Acesso Acesso
Teclado Verificação manual
Impressora (ao critério do fabri­
cante)
Impressão
Visualizar Controlo visual
Descarregamento
(executado só durante o
descarregamento)
Funcionamento cor­
reto
Sensor Funcionamento cor­
reto
Funcionamento correto
Sistema de comunicação à
distância
Funcionamento cor­
reto
Funcionamento correto
Módulo GNSS Funcionamento cor­
reto
Funcionamento correto
▼M3
Interface ITS Funcionamento cor­
reto
▼B
3.11 Leitura da memória de dados
90) O aparelho de controlo deve poder ler quaisquer dados
memorizados na sua memória.
3.12 Registo e memorização de dados na memória
▼M3
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 con­
duçã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» in­
clua pelo menos 7300 travessias de fronteiras,
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 41
— 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 indica­
dor que denota se a posição foi autenticada.
▼B
91) Os dados memorizados na memória não devem ser afetados
por um corte exterior na alimentação energética inferior a
12 meses, em condições de homologação. Por sua vez, os
dados memorizados no sistema externo de comunicação à
distância, conforme a definição constante do apêndice 14,
não devem ser afetados por um corte na alimentação ener­
gética inferior a 28 dias.
92) O aparelho de controlo deve poder registar e memorizar na
sua memória, implícita ou explicitamente, os seguintes
dados:
3.12.1 Dados de identificação do aparelho
3.12.1.1 D a d o s d e i d e n t i f i c a ç ã o d a u n i d a d e - v e í c u l o
93) O aparelho de controlo deve poder memorizar na sua me­
mória os seguintes dados de identificação da
unidade-veículo:
— nome do fabricante
— endereço do fabricante
— número da peça
— número de série
— geração da VU
— capacidade de utilização de cartões tacográficos da pri­
meira geração
— número da versão do software
— data de instalação da versão do software
— ano de fabrico do aparelho
— número de homologação
▼M3
— identificador da versão do mapa digital (requisito 133-L).
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 regu­
lamento e de acordo com a capacidade de utilização de
cartões tacográficos da primeira geração.
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 42
3.12.1.2 D a d o s d e i d e n t i f i c a ç ã o d o s e n s o r d e m o v i m e n t o s
95) O sensor de movimentos deve poder memorizar na sua
memória os seguintes dados de identificação:
— nome do fabricante
— número de série
— número de homologação
— identificador incorporado do componente de segurança
(por exemplo, número de chip/processador interno)
— identificador do sistema operativo (por exemplo, nú­
mero da versão do software)
96) Os dados de identificação do sensor de movimentos são
registados e memorizados definitivamente nele pelo seu
fabricante.
▼M3
97) A unidade-veículo deve poder registar e memorizar na sua
memória os seguintes dados relativos aos 20 emparelhamen­
tos bem-sucedidos mais recentes dos sensores de movimen­
tos (se, no espaço de um dia de calendário, ocorrerem
vários emparelhamentos, serão armazenados apenas o pri­
meiro e o último desse dia):
▼B
Para cada um desses emparelhamentos, devem registar-se
os seguintes dados:
— Dados de identificação do sensor de movimentos:
— número de série
— número de homologação
— Dados de emparelhamento do sensor de movimentos:
— data do emparelhamento.
3.12.1.3 D a d o s d e i d e n t i f i c a ç ã o d o s s i s t e m a s g l o b a i s d e
n a v e g a ç ã o p o r s a t é l i t e
98) O módulo GNSS externo deve poder memorizar na sua
memória os seguintes dados de identificação:
— nome do fabricante
— número de série
— número de homologação
— identificador incorporado do componente de segurança
(por exemplo, número de chip/processador interno)
— identificador do sistema operativo (por exemplo, nú­
mero da versão do software)
99) Os dados de identificação são registados e memorizados
definitivamente no módulo GNSS externo, pelo seu
fabricante.
▼M3
100) A unidade-veículo deve poder registar e memorizar na sua
memória os seguintes dados relativos aos 20 emparelhamen­
tos bem-sucedidos mais recentes dos módulos GNSS exter­
nos (se, no espaço de um dia de calendário, ocorrerem
vários emparelhamentos, serão armazenados apenas o pri­
meiro e o último desse dia).
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 43
Para cada um desses emparelhamentos, devem registar-se
os seguintes dados:
— Dados de identificação do módulo GNSS externo:
— número de série
— número de homologação
— Dados de emparelhamento do módulo GNSS externo:
— data do emparelhamento
3.12.2 Chaves e certificados
101) O aparelho de controlo deve poder memorizar várias chaves
e certificados criptográficos, conforme especifica o apên­
dice 11, parte A e parte B.
3.12.3 Dados relativos à inserção e à retirada de cartões de condutor ou
de oficina
102) Por cada ciclo de inserção e retirada de um cartão de con­
dutor ou de oficina, o aparelho de controlo regista e me­
moriza na sua memória de dados:
— O apelido e o nome próprio do titular do cartão, con­
forme registo no mesmo
— O número, o Estado-Membro emissor e o prazo de
validade do cartão, conforme registo no mesmo
— A geração do cartão
— A data e a hora da inserção do cartão
— O valor do conta-quilómetros do veículo no momento
da inserção
— A ranhura na qual o cartão foi inserido
— A data e a hora da retirada do cartão
— O valor do conta-quilómetros do veículo no momento
da retirada
— Os seguintes elementos relativos ao veículo anterior­
mente utilizado pelo titular do cartão, conforme registo
neste:
— VRN e Estado-Membro de matrícula
— Geração da VU (quando disponível)
— Data e hora da retirada do cartão
— Um indicador de o titular ter efetuado ou não a intro­
dução manual de atividades no momento da inserção do
cartão.
103) A memória deve poder guardar estes dados durante pelo
menos 365 dias.
104) Quando se esgota a capacidade de memorização, os dados
mais antigos são substituídos por dados mais recentes.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 44
3.12.4 Dados relativos à atividade de condutor
105) O aparelho de controlo deve registar e memorizar na sua
memória de dados qualquer mudança na atividade do con­
dutor ou do ajudante, qualquer mudança na situação da
condução e/ou qualquer inserção ou retirada de um cartão
de condutor ou de oficina:
— situação da condução (CREW, SINGLE)
— ranhura (DRIVER, CO-DRIVER)
— situação do cartão na ranhura correspondente: INSER­
TED (inserido), NOT INSERTED (não inserido)
— atividade (DRIVING, AVAILABILITY, WORK,
BREAK/REST)
— data e hora da mudança.
Por INSERTED entende-se que se encontra inserido na
ranhura um cartão válido de condutor ou de oficina. Por
NOT INSERTED entende-se o contrário, ou seja, que na
ranhura não se encontra inserido nenhum cartão válido de
condutor ou de oficina (por exemplo, não foi inserido ne­
nhum cartão ou o inserido é de empresa).
Os dados relativos à atividade introduzidos manualmente
por um condutor não são registados na memória.
106) A memória deve poder guardar durante pelo menos 365
dias os dados relativos à atividade do condutor.
107) Quando se esgota a capacidade de memorização, os dados
mais antigos são substituídos por dados mais recentes.
▼M1
3.12.5 Locais e posições em que se iniciam e concluem os períodos diários
de trabalho e/ou em que são alcançados os períodos de três horas de
condução acumulados
108) O aparelho de controlo deve registar e memorizar na sua
memória os seguintes dados:
— locais e posições em que o condutor e/ou o ajudante
inicia o seu período diário de trabalho;
— posições em que o tempo de condução acumulado
atinge um múltiplo de três horas;
— locais e posições em que o condutor e/ou o ajudante
conclui o seu período diário de trabalho.
▼B
109) Quando a posição do veículo não está disponível a partir do
recetor GNSS nessas ocasiões, o aparelho de controlo deve
utilizar a última posição disponível, bem como as corres­
pondentes data e hora.
110) Juntamente com cada local ou posição, o aparelho de con­
trolo deve registar e memorizar na sua memória os seguin­
tes dados:
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 45
— o número do cartão do condutor e/ou do ajudante e o
Estado-Membro emissor do cartão
▼B
— A geração do cartão
— A data e a hora da introdução de dados
▼M1
— O tipo de introdução (início, final ou 3 horas de tempo
de condução acumulado)
▼B
— A precisão relativa ao GNSS, a data e a hora, quando
aplicável
— O valor do conta-quilómetros do veículo
▼M3
— um indicador que denota se a posição foi autenticada.
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.
▼M1
111) A memória deve poder guardar os locais e as posições em
que se iniciam e concluem os períodos diários de trabalho
e/ou em que são alcançados os períodos de 3 horas de
condução acumulados durante pelo menos 365 dias.
▼B
112) Quando se esgota a capacidade de memorização, os dados
mais antigos são substituídos por dados mais recentes.
3.12.6 Dados do conta-quilómetros
113) O aparelho de controlo deve registar na sua memória de
dados o valor do conta-quilómetros do veículo e a corres­
pondente data, à meia-noite de cada dia.
114) A memória deve poder guardar durante pelo menos 365
dias os valores do conta-quilómetros registados à
meia-noite.
115) Quando se esgota a capacidade de memorização, os dados
mais antigos são substituídos por dados mais recentes.
3.12.7 Dados relativos à velocidade
▼M1
116) O aparelho de controlo deve registar e memorizar na sua
memória de dados a velocidade instantânea do veículo e as
correspondentes data e hora, a cada segundo de pelo menos
as últimas 24 horas de movimento do veículo.
▼B
3.12.8 Dados relativos a incidentes
Para efeitos da presente secção, os tempos devem ser registados com
a resolução de 1 segundo.
117) Relativamente a cada incidente detetado, o aparelho de con­
trolo deve registar e memorizar na sua memória, segundo as
regras indicadas, os seguintes dados:
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 46
Incidente Regras de memorização Dados a registar por cada incidente
Inserção de cartão não vá­
lido
— os 10 incidentes mais recentes — data e hora do incidente
— tipo, número, Estado-Membro emissor e
geração do cartão que causa o incidente
— número de incidentes similares nesse dia
Conflito de cartões — os 10 incidentes mais recentes — data e hora do início do incidente
— data e hora do final do incidente
— tipo, número, Estado-Membro emissor e
geração dos dois cartões que causam o
conflito
Condução sem cartão ade­
quado
— o incidente mais longo de cada um dos
últimos 10 dias de ocorrência
— os 5 incidentes mais longos dos últimos
365 dias
— data e hora do início do incidente
— data e hora do final do incidente
— tipo, número, Estado-Membro emissor e
geração de qualquer cartão inserido no
início e/ou no final do incidente
— número de incidentes similares nesse dia
Inserção de cartão durante
condução
— o último incidente de cada um dos úl­
timos 10 dias de ocorrência
— data e hora do incidente
— tipo, número, Estado-Membro emissor e
geração
— número de incidentes similares nesse dia
▼M3
Ú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.
▼B
Excesso de velocidade (1) — o incidente mais grave (ou seja, o caso
de velocidade média mais elevada) de
cada um dos últimos 10 dias de ocor­
rência
— um dos 5 incidentes mais graves dos
últimos 365 dias
— o primeiro incidente desde a última ca­
libração
— data e hora do início do incidente
— data e hora do final do incidente
— velocidade máxima medida durante o in­
cidente
— velocidade média (aritmética) medida
durante o incidente
— tipo, número, Estado-Membro emissor e
geração do cartão de condutor (quando
aplicável)
— número de incidentes similares nesse dia
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 47
Incidente Regras de memorização Dados a registar por cada incidente
Interrupção da alimenta­
ção energética (2)
— o incidente mais longo de cada um dos
últimos 10 dias de ocorrência
— os 5 incidentes mais longos dos últimos
365 dias
— data e hora do início do incidente
— data e hora do final do incidente
— tipo, número, Estado-Membro emissor e
geração de qualquer cartão inserido no
início e/ou no final do incidente
— número de incidentes similares nesse dia
Erro de comunicação com
o sistema de comunicação
à distância
— o incidente mais longo de cada um dos
últimos 10 dias de ocorrência
— os 5 incidentes mais longos dos últimos
365 dias
— data e hora do início do incidente
— data e hora do final do incidente
— tipo, número, Estado-Membro emissor e
geração de qualquer cartão inserido no
início e/ou no final do incidente
— número de incidentes similares nesse dia
Ausência de informações
sobre a posição do recetor
GNSS
— o incidente mais longo de cada um dos
últimos 10 dias de ocorrência
— os 5 incidentes mais longos dos últimos
365 dias
— data e hora do início do incidente
— data e hora do final do incidente
— tipo, número, Estado-Membro emissor e
geração de qualquer cartão inserido no
início e/ou no final do incidente
— número de incidentes similares nesse dia
▼M1
Erro de comunicação com
o módulo GNSS externo
— o incidente mais longo de cada um dos
últimos 10 dias de ocorrência,
— os 5 incidentes mais longos dos últimos
365 dias.
— data e hora do início do incidente,
— data e hora do final do incidente,
— tipo, número, Estado-Membro emissor e
geração de qualquer cartão inserido no
início e/ou no final do incidente,
— número de incidentes similares nesse dia
▼B
Erro nos dados de movi­
mento
— o incidente mais longo de cada um dos
últimos 10 dias de ocorrência
— os 5 incidentes mais longos dos últimos
365 dias
— data e hora do início do incidente
— data e hora do final do incidente
— tipo, número, Estado-Membro emissor e
geração de qualquer cartão inserido no
início e/ou no final do incidente
— número de incidentes similares nesse dia
Conflito relativo ao movi­
mento do veículo
— o incidente mais longo de cada um dos
últimos 10 dias de ocorrência
— os 5 incidentes mais longos dos últimos
365 dias
— data e hora do início do incidente
— data e hora do final do incidente
— tipo, número, Estado-Membro emissor e
geração de qualquer cartão inserido no
início e/ou no final do incidente
— número de incidentes similares nesse dia
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 48
Incidente Regras de memorização Dados a registar por cada incidente
Tentativas de violação da
segurança
— os 10 incidentes mais recentes por tipo
de incidente
— data e hora do início do incidente
— data e hora do final do incidente (se per­
tinente)
— tipo, número, Estado-Membro emissor e
geração de qualquer cartão inserido no
início e/ou no final do incidente
— tipo de incidente
▼M1
Conflito de tempo — o incidente mais grave de cada um dos
últimos 10 dias de ocorrência (ou seja,
os que apresentarem a maior diferença
entre data e hora no aparelho de con­
trolo e data e hora no GNSS),
— os 5 incidentes mais graves dos últimos
365 dias.
— data e hora do aparelho de controlo,
— data e hora do GNSS,
— tipo, número, Estado-Membro emissor e
geração de qualquer cartão inserido no
início e/ou no final do incidente,
— número de incidentes similares nesse dia
▼M3
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.
▼B
(1) O aparelho de controlo deve igualmente registar e me­
morizar na sua memória os seguintes dados:
— data e hora do último OVER SPEEDING CON­
TROL (controlo do excesso de velocidade)
— data e hora do primeiro excesso de velocidade a
seguir ao anterior OVER SPEEDING CONTROL
— número de incidentes de excesso de velocidade
desde o último OVER SPEEDING CONTROL.
(2) Estes dados só podem ser registados após a reposição
da alimentação energética. Os tempos podem ser conhe­
cidos com precisão até ao minuto.
3.12.9 Dados relativos a falhas
Para efeitos da presente secção, os tempos devem ser registados com
a resolução de 1 segundo.
118) Relativamente a cada falha detetada, o aparelho de controlo
deve procurar registar e memorizar na sua memória, se­
gundo as regras indicadas, os seguintes dados:
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 49
Falha Regras de memorização Dados a registar por cada falha
Falhas do cartão — as 10 falhas mais recentes de cartão de
condutor
— data e hora do início da falha
— data e hora do final da falha
— data e hora do início da falha, tipo, nú­
mero, Estado-Membro emissor e gera­
ção do cartão
Falhas do aparelho de
controlo
— as 10 falhas mais recentes por tipo de
falha
— a primeira falha ocorrida desde a úl­
tima calibração
— data e hora do início da falha, data e
hora do início da falha
— data e hora do final da falha
— tipo de falha
— tipo, número, Estado-Membro emissor e
geração de qualquer cartão inserido no
início e/ou no final da falha
3.12.10 Dados relativos à calibração
119) O aparelho de controlo deve registar e memorizar na sua
memória dados com interesse para:
— parâmetros conhecidos de calibração no momento da
ativação
— a primeira calibração após a ativação
— a primeira calibração no veículo em questão (identifi­
cado pelo VIN)
— as 20 calibrações mais recentes (se ocorrerem várias no
mesmo dia, é memorizada unicamente a última).
120) Para cada uma das seguintes calibrações, são registados os
seguintes dados:
— objetivo da calibração (ativação, primeira instalação,
instalação, inspeção periódica)
— nome e endereço da oficina
— número, Estado-Membro emissor e prazo de validade
do cartão de oficina
— identificação do veículo
— parâmetros atualizados ou confirmados: dimensão w, k,
l, medida do pneumático, ponto de regulação do dispo­
sitivo de limitação da velocidade, conta-quilómetros
(antigos e novos valores), data e hora (antigos e novos
valores)
— tipos e identificadores de todos os selos em vigor
▼M3
— 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)
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 50
— 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
121) O aparelho de controlo deve também registar e memorizar
na sua memória de dados a capacidade de utilização de
cartões tacográficos da primeira geração (ainda ativados
ou não).
122) O sensor de movimentos deve registar e memorizar na sua
memória os seguintes dados relativos à sua instalação:
— primeiro emparelhamento com uma VU (data, hora,
número de homologação da VU, número de série da
VU)
— último emparelhamento com uma VU (data, hora, nú­
mero de homologação da VU, número de série da VU).
123) O módulo GNSS externo deve registar e memorizar na sua
memória os seguintes dados relativos à instalação do mó­
dulo GNSS externo:
— primeiro emparelhamento com uma VU (data, hora,
número de homologação da VU, número de série da
VU)
— último emparelhamento com uma VU (data, hora, nú­
mero de homologação da VU, número de série da VU).
3.12.11 Dados relativos ao ajustamento do tempo
124) O aparelho de controlo deve registar e memorizar na sua
memória dados importantes para os ajustamentos do tempo
realizados em modo de calibração fora do âmbito de uma
calibração regular (definição f)):
— o mais recente ajustamento do tempo
— os 5 maiores ajustamentos do tempo
125) São registados os seguintes dados por cada um destes ajus­
tamentos do tempo:
— data e hora (antigo valor)
— data e hora (novo valor)
— nome e endereço da oficina
— número, Estado-Membro emissor, geração e prazo de
validade do cartão de oficina.
3.12.12 Dados relativos à atividade de controlo
126) O aparelho de controlo deve registar e memorizar na sua
memória os seguintes dados relativos às vinte atividades de
controlo mais recentes:
— data e hora do controlo
— número, Estado-Membro emissor e geração do cartão
de controlo
— tipo do controlo: visualização e/ou impressão e/ou des­
carregamento da VU e/ou descarregamento do cartão
e/ou controlo de calibração de estrada.
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 51
127) Em caso de descarregamento, são igualmente registadas as
datas dos dias descarregados mais antigo e mais recente.
3.12.13 Dados relativos aos bloqueamentos da empresa
128) O aparelho de controlo deve registar e memorizar na sua
memória os seguintes dados relativos aos 255 bloqueamen­
tos mais recentes da empresa:
— data e hora de início do bloqueamento (lock-in)
— data e hora de cessação do bloqueamento (lock-out)
— número, Estado-Membro emissor e geração do cartão
de empresa
— nome e endereço da empresa.
Devem tratar-se como não bloqueados os dados anterior­
mente bloqueados por um bloqueamento que, devido ao
limite supramencionado, foi apagado da memória.
3.12.14 Dados relativos à atividade de descarregamento
129) O aparelho de controlo deve registar e memorizar na sua
memória os seguintes dados relativos ao último descarrega­
mento de dados para meios externos em modo de empresa
ou de calibração:
— data e hora do descarregamento
— número, Estado-Membro emissor e geração do cartão
de empresa ou oficina
— nome da empresa ou da oficina.
3.12.15 Dados relativos às condições especiais
130) O aparelho de controlo deve registar na sua memória os
seguintes dados relativos a condições especiais:
— data e hora da introdução
— tipo de condição especial.
131) A memória deve poder guardar durante pelo menos 365
dias os dados relativos a condições especiais (partindo do
princípio de que, em média, é aberta e encerrada 1 condi­
ção por dia). Quando se esgota a capacidade de memoriza­
ção, os dados mais antigos são substituídos por dados mais
recentes.
3.12.16 Dados relativos ao cartão tacográfico
132) O aparelho de controlo deve poder memorizar os seguintes
dados relativos aos diferentes cartões tacográficos nos quais
foram utilizados, na VU:
— o número do cartão tacográfico e o respetivo número de
série
— o fabricante do cartão tacográfico
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 52
— o tipo de cartão tacográfico
— a versão do cartão tacográfico.
133) O aparelho de controlo deve poder memorizar pelo menos
88 registos deste tipo.
▼M3
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 con­
trolo deve registar e memorizar na sua memória os seguin­
tes 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 dis­
poní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,
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 53
— a data e a hora da operação de carga/descarga,
— a precisão, data e hora do GNSS relacionadas, se apli­
cá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 me­
nos 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 per­
mitidos 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 ins­
talados 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.
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 54
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.
▼B
3.13 Leitura de cartões tacográficos
134) O aparelho de controlo deve poder ler nos cartões tacográ­
ficos de primeira e segunda geração, consoante os casos, os
dados necessários para:
— identificar o tipo e o titular do cartão, o veículo utili­
zado anteriormente, a data e a hora da última retirada
do cartão e a atividade selecionada nesse momento
— verificar se a última sessão do cartão foi corretamente
encerrada
▼M3
— relativamente às semanas anterior e em curso, calcular o
tempo de condução contínua do condutor, o tempo acu­
mulado de pausas e o tempo acumulado de condução;
▼B
— fazer as impressões que se pretendam dos dados regis­
tados num cartão de condutor
— descarregar um cartão de condutor para meios externos.
Este requisito aplica-se somente aos cartões tacográficos de
primeira geração, caso a sua utilização não tenha sido su­
primida por uma oficina.
135) Na eventualidade de um erro de leitura, o aparelho de con­
trolo faz, no máximo, três novas tentativas, após o que, não
obtendo êxito, declara o cartão defeituoso e não válido.
▼M3
135-A) A estrutura na aplicação «TACHO_G2» depende da versão.
Os cartões da versão 2 contêm ficheiros elementares com­
plementares 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 memo­
rizada 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 memo­
rizada com a posição correspondente em EF Places.
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 55
— 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/des­
carga e tipos de carga.
— nos cartões de oficina:
— EF Calibration_Add_Data contém dados de calibra­
ção complementares dos memorizados em EF Cali­
bration. 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_Pla­
ces_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.
▼B
3.14 Registo e memorização de dados nos cartões tacográficos
3.14.1 Registo e memorização de dados nos cartões tacográficos de pri­
meira geração
136) Desde que os cartões tacográficos de primeira geração não
tenham sido suprimidos por uma oficina, o aparelho de
controlo deve registar e memorizar dados exatamente da
mesma forma que faria um aparelho de controlo da pri­
meira geração.
137) O aparelho de controlo deve lançar no cartão de condutor
ou de oficina, imediatamente após a sua inserção, os «da­
dos da sessão do cartão».
138) O aparelho de controlo deve atualizar os dados memoriza­
dos em cartões válidos de condutor, de oficina, de empresa
e/ou de controlo, com todos os dados de interesse para o
período durante o qual o cartão está inserido e para o seu
titular. Os dados memorizados nestes cartões são especifi­
cados no capítulo 4.
139) O aparelho de controlo deve atualizar os dados relativos à
atividade e à localização do condutor (conforme especifi­
cado nos pontos 4.5.3.1.9 e 4.5.3.1.11), memorizados em
cartões válidos de condutor e/ou de oficina, com os dados
relativos à atividade e à localização que o titular introduz
manualmente.
▼M3
140) Todos os incidentes e falhas não definidos para o aparelho
de controlo da primeira geração não devem ser memoriza­
dos nos cartões de condutor e de oficina.
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 56
141) A atualização dos dados de cartões tacográficos deve ser de
molde a que, se necessário e tendo em conta a capacidade
efetiva de memorização do cartão, os dados mais recentes
substituam os mais antigos.
142) Na eventualidade de um erro de escrita, o aparelho de
controlo faz, no máximo, três novas tentativas, após o
que, não obtendo êxito, declara o cartão defeituoso e não
válido.
▼M3
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
3.14.2 Registo e memorização de dados nos cartões tacográficos da se­
gunda geração
144) Os cartões tacográficos da segunda geração devem conter 2
aplicações diferentes para cartões, a primeira das quais será
exatamente a mesma que a aplicação TACHO dos cartões
tacográficos da primeira geração e a segunda a aplicação
«TACHO_G2», conforme especificado no capítulo 4 e no
apêndice 2.
▼M3
A estrutura na aplicação «TACHO_G2» depende da versão.
Os cartões da versão 2 contêm ficheiros elementares com­
plementares aos dos cartões da versão 1.
▼B
145) O aparelho de controlo deve lançar no cartão de condutor
ou de oficina, imediatamente após a sua inserção, os «da­
dos da sessão do cartão».
146) O aparelho de controlo deve atualizar os dados memoriza­
dos nas 2 aplicações de cartões válidos de condutor, de
oficina, de empresa e/ou de controlo, com todos os dados
de interesse para o período durante o qual o cartão está
inserido e para o seu titular. Os dados memorizados nestes
cartões são especificados no capítulo 4.
147) O aparelho de controlo deve atualizar os dados relativos aos
locais de atividade e às posições do condutor (conforme
especificado nos pontos 4.5.3.1.9, 4.5.3.1.11, 4.5.3.2.9 e
4.5.3.2.11), memorizados em cartões válidos de condutor
e/ou de oficina, com os dados relativos à atividade e aos
locais que o titular introduz manualmente.
▼M3
147-A) Aquando da inserção de um cartão de condutor ou de ofi­
cina, 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 ofi­
cina 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 memori­
zado 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;
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 57
— 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.
▼B
148) A atualização dos dados de cartões tacográficos deve ser de
molde a que, se necessário e tendo em conta a capacidade
efetiva de memorização do cartão, os dados mais recentes
substituam os mais antigos.
149) Na eventualidade de um erro de escrita, o aparelho de
controlo faz, no máximo, três novas tentativas, após o
que, não obtendo êxito, declara o cartão defeituoso e não
válido.
150) Antes de libertar um cartão de condutor e depois de me­
morizar todos os dados de interesse nas duas aplicações do
cartão, o aparelho de controlo restabelece os «dados da
sessão do cartão».
▼M3
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.
▼B
3.15 Visualização
151) Na visualização de mensagens deve haver pelo menos 20
carateres.
152) As dimensões mínimas de um caráter devem ser de 5 mm
de altura por 3,5 mm de largura.
153) A visualização deve aceitar os carateres indicados no apên­
dice 1, capítulo 4, «Conjuntos de carateres». A visualização
pode utilizar símbolos simplificados (por exemplo, ausência
de acento gráfico, maiúsculas em lugar de minúsculas, etc.).
154) Na visualização deve ser utilizada iluminação adequada,
não ofuscante.
155) As indicações devem ser visíveis de fora do aparelho de
controlo.
156) O aparelho de controlo deve poder exibir para visualização:
— data do incumprimento
— dados relativos a alertas
— dados relativos ao acesso ao menu
— outros dados solicitados por um utilizador.
O aparelho de controlo pode exibir elementos informativos
adicionais, desde que claramente distinguíveis das informa­
ções supra.
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 58
157) O visor do aparelho de controlo deve utilizar os pictogra­
mas ou combinações de pictogramas indicados no apêndice
3. Podem utilizar-se pictogramas ou combinações de picto­
gramas adicionais, desde que claramente distinguíveis dos
primeiros.
158) Com o veículo em movimento, o visor deve estar sempre
ligado (posição ON).
159) O aparelho de controlo deve incluir um dispositivo manual
ou automático para desligar o visor (levá-lo à posição OFF)
quando o veículo não está em movimento.
O formato da visualização é especificado no apêndice 5.
3.15.1 Visualização por defeito
160) Se não se impuserem outras informações, o aparelho de
controlo deve exibir, por defeito, as seguintes:
— hora local (hora UTC, com compensação introduzida
pelo condutor)
— modo de funcionamento
— atividade em curso do condutor e atividade em curso do
ajudante
— informação relativa ao condutor:
— se a sua atividade em curso for DRIVING: o seu atual
tempo de condução contínua e o seu atual tempo acu­
mulado de pausas
— se a sua atividade em curso não for DRIVING: a du­
ração dessa atividade (desde que foi selecionada) e o
seu atual tempo acumulado de pausas.
161) A exibição dos dados relativos ao condutor e ao ajudante
deve ser clara, direta e inequívoca. Caso a informação re­
lativa a um não possa ser visualizada ao mesmo tempo que
a relativa ao outro, o aparelho de controlo deve exibir por
defeito a informação relativa ao condutor, permitindo ao
utilizador visualizar a informação relativa ao ajudante.
162) Caso a largura do visor não permita exibir por defeito o
modo de funcionamento, o aparelho de controlo deve exibir
fugazmente o novo modo de funcionamento quando haja
mudança deste.
163) Quando haja inserção de um cartão, o aparelho de controlo
deve exibir fugazmente o nome do titular.
164) A abertura de uma condição «OUT OF SCOPE» ou
«FERRY/TRAIN» deve ser assinalada na visualização por
defeito, com recurso aos pictogramas pertinentes (é aceitá­
vel que a atividade em curso do condutor não seja visua­
lizada ao mesmo tempo).
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 59
3.15.2 Visualização de alerta
165) O aparelho de controlo deve exibir informações de alerta,
primeiramente com recurso aos pictogramas constantes do
apêndice 3, complementados, se necessário, por informação
adicional numericamente codificada. Pode também
acrescentar-se uma descrição literal do alerta, no idioma
de preferência do condutor.
3.15.3 Acesso ao menu
166) O aparelho de controlo deve proporcionar os comandos
necessários, mediante um menu adequadamente estruturado.
3.15.4 Outras visualizações
167) Deve ser possível visualizar seletivamente, conforme se
pretenda:
— data e hora UTC e hora local compensada
▼M3
— o conteúdo de qualquer das impressões enumeradas no
requisito 169 nos mesmos formatos das próprias im­
pressões;
▼B
— tempo de condução contínua e tempo acumulado de
pausas do condutor
— tempo de condução contínua e tempo acumulado de
pausas do ajudante
▼M3
— o tempo acumulado de condução do condutor nas se­
manas anterior e em curso,
— o tempo acumulado de condução do ajudante nas sema­
nas anterior e em curso,
▼B
Opcional:
— duração da atividade em curso do ajudante (desde que
foi selecionada)
▼M3
— o tempo acumulado de condução do condutor na se­
mana em curso,
— o tempo acumulado de condução do ajudante no pe­
ríodo de trabalho diário em curso,
— o tempo acumulado de condução do ajudante no pe­
ríodo de trabalho diário em curso.
▼B
168) A visualização do conteúdo das mensagens deve ser se­
quencial, linha a linha. Se a largura do visor for inferior
a 24 carateres, o utilizador deve poder obter a informação
completa por um meio adequado (linhas múltiplas, deslo­
camento, etc.).
As linhas reservadas a informação manuscrita podem ser
omitidas na visualização.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 60
3.16 Impressão
169) O aparelho de controlo deve poder imprimir informação
contida na sua memória de dados e/ou nos cartões tacográ­
ficos, de acordo com as sete impressões seguintes:
— atividades de condutor, da impressão diária dos cartões
— atividades de condutor, da impressão diária da
unidade-veículo
— incidentes e falhas, da impressão dos cartões
— incidentes e falhas, da impressão da unidade-veículo
— impressão de dados técnicos
— impressão de excesso de velocidade
— dados históricos do cartão tacográfico para uma deter­
minada VU (ver capítulo 3.12.16).
O formato e o conteúdo destas impressões são pormenori­
zados no apêndice 4.
No final das impressões, podem ser fornecidos dados
adicionais.
Podem também ser fornecidas impressões complementares
pelo aparelho de controlo, desde que claramente distinguí­
veis das sete impressões supramencionadas.
170) As funções «atividades de condutor, da impressão diária
dos cartões» e «incidentes e falhas, da impressão dos car­
tões» só devem ser viabilizadas quando o cartão inserido no
aparelho de controlo for de condutor ou de oficina. Antes
de iniciar a impressão, o aparelho de controlo atualiza os
dados memorizados no cartão em causa.
171) Para concretizar a impressão de «atividades de condutor, da
impressão diária dos cartões» e de «incidentes e falhas, da
impressão dos cartões», o aparelho de controlo deve:
— selecionar automaticamente o cartão de condutor ou de
oficina, se somente um destes cartões tiver sido inse­
rido, ou então
— facultar um comando que selecione o cartão da fonte ou
o cartão na ranhura do condutor, se no aparelho de
controlo tiverem sido inseridos dois destes cartões.
172) A impressora deve poder imprimir 24 carateres por linha.
173) As dimensões mínimas de um caráter devem ser de 2,1 mm
de altura por 1,5 mm de largura.
174) A impressão deve aceitar os carateres indicados no apên­
dice 1, capítulo 4, «Conjuntos de carateres».
175) As impressoras devem ser projetadas de modo a que as
impressões tenham um grau de definição suscetível de evi­
tar ambiguidades de leitura.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 61
176) A impressão deve conservar as dimensões e os registos em
condições normais de humidade (10-90 %) e de
temperatura.
177) O papel homologado utilizado pelo aparelho de controlo
deve exibir a correspondente marca de homologação e a
indicação do(s) tipo(s) de aparelho no qual pode ser
utilizado.
178) As impressões devem manter-se claramente legíveis e iden­
tificáveis em condições normais de armazenamento (no que
diz respeito a intensidade luminosa, humidade e tempera­
tura) durante pelo menos dois anos.
179) As impressões devem estar em conformidade, pelo menos,
com as especificações de ensaio definidas no apêndice 9.
180) A estes documentos deve ser igualmente possível acrescen­
tar notas manuscritas, como a assinatura do condutor.
181) Na eventualidade de um incidente «paper out» (falta de
papel) durante a impressão, o aparelho de controlo deve
geri-lo do seguinte modo: uma vez efetuada a recarga do
papel, retomar a impressão desde o início ou prossegui-la,
fazendo, nesta última hipótese, uma referência inequívoca à
parte anteriormente impressa.
3.17 Alertas
182) O aparelho de controlo deve prevenir o condutor quando
detetar algum incidente e/ou alguma falha.
183) A sinalização de um incidente de interrupção da alimenta­
ção energética pode ser adiada até se restabelecer a alimen­
tação.
184) O aparelho de controlo deve avisar o condutor 15 minutos
antes e no momento em que se ultrapassa o tempo máximo
de condução contínua permitido.
185) Os sinais de alerta devem ser visuais. Complementarmente,
podem ser também emitidos sinais sonoros.
186) Os alertas visuais devem ser claramente reconhecíveis pelo
utilizador, situar-se no seu campo de visão e ser claramente
legíveis tanto de dia como de noite.
187) Os alertas visuais podem ser incorporados no aparelho de
controlo ou ter localização à distância.
188) No último caso, o alerta visual deve comportar um símbolo
«T».
189) Os alertas devem ter a duração mínima de 30 segundos, a
menos que o condutor acuse a sua emissão premindo uma
ou mais teclas específicas do aparelho de controlo. Este
primeiro reconhecimento não deve eliminar a visualização
da causa do alerta referida no número seguinte.
190) A causa do alerta deve ser visualizada no aparelho de con­
trolo e manter-se visível até o utilizador acusar a sua emis­
são premindo uma tecla ou um comando específico.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 62
191) Podem ser emitidos alertas adicionais, desde que não pro­
voquem a confusão do condutor em relação a alertas pre­
viamente definidos.
3.18 Descarregamento de dados para meios externos
192) Caso se pretenda, o aparelho de controlo deve poder des­
carregar dados da sua memória ou de um cartão de condu­
tor para meios externos de memorização, através do conec­
tor de calibração/descarregamento. Antes de iniciar o des­
carregamento, o aparelho de controlo atualiza os dados
memorizados no cartão em causa.
▼M3
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
194) O descarregamento não deve alterar ou apagar dados
memorizados.
195) A interface elétrica do conector de calibração/descarrega­
mento é especificada no apêndice 6.
196) Os protocolos relativos ao descarregamento são especifica­
dos no apêndice 7.
▼M3
196-A) Uma empresa de transportes que utilize veículos equipados
com aparelhos de controlo em conformidade com o pre­
sente 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 de­
vem 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 des­
carregados da unidade-veículo durante, pelo menos, doze
meses após o registo.
▼B
3.19 Comunicação à distância para controlos de estrada seletivos
197) Quando a ignição está ligada, a unidade-veículo deve me­
morizar a cada 60 segundos, no sistema de comunicação à
distância, os dados mais recentes necessários à realização
dos controlos de estrada seletivos. Esses dados devem ser
encriptados e assinados, conforme se especifica no apêndice
11 e no apêndice 14.
198) Os dados a verificar à distância devem estar disponíveis
para os leitores de comunicações à distância por intermédio
de comunicação sem fios, conforme se especifica no apên­
dice 14.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 63
199) Os dados necessários à realização de controlos de estrada
seletivos devem estar relacionados com:
— a última tentativa de violação da segurança
— a mais longa interrupção da alimentação energética,
— falha do sensor
— erro nos dados de movimento
— conflito relativo ao movimento do veículo
— condução sem cartão válido
— inserção de cartão durante a condução,
— dados relativos ao ajustamento do tempo
— dados relativos à calibração, incluindo as datas dos dois
últimos registos de calibrações memorizados
— número de matrícula do veículo
— velocidade registada pelo tacógrafo,
▼M3
— posição do veículo,
— uma indicação se o condutor pode atualmente violar os
tempos de condução.
3.20 Intercâmbio de dados com dispositivos externos adicionais
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 pro­
duzidos 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, acei­
tando 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 dispo­
ní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 pes­
soais», sendo a autorização do condutor aplicável a
esses dados classificada como «pessoal»;
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 64
— o consentimento do condutor pode ser ativado ou desa­
tivado através de comandos no menu, a qualquer mo­
mento, 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 cor­
reto 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 tra­
tamento 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.
201) A interface de ligação em série, conforme se especifica no
anexo IB do Regulamento (CEE) n. o 3821/85, na sua úl­
tima 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.
▼B
3.21 Calibração
202) A função de calibração deve permitir:
— emparelhar automaticamente o sensor de movimentos
com a VU
— emparelhar automaticamente o módulo GNSS externo
com a VU, se for caso disso
— adaptar digitalmente a constante do aparelho de con­
trolo (k) ao coeficiente característico do veículo (w)
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 65
— ajustar o tempo atual no período de validade do cartão
de oficina inserido
— ajustar o valor atual do conta-quilómetros
— atualizar os dados de identificação do sensor de movi­
mentos, memorizados na memória
— atualizar, quando aplicável, os dados de identificação do
módulo GNSS externo memorizados na memória
— atualizar os tipos e identificadores de todos os selos em
vigor
▼M3
— 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,
— 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 rece­
tor GNSS.
▼B
203) Além disso, a função de calibração deve permitir suprimir a
utilização de cartões tacográficos de primeira geração no
aparelho de controlo, desde que se verifiquem as condições
especificadas no apêndice 15.
204) O emparelhamento do sensor de movimentos com a VU
deve consistir, pelo menos, em:
— atualizar os dados de instalação do sensor de movimen­
tos nele contidos (conforme necessário)
— copiar da memória do sensor de movimentos para a da
unidade-veículo os dados de identificação do sensor que
forem necessários.
▼M3
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 ex­
terno 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.
▼B
206) A função de calibração deve poder admitir os dados que
forem necessários, através do conector de calibração/descar­
regamento, segundo o protocolo definido no apêndice 8.
Deve também poder admitir tais dados através de outros
meios.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 66
3.22 Controlo de calibração de estrada
207) A função de controlo de calibração de estrada deve permitir
ler o número de série do sensor de movimentos (eventual­
mente incorporado no adaptador) e o número de série do
módulo GNSS externo (quando aplicável), ligado à
unidade-veículo, no momento do pedido.
208) Esta leitura deve ser possível, pelo menos, no visor da
unidade-veículo, através de comandos nos menus.
209) A função de controlo de calibração de estrada deve igual­
mente permitir controlar a seleção do modo de I/O de
calibração da linha de sinal I/O especificada no apêndice
6, através da interface K-line. Tal deve ser feito através do
ECUAdjustmentSession, conforme especifica o apêndice 8,
secção 7, «Controlo dos impulsos de ensaio — Unidade
funcional de controlo de entrada/saída».
▼M3
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.
▼B
3.23 Ajustamento do tempo
210) A função de ajustamento do tempo deve permitir ajustar
automaticamente o momento atual. No aparelho de controlo
são utilizadas duas fontes de tempo para ajustamento do
tempo: 1) o relógio interno da VU, 2) o recetor de GNSS.
▼M3
211) A hora do relógio interno da VU deve ser reajustada auto­
maticamente 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 confor­
midade 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 autentica­
das, conforme estipulado no apêndice 12. A referência tem­
poral para o ajustamento automático da hora do relógio
interno da VU deve ser determinada pelo recetor GNSS.
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;
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 67
— 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 confor­
midade com a secção 8 do apêndice 8.
▼B
3.24 Características de desempenho
213) A unidade-veículo deve estar plenamente funcional no in­
tervalo de temperatura de – 20 °C a 70 °C, o módulo
GNSS externo no intervalo de temperatura de – 20 °C a
70 °C e o sensor de movimentos no intervalo de tempera­
tura de – 40 °C a 135 °C. O conteúdo da memória de
dados deve ser preservado até à temperatura de – 40 °C.
214) O tacógrafo deve ser plenamente funcional no intervalo de
humidade de 10 % a 90 %.
215) Os selos utilizados no tacógrafo inteligente devem aceitar
as mesmas condições aplicáveis aos componentes de tacó­
grafo a que estão apostos.
216) O aparelho de controlo deve ser protegido contra sobreten­
são elétrica, inversão da polaridade da sua alimentação
energética e curtos-circuitos.
217) Os sensores de movimentos devem:
— reagir a campos magnéticos que perturbem a deteção do
movimento do veículo. Nessas circunstâncias,
a unidade-veículo regista e memoriza uma falha do
sensor (requisito n. o 88) ou,
— dispor de um elemento de deteção que esteja protegido
contra campos magnéticos ou lhes seja imune.
218) O aparelho de controlo e o módulo GNSS externo devem
cumprir o disposto na regulamentação internacional ONU
ECE R10 e ser protegidos contra descargas eletrostáticas e
contra transitórios.
3.25 Materiais
219) Todas as peças constituintes do aparelho de controlo devem
ser em material com estabilidade e resistência mecânica
suficientes e com características eletromagnéticas estáveis.
220) Em condições normais de utilização, todas as peças internas
do aparelho de controlo devem ser protegidas contra humi­
dade e poeiras.
221) A unidade-veículo e o módulo GNSS externo devem cum­
prir o grau de proteção IP 40 e o sensor de movimentos
deve cumprir o grau de proteção IP 64, conforme a norma
IEC 60529:1989, incluindo A1:1999 e A2:2013.
222) O aparelho de controlo deve cumprir as especificações téc­
nicas aplicáveis em matéria de ergonomia.
223) O aparelho de controlo deve ser protegido contra danos
acidentais.
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 68
3.26 Marcações
224) Se o aparelho de controlo exibir o valor do
conta-quilómetros e a velocidade do veículo, o visor deve
mostrar os seguintes elementos:
— junto ao número que indica a distância: a unidade de
medida da distância, indicada pela abreviatura «km»
— junto ao número que indica a velocidade: a referência
«km/h».
O aparelho de controlo pode também ser levado a exibir a
velocidade em milhas por hora, caso em que a correspon­
dente unidade de medida será indicada pela abreviatura
«mph». O aparelho de controlo pode também ser levado
a exibir a distância em milhas, caso em que a correspon­
dente unidade de medida será indicada pela abreviatura
«mi».
▼M1
225) Em cada componente separado do aparelho de controlo
deve ser afixada uma placa descritiva com os seguintes
elementos:
— nome e endereço do fabricante,
— número dado pelo fabricante e ano de fabrico,
— número de série,
— marca de homologação.
226) Se o espaço físico não for suficiente para mostrar todos os
pormenores supramencionados, a placa descritiva deve in­
dicar, pelo menos: o nome ou logótipo do fabricante e o
número de peça do aparelho.
▼M3
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 rea­
lização de atualizações de software sempre que tais atuali­
zações não envolvam a disponibilidade de recursos de
hardware adicionais, além dos recursos definidos no requi­
sito 226-F, e as entidades homologadoras deem a sua au­
torizaçã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.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 69
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 notifi­
cados às funções do aparelho de controlo.
226-F) A unidade-veículo deve fornecer recursos de hardware gra­
tuitos 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 neces­
sários para a versão do mapa NUTS 0 2021.
▼B
4 REQUISITOS DE CONSTRUÇÃO E FUNCIONAMENTO DOS
CARTÕES TACOGRÁFICOS
4.1 Dados visíveis
O anverso do cartão terá o seguinte conteúdo:
227) Os termos «cartão de condutor», «cartão de controlo», «car­
tão de oficina» ou «cartão de empresa», consoante o tipo de
cartão, impressos em maiúsculas na(s) língua(s) oficial(is)
do Estado-Membro emissor do cartão.
228) O nome do Estado-Membro que emite o cartão (faculta­
tivo).
229) O símbolo distintivo do Estado-Membro que emite o car­
tão, impresso em negativo num retângulo azul e rodeado de
doze estrelas amarelas. Os símbolos distintivos são os
seguintes:
B
BG
CZ
CY
Bélgica
Bulgária
República Checa
Chipre
LV
L
LT
M
Letónia
Luxemburgo
Lituânia
Malta
DK Dinamarca NL Países Baixos
D
EST
Alemanha
Estónia
A
PL
Áustria
Polónia
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 70
GR Grécia P
RO
SK
SLO
Portugal
Roménia
Eslováquia
Eslovénia
E Espanha FIN Finlândia
F
HR
H
França
Croácia
Hungria
S Suécia
IRL Irlanda UK Reino Unido
I Itália
230) Elementos específicos do cartão, com a seguinte numera­
ção:
Cartão de condutor Cartão de controlo
Cartão de empresa ou de ofi­
cina
1. Apelido do condutor Nome do organismo de
controlo
Nome da empresa ou da
oficina
2. Nome próprio do condutor Apelido do controlador
(se aplicável)
Apelido do titular do cartão
(se aplicável)
3. Data de nascimento do
condutor
Nome próprio do controla­
dor
(se aplicável)
Nome próprio do titular do
cartão
(se aplicável)
4.a Data do início da validade do cartão
4.b Prazo de validade do cartão
4.c Nome da autoridade emissora (pode ser impresso no verso)
4.d Número distinto do referido na rubrica 5, com utilidade para efeitos administrativos
(referência facultativa)
5. a Número da carta de con­
dução
(à data de emissão do car­
tão de condutor)
— —
5. b Número do cartão
6. Fotografia do condutor Fotografia do controlador
(opcional)
Fotografia do instalador
(opcional)
7. Assinatura do titular (opcional)
8. Local de residência normal
ou endereço postal do titu­
lar (facultativo).
Endereço postal do orga­
nismo de controlo
Endereço postal da empresa
ou da oficina
231) Datas, com o formato «dd/mm/aaaa» ou «dd.mm.aaaa»
(dia, mês, ano).
O verso do cartão terá o seguinte conteúdo:
232) Explicação dos elementos numerados que constam do
anverso;
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 71
233) Com caráter eventual e mediante o consentimento expresso
e por escrito do titular: informação não relacionada com a
administração do cartão, sob condição de não prejudicar a
utilização do modelo como cartão tacográfico.
234) Os cartões tacográficos devem ser impressos com as se­
guintes colorações de fundo:
— Cartão de condutor: branco
— Cartão de controlo: azul
— Cartão de oficina: vermelho
— Cartão de empresa: amarelo.
235) Os cartões tacográficos devem ter as seguintes característi­
cas de proteção contra falsificações:
— fundo de segurança em guilhoché fino e impressão iri­
sada
— na zona da fotografia, sobreposição do fundo de segu­
rança e da fotografia
— pelo menos uma linha de microimpressão bicromática.
► (1) M1
► (2) M3
236) Mediante consulta da Comissão, os Estados-Membros po­
dem acrescentar colorações ou marcações, como símbolos
nacionais e elementos de segurança, sem prejuízo do dis­
posto no presente anexo.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 72
237) Os cartões temporários referidos no artigo 26. o , n. o 4, do
Regulamento (UE) n. o 165/2014 devem cumprir o disposto
neste anexo.
4.2 Segurança
A segurança do sistema visa proteger a integridade e a autenticidade
dos dados que circulam entre os cartões e o aparelho de controlo e
dos dados descarregados dos cartões, permitindo unicamente ao
aparelho de controlo determinadas operações de escrita nos cartões,
desencriptando dados, excluindo qualquer possibilidade de falsifica­
ção dos dados memorizados, prevenindo contrafações e detetando
tentativas nesse sentido.
238) Com vista a conseguir a segurança do sistema, os cartões
tacográficos devem cumprir o prescrito nos apêndices 10
e 11.
239) Os cartões tacográficos devem ser legíveis por outros apa­
relhos, como, por exemplo, computadores pessoais.
4.3 Normas
240) Os cartões tacográficos devem obedecer às seguintes
normas:
— ISO/IEC 7810 Identification cards — Physical
characteristics,
— ISO/IEC 7816 Identification cards — Integrated circuit
cards:
— Part 1: Physical characteristics
— Part 2: Dimensions and position of the contacts
(ISO/IEC 7816-2:2007)
— Part 3: Electrical interface and transmission proto­
cols (ISO/IEC 7816-3:2006)
— Part 4: Organisation, security and commands for
interchange (ISO/IEC 7816-4:2013 + Cor 1:2014)
— Part 6: Interindustry data elements for interchange
(ISO/IEC 7816-6:2004 + Cor 1:2006)
— Part 8: Commands for security operations (ISO/IEC
7816-8:2004).
— Devem ser feitos ensaios aos cartões tacográficos, em
conformidade com a norma ISO/IEC 10373-3: 2010
Identification cards — Test methods — Part 3: Integra­
ted circuit cards with contacts and related interface
devices.
4.4 Especificações ambientais e elétricas
241) Os cartões tacográficos devem poder funcionar correta­
mente nas condições climáticas normalmente ocorrentes
no território da União Europeia e pelo menos no intervalo
térmico de – 25 °C a + 70 °C, com picos ocasionais até +
85 °C, entendendo-se por «ocasionais» ocorrências de du­
ração não superior a 4 horas e em número não superior a
100 ao longo do período de vida útil do cartão.
242) Os cartões tacográficos devem poder funcionar correta­
mente no intervalo de humidade de 10 % a 90 %.
243) Os cartões tacográficos devem poder funcionar correta­
mente durante um período de cinco anos, desde que utili­
zados em conformidade com as especificações ambientais e
elétricas.
244) Durante o seu funcionamento, os cartões devem cumprir o
disposto no Regulamento ECE R10, relativo à compatibili­
dade eletromagnética, e estar protegidos contra descargas
eletrostáticas.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 73
4.5 Armazenamento dos dados
Para efeitos da presente secção,
— 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.
As funções, os comandos e estruturas lógicas e os requisitos de
memorização de dados, aplicáveis aos cartões tacográficos, constam
do apêndice 2.
Salvo disposição em contrário, a memorização de dados nos cartões
tacográficos deve ser organizada de forma que os novos dados
substituem os dados mais antigos memorizados no caso de estar
esgotado o tamanho da memória previsto para os registos
particulares.
245) Nesta secção, especifica-se a capacidade mínima de memo­
rização para os ficheiros de dados das diversas aplicações.
Os cartões tacográficos devem poder indicar ao aparelho de
controlo a capacidade efetiva de memorização desses
ficheiros.
▼M3
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
247) Cada ficheiro principal (MF) de qualquer cartão tacográfico
deve conter até cinco ficheiros elementares (EF), para ges­
tão de cartões, aplicações e identificações de chip, e dois
ficheiros dedicados (DF):
— DF Tachograph, que contém a aplicação acessível
a unidades-veículo da primeira geração e que também
está presente em cartões tacográficos da primeira gera­
ção
— DF Tachograph_G2, que contém a aplicação acessível
apenas a unidades-veículo da segunda geração e que
está presente apenas em cartões tacográficos da segunda
geração.
▼M3
Nota: a versão 2 dos cartões da segunda geração contém
ficheiros elementares adicionais em DF Tachograph_G2.
▼B
As informações completas acerca da estrutura dos cartões
tacográficos são especificadas no apêndice 2.
4.5.1 Ficheiros elementares para identificação e gestão de cartões
4.5.2 Identificação do cartão IC
248) Os cartões tacográficos devem poder memorizar os seguin­
tes dados de identificação de cartões inteligentes:
— paragem do relógio
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 74
— número de série do cartão (incluindo referências de
fabrico)
— número de homologação do tipo de cartão
— identificação personalizada do cartão (ID)
— identificação incorporada
— identificador do IC.
4.5.2.1 I d e n t i f i c a ç ã o d o c h i p
249) Os cartões tacográficos devem poder memorizar os seguin­
tes dados de identificação do IC (circuito integrado):
— número de série do IC
— referências de fabrico do IC.
4.5.2.2 D I R ( p r e s e n t e s o m e n t e n o s c a r t õ e s t a c o g r á f i c o s
d a s e g u n d a g e r a ç ã o )
250) Os cartões tacográficos devem poder memorizar os objetos
de dados de identificação da aplicação detalhados no apên­
dice 2.
4.5.2.3 I n f o r m a ç õ e s A T R ( c o n d i c i o n a d a s , p r e s e n t e s s o ­
m e n t e n o s c a r t õ e s t a c o g r á f i c o s d a s e g u n d a g e r a ­
ç ã o )
251) Os cartões tacográficos devem poder memorizar o objeto de
dados de informação do aumento do comprimento:
— no caso de o cartão tacográfico aceitar o aumento dos
campos de comprimento, o objeto de dados de infor­
mação do aumento do comprimento especificado no
apêndice 2.
4.5.2.4 I n f o r m a ç ã o d o a u m e n t o d o c o m p r i m e n t o ( c o n d i ­
c i o n a d o , p r e s e n t e s o m e n t e n o s c a r t õ e s t a c o g r á ­
f i c o s d a s e g u n d a g e r a ç ã o )
252) Os cartões tacográficos devem poder memorizar os objetos
de dados de informação do aumento do comprimento:
— no caso de o cartão tacográfico aceitar o aumento dos
campos de comprimento, os objetos de dados de infor­
mação do aumento do comprimento especificados no
apêndice 2.
4.5.3 Cartão de condutor
4.5.3.1 A p l i c a ç ã o t a c o g r á f i c a ( a c e s s í v e l à s u n i d a d e s -
v e í c u l o d a s p r i m e i r a e s e g u n d a g e r a ç õ e s )
4.5.3.1.1 Identificação da aplicação
253) O cartão de condutor deve poder memorizar os seguintes
dados relativos à identificação da respetiva aplicação:
— identificação da aplicação tacográfica
— identificação do tipo de cartão tacográfico.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 75
4.5.3.1.2 Chaves e certificados
254) O cartão tacográfico deve poder memorizar várias chaves e
certificados criptográficos, conforme especifica o apêndice
11, parte A.
4.5.3.1.3 Identificação do cartão
255) O cartão de condutor deve poder memorizar os seguintes
dados de identificação do cartão:
— número do cartão
— Estado-Membro emissor, autoridade emissora, data de
emissão
— datas de início e de cessação do prazo de validade.
4.5.3.1.4 Identificação do titular
256) O cartão de condutor deve poder memorizar os seguintes
dados de identificação do respetivo titular:
— apelido
— nome próprio
— data de nascimento
— idioma de preferência.
4.5.3.1.5 Descarregamento do cartão
257) O cartão de condutor deve poder memorizar os seguintes
dados relativos ao descarregamento do cartão:
— data e hora relativas ao último descarregamento do car­
tão (para outras finalidades que não o controlo).
258) O cartão de condutor deve poder guardar 1 registo deste
tipo.
4.5.3.1.6 Elementos relativos à carta de condução
259) O cartão de condutor deve poder memorizar os seguintes
dados relativos à carta de condução:
— Estado-Membro emissor, autoridade emissora
— número da carta de condução (à data de emissão do
cartão).
4.5.3.1.7 Dados relativos a incidentes
Para efeitos da presente secção, os tempos devem ser memorizados
com a resolução de 1 segundo.
260) O cartão de condutor deve poder memorizar os dados rela­
tivos aos seguintes incidentes detetados pelo aparelho de
controlo durante o período de inserção do cartão:
— sobreposição de tempos (se este cartão for a causa do
incidente)
— inserção de cartão durante a condução (se este cartão
for o protagonista do incidente)
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 76
— última sessão de cartão encerrada incorretamente (se
este cartão for o protagonista do incidente)
— interrupção da alimentação energética
— erro nos dados de movimento
— tentativas de violação da segurança.
261) O cartão de condutor deve poder memorizar os seguintes
dados relativos àqueles incidentes:
— código do incidente
— data e hora do início do incidente (ou da inserção do
cartão, caso o incidente estivesse em curso nesse mo­
mento)
— data e hora do final do incidente (ou da retirada do
cartão, caso o incidente estivesse em curso nesse mo­
mento)
— VRN e Estado-Membro de matrícula do veículo no qual
se produziu o incidente.
Nota: No que se refere ao incidente «sobreposição de tem­
pos»:
— a data e a hora de início do incidente devem correspon­
der à data e à hora de retirada do cartão do veículo
anterior
— a data e a hora do final do incidente devem correspon­
der à data e à hora de inserção do cartão no veículo
presente
— os dados relativos ao veículo devem corresponder ao
veículo presente, no qual se produziu o incidente.
Nota: No que se refere ao incidente «última sessão de
cartão encerrada incorretamente»:
— a data e a hora de início do incidente devem correspon­
der à data e à hora de inserção do cartão na sessão
encerrada incorretamente
— a data e a hora do final do incidente devem correspon­
der à data e à hora de inserção do cartão na sessão
durante a qual o incidente foi detetado (sessão em
curso)
— os dados relativos ao veículo devem corresponder ao
veículo no qual a sessão não foi encerrada
corretamente.
262) O cartão de condutor deve poder memorizar os dados rela­
tivos aos 6 incidentes mais recentes de cada um dos 6 tipos
(ou seja, os dados relativos a 36 incidentes).
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 77
4.5.3.1.8 Dados relativos a falhas
Para efeitos da presente secção, os tempos devem ser registados com
a resolução de 1 segundo.
263) O cartão de condutor deve poder memorizar os dados rela­
tivos às seguintes falhas detetadas pelo aparelho de controlo
durante o período de inserção do cartão:
▼M1
— falha do cartão (se este for o protagonista da falha)
▼B
— falha do aparelho de controlo.
264) O cartão de condutor deve poder memorizar os seguintes
dados relativos àquelas falhas:
— código de falha
— data e hora do início da falha (ou da inserção do cartão,
caso a falha estivesse em curso nesse momento)
— data e hora do final da falha (ou da retirada do cartão,
caso a falha estivesse em curso nesse momento)
— VRN e Estado-Membro de matrícula do veículo no qual
se produziu a falha.
265) O cartão de condutor deve poder memorizar os dados rela­
tivos às 12 falhas mais recentes de cada um dos tipos (ou
seja, os dados relativos a 24 falhas).
4.5.3.1.9 Dados relativos à atividade de condutor
266) Relativamente a cada dia em que o cartão seja utilizado ou
relativamente ao qual o condutor introduza atividades ma­
nualmente, o cartão de condutor deve poder memorizar os
seguintes dados:
— data
— contador de presença diária (com incrementos de uma
unidade por cada um destes dias)
— distância total percorrida pelo condutor nesse dia
— situação do condutor às 00h00
— a cada mudança da atividade do condutor e/ou da si­
tuação da condução e/ou a cada inserção ou retirada do
cartão do condutor:
— situação da condução (CREW, SINGLE)
— ranhura (DRIVER, CO-DRIVER)
— situação do cartão (INSERTED, NOT INSERTED)
— atividade (DRIVING, AVAILABILITY, WORK,
BREAK/REST)
— hora da mudança.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 78
267) A memória do cartão de condutor deve poder guardar os
dados relativos à atividade do condutor durante pelo menos
28 dias (define-se atividade média de um condutor como 93
mudanças de atividade por dia).
268) Os dados referidos nos requisitos n. os 261, 264 e 266 de­
vem ser memorizados de modo a permitir recuperar ativi­
dades segundo a sua ordem de ocorrência, mesmo na even­
tualidade de sobreposição de tempos.
4.5.3.1.10 Dados relativos à utilização de veículos
269) Relativamente a cada dia em que o cartão seja utilizado e a
cada período de utilização de um determinado veículo nesse
dia (um período de utilização inclui a totalidade dos ciclos
consecutivos de inserção/retirada do cartão no veículo, con­
siderados do ponto de vista do cartão), o cartão de condutor
deve poder memorizar os seguintes dados:
— data e hora da primeira utilização do veículo (ou seja,
primeira inserção de cartão durante este período de uti­
lização do veículo, ou 00h00 se o período de utilização
estiver a decorrer no momento)
— valor do conta-quilómetros do veículo no momento
— data e hora da última utilização do veículo (ou seja,
última retirada de cartão durante este período de utili­
zação do veículo, ou 23h59 se o período de utilização
estiver a decorrer no momento)
— valor do conta-quilómetros do veículo no momento
— VRN e Estado-Membro de matrícula do veículo.
270) O cartão de condutor deve poder memorizar pelo menos 84
registos deste tipo.
4.5.3.1.11 Locais de início e/ou final dos períodos de trabalho diário
271) O cartão de condutor deve poder memorizar os seguintes
dados relativos aos locais, introduzidos pelo condutor, em
que se iniciam e/ou terminam os períodos de trabalho diá­
rio:
— data e hora da introdução (ou data e hora relativas à
introdução, se esta for manual)
— tipo de introdução (início ou final, condição da intro­
dução)
— país e região introduzidos
— valor do conta-quilómetros do veículo.
272) A memória do cartão de condutor deve poder guardar pelo
menos 42 pares de registos deste tipo.
4.5.3.1.12 Dados relativos à sessão de cartão
273) O cartão de condutor deve poder memorizar os dados rela­
tivos ao veículo que abriu a sua sessão em curso:
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 79
— data e hora de abertura da sessão (ou seja, da inserção
do cartão), com a resolução de 1 segundo
— VRN e Estado-Membro de matrícula.
4.5.3.1.13 Dados relativos à atividade de controlo
274) O cartão de condutor deve poder memorizar os seguintes
dados relativos a atividades de controlo:
— data e hora do controlo
— número e Estado-Membro emissor do cartão de controlo
— tipo de controlo: visualização, impressão, descarrega­
mento da VU e/ou descarregamento do cartão (ver nota)
— período descarregado (se o controlo for de descarrega­
mento)
— VRN e Estado-Membro de matrícula do veículo no qual
teve lugar o controlo.
Nota: o descarregamento do cartão só será registado se
executado por intermédio de um aparelho de controlo.
275) O cartão de condutor deve poder guardar 1 registo deste
tipo.
4.5.3.1.14 Dados relativos às condições especiais
276) O cartão de condutor deve poder memorizar os seguintes
dados relativos às condições especiais introduzidas durante
o período de inserção do cartão (independentemente da
ranhura):
— data e hora da introdução dos dados
— tipo de condição especial.
277) O cartão de condutor deve poder memorizar pelo menos 56
registos deste tipo.
▼M3
4.5.3.2 A p l i c a ç ã o t a c o g r á f i c a d a g e r a ç ã o 2 ( n ã o a c e s s í ­
v e l à s u n i d a d e s - v e í c u l o d a p r i m e i r a g e r a ç ã o ,
a c e s s í v e l à s v e r s õ e s 1 e 2 d a s u n i d a d e s - v e í c u l o
d a s e g u n d a g e r a ç ã o )
▼B
4.5.3.2.1 Identificação da aplicação
278) O cartão de condutor deve poder memorizar os seguintes
dados relativos à identificação da respetiva aplicação:
— identificação da aplicação tacográfica
— identificação do tipo de cartão tacográfico.
▼M3
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 iden­
tificação da aplicação adicionais, apenas aplicável à ver­
são 2.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 80
4.5.3.2.2 Chaves e certificados
279) O cartão tacográfico deve poder memorizar várias chaves e
certificados criptográficos, conforme especifica o apêndice
11, parte B.
4.5.3.2.3 Identificação do cartão
280) O cartão de condutor deve poder memorizar os seguintes
dados de identificação do cartão:
— número do cartão
— Estado-Membro emissor, autoridade emissora, data de
emissão
— datas de início e de cessação do prazo de validade.
4.5.3.2.4 Identificação do titular
281) O cartão de condutor deve poder memorizar os seguintes
dados de identificação do respetivo titular:
— apelido do titular
— nome próprio do titular
— data de nascimento
— idioma de preferência.
4.5.3.2.5 Descarregamento do cartão
282) O cartão de condutor deve poder memorizar os seguintes
dados relativos ao descarregamento do cartão:
— data e hora relativas ao último descarregamento (para
outras finalidades que não o controlo).
283) O cartão de condutor deve poder guardar 1 registo deste
tipo.
4.5.3.2.6 Elementos relativos à carta de condução
284) O cartão de condutor deve poder memorizar os seguintes
dados relativos à carta de condução:
— Estado-Membro emissor, autoridade emissora
— número da carta de condução (à data de emissão do
cartão).
4.5.3.2.7 Dados relativos a incidentes
Para efeitos da presente secção, os tempos devem ser memorizados
com a resolução de 1 segundo.
285) O cartão de condutor deve poder memorizar os dados rela­
tivos aos seguintes incidentes detetados pelo aparelho de
controlo durante o período de inserção do cartão:
— sobreposição de tempos (se este cartão for a causa do
incidente)
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 81
— inserção de cartão durante a condução (se este cartão
for o protagonista do incidente)
— última sessão de cartão encerrada incorretamente (se
este cartão for o protagonista do incidente)
— interrupção da alimentação energética
— erro de comunicação com o sistema de comunicação à
distância
— incidente «Ausência de informações sobre a posição do
recetor GNSS»
— erro de comunicação com o módulo GNSS externo
— erro nos dados de movimento
— conflito relativo ao movimento do veículo
— tentativas de violação da segurança
— conflito de tempo.
286) O cartão de condutor deve poder memorizar os seguintes
dados relativos àqueles incidentes:
— código do incidente
— data e hora do início do incidente (ou da inserção do
cartão, caso o incidente estivesse em curso nesse mo­
mento)
— data e hora do final do incidente (ou da retirada do
cartão, caso o incidente estivesse em curso nesse mo­
mento)
— VRN e Estado-Membro de matrícula do veículo no qual
se produziu o incidente.
Nota: No que se refere ao incidente «sobreposição de tem­
pos»:
— a data e a hora de início do incidente devem correspon­
der à data e à hora de retirada do cartão do veículo
anterior
— a data e a hora do final do incidente devem correspon­
der à data e à hora de inserção do cartão no veículo
presente
— os dados relativos ao veículo devem corresponder ao
veículo presente, no qual se produziu o incidente.
Nota: No que se refere ao incidente «última sessão de
cartão encerrada incorretamente»:
— a data e a hora de início do incidente devem correspon­
der à data e à hora de inserção do cartão na sessão
encerrada incorretamente
— a data e a hora do final do incidente devem correspon­
der à data e à hora de inserção do cartão na sessão
durante a qual o incidente foi detetado (sessão em
curso)
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 82
— os dados relativos ao veículo devem corresponder ao
veículo no qual a sessão não foi encerrada
corretamente.
▼M3
287) O cartão de condutor deve poder memorizar os dados rela­
tivos aos 12 incidentes mais recentes de cada um dos tipos
(ou seja, os dados relativos a 132 incidentes)
▼B
4.5.3.2.8 Dados relativos a falhas
Para efeitos da presente secção, os tempos devem ser registados com
a resolução de 1 segundo.
288) O cartão de condutor deve poder memorizar os dados rela­
tivos às seguintes falhas detetadas pelo aparelho de controlo
durante o período de inserção do cartão:
▼M1
— falha do cartão (se este for o protagonista da falha)
▼B
— falha do aparelho de controlo.
289) O cartão de condutor deve poder memorizar os seguintes
dados relativos àquelas falhas:
— código de falha
— data e hora do início da falha (ou da inserção do cartão,
caso a falha estivesse em curso nesse momento)
— data e hora do final da falha (ou da retirada do cartão,
caso a falha estivesse em curso nesse momento)
— VRN e Estado-Membro de matrícula do veículo no qual
se produziu a falha.
▼M3
290) O cartão de condutor deve poder memorizar os dados rela­
tivos às 24 falhas mais recentes de cada um dos tipos (ou
seja, os dados relativos a 48 falhas).
▼B
4.5.3.2.9 Dados relativos à atividade de condutor
291) Relativamente a cada dia em que o cartão seja utilizado ou
relativamente ao qual o condutor introduza atividades ma­
nualmente, o cartão de condutor deve poder memorizar os
seguintes dados:
— data
— contador de presença diária (com incrementos de uma
unidade por cada um destes dias)
— distância total percorrida pelo condutor nesse dia
— situação do condutor às 00h00
— a cada mudança da atividade do condutor e/ou da si­
tuação da condução e/ou a cada inserção ou retirada do
cartão do condutor:
— situação da condução (CREW, SINGLE)
— ranhura (DRIVER, CO-DRIVER)
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 83
— situação do cartão (INSERTED, NOT INSERTED)
— atividade (DRIVING, AVAILABILITY, WORK,
BREAK/REST).
— hora da mudança.
▼M3
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).
▼B
293) Os dados referidos nos requisitos n. os 286, 289 e 291 de­
vem ser memorizados de modo a permitir recuperar ativi­
dades segundo a sua ordem de ocorrência, mesmo na even­
tualidade de sobreposição de tempos.
4.5.3.2.10 Dados relativos à utilização de veículos
294) Relativamente a cada dia em que se utilize o cartão e a
cada período de utilização de um determinado veículo nesse
dia (um período de utilização inclui a totalidade dos ciclos
consecutivos de inserção/retirada do cartão no veículo, con­
siderados do ponto de vista do cartão), o cartão de condutor
deve poder memorizar os seguintes dados:
— data e hora da primeira utilização do veículo (ou seja,
primeira inserção de cartão durante este período de uti­
lização do veículo, ou 00h00 se o período de utilização
estiver a decorrer no momento)
— valor do conta-quilómetros do veículo aquando da pri­
meira utilização
— data e hora da última utilização do veículo (ou seja,
última retirada de cartão durante este período de utili­
zação do veículo, ou 23h59 se o período de utilização
estiver a decorrer no momento)
— valor do conta-quilómetros do veículo aquando da úl­
tima utilização
— VRN e Estado-Membro de matrícula do veículo
— VIN do veículo.
▼M3
295) O cartão de condutor deve poder memorizar 200 registos
deste tipo.
▼B
4.5.3.2.11 Locais e posições de início e/ou final dos períodos de trabalho
diário
296) O cartão de condutor deve poder memorizar os seguintes
dados relativos aos locais, introduzidos pelo condutor, em
que se iniciam e/ou terminam os períodos de trabalho diá­
rio:
— data e hora da introdução (ou data e hora relativas à
introdução, se esta for manual)
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 84
— tipo de introdução (início ou final, condição da intro­
dução)
— país e região introduzidos
— valor do conta-quilómetros do veículo
— posição do veículo
— precisão GNSS, data e hora no momento de determina­
ção da posição.
▼M3
297) O cartão de condutor deve poder guardar 112 registos deste
tipo.
▼B
4.5.3.2.12 Dados relativos à sessão de cartão
298) O cartão de condutor deve poder memorizar os dados rela­
tivos ao veículo que abriu a sua sessão em curso:
— data e hora de abertura da sessão (ou seja, da inserção
do cartão), com a resolução de 1 segundo
— VRN e Estado-Membro de matrícula.
4.5.3.2.13 Dados relativos à atividade de controlo
299) O cartão de condutor deve poder memorizar os seguintes
dados relativos a atividades de controlo:
— data e hora do controlo
— número e Estado-Membro emissor do cartão de controlo
— tipo de controlo: visualização, impressão, descarrega­
mento da VU e/ou descarregamento do cartão (ver nota)
— período descarregado (se o controlo for de descarrega­
mento)
— VRN e Estado-Membro de matrícula do veículo no qual
teve lugar o controlo.
Nota: os requisitos de segurança implicam que o descarre­
gamento do cartão só seja registado se executado por in­
termédio de um aparelho de controlo.
300) O cartão de condutor deve poder guardar 1 registo deste
tipo.
4.5.3.2.14 Dados relativos às condições especiais
301) O cartão de condutor deve poder memorizar os seguintes
dados relativos às condições especiais introduzidas durante
o período de inserção do cartão (independentemente da
ranhura):
— data e hora da introdução dos dados
— tipo de condição especial.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 85
302) O cartão de condutor deve poder memorizar 112 registos
deste tipo.
▼B
4.5.3.2.15 Dados relativos à utilização de unidades-veículo
303) O cartão de condutor deve poder memorizar os seguintes
dados relativos às diferentes unidades-veículo nas quais foi
utilizado o cartão:
— data e hora do início do período de utilização da
unidade-veículo (ou seja, a primeira inserção do cartão
na unidade-veículo relativa ao período)
— fabricante da VU
— tipo de unidade-veículo
— número da versão do software da VU.
▼M3
304) O cartão de condutor deve poder memorizar 200 registos
deste tipo.
▼M1
4.5.3.2.16 Dados relativos à localização das três horas de condução acumula­
das
305) O cartão de condutor deve poder memorizar os seguintes
dados relativos à posição do veículo, em que o tempo de
condução acumulado atinge um múltiplo de três horas:
— data e hora em que o tempo de condução acumulado
atinge um múltiplo de três horas,
— posição do veículo,
— precisão GNSS, data e hora no momento de determina­
ção da posição,
— valor do conta-quilómetros do veículo.
▼M3
306) O cartão de condutor deve poder memorizar 336 registos
deste tipo.
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 adicio­
nais 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 cor­
respondentes à 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.
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 86
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 correspon­
dentes à 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 determi­
nação da posição,
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 87
— 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 passagei­
ros),
— 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.
▼B
4.5.4 Cartão de oficina
4.5.4.1 A p l i c a ç ã o t a c o g r á f i c a ( a c e s s í v e l à s
u n i d a d e s - v e í c u l o d a s p r i m e i r a e s e g u n d a g e r a ­
ç õ e s )
4.5.4.1.1 Identificação da aplicação
307) O cartão de oficina deve poder memorizar os seguintes
dados relativos à identificação da respetiva aplicação:
— identificação da aplicação tacográfica
— identificação do tipo de cartão tacográfico.
4.5.4.1.2 Chaves e certificados
308) O cartão de oficina deve poder memorizar várias chaves e
certificados criptográficos, conforme especifica o apêndice
11, parte A.
309) O cartão de oficina deve poder memorizar um número de
identificação pessoal (código PIN).
4.5.4.1.3 Identificação do cartão
310) O cartão de oficina deve poder memorizar os seguintes
dados relativos à sua identificação:
— número do cartão
— Estado-Membro emissor, autoridade emissora, data de
emissão
— datas de início e de cessação do prazo de validade.
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 88
4.5.4.1.4 Identificação do titular
311) O cartão de oficina deve poder memorizar os seguintes
dados de identificação do respetivo titular:
— nome da oficina
— endereço da oficina
— apelido do titular
— nome próprio do titular
— idioma de preferência.
4.5.4.1.5 Descarregamento do cartão
312) O cartão de oficina deve poder memorizar os dados relati­
vos ao descarregamento do cartão de modo idêntico a um
cartão de condutor.
4.5.4.1.6 Dados relativos à calibração e ao ajustamento do tempo
313) O cartão de oficina deve poder guardar os registos relativos
a operações de calibração e/ou de ajustamento do tempo
executadas durante o período de inserção do cartão num
aparelho de controlo.
314) Cada registo relativo a calibração deve poder guardar os
seguintes dados:
— objetivo da calibração (ativação, primeira instalação,
instalação, inspeção periódica)
— identificação do veículo
— parâmetros atualizados ou confirmados (dimensões w,
k, l, medida do pneumático, ponto de regulação do
eventual dispositivo de limitação da velocidade, valor
do conta-quilómetros atual e anterior, data e hora atual
e anterior)
— identificação do aparelho de controlo (número de peça
da VU, número de série da VU, número de série do
sensor de movimentos).
315) O cartão de oficina deve poder memorizar pelo menos 88
registos deste tipo.
316) O cartão de oficina deve ser equipado com um contador
que indique o número total de calibrações executadas com
o cartão.
317) O cartão de oficina deve ser equipado com um contador
que indique o número de calibrações executadas desde o
seu último descarregamento.
4.5.4.1.7 Dados relativos a incidentes e a falhas
318) O cartão de oficina deve poder memorizar os dados relati­
vos a incidentes e a falhas de modo idêntico a um cartão de
condutor.
319) O cartão de oficina deve poder memorizar os dados relati­
vos aos 3 incidentes mais recentes de cada um dos tipos
(ou seja, os dados relativos a 18 incidentes) e os dados
relativos às 6 falhas mais recentes de cada um dos tipos
(ou seja, os dados relativos a 12 falhas).
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 89
4.5.4.1.8 Dados relativos à atividade de condutor
320) O cartão de oficina deve poder memorizar os dados relati­
vos à atividade de condutor de modo idêntico a um cartão
de condutor.
321) O cartão de oficina deve poder guardar os dados relativos à
atividade de condutor durante pelo menos 1 dia de ativi­
dade média do condutor.
4.5.4.1.9 Dados relativos à utilização de veículos
322) O cartão de oficina deve poder memorizar os dados relati­
vos à utilização de veículos de modo idêntico a um cartão
de condutor.
323) O cartão de oficina deve poder memorizar pelo menos 4
registos deste tipo.
4.5.4.1.10 Dados relativos ao início e/ou ao final dos períodos de trabalho
diário
324) O cartão de oficina deve poder memorizar os dados relati­
vos ao início e/ou ao final dos períodos de trabalho diário
de modo idêntico a um cartão de condutor.
325) O cartão de oficina deve poder guardar pelo menos 3 pares
de registos deste tipo.
4.5.4.1.11 Dados relativos à sessão de cartão
326) O cartão de oficina deve poder memorizar o registo dos
dados relativos à sessão do cartão de modo idêntico a um
cartão de condutor.
4.5.4.1.12 Dados relativos à atividade de controlo
327) O cartão de oficina deve poder memorizar os dados relati­
vos à atividade de controlo de modo idêntico a um cartão
de condutor.
4.5.4.1.13 Dados relativos às condições especiais
328) O cartão de oficina deve poder memorizar os dados relati­
vos às condições especiais de modo idêntico a um cartão de
condutor.
329) O cartão de oficina deve poder memorizar pelo menos 2
registos deste tipo.
▼M3
4.5.4.2 A p l i c a ç ã o t a c o g r á f i c a d a g e r a ç ã o 2 ( n ã o a c e s s í ­
v e l à s u n i d a d e s - v e í c u l o d a p r i m e i r a g e r a ç ã o ,
a c e s s í v e l à s v e r s õ e s 1 e 2 d a s u n i d a d e s - v e í c u l o
d a s e g u n d a g e r a ç ã o )
▼B
4.5.4.2.1 Identificação da aplicação
330) O cartão de oficina deve poder memorizar os seguintes
dados relativos à identificação da respetiva aplicação:
— identificação da aplicação tacográfica
— identificação do tipo de cartão tacográfico.
▼M3
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 iden­
tificação da aplicação adicionais apenas aplicáveis à ver­
são 2.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 90
4.5.4.2.2 Chaves e certificados
331) O cartão de oficina deve poder memorizar várias chaves e
certificados criptográficos, conforme especifica o apêndice
11, parte B.
332) O cartão de oficina deve poder memorizar um número de
identificação pessoal (código PIN).
4.5.4.2.3 Identificação do cartão
333) O cartão de oficina deve poder memorizar os seguintes
dados relativos à sua identificação:
— número do cartão
— Estado-Membro emissor, autoridade emissora, data de
emissão
— datas de início e de cessação do prazo de validade.
4.5.4.2.4 Identificação do titular
334) O cartão de oficina deve poder memorizar os seguintes
dados de identificação do respetivo titular:
— nome da oficina
— endereço da oficina
— apelido do titular
— nome próprio do titular
— idioma de preferência.
4.5.4.2.5 Descarregamento do cartão
335) O cartão de oficina deve poder memorizar os dados relati­
vos ao descarregamento do cartão de modo idêntico a um
cartão de condutor.
4.5.4.2.6 Dados relativos à calibração e ao ajustamento do tempo
336) O cartão de oficina deve poder guardar os registos relativos
a operações de calibração e/ou de ajustamento do tempo
executadas durante o período de inserção do cartão num
aparelho de controlo.
337) Cada registo relativo a calibração deve poder guardar os
seguintes dados:
— objetivo da calibração (ativação, primeira instalação,
instalação, inspeção periódica)
— identificação do veículo
— parâmetros atualizados ou confirmados (dimensões w,
k, l, medida do pneumático, ponto de regulação do
eventual dispositivo de limitação da velocidade, valor
do conta-quilómetros atual e anterior, data e hora atual
e anterior)
— identificação do aparelho de controlo (número de peça
da VU, número de série da VU, número de série do
sensor de movimentos, número de série do sistema de
comunicação à distância e número de série do módulo
GNSS externo, quando aplicável)
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 91
— tipo de selo e identificador de todos os selos em vigor
— capacidade de utilização de cartões tacográficos da pri­
meira geração por parte da VU (ativada ou não).
▼M3
338) O cartão de oficina deve poder memorizar 255 registos
deste tipo.
▼B
339) O cartão de oficina deve ser equipado com um contador
que indique o número total de calibrações executadas com
o cartão.
340) O cartão de oficina deve ser equipado com um contador
que indique o número de calibrações executadas desde o
seu último descarregamento.
4.5.4.2.7 Dados relativos a incidentes e a falhas
341) O cartão de oficina deve poder memorizar os dados relati­
vos a incidentes e a falhas de modo idêntico a um cartão de
condutor.
342) O cartão de oficina deve poder memorizar os dados relati­
vos aos 3 incidentes mais recentes de cada um dos tipos
(ou seja, os dados relativos a 33 incidentes) e os dados
relativos às 6 falhas mais recentes de cada um dos tipos
(ou seja, os dados relativos a 12 falhas).
4.5.4.2.8 Dados relativos à atividade de condutor
343) O cartão de oficina deve poder memorizar os dados relati­
vos à atividade de condutor de modo idêntico a um cartão
de condutor.
▼M3
344) O cartão de oficina deve poder guardar os dados relativos à
atividade de condutor durante 1 dia contendo 240 mudanças
de atividade.
▼B
4.5.4.2.9 Dados relativos à utilização de veículos
345) O cartão de oficina deve poder memorizar os dados relati­
vos à utilização de veículos de modo idêntico a um cartão
de condutor.
▼M3
346) O cartão de oficina deve poder memorizar 8 registos deste
tipo.
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 po­
siçõ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 re­
gistos deste tipo.
▼B
4.5.4.2.11 Dados relativos à sessão de cartão
349) O cartão de oficina deve poder memorizar o registo dos
dados relativos à sessão do cartão de modo idêntico a um
cartão de condutor.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 92
4.5.4.2.12 Dados relativos à atividade de controlo
350) O cartão de oficina deve poder memorizar os dados relati­
vos à atividade de controlo de modo idêntico a um cartão
de condutor.
4.5.4.2.13 Dados relativos à utilização de unidades-veículo
351) O cartão de oficina deve poder memorizar os seguintes
dados relativos às diferentes unidades-veículo nas quais
foi utilizado o cartão:
— data e hora do início do período de utilização da
unidade-veículo (ou seja, a primeira inserção do cartão
na unidade-veículo relativa ao período)
— fabricante da VU
— tipo de unidade-veículo
— número da versão do software da VU.
▼M3
352) O cartão de oficina deve poder memorizar 8 registos deste
tipo.
▼M1
4.5.4.2.14 Dados relativos à localização das três horas de condução acumula­
das
353) O cartão de oficina deve poder memorizar os seguintes
dados relativos à posição do veículo, em que o tempo de
condução acumulado atinge um múltiplo de três horas:
— data e hora em que o tempo de condução acumulado
atinge um múltiplo de três horas,
— posição do veículo,
— precisão GNSS, data e hora no momento de determina­
ção da posição,
— valor do conta-quilómetros do veículo.
▼M3
354) O cartão de oficina deve poder memorizar 24 registos deste
tipo.
▼B
4.5.4.2.15 Dados relativos às condições especiais
355) O cartão de oficina deve poder memorizar os dados relati­
vos às condições especiais de modo idêntico a um cartão de
condutor.
▼M3
356) O cartão de oficina deve poder memorizar 4 registos deste
tipo.
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.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 93
356-B) O cartão de oficina deve poder memorizar 4 pares de re­
gistos 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 relati­
vos à 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 relati­
vos à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 cali­
braçã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 valo­
res memorizados em EF Calibration no DF Tacho­
graph_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.
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 94
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.
▼B
4.5.5 Cartão de controlo
4.5.5.1 A p l i c a ç ã o t a c o g r á f i c a ( a c e s s í v e l à s
u n i d a d e s - v e í c u l o d a s p r i m e i r a e s e g u n d a g e r a ­
ç õ e s )
4.5.5.1.1 Identificação da aplicação
357) O cartão de controlo deve poder memorizar os seguintes
dados de identificação da aplicação:
— identificação da aplicação tacográfica
— identificação do tipo de cartão tacográfico.
4.5.5.1.2 Chaves e certificados
358) O cartão de controlo deve poder memorizar várias chaves e
certificados criptográficos, conforme especifica o apêndice
11, parte A.
4.5.5.1.3 Identificação do cartão
359) O cartão de controlo deve poder memorizar os seguintes
dados relativos à sua identificação:
— número do cartão
— Estado-Membro emissor, autoridade emissora, data de
emissão
— eventuais datas de início e de cessação do prazo de
validade.
4.5.5.1.4 Identificação do titular
360) O cartão de controlo deve poder memorizar os seguintes
dados de identificação do respetivo titular:
— nome do organismo de controlo
— endereço do organismo de controlo
— apelido do titular
— nome próprio do titular
— idioma de preferência.
4.5.5.1.5 Dados relativos à atividade de controlo
361) O cartão de controlo deve poder memorizar os seguintes
dados relativos a atividades de controlo:
— data e hora do controlo
▼M3
— tipo do controlo (visualização e/ou impressão e/ou des­
carregamento da VU e/ou descarregamento do cartão),
▼B
— período do descarregamento (eventual)
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 95
— VRN e Estado-Membro de matrícula do veículo sujeito
ao controlo
— número do cartão e Estado-Membro emissor do cartão
de condutor sujeito ao controlo.
362) O cartão de controlo deve poder guardar pelo menos 230
registos deste tipo.
4.5.5.2 A p l i c a ç ã o t a c o g r á f i c a G 2 ( n ã o a c e s s í v e l
a u n i d a d e s - v e í c u l o d a p r i m e i r a g e r a ç ã o )
4.5.5.2.1 Identificação da aplicação
363) O cartão de controlo deve poder memorizar os seguintes
dados de identificação da aplicação:
— identificação da aplicação tacográfica
— identificação do tipo de cartão tacográfico.
▼M3
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 iden­
tificação da aplicação adicionais apenas aplicáveis à ver­
são 2.
▼B
4.5.5.2.2 Chaves e certificados
364) O cartão de controlo deve poder memorizar várias chaves e
certificados criptográficos, conforme especifica o apêndice
11, parte B.
4.5.5.2.3 Identificação do cartão
365) O cartão de controlo deve poder memorizar os seguintes
dados relativos à sua identificação:
— número do cartão
— Estado-Membro emissor, autoridade emissora, data de
emissão
— eventuais datas de início e de cessação do prazo de
validade.
4.5.5.2.4 Identificação do titular
366) O cartão de controlo deve poder memorizar os seguintes
dados de identificação do respetivo titular:
— nome do organismo de controlo
— endereço do organismo de controlo
— apelido do titular
— nome próprio do titular
— idioma de preferência.
4.5.5.2.5 Dados relativos à atividade de controlo
367) O cartão de controlo deve poder memorizar os seguintes
dados relativos a atividades de controlo:
— data e hora do controlo
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 96
— tipo de controlo: visualização, impressão, descarrega­
mento da VU e/ou descarregamento do cartão e/ou con­
trolo de calibração de estrada
— período do descarregamento (eventual)
— VRN e Estado-Membro de matrícula do veículo sujeito
ao controlo
— número do cartão e Estado-Membro emissor do cartão
de condutor sujeito ao controlo.
368) O cartão de controlo deve poder guardar pelo menos 230
registos deste tipo.
▼M3
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.
▼B
4.5.6 Cartão de empresa
4.5.6.1 A p l i c a ç ã o t a c o g r á f i c a ( a c e s s í v e l à s
u n i d a d e s - v e í c u l o d a s p r i m e i r a e s e g u n d a g e r a ­
ç õ e s )
4.5.6.1.1 Identificação da aplicação
369) O cartão de empresa deve poder memorizar os seguintes
dados de identificação da aplicação:
— identificação da aplicação tacográfica
— identificação do tipo de cartão tacográfico.
4.5.6.1.2 Chaves e certificados
370) O cartão de empresa deve poder memorizar várias chaves e
certificados criptográficos, conforme especifica o apêndice
11, parte A.
4.5.6.1.3 Identificação do cartão
371) O cartão de empresa deve poder memorizar os seguintes
dados relativos à sua identificação:
— número do cartão
— Estado-Membro emissor, autoridade emissora, data de
emissão
— eventuais datas de início e de cessação do prazo de
validade.
4.5.6.1.4 Identificação do titular
372) O cartão de empresa deve poder memorizar os seguintes
dados de identificação do respetivo titular:
— nome da empresa
— endereço da empresa.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 97
4.5.6.1.5 Dados relativos à atividade da empresa
373) O cartão de empresa deve poder memorizar os seguintes
dados relativos à atividade da empresa:
— data e hora da atividade
— tipo de atividade: início (lock-in) e/ou final (lock-out)
de bloqueamento da VU, descarregamento da VU e/ou
descarregamento do cartão
— período do descarregamento (eventual)
— VRN e Estado-Membro de matrícula do veículo
— número e Estado-Membro emissor do cartão (em caso
de descarregamento do cartão).
374) O cartão de empresa deve poder guardar pelo menos 230
registos deste tipo.
4.5.6.2 A p l i c a ç ã o t a c o g r á f i c a G 2 ( n ã o a c e s s í v e l
a u n i d a d e s - v e í c u l o d a p r i m e i r a g e r a ç ã o )
4.5.6.2.1 Identificação da aplicação
375) O cartão de empresa deve poder memorizar os seguintes
dados de identificação da aplicação:
— identificação da aplicação tacográfica
— identificação do tipo de cartão tacográfico.
▼M3
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 iden­
tificação da aplicação adicionais apenas aplicáveis à ver­
são 2.
▼B
4.5.6.2.2 Chaves e certificados
376) O cartão de empresa deve poder memorizar várias chaves e
certificados criptográficos, conforme especifica o apêndice
11, parte B.
4.5.6.2.3 Identificação do cartão
377) O cartão de empresa deve poder memorizar os seguintes
dados relativos à sua identificação:
— número do cartão
— Estado-Membro emissor, autoridade emissora, data de
emissão
— eventuais datas de início e de cessação do prazo de
validade.
4.5.6.2.4 Identificação do titular
378) O cartão de empresa deve poder memorizar os seguintes
dados de identificação do respetivo titular:
— nome da empresa
— endereço da empresa.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 98
4.5.6.2.5 Dados relativos à atividade da empresa
379) O cartão de empresa deve poder memorizar os seguintes
dados relativos à atividade da empresa:
— data e hora da atividade
— tipo de atividade: início (lock-in) e/ou final (lock-out)
de bloqueamento da VU, descarregamento da VU e/ou
descarregamento do cartão
— período do descarregamento (eventual)
— VRN e Estado-Membro de matrícula do veículo
— número e Estado-Membro emissor do cartão (em caso
de descarregamento do cartão).
380) O cartão de empresa deve poder guardar pelo menos 230
registos deste tipo.
▼M3
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.
▼B
5 INSTALAÇÃO DE APARELHO DE CONTROLO
5.1 Instalação
381) Os aparelhos de controlo novos devem ser entregues não
ativados aos instaladores ou fabricantes dos veículos, com
todos os parâmetros de calibração, constantes do
capítulo 3.21, ajustados aos correspondentes valores por
defeito. Nos casos em que não existam valores definidos
por defeito, os parâmetros literais devem ser apresentados
em séries de «?» e os parâmetros numéricos em séries de
«0». A entrega de peças relevantes para a segurança do
aparelho de controlo pode ser restringida, se a certificação
de segurança o exigir.
382) Antes da ativação, o aparelho de controlo deve dar acesso à
função de calibração, mesmo que não esteja em modo de
calibração.
▼M3
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 requi­
sito 117, e as falhas do aparelho de controlo, de acordo
com o requisito 118.
▼B
384) Durante a instalação, os fabricantes de veículos devem pré-
-ajustar todos os parâmetros conhecidos.
385) Os fabricantes de veículos ou instaladores devem ativar o
aparelho de controlo o mais tardar antes de o veículo ser
utilizado para os fins abrangidos pelo Regulamento (CE)
n. o 561/2006.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 99
386) A ativação do aparelho de controlo deve ser automatica­
mente acionada pela primeira inserção de um cartão de
oficina em qualquer das suas interfaces.
387) As eventuais operações específicas de emparelhamento en­
tre o sensor de movimentos e a unidade-veículo devem
processar-se automaticamente antes ou durante a ativação.
388) Do mesmo modo, as eventuais operações específicas de
emparelhamento entre o módulo GNSS externo e
a unidade-veículo devem processar-se automaticamente an­
tes ou durante a ativação.
389) Uma vez ativado, o aparelho de controlo deve cumprir
plenamente as funções e os direitos de acesso aos dados.
390) Uma vez ativado, o aparelho de controlo deve comunicar
ao sistema de comunicação à distância os dados securizados
necessários para a realização de controlos de estrada
seletivos.
391) As funções de registo e de memorização do aparelho de
controlo devem ficar plenamente operacionais após a ativa­
ção.
▼M3
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 cir­
cunstâ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
393) A instalação de um módulo GNSS externo exige o empa­
relhamento com a unidade-veículo e a posterior verificação
das informações de posição GNSS.
394) O aparelho de controlo deve ser instalado no veículo de
modo a que o condutor, do seu lugar, possa ter acesso às
funções que pretender.
5.2 Placa de instalação
395) ►M3 Uma vez verificado o aparelho de controlo aquando
da instalação, deve afixar-se no mesmo uma placa de ins­
talaçã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. ◄
No final de qualquer inspeção efetuada por um instalador
ou oficina homologada, a placa anterior deve ser substituída
por uma nova.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 100
396) Na placa devem figurar pelo menos os seguintes elementos:
— nome, endereço e marca do instalador ou oficina
homologada,
— coeficiente característico do veículo, sob a forma «w =
… imp/km»,
— constante do aparelho de controlo, sob a forma «k = …
imp/km»,
— perímetro efetivo dos pneus das rodas, sob a forma «l =
… mm»,
— medida do pneumático,
— data de medição do coeficiente característico do veículo
e do perímetro efetivo dos pneus das rodas,
— número de identificação do veículo,
— presença (ou ausência) de um módulo GNSS externo,
— número de série do módulo GNSS externo, quando
aplicável,
▼M3
— o número de série do sistema de comunicação à distân­
cia, caso exista;
▼M1
— número de série de todos os selos em vigor,
— parte do veículo onde eventualmente está instalado o
adaptador,
— parte do veículo onde está instalado o sensor de movi­
mentos, se não estiver ligado à caixa de velocidades ou
não estiver a ser utilizado um adaptador,
— descrição da cor do cabo entre o adaptador e a parte do
veículo de onde provêm os impulsos de entrada,
— número de série do sensor de movimentos incorporado
no adaptador.
▼M3
— o tipo de carga por defeito associado ao veículo.
▼B
397) Apenas no que diz respeito a veículos M1 e N1, equipados
com um adaptador em conformidade com o estabelecido no
Regulamento (CE) n. o 68/2009 ( 1 ), e se não for possível
incluir toda a informação necessária, conforme descrito no
requisito n. o 396, pode utilizar-se uma segunda placa adi­
cional, caso em que tal placa adicional deve conter, pelo
menos, os últimos quatro travessões descritos no requisito
n. o 396.
▼M1
( 1 ) Regulamento (CE) n. o 68/2009 da Comissão, de 23 de janeiro de 2009, que adapta pela
nona vez ao progresso técnico o Regulamento (CEE) n. o 3821/85 do Conselho relativo à
introdução de um aparelho de controlo no domínio dos transportes rodoviários (JO L 21
de 24.1.2009, p. 3).
02016R0799 — PT — 21.08.2023 — 003.002 — 101
A eventual segunda placa deve ser afixada próximo ou ao
lado da primeira placa primária descrita no requisito n. o 396
e deve ter o mesmo nível de proteção. A placa secundária
deve também apresentar o nome, o endereço ou a designa­
ção comercial do instalador ou a oficina homologada que
efetuou a instalação, bem como a data da instalação.
5.3 Selagem
398) Devem ser seladas as seguintes peças:
— qualquer ligação que, se estiver desligada, provoque
alterações indetetáveis ou perda indetetável de dados
(pode, por exemplo, aplicar-se ao encaixe do sensor
de movimentos na caixa de velocidades, ao adaptador
para veículos M1/N1, à ligação GNSS externa ou à
unidade-veículo);
— a placa de instalação, a menos que seja aplicada de tal
maneira que não se possa retirar sem destruir as mar­
cações.
▼M1
398a) Os selos anteriormente referidos devem ser certificados de
acordo com a norma EN 16882:2016.
▼B
399) Os selos supramencionados podem ser removidos:
— em caso de emergência
— para instalar, ajustar ou reparar um dispositivo de limi­
tação da velocidade ou outro dispositivo de segurança
rodoviária, sob condição de o aparelho de controlo con­
tinuar a funcionar corretamente e ser de novo selado
por um instalador ou oficina homologada (em confor­
midade com o capítulo 6) imediatamente após a fixação
do dispositivo de limitação da velocidade ou de outro
dispositivo de segurança rodoviária ou no prazo de sete
dias noutros casos.
400) Cada vez que os selos forem removidos, deve ser redigida e
disponibilizada à autoridade competente uma declaração de
motivos.
401) Os selos devem possuir um número de identificação, atri­
buído pelo seu fabricante. Este número deve ser único e
distinto de qualquer outro número de selo atribuído por
qualquer outro fabricante de selos.
▼M1
O número de identificação único é definido como:
MMNNNNNNNN por marcação não removível, sendo
MM a identificação única do fabricante (registo da base
de dados a gerir pela CE) e NNNNNNNN o código alfa­
numérico do selo, único no domínio do fabricante.
▼B
402) Os selos devem dispor de um espaço livre onde os ins­
taladores, as oficinas ou os fabricantes de veículos (homo­
logados) possam adicionar uma marca especial nos termos
do artigo 22. o , n. o 3 do Regulamento (UE) n. o 165/2014.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 102
Esta marca não deve abranger o número de identificação do
selo.
▼M1
403) Os fabricantes de selos devem estar registados numa base
de dados dedicada após obtenção de modelo de selo certi­
ficado de acordo com a norma EN 16882:2016 e disponi­
bilizar publicamente os números dos selos de identificação
através de um procedimento a estabelecer pela Comissão
Europeia.
404) As oficinas e os fabricantes de veículos (homologados)
devem, no âmbito do Regulamento (UE) n. o 165/2014, uti­
lizar somente selos certificados de acordo com a norma EN
16882:2016 de entre os listados pelos fabricantes na base
de dados supramencionada.
▼B
405) Os fabricantes de selos e os respetivos distribuidores devem
manter registos completos de rastreabilidade dos selos ven­
didos a utilizar no âmbito do Regulamento (UE)
n. o 165/2014 e devem estar preparados para os produzir
para as autoridades nacionais competentes, sempre que ne­
cessário.
406) Os números de identificação única dos selos devem estar
visíveis na placa de instalação.
6 VERIFICAÇÕES, INSPEÇÕES E REPARAÇÕES
Os requisitos aplicáveis à remoção dos selos, nos termos do ar­
tigo 22. o , n. o 5, do Regulamento (UE) n. o 165/2014, figuram no
capítulo 5.3 do presente anexo.
6.1 Homologação de instaladores, oficinas e fabricantes de veículos
Os Estados-Membros homologam, sujeitam a controlo regular e
certificam os organismos responsáveis pelas seguintes operações:
— instalação
— controlos
— inspeções
— reparação.
Os cartões de oficina são emitidos unicamente em nome de ins­
taladores e/ou oficinas homologados para efeitos de ativação e/ou
calibração dos aparelhos de controlo, em conformidade com o pre­
sente anexo, e, salvo devida justificação:
— que não sejam elegíveis para atribuição de cartão de empresa
— cujas restantes atividades profissionais não representem um risco
potencial para a segurança geral do sistema, na aceção do apên­
dice 10.
▼M1
6.2 Verificação de componentes novos ou reparados
407) Cada dispositivo individual, novo ou reparado, deve ser
verificado em relação ao seu funcionamento correto e à
precisão dos seus registos e leituras, dentro dos limites
estabelecidos nos capítulos 3.2.1, 3.2.2, 3.2.3 e 3.3.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 103
6.3 Inspeção da instalação
▼M1
408) Na fixação a um veículo, o conjunto da instalação (in­
cluindo o aparelho de controlo) deve cumprir o disposto
nos capítulos 3.2.1, 3.2.2, 3.2.3 e 3.3 em matéria de tole­
râncias máximas. O conjunto da instalação deve ser selado
em conformidade com o disposto no capítulo 5.3, incluindo
uma calibração.
▼B
6.4 Inspeções periódicas
▼M3
409) Devem ser feitas inspeções periódicas aos aparelhos ins­
talados 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 su­
periores 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
410) Estas inspeções devem incluir as seguintes verificações:
— funcionamento correto do aparelho de controlo, in­
cluindo a função de memorização de dados nos cartões
tacográficos e a comunicação com os leitores de comu­
nicação à distância
— garantia de conformidade com o disposto nos capítulos
3.2.1 e 3.2.2 acerca das tolerâncias máximas admissí­
veis aquando da instalação
— garantia de conformidade com o disposto nos capítulos
3.2.3 e 3.3
— colocação da marca de homologação de tipo no apare­
lho de controlo
— presença da placa de instalação, definida no requisito
n. o 396, e da placa descritiva, definida no requisito
n. o 225
— medida do pneumático e perímetro efetivo dos pneumá­
ticos
— inexistência de dispositivos de manipulação fixados no
equipamento
— colocação correta dos selos, bom estado, validade dos
números de identificação (fabricante de selos referido
na base de dados CE) e correspondência dos respetivos
números de identificação com as marcas da placa de
instalação (ver requisito n. o 401).
▼M3
— que o identificador da versão do mapa digital memori­
zado é o mais recente.
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.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 104
411) Caso se verifique, desde a última inspeção, a ocorrência de
um dos incidentes enumerados no capítulo 3.9 (Deteção de
incidentes e/ou falhas), que os fabricantes do tacógrafo e/ou
as autoridades nacionais considerem suscetíveis de pôr em
risco a segurança do equipamento, a oficina deve:
a. fazer uma comparação entre os dados de identificação
do sensor de movimentos ligado à caixa de velocidades
com os do sensor de movimentos emparelhado registado
na unidade-veículo
b. verificar se as informações gravadas na placa de instala­
ção correspondem às informações contidas no registo da
unidade-veículo
c. verificar se o número de série e o número de homolo­
gação do sensor de movimentos, quando impresso na
caixa do sensor de movimentos, corresponde às infor­
mações contidas na memória de dados do aparelho de
controlo
d. comparar os dados de identificação marcados na placa
descritiva do módulo GNSS externo, se houver, com os
memorizados na memória de dados da unidade-veículo.
412) As oficinas devem manter, nos seus relatórios de inspeção,
registos de quaisquer constatações relativas a selos quebra­
dos ou dispositivos de manipulação. Estes relatórios devem
ser mantidos pelas oficinas durante um período mínimo de
dois anos e disponibilizados à autoridade competente sem­
pre que esta o solicite.
413) Estas inspeções devem incluir uma calibração e uma subs­
tituição preventiva dos selos cuja instalação esteja sob a
responsabilidade de oficinas.
6.5 Determinação dos erros
414) A determinação dos erros na instalação e durante a utiliza­
ção efetua-se nas seguintes condições, a considerar como
condições normais de ensaio:
— veículos em vazio, em condições normais de marcha
— pressão dos pneus, segundo as indicações do fabricante
— desgaste dos pneus, segundo os limites autorizados pela
legislação nacional
— circulação de veículos:
— o veículo deve avançar movido pelo seu próprio motor,
em linha reta sobre uma superfície plana, à velocidade
de 50 ± 5 km/h. A distância de medição deve ser de
pelo menos 1 000 m.
— sob condição de terem precisão comparável, podem
igualmente utilizar-se para o ensaio métodos alternati­
vos, como um banco de ensaios adequado.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 105
6.6 Reparações
415) As oficinas devem poder descarregar dados do aparelho de
controlo para a empresa de transportes pertinente.
416) Se um mau funcionamento do aparelho de controlo invia­
bilizar o descarregamento de dados previamente registados,
mesmo após reparação efetuada por uma oficina homolo­
gada, esta última deve emitir, em nome da empresa de
transportes, um certificado relativo à impossibilidade de
descarregamento de dados. A oficina deve guardar, durante
um período mínimo de dois anos, uma cópia de cada cer­
tificado emitido.
7 EMISSÃO DE CARTÕES
Os processos de emissão de cartões estabelecidos pelos
Estados-Membros devem cumprir as seguintes condições:
417) O número de um cartão tacográfico, relativo à sua primeira
emissão em nome de um requerente, deve ter um índice de
série (eventual), um índice de substituição e um índice de
renovação ajustado a «0».
418) Os números dos cartões tacográficos não pessoais emitidos
em nome de um só organismo de controlo, de uma só
oficina ou de uma só empresa de transportes devem ter
os mesmos 13 primeiros algarismos, mas diferentes índices
de série.
419) Um cartão tacográfico emitido em substituição de outro
existente deve ter o mesmo número do cartão substituído,
com exceção do índice de substituição, que é sucessiva­
mente acrescido de uma unidade (segundo a ordem 0, …,
9, A, …, Z).
420) Um cartão tacográfico emitido em substituição de outro
existente deve ter o mesmo prazo de validade do subs­
tituído.
421) Um cartão tacográfico emitido para renovação de outro
existente deve ter o mesmo número do cartão renovado,
com exceção do índice de substituição, que é ajustado a
«0», e do índice de renovação, que é sucessivamente acres­
cido de uma unidade (segundo a ordem 0, …, 9, A, …, Z).
422) A troca de um cartão tacográfico existente, visando alterar
dados administrativos, deve obedecer às regras da renova­
ção se se processar dentro do mesmo Estado-Membro, ou
às regras de uma primeira emissão se se processar noutro
Estado-Membro.
423) Tratando-se de cartões de oficina ou de controlo, o espaço
destinado ao «apelido do titular do cartão» deve ser preen­
chido com o nome da oficina ou organismo de controlo, ou
com o nome do instalador ou do agente de controlo, caso
os Estados-Membros assim o decidam.
424) Os Estados-Membros devem proceder ao intercâmbio ele­
trónico de dados, a fim de garantir que os cartões de con­
dutor do tacógrafo que emitirem são únicos, em conformi­
dade com o artigo 31. o do Regulamento (UE) n. o 165/2014.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 106
8 HOMOLOGAÇÃO DE TIPO DOS APARELHOS DE CON­
TROLO E DOS CARTÕES TACOGRÁFICOS
8.1 Aspetos gerais
▼M1
Na aceção do presente capítulo, por «aparelho de controlo»
entende-se «o aparelho de controlo ou os seus componentes». Não
é necessária homologação de tipo para o(s) cabo(s) que liga(m) o
sensor de movimentos à VU, que liga(m) o módulo GNSS externo à
VU ou que liga(m) o sistema externo de comunicação à distância à
VU. O papel utilizado no aparelho de controlo é considerado um
seu componente.
Qualquer fabricante pode solicitar a homologação de tipo de qual­
quer componente do aparelho de controlo, desde que estes estejam
em conformidade com os requisitos do presente anexo. Em alterna­
tiva, os fabricantes podem também solicitar a homologação de tipo
do aparelho de controlo.
Tal como descrito na definição (10) constante do artigo 2. o do pre­
sente regulamento, as unidades-veículo possuem variantes a nível do
conjunto de componentes. Independentemente do conjunto de com­
ponentes da unidade-veículo, a antena externa e (quando aplicável)
o repartidor de antena ligado ao recetor GNSS ou ao módulo de
comunicação à distância não fazem parte da homologação de tipo da
unidade-veículo.
Não obstante, os fabricantes que obtiveram a homologação de tipo
para o aparelho de controlo devem publicitar uma lista de antenas e
repartidores de antena compatíveis com cada uma das
unidades-veículo, dos módulos GNSS externos e dos módulos de
comunicação à distância homologados.
▼B
425) Ao ser apresentado para homologação, o aparelho de con­
trolo deve vir acompanhado de quaisquer dispositivos in­
tegrados adicionais.
426) A homologação de tipo do aparelho de controlo e dos
cartões tacográficos deve incluir os ensaios de segurança
associados, os ensaios de funcionalidade e os ensaios de
interoperabilidade. Os resultados positivos de cada um des­
tes ensaios devem constar de correspondentes certificados.
▼M1
427) As autoridades responsáveis pela homologação de tipo nos
Estados-Membros não podem emitir certificados de homo­
logação de tipo se não tiverem na sua posse:
— um certificado de segurança (se requerido no presente
anexo),
— um certificado de funcionalidade,
— um certificado de interoperabilidade (se requerido no
presente anexo)
relativos ao aparelho de controlo ou ao cartão tacográfico
que são objeto do pedido de homologação de tipo.
▼B
428) Qualquer modificação no software, no equipamento infor­
mático ou na natureza dos materiais utilizados no fabrico
do aparelho deve ser notificada à autoridade que concedeu
a homologação de tipo do aparelho, antes de este entrar em
utilização. Essa autoridade confirma ao fabricante a exten­
são da homologação de tipo ou pede uma atualização ou
confirmação dos certificados de segurança, de funcionali­
dade e/ou de interoperabilidade.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 107
429) Os procedimentos de atualização in situ do software apli­
cado ao aparelho de controlo devem ser homologados pela
autoridade que concedeu a homologação de tipo do apare­
lho 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 fabri­
cante 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 modi­
ficaçõ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 con­
juntos de carateres, se não for tecnicamente viável.
▼B
8.2 Certificado de segurança
431) O certificado de segurança é entregue em conformidade
com o disposto no apêndice 10 do presente anexo. Os
aparelhos de controlo a certificar são a unidade-veículo, o
sensor de movimentos, o módulo GNSS externo e os car­
tões tacográficos.
432) Caso as autoridades de certificação de segurança se recu­
sem, excecionalmente, a certificar novo equipamento por
motivo de obsolescência dos mecanismos de segurança, a
homologação de tipo deve continuar a ser concedida apenas
nesta circunstância específica e excecional e se não existir
solução alternativa que cumpra o regulamento.
433) Nesta circunstância, o Estado-Membro em causa deve, sem
demora, informar a Comissão Europeia, a qual, no prazo de
doze meses civis a contar da concessão da homologação de
tipo, iniciará um procedimento para assegurar a restauração
do nível de segurança original.
8.3 Certificado de funcionalidade
434) Os candidatos à homologação de tipo devem fornecer às
autoridades nacionais competentes todo o material e docu­
mentação que estas requererem.
435) Os fabricantes devem fornecer, no prazo de um mês após a
apresentação do pedido, as amostras pertinentes dos produ­
tos candidatos a homologação de tipo, bem como a docu­
mentação correlata, que os laboratórios nomeados para exe­
cutar os ensaios de funcionalidade solicitarem. Quaisquer
custos resultantes destes pedidos serão assumidos pela en­
tidade requerente. Os laboratórios devem tratar confiden­
cialmente as informações comercialmente sensíveis.
436) Ao fabricante só pode ser concedido um certificado de
funcionalidade depois de efetuados com êxito pelo menos
os ensaios de funcionalidade especificados no apêndice 9.
437) A autoridade responsável pela homologação de tipo emite o
certificado de funcionalidade, do qual constará, além do
nome do beneficiário e da identificação do modelo, uma
lista dos ensaios executados e dos respetivos resultados.
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 108
438) O certificado de funcionalidade de qualquer componente de
um aparelho de controlo deve também indicar os números
de homologação de todos os outros tipos de componentes
de aparelhos de controlo compatíveis que tenham sido ho­
mologados e ensaiados para esta certificação.
439) O certificado de funcionalidade de qualquer componente de
um aparelho de controlo deve também indicar a norma ISO
ou CEN segundo a qual a interface funcional foi
certificada.
8.4 Certificado de interoperabilidade
440) Os ensaios de interoperabilidade são executados por um
laboratório, sob a autoridade e a responsabilidade da Co­
missão Europeia.
441) O laboratório regista, segundo a ordem cronológica de che­
gada, os pedidos de ensaio de interoperabilidade apresenta­
dos pelos fabricantes.
442) Os pedidos de ensaio só são oficialmente registados quando
o laboratório estiver de posse dos seguintes elementos:
— conjunto completo de material e documentação, neces­
sário para os ensaios de interoperabilidade em causa
— certificado de segurança correspondente
— certificado de funcionalidade correspondente.
A data de registo do pedido é comunicada ao fabricante.
▼M3
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 fun­
cional, exceto nas circunstâncias excecionais referidas no
requisito 432.
▼B
444) O fabricante que apresenta um pedido de ensaio de intero­
perabilidade compromete-se a deixar ao laboratório respon­
sável pelo ensaio o conjunto completo de material e docu­
mentação que forneceu para a execução do ensaio.
445) Em conformidade com o disposto no apêndice 9 do pre­
sente anexo, os ensaios de interoperabilidade são executa­
dos, respetivamente, com todos os tipos de aparelhos de
controlo e de cartões tacográficos:
— cuja homologação de tipo é ainda válida ou
— cuja homologação de tipo está pendente e que têm
certificado de interoperabilidade válido.
446) Os ensaios de interoperabilidade devem abranger todas as
gerações de aparelhos de controlo ou cartões tacográficos
ainda em utilização.
▼M3
447) O certificado de interoperabilidade é emitido pelo laborató­
rio ao fabricante apenas depois de todos os ensaios de
interoperabilidade exigidos terem sido realizados com su­
cesso e depois de o fabricante comprovar que foram con­
cedidos um certificado de funcionalidade válido e um cer­
tificado de segurança válido ao produto, exceto nas circuns­
tâncias excecionais referidas no requisito 432.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 109
448) Se os ensaios de interoperabilidade não forem bem sucedi­
dos relativamente a um ou mais aparelhos de controlo ou
cartões tacográficos, o certificado de interoperabilidade não
será emitido até o fabricante requerente efetuar as modifi­
cações necessárias e obter resultados positivos nos ensaios.
O laboratório deve identificar a causa do problema com a
ajuda dos fabricantes afetos à falha de interoperabilidade e
procurar ajudar o fabricante requerente a encontrar uma
solução técnica. No caso de o fabricante ter modificado o
seu produto, compete-lhe confirmar junto das autoridades
competentes a validade dos certificados de segurança e de
funcionalidade.
449) O certificado de interoperabilidade tem uma validade de
seis meses, sendo revogado no final deste período se o
fabricante não receber o correspondente certificado de ho­
mologação de tipo. É transmitido pelo fabricante à autori­
dade responsável pela homologação de tipo no
Estado-Membro emissor do certificado de funcionalidade.
450) Os elementos suscetíveis de originar falhas de interopera­
bilidade não podem ser utilizados para a obtenção de van­
tagens ou posições dominantes.
8.5 Certificado de homologação
451) A autoridade nacional competente pode emitir o certificado
de homologação de tipo logo que disponha dos três certi­
ficados requeridos.
452) O certificado de homologação de tipo de qualquer compo­
nente de um aparelho de controlo deve também indicar os
números de homologação de tipo de todos os outros apare­
lhos de controlo interoperáveis homologados.
453) No momento da entrega ao fabricante, o certificado de
homologação de tipo é copiado pela autoridade competente
para o laboratório responsável pelos ensaios de
interoperabilidade.
454) O laboratório competente para os ensaios de interoperabili­
dade deve gerir um sítio público na Internet do qual cons­
tará uma lista atualizada dos modelos de aparelho de con­
trolo ou de cartão tacográfico:
— relativamente aos quais tenham sido registados pedidos
de ensaio de interoperabilidade
— que tenham recebido certificado de interoperabilidade
(ainda que provisório)
— que tenham recebido certificado de homologação de
tipo.
8.6 Procedimento excecional: primeiros certificados de interoperabi­
lidade para aparelhos de controlo e cartões tacográficos da se­
gunda geração
455) Durante o período de quatro meses após um conjunto de
aparelho de controlo e cartões tacográficos da segunda ge­
ração (cartão de condutor, cartão de oficina, cartão de con­
trolo e cartão de empresa) ter sido certificado pela primeira
vez como interoperável, deve ser considerado provisório
qualquer certificado de interoperabilidade (incluindo esse
primeiro) emitido em resposta a pedidos registados ao
longo do referido período.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 110
456) Se, no final do referido período, todos os produtos em
causa forem mutuamente interoperáveis, os correspondentes
certificados de interoperabilidade tornam-se efetivos.
457) Se, ao longo do referido período, forem detetadas falhas de
interoperabilidade, o laboratório responsável pelos ensaios
de interoperabilidade identifica as causas dos problemas
com a ajuda dos fabricantes envolvidos e convida-os a
efetuarem as necessárias modificações.
458) Se, no final deste período, subsistirem problemas de inte­
roperabilidade, o laboratório responsável pelos ensaios de
interoperabilidade, com a colaboração dos fabricantes en­
volvidos e das autoridades responsáveis pela homologação
de tipo que emitiram os correspondentes certificados de
funcionalidade, deve determinar as causas dessas falhas e
estabelecer as modificações a introduzir por cada um dos
fabricantes envolvidos. A procura de soluções técnicas pode
prolongar-se por um máximo de dois meses, após o que, se
não for encontrada solução comum, a Comissão, depois de
consultar o laboratório responsável pelos ensaios de intero­
perabilidade, decide qual ou quais os aparelhos de controlo
e cartões tacográficos que devem receber certificado defi­
nitivo de interoperabilidade, com especificação dos
motivos.
459) Os pedidos de ensaio de interoperabilidade, registados pelo
laboratório entre o final do período de quatro meses depois
de emitido o primeiro certificado provisório de interopera­
bilidade e a data da decisão da Comissão referida no re­
quisito n. o 455, ficam em suspenso até estarem resolvidos
os problemas iniciais de interoperabilidade. Os pedidos são
então processados segundo a ordem cronológica do registo.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 111
Apêndice 1
DICIONÁRIO DE DADOS
ÍNDICE
1. INTRODUÇÃO
1.1. Metodologia na definição dos tipos de dados
1.2. Referências
2. DEFINIÇÕES DOS TIPOS DE DADOS
2.1. ActivityChangeInfo
2.2. Endereço
2.3. AESKey
2.4. AES128Key
2.5. AES192Key
2.6. AES256Key
2.7. BCDString
2.8. CalibrationPurpose
2.9. CardActivityDailyRecord
2.10. CardActivityLengthRange
2.11. CardApprovalNumber
▼M3
2.11-A. CardBorderCrossing
2.11b. CardBorderCrossingRecord
▼B
2.12. CardCertificate
2.13. CardChipIdentification
2.14. CardConsecutiveIndex
2.15. CardControlActivityDataRecord
2.16. CardCurrentUse
2.17. CardDriverActivity
2.18. CardDrivingLicenceInformation
2.19. CardEventData
2.20. CardEventRecord
2.21. CardFaultData
2.22. CardFaultRecord
2.23. CardIccIdentification
2.24. CardIdentification
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 112
2.24-A. CardLoadTypeEntries
2.24-B. CardLoadTypeEntryRecord
2.24-C. CardLoadUnloadOperations
2.24-D. CardLoadUnloadRecord
▼B
2.25. CardMACertificate
2.26. CardNumber
▼M3
2.26-A. CardPlaceAuthDailyWorkPeriod
▼B
2.27. CardPlaceDailyWorkPeriod
2.28. CardPrivateKey
2.29. CardPublicKey
2.30. CardRenewalIndex
2.31. CardReplacementIndex
2.32. CardSignCertificate
2.33. CardSlotNumber
2.34. CardSlotsStatus
2.35. CardSlotsStatusRecordArray
2.36. CardStructureVersion
2.37. CardVehicleRecord
2.38. CardVehiclesUsed
2.39. CardVehicleUnitRecord
2.40. CardVehicleUnitsUsed
2.41. Certificado
2.42. CertificateContent
2.43. CertificateHolderAuthorisation
2.44. CertificateRequestID
2.45. CertificationAuthorityKID
2.46. CompanyActivityData
2.47. CompanyActivityType
2.48. CompanyCardApplicationIdentification
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 113
2.48-A. CompanyCardApplicationIdentificationV2
▼B
2.49. CompanyCardHolderIdentification
2.50. ControlCardApplicationIdentification
▼M3
2.50-A. ControlCardApplicationIdentificationV2
▼B
2.51. ControlCardControlActivityData
2.52. ControlCardHolderIdentification
2.53. ControlType
2.54. CurrentDateTime
2.55. CurrentDateTimeRecordArray
2.56. DailyPresenceCounter
2.57. Datef
2.58. DateOfDayDownloaded
2.59. DateOfDayDownloadedRecordArray
2.60. Distância
▼M3
2.60-A. DownloadInterfaceVersion
▼B
2.61. DriverCardApplicationIdentification
▼M3
2.61-A. DriverCardApplicationIdentificationV2
▼B
2.62. DriverCardHolderIdentification
▼M1
2.63. Reservado para utilização futura
▼B
2.64. EGFCertificate
2.65. EmbedderIcAssemblerId
2.66. EntryTypeDailyWorkPeriod
2.67. EquipmentType
2.68. EuropeanPublicKey
2.69. EventFaultRecordPurpose
2.70. EventFaultType
2.71. ExtendedSealIdentifier
2.72. ExtendedSerialNumber
2.73. FullCardNumber
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 114
2.74. FullCardNumberAndGeneration
2.75. Generation
2.76. GeoCoordinates
2.77. GNSSAccuracy
▼M1
2.78. GNSSAccumulatedDriving
2.79. GNSSAccumulatedDrivingRecord
▼M3
2.79-A. GNSSAuthAccumulatedDriving
2.79-B. GNSSAuthStatusADRecord
2.79-C. GNSSPlaceAuthRecord
▼B
2.80. GNSSPlaceRecord
2.81. HighResOdometer
2.82. HighResTripDistance
2.83. HolderName
▼M3
2.84. Reservado para utilização futura
▼B
2.85. K-ConstantOfRecordingEquipment
2.86. KeyIdentifier
2.87. KMWCKey
2.88. Language
2.89. LastCardDownload
▼M3
2.89-A. LengthOfFollowingData
▼B
2.90. LinkCertificate
▼M3
2.90-A. LoadType
▼B
2.91. L-TyreCircumference
2.92. MAC
2.93. ManualInputFlag
2.94. ManufacturerCode
2.95. ManufacturerSpecificEventFaultData
2.96. MemberStateCertificate
2.97. MemberStateCertificateRecordArray
2.98. MemberStatePublicKey
2.99. Name
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 115
2.100. NationAlpha
2.101. NationNumeric
▼M3
2.101-A. NoOfBorderCrossingRecords
▼B
2.102. NoOfCalibrationRecords
2.103. NoOfCalibrationsSinceDownload
2.104. NoOfCardPlaceRecords
2.105. NoOfCardVehicleRecords
2.106. NoOfCardVehicleUnitRecords
2.107. NoOfCompanyActivityRecords
2.108. NoOfControlActivityRecords
2.109. NoOfEventsPerType
2.110. NoOfFaultsPerType
▼M1
2.111. NoOfGNSSADRecords
▼M3
2.111-A. NoOfLoadUnloadRecords
▼B
2.112. NoOfSpecificConditionRecords
▼M3
2.112a. NoOfLoadTypeEntryRecords
▼B
2.113. OdometerShort
2.114. OdometerValueMidnight
▼M3
2.114-A. OperationType
▼B
2.115. OdometerValueMidnightRecordArray
2.116. OverspeedNumber
▼M3
2.116-A. PlaceAuthRecord
2.116-A. PlaceAuthStatusRecord
▼B
2.117. PlaceRecord
▼M3
2.117-A. PositionAuthenticationStatus
▼B
2.118. PreviousVehicleInfo
2.119. PublicKey
2.120. RecordType
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 116
2.121. RegionAlpha
2.122. RegionNumeric
2.123. RemoteCommunicationModuleSerialNumber
2.124. RSAKeyModulus
2.125. RSAKeyPrivateExponent
2.126. RSAKeyPublicExponent
2.127. RtmData
2.128. SealDataCard
2.129. SealDataVu
2.130. SealRecord
2.131. SensorApprovalNumber
2.132. SensorExternalGNSSApprovalNumber
2.133. SensorExternalGNSSCoupledRecord
2.134. SensorExternalGNSSIdentification
2.135. SensorExternalGNSSInstallation
2.136. SensorExternalGNSSOSIdentifier
2.137. SensorExternalGNSSSCIdentifier
2.138. SensorGNSSCouplingDate
2.139. SensorGNSSSerialNumber
2.140. SensorIdentification
2.141. SensorInstallation
2.142. SensorInstallationSecData
2.143. SensorOSIdentifier
2.144. SensorPaired
2.145. SensorPairedRecord
2.146. SensorPairingDate
2.147. SensorSCIdentifier
2.148. SensorSerialNumber
2.149. Signature
2.150. SignatureRecordArray
2.151. SimilarEventsNumber
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 117
2.152. SpecificConditionRecord
2.153. SpecificConditions
2.154. SpecificConditionType
2.155. Speed
2.156. SpeedAuthorised
2.157. SpeedAverage
2.158. SpeedMax
▼M3
2.158-A. TachographCardsGen1Suppression
▼B
2.159. TachographPayload
▼M1
2.160. Reservado para utilização futura
▼B
2.161. TDesSessionKey
2.162. TimeReal
2.163. TyreSize
2.164. VehicleIdentificationNumber
2.165. VehicleIdentificationNumberRecordArray
2.166. VehicleRegistrationIdentification
▼M3
2.166-A. VehicleRegistrationIdentificationRecordArray
▼B
2.167. VehicleRegistrationNumber
2.168. VehicleRegistrationNumberRecordArray
2.169. VuAbility
2.170. VuActivityDailyData
2.171. VuActivityDailyRecordArray
2.172. VuApprovalNumber
2.173. VuCalibrationData
2.174. VuCalibrationRecord
2.175. VuCalibrationRecordArray
2.176. VuCardIWData
2.177. VuCardIWRecord
2.178. VuCardIWRecordArray
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 118
2.179. VuCardRecord
2.180. VuCardRecordArray
2.181. VuCertificate
2.182. VuCertificateRecordArray
2.183. VuCompanyLocksData
2.184. VuCompanyLocksRecord
2.185. VuCompanyLocksRecordArray
▼M3
2.185-A. VuConfigurationLengthRange
▼B
2.186. VuControlActivityData
2.187. VuControlActivityRecord
2.188. VuControlActivityRecordArray
2.189. VuDataBlockCounter
2.190. VuDetailedSpeedBlock
2.191. VuDetailedSpeedBlockRecordArray
2.192. VuDetailedSpeedData
▼M3
2.192-A. VuDigitalMapVersion
▼B
2.193. VuDownloadablePeriod
2.194. VuDownloadablePeriodRecordArray
2.195. VuDownloadActivityData
2.196. VuDownloadActivityDataRecordArray
2.197. VuEventData
2.198. VuEventRecord
2.199. VuEventRecordArray
2.200. VuFaultData
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 119
2.201. VuFaultRecord
2.202. VuFaultRecordArray
▼M1
2.203. VuGNSSADRecord
▼M3
2.203-A. VuBorderCrossingRecord
2.203-B. VuBorderCrossingRecordArray
▼M1
2.204. VuGNSSADRecordArray
▼M3
2.204-B. VuGnssMaximalTimeDifference
▼B
2.205. VuIdentification
2.206. VuIdentificationRecordArray
2.207. VuITSConsentRecord
2.208. VuITSConsentRecordArray
▼M3
2.208-A. VuLoadUnloadRecord
2.208-B. VuLoadUnloadRecordArray
▼B
2.209. VuManufacturerAddress
2.210. VuManufacturerName
2.211. VuManufacturingDate
2.212. VuOverSpeedingControlData
2.213. VuOverSpeedingControlDataRecordArray
2.214. VuOverSpeedingEventData
2.215. VuOverSpeedingEventRecord
2.216. VuOverSpeedingEventRecordArray
2.217. VuPartNumber
2.218. VuPlaceDailyWorkPeriodData
2.219. VuPlaceDailyWorkPeriodRecord
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 120
2.220. VuPlaceDailyWorkPeriodRecordArray
2.221. VuPrivateKey
2.222. VuPublicKey
▼M3
2.222-A. VuRtcTime
▼B
2.223. VuSerialNumber
2.224. VuSoftInstallationDate
2.225. VuSoftwareIdentification
2.226. VuSoftwareVersion
2.227. VuSpecificConditionData
2.228. VuSpecificConditionRecordArray
2.229. VuTimeAdjustmentData
▼M1
2.230. Reservado para utilização futura
2.231. Reservado para utilização futura
▼B
2.232. VuTimeAdjustmentRecord
2.233. VuTimeAdjustmentRecordArray
2.234. WorkshopCardApplicationIdentification
▼M3
2.234-A. WorkshopCardApplicationIdentificationV2
2.234-B. WorkshopCardCalibrationAddData
2.234-C. WorkshopCardCalibrationAddDataRecord
▼B
2.235. WorkshopCardCalibrationData
2.236. WorkshopCardCalibrationRecord
2.237. WorkshopCardHolderIdentification
2.238. WorkshopCardPIN
2.239. W-VehicleCharacteristicConstant
2.240. VuPowerSupplyInterruptionRecord
2.241. VuPowerSupplyInterruptionRecordArray
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 121
2.242. VuSensorExternalGNSSCoupledRecordArray
2.243. VuSensorPairedRecordArray
3. DEFINIÇÕES DOS VALORES E DOS INTERVALOS DE DIMEN­
SÃO
4. CONJUNTOS DE CARATERES
5. CODIFICAÇÃO
6. IDENTIFICADORES DE OBJETO E IDENTIFICADORES DE APLI­
CAÇÃO
6.1. Identificadores de objeto
6.2. Identificadores da aplicação
1. INTRODUÇÃO
O presente apêndice especifica os formatos, os elementos e as estruturas
dos dados a utilizar no aparelho de controlo e nos cartões tacográficos.
1.1. Metodologia na definição dos tipos de dados
O presente apêndice utiliza a Abstract Syntax Notation One («notação de
sintaxe abstrata um» ou ASN.1) para definir os tipos de dados, per­
mitindo que dados simples e estruturados sejam definidos sem sintaxe
específica de transferência (regra de codificação) dependente da aplica­
ção e do ambiente.
As convenções ASN.1 para a nomeação do tipo obedecem à norma
ISO/IEC 8824-1, o que implica:
— sempre que possível, o significado do tipo de dado está implícito nos
nomes selecionados
— se um tipo de dado consistir numa composição de outros tipos de
dados, o nome daquele tipo de dado será ainda uma sequência sim­
ples de carateres alfabéticos a começar por uma letra maiúscula,
utilizando-se todavia outras maiúsculas no interior do nome a marcar
as diversas significações
— os nomes dos tipos de dados estão em geral relacionados com o
nome dos tipos de dados a partir dos quais são constituídos, com
o equipamento no qual os dados são memorizados e com a função a
eles relativa.
Se um tipo ASN.1 estiver já definido como parte de outra norma e for
suscetível de utilização no aparelho de controlo, será definido no pre­
sente apêndice.
Tendo em conta os diversos tipos de regras de codificação, alguns tipos
ASN.1 que constam do presente apêndice são restringidos por identifi­
cadores de intervalos (ou gamas) de valores. Na secção 3 e no apêndice 2
definem-se os identificadores de gamas de valores.
1.2. Referências
No presente apêndice, utilizam-se as seguintes referências:
ISO 639 Code for the representation of names of languages.
First Edition: 1988.
ISO 3166 Codes for the representation of names of countries
and their subdivisions — Part 1: Country codes, 2013
ISO 3779 Road vehicles — Vehicle identification
number (VIN) — Content and structure. 2009
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 122
ISO/IEC 7816-5 Identification cards — Integrated circuit cards — Part
5: Registration of application providers.
Second edition: 2004.
ISO/IEC 7816-6 Identification cards — Integrated circuit cards — Part
6: Interindustry data elements for interchange, 2004
+ Technical Corrigendum 1: 2006
ISO/IEC 8824-1 Information technology — Abstract Syntax Notation
One (ASN.1): Specification of basic notation. 2008 +
Technical Corrigendum 1: 2012 and Technical Corri­
gendum 2: 2014.
ISO/IEC 8825-2 Information technology — ASN.1 encoding rules:
Specification of Packed Encoding Rules (PER). 2008.
ISO/IEC 8859-1 Information technology — 8 bit single-byte coded
graphic character sets — Part 1: Latin alphabet No.1.
First edition: 1998.
ISO/IEC 8859-7 Information technology — 8 bit single-byte coded
graphic character sets — Part 7: Latin/Greek alphabet.
2003.
ISO 16844-3 Road vehicles — Tachograph systems — Motion
Sensor Interface. 2004 + Technical Corrigendum 1:
2006..
TR-03110-3 BSI / ANSSI Technical Guideline TR-03110-3, Ad­
vanced Security Mechanisms for Machine Readable
Travel Documents and eIDAS Token — Part 3 Com­
mon Specifications, version 2.20, 3. February 2015
2. DEFINIÇÕES DOS TIPOS DE DADOS
▼M3
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.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 123
2.1. ActivityChangeInfo
Este tipo de dado permite codificar, numa palavra de dois bytes, uma
situação de ranhura às 00h00 e/ou uma situação de condutor às 00h00
e/ou alterações na atividade e/ou alterações na situação da condução e/ou
alterações na situação do cartão, quer para o condutor quer para o
ajudante. Este tipo de dado está relacionado com os requisitos 105,
266, 291, 320, 321, 343 e 344 do anexo 1C.
Valor atribuído — Alinhamento de octetos: «scpaattttttttttt»B (16 bits)
Para registos na memória de dados (ou situação da ranhura):
«s»B Ranhura:
«0»B: CONDUTOR,
«1»B: AJUDANTE,
«c»B Situação da condução:
«0»B: ÚNICO,
«1»B: TRIPULAÇÃO,
«p»B Situação do cartão de condutor (ou de oficina) na
ranhura pertinente:
«0»B: INSERIDO, está inserido um cartão,
«1»B: NÃO INSERIDO, não está inserido nenhum
cartão (ou foi retirado um),
«aa»B Atividade:
«00»B: PAUSA/DESCANSO,
«01»B: DISPONIBILIDADE,
«10»B: TRABALHO,
«11»B: CONDUÇÃO,
«ttttttttttt»B Momento da mudança: quantidade de minutos desde
as 00h00 no dia em questão.
Para registos (e situação do condutor) no cartão de condutor (ou de
oficina):
«s»B Ranhura (não pertinente quando «p»=1, exceto nota
infra):
«0»B: CONDUTOR,
«1»B: AJUDANTE,
«c»B Situação da condução (caso «p»=0) ou
Situação da atividade seguinte (caso «p»=1):
«0»B: ÚNICO,
«0»B: DESCONHECIDO
«1»B: TRIPULAÇÃO,
«1»B: CONHECIDO (= entrada manual)
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 124
«p»B Situação do cartão:
«0»B: INSERIDO, o cartão está inserido num apare­
lho de controlo,
«1»B: NÃO INSERIDO, o cartão não está inserido
(ou foi retirado),
«aa»B Atividade (não pertinente quando «p»=1 e «c»=0,
exceto nota infra):
«00»B: PAUSA/DESCANSO,
«01»B: DISPONIBILIDADE,
«10»B: TRABALHO,
«11»B: CONDUÇÃO,
«ttttttttttt»B Momento da mudança: quantidade de minutos desde
as 00h00 no dia em questão.
Nota relativa ao caso «retirada do cartão»:
Quando o cartão é retirado:
— «s» é pertinente e indica a ranhura da qual o cartão é retirado
— «c» deve ser fixado em 0
— «p» deve ser fixado em 1
— «aa» deve codificar a atividade em curso, selecionada no momento.
Em resultado de uma entrada manual, os bits «c» e «aa» da palavra
(memorizada num cartão) podem ser posteriormente reescritos por cima,
refletindo a entrada.
2.2. Endereço
Um endereço.
codePage especifica um conjunto de carateres definido no capítulo 4
address é um endereço codificado que utiliza o conjunto de carateres
especificado.
2.3. AESKey
Geração 2:
Uma chave AES com o comprimento de 128, 192 ou 256 bits.
Valor atribuído: sem mais especificações.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 125
2.4. AES128Key
Geração 2:
Uma chave AES128.
length indica o comprimento da chave AES128 em octetos.
aes128Key: chave AES com comprimento de 128 bits.
Valor atribuído:
O comprimento deve ter o valor 16.
2.5. AES192Key
Geração 2:
Uma chave AES192.
length indica o comprimento da chave AES192 em octetos.
aes192Key: chave AES com um comprimento de 192 bits.
Valor atribuído:
O comprimento deve ter o valor 24.
2.6. AES256Key
Geração 2:
Uma chave AES256.
length indica o comprimento da chave AES256 em octetos.
aes256Key: chave AES com 256 bits de comprimento.
Valor atribuído:
O comprimento deve ter o valor de 32.
2.7. BCDString
BCDString aplica-se na representação de Binary Code Decimal («código
binário decimal» ou BCD). Este tipo de dado utiliza-se para representar
um algarismo decimal num semiocteto (4 bits). BCDString baseia-se em
«CharacterStringType» da norma ISO/IEC 8824-1.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 126
BCDString utiliza uma notação «hstring». O algarismo hexadecimal
mais à esquerda deve ser o semiocteto mais significativo do primeiro
octeto. Para produzir um múltiplo de octetos, inserem-se os necessários
semioctetos de zeros à direita, a partir da posição de semiocteto mais à
esquerda no primeiro octeto.
Algarismos autorizados: 0, 1, …, 9.
2.8. CalibrationPurpose
Código que explica por que foi registado um conjunto de parâmetros de
calibração. Este tipo de dado está relacionado com os requisitos 097 e
098 do anexo 1B e com o requisito 119 do anexo 1C.
Valor atribuído:
Geração 1:
«00»H valor reservado
«01»H ativação: registo de parâmetros de calibração co­
nhecidos, no momento da ativação da VU
«02»H primeira instalação: primeira calibração da VU
depois de ativada
«03»H instalação: primeira calibração da VU no veículo
atual
«04»H inspeção periódica.
Geração 2:
Utilizam-se os seguintes elementos de dados, além dos utilizados na
geração 1:
«05»H introdução do VRN pela empresa
«06»H ajustamento do tempo sem calibração
«07»H a «7F»H RFU,
«80»H a «FF»H Específico do fabricante.
2.9. CardActivityDailyRecord
Informação memorizada num cartão e relativa às atividades de condutor
num determinado dia. Este tipo de dado está relacionado com os requi­
sitos 266, 291, 320 e 343 do anexo 1C.
activityPreviousRecordLength é o comprimento total, em bytes, do
anterior registo diário. O valor máximo é dado pelo comprimento do
OCTET STRING que contém estes registos (ver CardActivityLength­
Range, apêndice 2, ponto 4). Se este registo for o registo diário mais
antigo, o valor de activityPreviousRecordLength deve ser fixado em 0.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 127
activityRecordLength é o comprimento total, em bytes, deste registo. O
valor máximo é dado pelo comprimento do OCTET STRING que con­
tém estes registos.
activityRecordDate é a data do registo.
activityDailyPresenceCounter é o contador de presenças diárias relativo
ao cartão neste dia.
activityDayDistance é a distância total percorrida pelo veículo neste dia.
activityChangeInfo é o conjunto de dados ActivityChangeInfo relativos
ao condutor neste dia. Pode conter, no máximo, 1 440 valores (uma
mudança de atividade por minuto). Este conjunto inclui sempre a acti­
vityChangeInfo que codifica a situação do condutor às 00h00.
2.10. CardActivityLengthRange
Número de bytes num cartão de condutor ou de oficina, disponíveis para
memorizar registos da atividade de condutor.
Valor atribuído: ver apêndice 2.
2.11. CardApprovalNumber
Número de homologação do tipo de cartão.
Valor atribuído:
O número de homologação deve ser apresentado conforme publicação no
respetivo sítio Web da Comissão Europeia, ou seja, incluindo eventuais
hífenes. O número de homologação deve estar alinhado à esquerda.
▼M3
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 fron­
teira 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.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 128
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 fron­
teira 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 dispo­
ní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á locali­
zado (por exemplo, o país atual não consta dos mapas digitais memori­
zados).
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á locali­
zado (por exemplo, o país atual não consta dos mapas digitais memori­
zados).
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.
▼B
2.12. CardCertificate
Geração 1:
Certificado da chave pública de um cartão.
2.13. CardChipIdentification
Informação memorizada num cartão e relativa à identificação do circuito
integrado (IC) desse cartão (requisito 249 do anexo 1C). O icSerialNum­
ber, juntamente com o icManufacturingReferences, identifica a pastilha
do cartão de forma única. O icSerialNumber sozinho não identifica a
pastilha do cartão de forma única.
icSerialNumber é o número de série do IC.
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 129
icManufacturingReferences é o identificador específico do fabricante
do IC.
2.14. CardConsecutiveIndex
Um índice de série do cartão (definição h)).
Valor atribuído: (ver anexo 1C, capítulo 7)
Ordem de acréscimo: «0, …, 9, A, …, Z, a, …, z»
2.15. CardControlActivityDataRecord
Informação memorizada num cartão de condutor ou de oficina e relativa
ao último controlo a que o condutor tiver sido sujeito (requisitos 274,
299, 327 e 350 do anexo 1C).
controlType é o tipo do controlo.
controlTime é a data e a hora do controlo.
controlCardNumber é o FullCardNumber do técnico que efetuou o
controlo.
controlVehicleRegistration é o VRN e o Estado-Membro de matrícula
do veículo no qual ocorreu o controlo.
controlDownloadPeriodBegin e controlDownloadPeriodEnd é o pe­
ríodo descarregado (na eventualidade de descarregamento).
2.16. CardCurrentUse
Informação relativa à utilização efetiva do cartão (requisito 273, 298,
326 e 349 do anexo 1C).
sessionOpenTime é o momento de inserção do cartão para a utilização
em curso. Este elemento é fixado em 0 ao ser retirado o cartão.
sessionOpenVehicle é a identificação do veículo em utilização, fixada
ao ser inserido o cartão. Este elemento é fixado em 0 ao ser retirado o
cartão.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 130
2.17. CardDriverActivity
Informação memorizada num cartão de condutor ou de oficina e relativa
às atividades do condutor (requisitos 267, 268, 292, 293, 321 e 344 do
anexo 1C).
activityPointerOldestDayRecord é a especificação do início do local de
memorização (número de bytes desde o princípio da cadeia) do mais
antigo registo diário completo na cadeia activityDailyRecords. O valor
máximo é dado pelo comprimento da cadeia.
activityPointerNewestRecord é a especificação do início do local de
memorização (número de bytes desde o princípio da cadeia) do mais
recente registo diário na cadeia activityDailyRecords. O valor máximo é
dado pelo comprimento da cadeia.
activityDailyRecords é o espaço disponível para memorizar os dados de
atividade do condutor (estrutura de dados: CardActivityDailyRecord)
para cada dia de calendário em que o cartão foi utilizado.
Valor atribuído: esta cadeia de octetos é ciclicamente preenchida com
registos de CardActivityDailyRecord. Na primeira utilização, a memori­
zação inicia-se no primeiro byte da cadeia. Cada novo registo é apenso
ao final do precedente. Quando a cadeia está preenchida, a memorização
prossegue no primeiro byte da cadeia, independentemente de haver des­
continuidade dentro de um elemento de dado. Antes de se colocarem
novos dados de atividade na cadeia (aumentando o atual activityDaily­
Record ou colocando um novo activityDailyRecord) em substituição dos
dados de atividade mais antigos, o activityPointerOldestDayRecord tem
de ser atualizado, em reflexo da nova localização do mais antigo registo
diário completo, e o activityPreviousRecordLength deste (novo) registo
diário completo mais antigo deve ser reposto em 0.
2.18. CardDrivingLicenceInformation
Informação memorizada num cartão de condutor e relativa aos dados da
carta de condução do titular do cartão (requisito 259 e 284 do
anexo 1C).
drivingLicenceIssuingAuthority é a autoridade responsável pela emis­
são da carta de condução.
drivingLicenceIssuingNation é a nacionalidade da autoridade que emite
a carta de condução.
drivingLicenceNumber é o número da carta de condução.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 131
2.19. CardEventData
Geração 1:
Informação memorizada num cartão de condutor ou de oficina e relativa
aos incidentes associados ao titular do cartão (requisitos 260 e 318 do
anexo IC).
CardEventData é uma sequência de registos cardEventRecords (com
exceção dos registos relacionados com tentativas de violação da segu­
rança, os quais são reunidos no último conjunto da sequência), por
ordem crescente do valor de EventFaultType.
cardEventRecords é um conjunto de registos de incidentes de determi­
nado tipo (ou categoria, no caso de incidentes relativos a tentativas de
violação da segurança).
Geração 2:
Informação memorizada num cartão de condutor ou de oficina e relativa
aos incidentes associados ao titular do cartão (requisitos 285 e 341 do
anexo IC).
CardEventData é uma sequência de registos cardEventRecords (com
exceção dos registos relacionados com tentativas de violação da segu­
rança, os quais são reunidos no último conjunto da sequência), por
ordem crescente do valor de EventFaultType.
cardEventRecords é um conjunto de registos de incidentes de determi­
nado tipo (ou categoria, no caso de incidentes relativos a tentativas de
violação da segurança).
▼B
2.20. CardEventRecord
Informação memorizada num cartão de condutor ou de oficina e relativa
a um incidente associado ao titular do cartão (requisitos 261, 286, 318 e
341 do anexo 1C).
eventType é o tipo de incidente.
eventBeginTime é a data e a hora de início do incidente.
eventEndTime é a data e a hora de cessação do incidente.
eventVehicleRegistration é o VRN e o Estado-Membro de matrícula do
veículo no qual ocorreu o incidente.
▼M1
02016R0799 — PT — 21.08.2023 — 003.002 — 132
2.21. CardFaultData
Informação memorizada num cartão de condutor ou de oficina e relativa
às falhas associadas ao titular do cartão (requisitos 263, 288, 318 e 341
do anexo 1C).
CardFaultData: sequência formada pelo conjunto de registos de falhas
do aparelho de controlo ao qual se segue o conjunto de registos de falhas
do cartão.
cardFaultRecords: conjunto de registos de falhas de determinada cate­
goria (falhas do aparelho de controlo ou do cartão).
2.22. CardFaultRecord
Informação memorizada num cartão de condutor ou de oficina e relativa
a uma falha associada ao titular do cartão (requisitos 264, 289, 318 e
341 do anexo 1C).
faultType é o tipo da falha.
faultBeginTime é a data e a hora de início da falha.
faultEndTime é a data e a hora de cessação da falha.
faultVehicleRegistration é o VRN e o Estado-Membro de matrícula do
veículo no qual ocorreu a falha.
2.23. CardIccIdentification
Informação memorizada num cartão e relativa à identificação do circuito
integrado (IC) (requisito 248 do anexo 1C).
clockStop é o modo Clockstop (relógio parado), cf. definição no apên­
dice 2.
cardExtendedSerialNumber é o número de série único do cartão IC
conforme especificado pelo tipo de dados ExtendedSerialNumber.
cardApprovalNumber é o número de homologação de tipo do cartão.
cardPersonaliserID é a identificação personalizada do cartão (ID) co­
dificada como ManufacturerCode.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 133
embedderIcAssemblerId fornece informações acerca do fabricante/
/montador do IC.
icIdentifier é o identificador do IC no cartão e do seu fabricante (cf.
definição na norma ISO/IEC 7816-6).
2.24. CardIdentification
Informação memorizada num cartão e relativa à sua identificação (requi­
sitos 255, 280, 310, 333, 359, 365, 371 e 377 do anexo 1C).
cardIssuingMemberState é o código do Estado-Membro que emite o
cartão.
cardNumber é o número do cartão.
cardIssuingAuthorityName é a designação da autoridade que emite o
cartão.
cardIssueDate é a data de emissão do cartão ao atual titular.
cardValidityBegin é a data de início da validade do cartão.
cardExpiryDate é a data-limite da validade do cartão.
▼M3
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 (requisi­
tos 306-J e 356-J do anexo IC).
loadTypeEntryPointerNewestRecord é o índice do último registo atua­
lizado 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.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 134
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 atuali­
zado 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 indi­
caçã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.
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 135
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.
▼B
2.25. CardMACertificate
Geração 2:
Certificado da chave pública do cartão para autenticação mútua com uma
VU. A estrutura deste certificado é especificada no apêndice 11.
2.26. CardNumber
Um número de cartão, em conformidade com a definição g).
driverIdentification é a identificação única de um condutor num
Estado-Membro.
ownerIdentification é a identificação única de uma empresa, de uma
oficina ou de um organismo de controlo num Estado-Membro.
cardConsecutiveIndex é o índice de série do cartão.
cardReplacementIndex é o índice de substituição do cartão.
cardRenewalIndex é o índice de renovação do cartão.
A primeira sequência da escolha é adequada para codificar o número de
cartão de um condutor; a segunda é adequada para codificar os números
de cartão de uma oficina, de um organismo de controlo ou de uma
empresa.
▼M3
2.26-A. CardPlaceAuthDailyWorkPeriod
Geração 2, versão 2:
Informação memorizada num cartão de condutor ou de oficina que in­
dica 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).
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 136
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 esta­
tuto de autenticação do local dos locais introduzidos
▼B
2.27. CardPlaceDailyWorkPeriod
Informação memorizada num cartão de condutor ou de oficina e relativa
aos locais onde se iniciam e/ou terminam os períodos de trabalho diário
(requisitos 272, 297, 325 e 348 do anexo 1C).
placePointerNewestRecord é o índice do último registo atualizado do
local.
Valor atribuído: o número correspondente ao numerador do registo do
local, a começar por «0» na primeira ocorrência dos registos do local na
estrutura.
placeRecords é o conjunto dos registos que contêm informação acerca
dos locais introduzidos.
2.28. CardPrivateKey
Geração 1:
A chave privada de um cartão.
2.29. CardPublicKey
A chave pública de um cartão.
▼M1
2.30. CardRenewalIndex
O índice de renovação de um cartão, conforme definição i).
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 137
Valor atribuído: (ver capítulo 7 do presente anexo).
«0» Primeira emissão.
Ordem de acréscimo: «0, …, 9, A, …, Z»
▼B
2.31. CardReplacementIndex
O índice de substituição de um cartão, conforme definição j).
Valor atribuído: (ver capítulo VII do presente anexo).
«0» Cartão original.
Ordem de acréscimo: «0, …, 9, A, …, Z»
2.32. CardSignCertificate
Geração 2:
Certificado da chave pública do cartão para assinatura. A estrutura deste
certificado é especificada no apêndice 11.
2.33. CardSlotNumber
Código que distingue as duas ranhuras de uma unidade-veículo.
Valor atribuído: sem mais especificações.
2.34. CardSlotsStatus
Código que indica o tipo dos cartões inseridos nas duas ranhuras da
unidade-veículo.
Valor atribuído — Alinhamento de octetos: «ccccdddd»B
«cccc»B Identificação do tipo de cartão inserido na ranhura do
ajudante
«dddd»B Identificação do tipo de cartão inserido na ranhura do
condutor
com os seguintes códigos de identificação:
«0000»B nenhum cartão inserido
«0001»B inserido um cartão de condutor
«0010»B inserido um cartão de oficina
«0011»B inserido um cartão de controlo
«0100»B inserido um cartão de empresa.
▼M1
02016R0799 — PT — 21.08.2023 — 003.002 — 138
2.35. CardSlotsStatusRecordArray
Geração 2:
O CardSlotsStatus, mais metadados utilizados no protocolo de
descarregamento.
recordType indica o tipo de registo (CardSlotsStatus). Valor atribuído:
ver RecordType
recordSize: tamanho do CardSlotsStatus, em bytes.
noOfRecords: número de registos nos registos definidos.
records: conjunto de registos CardSlotsStatus.
2.36. CardStructureVersion
Código que indica a versão da estrutura aplicada num cartão tacográfico.
Valor atribuído: «aabb»H:
«aa»H Índice para alterações da estrutura.
«00»H para aplicações da geração 1
«01»H para aplicações da geração 2
▼M3
«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
▼B
2.37. CardVehicleRecord
Informação memorizada num cartão de condutor ou de oficina e relativa
a um período de utilização de um veículo durante um dia (requisitos
269, 294, 322 e 345 do anexo 1C).
Geração 1:
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 139
vehicleOdometerBegin é o valor do conta-quilómetros do veículo no
início do período da sua utilização.
vehicleOdometerEnd é o valor do conta-quilómetros do veículo no
final do período da sua utilização.
vehicleFirstUse é a data e a hora do início do período de utilização do
veículo.
vehicleLastUse é a data e a hora do final do período de utilização do
veículo.
vehicleRegistration é o VRN (número de matrícula) e o
Estado-Membro de matrícula do veículo.
vuDataBlockCounter é o valor exibido pelo vuDataBlockCounter (con­
tador do bloco de dados da VU) quando da última extração do período
de utilização do veículo.
Geração 2:
Utilizam-se os seguintes elementos de dados, além dos utilizados na
geração 1:
VehicleIdentificationNumber é o número de identificação do veículo e
diz respeito ao veículo como um todo.
2.38. CardVehiclesUsed
Informação memorizada num cartão de condutor ou de oficina e relativa
aos veículos utilizados pelo titular do cartão (requisitos 270, 295, 323 e
346 do anexo 1C).
vehiclePointerNewestRecord é o índice do último registo atualizado do
veículo.
Valor atribuído: o número correspondente ao numerador do registo do
veículo, a começar por «0» na primeira ocorrência dos registos do
veículo na estrutura.
cardVehicleRecords é o conjunto dos registos que contêm informação
acerca dos veículos utilizados.
2.39. CardVehicleUnitRecord
Geração 2:
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 140
Informação memorizada num cartão de condutor ou de oficina e relativa
a uma unidade-veículo que foi utilizada (requisitos 303 e 351 do
anexo 1C).
timeStamp é o início do período de utilização da unidade-veículo (ou
seja, a primeira inserção do cartão na unidade-veículo, relativa ao pe­
ríodo).
manufacturerCode identifica o fabricante da unidade-veículo.
deviceID identifica o tipo de unidade-veículo de um fabricante. O valor
é específico do fabricante.
vuSoftwareVersion é o número da versão do software da
unidade-veículo.
2.40. CardVehicleUnitsUsed
▼M3
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)
▼B
vehicleUnitPointerNewestRecord é o índice do último registo atuali­
zado da unidade-veículo.
Valor atribuído: o número correspondente ao numerador do registo da
unidade-veículo, a começar por «0» na primeira ocorrência dos registos
da unidade-veículo na estrutura.
cardVehicleUnitRecords é o conjunto de registos que contêm informa­
ção acerca das unidades-veículos utilizadas.
2.41. Certificado
O certificado de uma chave pública emitida por uma autoridade de
certificação.
Geração 1:
Valor atribuído: assinatura digital com recuperação parcial de um Cer­
tificateContent (conteúdo do certificado) em conformidade com os me­
canismos comuns de segurança (apêndice 11): Assinatura (128 bytes) ||
Alerta de chave pública (58 bytes) || Referência da autoridade de certi­
ficação (8 bytes).
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 141
Geração 2:
Valor atribuído: ver apêndice 11
2.42. CertificateContent
Geração 1:
O conteúdo (claro) do certificado de uma chave pública, em conformi­
dade com os mecanismos comuns de segurança (apêndice 11).
certificateProfileIdentifier é a versão do certificado correspondente.
Valor atribuído: «01h» para esta versão.
certificationAuthorityReference identifica a autoridade de certificação
que emite o certificado. Referencia também a chave pública dessa
autoridade.
certificateHolderAuthorisation identifica os direitos do titular do
certificado.
certificateEndOfValidity é a data-limite administrativa de validade do
certificado.
certificateHolderReference identifica o titular do certificado. Referencia
também a chave pública do titular.
publicKey é a chave pública certificada por este certificado.
2.43. CertificateHolderAuthorisation
Identificação dos direitos do titular de um certificado.
Geração 1:
tachographApplicationID é o identificador de aplicação da aplicação
tacográfica.
Valor atribuído: «FFh» «54h» «41h» «43h» «48h» «4Fh». Este AID é
um identificador de aplicação não registada de proprietário, em confor­
midade com a norma ISO/IEC 7816-5.
equipmentType é a identificação do tipo de equipamento ao qual se
refere o certificado.
Valor atribuído: em conformidade com o tipo de dado EquipmentType:
0 se se tratar do certificado de um Estado-Membro.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 142
Geração 2:
tachographApplicationID indica os 6 bytes mais significativos do iden­
tificador de aplicação (AID) do cartão tacográfico de geração 2. O AID
destinado à aplicação do cartão tacográfico é definido no capítulo 6.2.
Valor atribuído: «FF 53 4D 52 44 54»
equipmentType: identificação do tipo de equipamento, tal como espe­
cificado para a geração 2, ao qual se refere o certificado.
Valor atribuído: em conformidade com o tipo de dado EquipmentType.
2.44. CertificateRequestID
Identificação única de um pedido de certificado. Pode igualmente
utilizar-se como identificador da chave pública de uma
unidade-veículo se, no momento da geração do certificado, não se co­
nhecer o número de série da unidade-veículo à qual a chave se destina.
requestSerialNumber é um número de série do pedido de certificado,
único para o fabricante e para o mês infra.
requestMonthYear é a identificação do mês e do ano do pedido de
certificado.
Valor atribuído: codificação BCD de Month (mês, com dois algaris­
mos) e de Year (ano, com os dois últimos algarismos).
crIdentifier: é um identificador que estabelece a distinção entre um
pedido de certificado e um número de série alargado.
Valor atribuído: «FFh».
manufacturerCode: é o código numérico do fabricante que pede o
certificado.
2.45. CertificationAuthorityKID
Identificador da chave pública de uma autoridade de certificação (um
Estado-Membro ou a autoridade europeia de certificação).
nationNumeric é o código numérico da autoridade de certificação
nacional.
nationAlpha é o código alfanumérico da autoridade de certificação
nacional.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 143
keySerialNumber é um número de série que distingue as diferentes
chaves da autoridade de certificação, caso sejam alteradas.
additionalInfo é um campo de dois bytes para codificação adicional
(específico da autoridade de certificação).
caIdentifier é um identificador que serve para distinguir um identifica­
dor de chave da autoridade de certificação dos outros identificadores de
chave.
Valor atribuído: «01h».
2.46. CompanyActivityData
Informação memorizada num cartão de empresa e relativa às atividades
executadas com o cartão (requisitos 373 e 379 do anexo 1C).
companyPointerNewestRecord é o índice do último companyActivity­
Record atualizado.
Valor atribuído: o número correspondente ao numerador do registo da
atividade da empresa, a começar por «0» na primeira ocorrência dos
registos da atividade da empresa na estrutura.
companyActivityRecords é o conjunto de todos os registos de atividade
da empresa.
companyActivityRecord é a sequência de informação relativa à ativi­
dade da empresa.
companyActivityType é o tipo em que se integra a atividade da
empresa.
companyActivityTime é a data e a hora da atividade da empresa.
cardNumberInformation é o número e o Estado-Membro emissor do
cartão eventualmente descarregado.
vehicleRegistrationInformation é o VRN e o Estado-Membro de ma­
trícula do veículo descarregado, bloqueado ou desbloqueado.
downloadPeriodBegin e downloadPeriodEnd é o período eventual­
mente descarregado da VU.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 144
2.47. CompanyActivityType
Código que indica uma atividade executada por uma empresa que utiliza
o respetivo cartão.
2.48. CompanyCardApplicationIdentification
Informação memorizada num cartão de empresa e relativa à identificação
da aplicação do cartão (requisitos 369 e 375 do anexo 1C).
typeOfTachographCardId especifica o tipo de cartão aplicado.
cardStructureVersion especifica a versão da estrutura aplicada no car­
tão.
noOfCompanyActivityRecords é o número de registos de atividade da
empresa que o cartão pode memorizar.
▼M3
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 taco­
gráfico, disponíveis para memorizar configurações da VU.
▼B
2.49. CompanyCardHolderIdentification
Informação memorizada num cartão de empresa e relativa à identificação
do seu titular (requisitos 372 e 378 do anexo 1C).
companyName é o nome da empresa titular.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 145
companyAddress é o endereço da empresa titular.
cardHolderPreferredLanguage é o idioma preferencial do titular do
cartão.
2.50. ControlCardApplicationIdentification
Informação memorizada num cartão de controlo e relativa à identificação
da aplicação do cartão (requisitos 357 e 363 do anexo 1C).
typeOfTachographCardId especifica o tipo de cartão aplicado.
cardStructureVersion especifica a versão da estrutura que é aplicada no
cartão.
noOfControlActivityRecords é o número de registos de atividade de
controlo que o cartão pode memorizar.
▼M3
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 taco­
gráfico, disponíveis para memorizar configurações da VU.
▼B
2.51. ControlCardControlActivityData
Informação memorizada num cartão de controlo e relativa à atividade de
controlo executada com o cartão (requisitos 361 e 367 do anexo 1C).
controlPointerNewestRecord é o índice do último registo atualizado da
atividade de controlo.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 146
Valor atribuído é o número correspondente ao numerador do registo da
atividade de controlo, a começar por «0» na primeira ocorrência dos
registos da atividade de controlo na estrutura.
controlActivityRecords é o conjunto de todos os registos de atividade
de controlo.
controlActivityRecord é a sequência de informação relativa a um
controlo.
controlType é o tipo do controlo.
controlTime é a data e a hora do controlo.
controlledCardNumber é o número e o Estado-Membro emissor do
cartão controlado.
controlledVehicleRegistration é o VRN e o Estado-Membro de matrí­
cula do veículo no qual o controlo foi efetuado.
controlDownloadPeriodBegin e controlDownloadPeriodEnd é o pe­
ríodo descarregado.
2.52. ControlCardHolderIdentification
Informação memorizada num cartão de controlo e relativa à identificação
do titular do cartão (requisitos 360 e 366 do anexo 1C).
controlBodyName é o nome do organismo de controlo do titular do
cartão.
controlBodyAddress é o endereço do organismo de controlo do titular
do cartão.
cardHolderName é o apelido e o nome próprio do titular do cartão de
controlo.
cardHolderPreferredLanguage é o idioma preferencial do titular do
cartão.
2.53. ControlType
Código que indica as atividades executadas durante um controlo. Este
tipo de dado está relacionado com os requisitos 126, 274, 299, 327 e
350 do anexo 1C.
Geração 1:
Valor atribuído — Alinhamento de octetos: «cvpdxxxx»B (8 bits)
«c»B descarregamento do cartão:
«0»B: cartão não descarregado durante esta atividade de
controlo
«1»B: cartão descarregado durante esta atividade de
controlo
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 147
«v»B descarregamento da VU:
«0»B: VU não descarregada durante esta atividade de
controlo
«1»B: VU descarregada durante esta atividade de con­
trolo
«p»B impressão:
«0»B: não efetuada impressão durante esta atividade de
controlo
«1»B: efetuada impressão durante esta atividade de con­
trolo
«d»B visualização:
«0»B: não utilizada visualização durante esta atividade
de controlo
«1»B: utilizada visualização durante esta atividade de
controlo
«xxxx»B Não utilizada.
Geração 2:
Valor atribuído — Alinhamento de octetos: «cvpdexxx»B (8 bits)
«c»B descarregamento do cartão:
«0»B: cartão não descarregado durante esta atividade de
controlo
«1»B: cartão descarregado durante esta atividade de
controlo
«v»B descarregamento da VU:
«0»B: VU não descarregada durante esta atividade de
controlo
«1»B: VU descarregada durante esta atividade de con­
trolo
«p»B impressão:
«0»B: não efetuada impressão durante esta atividade de
controlo
«1»B: efetuada impressão durante esta atividade de con­
trolo
«d»B visualização:
«0»B: não utilizada visualização durante esta atividade
de controlo
«1»B: utilizada visualização durante esta atividade de
controlo
«e»B Controlo de calibração de estrada:
«0»B: parâmetros de calibração não verificados durante
esta atividade de controlo
«1»B: parâmetros de calibração verificados durante esta
atividade de controlo
«xxx»B RFU.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 148
2.54. CurrentDateTime
Data e hora atuais do aparelho de controlo.
Valor atribuído: sem mais especificações.
2.55. CurrentDateTimeRecordArray
Geração 2:
Data e hora atuais, mais metadados utilizados no protocolo de
descarregamento.
recordType indica o tipo de registo (CurrentDateTime). Valor atri­
buído: ver RecordType
recordSize: tamanho do CurrentDateTime, em bytes.
noOfRecords: número de registos nos registos definidos.
records: conjunto de registos atuais da data e da hora.
2.56. DailyPresenceCounter
Contador, memorizado num cartão de condutor ou de oficina, que vai
sofrendo acréscimos unitários por cada dia em que o cartão tenha estado
inserido numa VU. Este tipo de dado está relacionado com os requisitos
266, 299, 320 e 343 do anexo 1C.
Valor atribuído: número consecutivo com o valor máximo de 9 999, a
recomeçar em 0. No momento da primeira emissão do cartão, o número
é fixado em 0.
2.57. Datef
Data expressa num formato numérico que pode ser impresso de
imediato.
Valor atribuído:
aaaa Ano
mm Mês
dd Dia
«00000000»H não indica explicitamente qualquer data.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 149
2.58. DateOfDayDownloaded
Geração 2:
Data e hora do descarregamento.
Valor atribuído: sem mais especificações.
2.59. DateOfDayDownloadedRecordArray
Geração 2:
Data e hora do descarregamento, mais metadados utilizados no protocolo
de descarregamento.
recordType indica o tipo de registo (DateOfDayDownloaded). Valor
atribuído: ver RecordType
recordSize: tamanho do CurrentDateTime, em bytes.
noOfRecords: número de registos nos registos definidos.
records: conjunto de data e hora dos registos descarregados.
2.60. Distância
Uma distância percorrida (resulta do cálculo da diferença entre dois
valores do conta-quilómetros do veículo, em quilómetros).
Valor atribuído: Binário sem sinal. Valor em km no intervalo opera­
cional de 0 a 9 999 km.
▼M3
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.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 150
2.61. DriverCardApplicationIdentification
Informação memorizada num cartão de condutor e relativa à identifica­
ção da aplicação do cartão (requisitos 253 e 278 do anexo 1C).
Geração 1:
typeOfTachographCardId especifica o tipo de cartão aplicado.
cardStructureVersion especifica a versão da estrutura aplicada no car­
tão.
noOfEventsPerType: número de incidentes, por tipo, que o cartão pode
registar.
noOfFaultsPerType: número de falhas, por tipo, que o cartão pode
registar.
activityStructureLength indica o número de bytes disponíveis para
memorizar registos de atividade.
noOfCardVehicleRecords: número de registos de veículo que o cartão
pode conter.
noOfCardPlaceRecords: número de locais que o cartão pode registar.
Geração 2:
▼M1
Utilizam-se os seguintes elementos de dados, além dos utilizados na
geração 1:
noOfGNSSADRecords é o número de registos GNSS de condução
acumulados que o cartão pode memorizar.
noOfSpecificConditionRecords é o número dos registos de condição
especial que o cartão pode memorizar.
noOfCardVehicleUnitRecords é o número de registos de utilização de
unidades-veículo que o cartão pode memorizar.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 151
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 taco­
gráfico, disponíveis para memorizar configurações da VU.
▼B
2.62. DriverCardHolderIdentification
Informação memorizada num cartão de condutor e relativa à identifica­
ção do titular do cartão (requisitos 256 e 281 do anexo 1C).
cardHolderName é o apelido e o nome próprio do titular do cartão de
condutor.
cardHolderBirthDate é a data de nascimento do titular do cartão de
condutor.
cardHolderPreferredLanguage é o idioma preferencial do titular do
cartão.
▼M3
2.63. DSRCSecurityData
Geração 2:
Relativamente à definição deste tipo de dados, ver o apêndice 11.
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 152
2.64. EGFCertificate
Geração 2:
Certificado da chave pública do módulo GNSS externo para autenticação
mútua com uma VU. A estrutura deste certificado é especificada no
apêndice 11.
2.65. EmbedderIcAssemblerId
Fornece informações sobre o fabricante do IC.
countryCode é o código de país de duas letras, do fabricante do mó­
dulo, em conformidade com a norma ISO 3166.
moduleEmbedder identifica o fabricante do módulo.
manufacturerInformation para utilização interna do fabricante.
2.66. EntryTypeDailyWorkPeriod
Código que distingue entre o início e o final de uma entrada relativa ao
local de um período de trabalho diário e a condição da entrada.
Geração 1
Valor atribuído: em conformidade com a norma ISO/IEC 8824-1.
▼M3
Geração 2
Valor atribuído: em conformidade com a norma ISO/IEC 8824-1.
▼B
2.67. EquipmentType
Código que distingue diferentes tipos de equipamento para a aplicação
tacográfica.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 153
Geração 1:
Valor atribuído: em conformidade com a norma ISO/IEC 8824-1.
O valor 0 é reservado para designar um Estado-Membro ou a Europa no
campo de certificados CHA.
Geração 2:
▼M1
Utilizam-se os mesmos valores da geração 1, com as seguintes obser­
vações:
Nota 1: Os valores da geração 2 para a placa, o adaptador e a conexão
GNSS externa, bem como os valores da geração 1 para a unidade-veí­
culo e o sensor de movimentos, podem ser utilizados em SealRecord (se
pertinente).
Nota 2: No campo CardHolderAuthorisation (CHA) de um certificado
de geração 2, os valores (1), (2) e (6) devem ser interpretados como
indicando um certificado de autenticação mútua para o respetivo tipo de
equipamento. Para indicar o respetivo certificado de criação de uma
assinatura digital, devem ser utilizados os valores (17), (18) ou (19).
▼B
2.68. EuropeanPublicKey
Geração 1:
A chave pública europeia.
2.69. EventFaultRecordPurpose
Código que explica por que foram registados um incidente ou uma falha.
Valor atribuído:
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 154
um dos 10 mais recentes (ou últimos) incidentes ou falhas
o incidente mais longo de um dos últimos 10 dias de ocorrência
um dos 5 incidentes mais longos dos últimos 365 dias
o último incidente de um dos últimos 10 dias de ocorrência
o incidente mais grave de um dos últimos 10 dias de ocorrência
um dos 5 incidentes mais graves dos últimos 365 dias
o primeiro incidente ou falha desde a última calibração
um incidente ou falha ativos ou em curso
RFU
específico do fabricante
2.70. EventFaultType
Código que qualifica um incidente ou uma falha.
Valor atribuído:
Geração 1:
Incidentes gerais
Sem pormenores adicionais
Inserção de cartão não válido
Conflito de cartões
Sobreposição de tempos
Condução sem cartão adequado
Inserção de cartão durante a condução
Última sessão de cartão encerrada incorretamente
Excesso de velocidade
Interrupção da alimentação energética
Erro nos dados de movimento
Conflito relativo ao movimento do veículo
RFU
Incidentes de tentativa de violação da segurança relativos à VU
Sem pormenores adicionais
Falha da autenticação do sensor de movimentos
Falha da autenticação do cartão tacográfico
Mudança não autorizada de sensor de movimentos
Erro de integridade na entrada de dados relativos ao cartão
Erro de integridade nos dados de utilização memorizados
Erro na transferência interna de dados
Abertura não autorizada da caixa
Sabotagem do equipamento informático
RFU
Incidentes de tentativa de violação da segurança relativos ao sensor
Sem pormenores adicionais
Falha de autenticação
Erro de integridade em dados memorizados
Erro na transferência interna de dados
Abertura não autorizada da caixa
Sabotagem do equipamento informático
RFU
Falhas do aparelho de controlo
Sem pormenores adicionais
Falha interna da VU
Falha da impressora
Falha da visualização
Falha do descarregamento
Falha do sensor
RFU
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 155
Falhas do cartão
Sem pormenores adicionais
RFU
RFU
Específico do fabricante.
▼M3
Geração 2, versão 1:
▼M1
Incidentes gerais
Sem pormenores adicionais
Inserção de cartão não válido
Conflito de cartões
Sobreposição de tempos
Condução sem cartão adequado
Inserção de cartão durante a condução
Última sessão de cartão encerrada incorretamente
Excesso de velocidade
Interrupção da alimentação energética
Erro nos dados de movimento
Conflito relativo ao movimento do veículo
Conflito de tempo (GNSS versus relógio interno da VU)
Erro de comunicação com o sistema de comunicação à distância
Ausência de informações sobre a posição do recetor GNSS
Erro de comunicação com o módulo GNSS externo
RFU
Incidentes de tentativa de violação da segurança relativos à VU
Sem pormenores adicionais
Falha da autenticação do sensor de movimentos
Falha da autenticação do cartão tacográfico
Mudança não autorizada de sensor de movimentos
Erro de integridade na entrada de dados relativos ao cartão
Erro de integridade nos dados de utilização memorizados
Erro na transferência interna de dados
Abertura não autorizada da caixa
Sabotagem do equipamento informático
Violação de deteção de GNSS
Falha de autenticação do módulo GNSS externo
Certificado do módulo GNSS externo expirado
RFU
Incidentes de tentativa de violação da segurança relativos ao sensor
Sem pormenores adicionais
Falha de autenticação
Erro de integridade em dados memorizados
Erro na transferência interna de dados
Abertura não autorizada da caixa
Sabotagem do equipamento informático
RFU
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 156
Falhas do aparelho de controlo
Sem pormenores adicionais
Falha interna da VU
Falha da impressora
Falha da visualização
Falha do descarregamento
Falha do sensor
Recetor GNSS interno
Módulo GNSS externo
Sistema de comunicação à distância
Interface ITS
RFU
Falhas do cartão
Sem pormenores adicionais
RFU
RFU
Específico do fabricante.
▼M3
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 comuni­
cação à distância,
«0D»H Ausência de informações sobre a posição do re­
cetor 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,
▼M1
02016R0799 — PT — 21.08.2023 — 003.002 — 157
«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 rela­
tivos 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.
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 158
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 atri­
buí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].
▼B
2.72. ExtendedSerialNumber
Identificação única de um equipamento. Pode também ser utilizado como
identificador da chave pública de um equipamento.
Geração 1:
serialNumber é um número de série do equipamento, único para o
fabricante, para o tipo de equipamento e para o mês e ano infra.
monthYear é a identificação do mês e do ano de fabrico (ou de atri­
buição do número de série).
Valor atribuído: codificação BCD de Month (mês, com dois algaris­
mos) e de Year (ano, com os dois últimos algarismos).
type é um identificador do tipo de equipamento.
Valor atribuído: específico do fabricante, com valor reservado «FFh».
manufacturerCode: é o código numérico identificativo de um fabricante
do tipo de equipamento homologado.
Geração 2:
serialNumber: ver geração 1
monthYear: ver geração 1
type indica o tipo de equipamento
manufacturerCode: ver geração 1.
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 159
2.73. FullCardNumber
Código que identifica plenamente um cartão tacográfico.
cardType é o tipo do cartão tacográfico.
cardIssuingMemberState é o código do Estado-Membro que emitiu o
cartão.
cardNumber é o número do cartão.
2.74. FullCardNumberAndGeneration
Geração 2:
código que identifica plenamente um cartão tacográfico e a respetiva
geração.
fullcardNumber identifica o cartão tacográfico.
generation indica a geração do cartão tacográfico utilizado.
2.75. Generation
Geração 2:
indica a geração do tacógrafo utilizado.
Valor atribuído:
«00»H RFU
«01»H Geração 1
«02»H Geração 2
«03»H .. «FF»H RFU
2.76. GeoCoordinates
▼M3
Geração 2:
As coordenadas geográficas são codificadas como números inteiros. Es­
tes 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).
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 160
latitude: codificada como um múltiplo (fator 10) da representação
±DDMM.M.
longitude: codificada como um múltiplo (fator 10) da representação
±DDDMM.M.
2.77. GNSSAccuracy
Geração 2:
A precisão dos dados de posição GNSS (definição eee)). Esta precisão é
codificada como um número inteiro e é um múltiplo (fator 10) do valor
X.Y fornecido pela frase GSA NMEA.
▼M1
2.78. GNSSAccumulatedDriving
Geração 2:
Informação memorizada num cartão de condutor ou de oficina e relativa
à posição GNSS do veículo, se o tempo de condução acumulado atingir
um múltiplo de três horas (requisitos 306 e 354 do anexo IC).
gnssADPointerNewestRecord é o índice do último registo GNSS atua­
lizado da condução acumulada.
Valor atribuído é o número correspondente ao numerador do registo
GNSS da condução acumulada, a começar por «0» na primeira ocorrên­
cia dos registos GNSS da condução acumulada na estrutura.
gnssAccumulatedDrivingRecords é o conjunto de registos que contêm
a data e a hora em que a condução acumulada atinge um múltiplo de três
horas e informações sobre a posição do veículo.
2.79. GNSSAccumulatedDrivingRecord
Geração 2:
Informação memorizada num cartão de condutor ou de oficina e relativa
à posição GNSS do veículo, se o tempo de condução acumulado atingir
um múltiplo de três horas (requisitos 305 e 353 do anexo IC).
timeStamp é a data e hora em que o tempo de condução acumulado
atinge um múltiplo de três horas.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 161
gnssPlaceRecord contém informação relacionada com a posição do veí­
culo.
vehicleOdometerValue é o valor do conta-quilómetros no momento em
que o tempo de condução acumulado atinge um múltiplo de três horas.
▼M3
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.
▼M1
02016R0799 — PT — 21.08.2023 — 003.002 — 162
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.
▼B
2.80. GNSSPlaceRecord
Geração 2:
a informação relacionada com a posição GNSS do veículo (requisitos
108, 109, 110, 296, 305, 347 e 353 do anexo 1C).
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.
2.81. HighResOdometer
Valor do conta-quilómetros do veículo: cúmulo das distâncias percorridas
pelo veículo durante o seu funcionamento.
Valor atribuído: Binário sem sinal. Valor em 1/200 km no intervalo
operacional de 0 a 21 055 406 km.
2.82. HighResTripDistance
Distância percorrida durante um dia ou parte de um dia.
Valor atribuído: Binário sem sinal. Valor em 1/200 km no intervalo
operacional de 0 a 21 055 406 km.
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 163
2.83. HolderName
Apelido e nome próprio do titular de um cartão.
holderSurname é o apelido (nome de família) do titular. Não inclui
títulos.
Valor atribuído: Se o cartão não for pessoal, holderSurname contém a
mesma informação que companyName, workshopName ou controlBody­
Name.
holderFirstNames é o nome próprio e as iniciais do titular.
▼M3
2.84. Reservado para utilização futura
▼B
Geração 2:
Informações sobre se recetor GNSS é interno ou externo à
unidade-veículo. True significa que o recetor GNSS é interno à VU.
False significa que o recetor GNSS é externo.
2.85. K-ConstantOfRecordingEquipment
Constante do aparelho de controlo [definição m)].
Valor atribuído: Impulsos por quilómetro no intervalo operacional de 0
a 64 255 impulsos/km.
▼M1
2.86. KeyIdentifier
Identificador único de uma chave pública utilizada para referenciar e
selecionar a chave. Identifica também o titular da chave.
A primeira opção é adequada para referenciar a chave pública de uma
unidade-veículo ou de um cartão tacográfico ou de um módulo GNSS
externo.
A segunda opção é adequada para referenciar a chave pública de uma
unidade-veículo (caso o número de série da VU não possa ser conhecido
no momento da geração do certificado).
A terceira opção é adequada para referenciar a chave pública de um
Estado-Membro.
▼B
2.87. KMWCKey
Geração 2:
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 164
Chave AES e a respetiva versão da chave associada, utilizada para
emparelhamento do sensor de movimentos com a VU. Para mais infor­
mações, ver apêndice 11.
kMWCKey é o comprimento da chave AES concatenada com a chave
utilizada para o emparelhamento do sensor de movimentos com a VU.
keyVersion indica a versão de chave da chave AES.
2.88. Language
Código identificativo de um idioma.
Valor atribuído: Código constituído por duas letras minúsculas, em
conformidade com a norma ISO 639.
2.89. LastCardDownload
Data e hora, memorizadas num cartão de condutor e relativas ao último
descarregamento do cartão (para outras finalidades que não o controlo)
(requisitos 257 e 282 do anexo 1C). Esta data é atualizável por uma VU
ou por qualquer leitor de cartões.
Valor atribuído: sem mais especificações.
▼M3
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.
▼B
2.90. LinkCertificate
Geração 2:
O certificado de ligação entre pares de chaves European Root CA.
▼M3
2.90-A. LoadType
Geração 2, versão 2:
Código que identifica um tipo de carga introduzido.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 165
Valor atribuído:
«00»H Tipo de carga indefinido,
«01»H Mercadorias,
«02»H Passageiros,
«03»H .. «FF»H RFU.
▼B
2.91. L-TyreCircumference
Perímetro efetivo dos pneus das rodas [definição u)].
Valor atribuído: Binário sem sinal, valor em 1/8 mm no intervalo ope­
racional de 0 a 8 031 mm.
▼M1
2.92. MAC
Geração 2:
Uma soma criptográfica de teste, com 8, 12 ou 16 bytes de comprimento,
correspondente aos conjuntos de codificação especificados no apên­
dice 11.
▼B
2.93. ManualInputFlag
Código que identifica se um titular introduziu manualmente atividades de
condutor no momento da inserção do cartão ou não (requisito 081 do
anexo 1B e requisito 102 do anexo 1C).
Valor atribuído: sem mais especificações.
2.94. ManufacturerCode
Código identificativo de um fabricante do tipo de equipamento
homologado.
O laboratório competente para ensaios de interoperabilidade deve manter
e publicar a lista de códigos de fabricantes no seu sítio Web (requisito
454 do anexo 1C).
Os ManufacturerCodes são provisoriamente atribuídos a criadores de
tacógrafos quando do pedido de ensaios de interoperabilidade ao labo­
ratório competente.
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 166
2.95. ManufacturerSpecificEventFaultData
Geração 2:
Os códigos de erro específicos do fabricante simplificam a análise de
erros e a manutenção das unidades-veículo.
ManufacturerCode identifica o fabricante da unidade-veículo.
manufacturerSpecificErrorCode é um código de erro específico para o
fabricante.
2.96. MemberStateCertificate
O certificado da chave pública de um Estado-Membro, emitido pela
autoridade europeia de certificação.
2.97. MemberStateCertificateRecordArray
Geração 2:
O certificado do Estado-Membro, mais metadados utilizados no proto­
colo de descarregamento.
recordType indica o tipo de registo (MemberStateCertificate). Valor
atribuído: ver RecordType
recordSize: tamanho do MemberStateCertificate, em bytes.
noOfRecords: número de registos nos registos definidos. O valor deve
ser fixado em 1, dado que os certificados podem ter comprimentos
diferentes.
records: conjunto de certificados do Estado-Membro.
2.98. MemberStatePublicKey
Geração 1:
Chave pública de um Estado-Membro.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 167
2.99. Name
Um nome.
codePage especifica um conjunto de carateres definido no capítulo 4
name é um nome codificado que utiliza o conjunto de carateres
especificado.
2.100. NationAlpha
A referência alfabética a um país deve estar em conformidade com os
códigos distintivos utilizados em veículos no tráfego internacional (Con­
venção das Nações Unidas sobre Trânsito Viário, Viena, 1968).
Os códigos NationAlpha e NationNumeric devem constar de uma lista
publicada no sítio Web do laboratório nomeado para a realização do
ensaio de interoperabilidade, conforme estabelecido no requisito 440
do anexo 1C.
2.101. NationNumeric
Referência numérica a um país.
Valor atribuído: ver tipo de dados 2.100 (NationAlpha).
Só deve ser efetuada uma alteração ou atualização da especificação
NationAlpha ou NationNumeric descrita no parágrafo supra após o la­
boratório nomeado receber os pontos de vista de fabricantes de
unidades-veículo homologadas para tacógrafos digitais e tacógrafos
inteligentes.
▼M3
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.
▼B
2.102. NoOfCalibrationRecords
Número de registos de calibração que um cartão de oficina pode
memorizar.
Geração 1:
Valor atribuído: ver apêndice 2.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 168
Geração 2:
Valor atribuído: ver apêndice 2.
2.103. NoOfCalibrationsSinceDownload
Contador que indica o número de calibrações efetuadas com um cartão
de oficina desde o seu último descarregamento (requisitos 317 e 340 do
anexo 1C).
Valor atribuído: sem outras especificações.
2.104. NoOfCardPlaceRecords
Número de registos de local que um cartão de condutor ou de oficina
pode memorizar.
Geração 1:
Valor atribuído: ver apêndice 2.
Geração 2:
Valor atribuído: ver apêndice 2.
2.105. NoOfCardVehicleRecords
Número de registos de utilização de veículos que um cartão de condutor
ou de oficina pode memorizar.
Valor atribuído: ver apêndice 2.
2.106. NoOfCardVehicleUnitRecords
Geração 2:
Número de registos de utilização de unidades-veículo que um cartão de
condutor ou de oficina pode memorizar.
Valor atribuído: ver apêndice 2.
2.107. NoOfCompanyActivityRecords
Número de registos de atividade de empresa que um cartão de empresa
pode memorizar.
Valor atribuído: ver apêndice 2.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 169
2.108. NoOfControlActivityRecords
Número de registos de atividade de controlo que um cartão de controlo
pode memorizar.
Valor atribuído: ver apêndice 2.
2.109. NoOfEventsPerType
Número de incidentes, por tipo, que um cartão pode memorizar.
Valor atribuído: ver apêndice 2.
2.110. NoOfFaultsPerType
Número de falhas, por tipo, que um cartão pode memorizar.
Valor atribuído: ver apêndice 2.
▼M1
2.111. NoOfGNSSADRecords
Geração 2:
Número de registos GNSS de condução acumulada que o cartão pode
memorizar.
Valor atribuído: ver apêndice 2.
▼M3
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.
▼B
2.112. NoOfSpecificConditionRecords
Geração 2:
Número de registos de condição especial que o cartão pode memorizar.
Valor atribuído: ver apêndice 2.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 170
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.
▼B
2.113. OdometerShort
Valor do conta-quilómetros do veículo sob forma sincopada (abre­
viada).
Valor atribuído: Binário sem sinal. Valor em km no intervalo opera­
cional de 0 a 9 999 999 km.
2.114. OdometerValueMidnight
O valor do conta-quilómetros do veículo à meia-noite de um determi­
nado dia (requisito 090 do anexo 1B e requisito 113 do anexo 1C).
Valor atribuído: sem mais especificações.
▼M3
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.
▼B
2.115. OdometerValueMidnightRecordArray
Geração 2:
O OdometerValueMidnight, mais metadados utilizados no protocolo de
descarregamento.
recordType indica o tipo de registo (OdometerValueMidnight). Valor
atribuído: ver RecordType
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 171
recordSize: tamanho do OdometerValueMidnight, em bytes.
noOfRecords: número de registos nos registos definidos.
records: conjunto dos registos OdometerValueMidnight.
2.116. OverspeedNumber
Número de incidentes de velocidade excessiva desde o último controlo
de excesso de velocidade.
Valor atribuído: 0 significa que, desde o último controlo de excesso
de velocidade, não ocorreu nenhum incidente de excesso de velocidade,
1 significa que ocorreu um incidente de excesso de velocidade, …, 255
significa que ocorreram 255 ou mais incidentes.
▼M3
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 ter­
minam 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 memori­
zadas num registo diferente (ver o ponto 2.117 PlaceRecord).
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 172
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.
▼B
2.117. PlaceRecord
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 1C).
Geração 1:
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.
Geração 2:
Utilizam-se os seguintes elementos de dados, além dos utilizados na
geração 1:
entryGNSSPlaceRecord: localização e hora registadas.
▼M3
2.117-A. PositionAuthenticationStatus
Geração 2, versão 2:
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 173
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.
▼B
2.118. PreviousVehicleInfo
Informação relativa ao veículo previamente utilizado por um condutor
no momento em que insere o seu cartão numa unidade-veículo (requi­
sito 081 do anexo 1B e requisito 102 do anexo 1C).
Geração 1:
vehicleRegistrationIdentification é o VRN e o Estado-Membro de
matrícula do veículo.
cardWithdrawalTime: data e hora a que o cartão foi retirado.
Geração 2:
Utiliza-se o seguinte elemento de dados, além dos utilizados na gera­
ção 1:
vuGeneration identifica a geração da unidade-veículo.
2.119. PublicKey
Geração 1:
Uma chave pública RSA.
rsaKeyModulus é o módulo do par de chaves.
rsaKeyPublicExponent é o expoente público do par de chaves.
2.120. RecordType
Geração 2:
Referência a um tipo de registo. Utiliza-se este tipo de dados em
RecordArrays.
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 174
Valor atribuído:
► (1) M1
► (2) M3
ActivityChangeInfo
CardSlotsStatus
CurrentDateTime
MemberStateCertificate
OdometerValueMidnight
DateOfDayDownloaded
SensorPaired
Signature
SpecificConditionRecord
VehicleIdentificationNumber
VehicleRegistrationNumber
VuCalibrationRecord
VuCardIWRecord
VuCardRecord
VuCertificate
VuCompanyLocksRecord
VuControlActivityRecord
VuDetailedSpeedBlock
VuDownloadablePeriod
VuDownloadActivityData
VuEventRecord
►M1 VuGNSSADRecord ◄
VuITSConsentRecord
VuFaultRecord
VuIdentification
VuOverSpeedingControlData
VuOverSpeedingEventRecord
VuPlaceDailyWorkPeriodRecord
VuTimeAdjustmentGNSSRecord
VuTimeAdjustmentRecord
VuPowerSupplyInterruptionRecord
SensorPairedRecord
SensorExternalGNSSCoupledRecord
►M3 VuBorderCrossingRecord
VuLoadUnloadRecord
VehicleRegistrationIdentification
RFU ◄
Específico do fabricante.
2.121. RegionAlpha
Referência alfabética a uma região, dentro de um país especificado.
Geração 1:
Valor atribuído:
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 175
Geração 2:
Os códigos RegionAlpha devem constar de uma lista publicada no sítio
Web do laboratório nomeado para a realização do ensaio de
interoperabilidade.
2.122. RegionNumeric
Referência numérica a uma região, dentro de um país especificado.
Geração 1:
Valor atribuído:
Geração 2:
Os códigos RegionNumeric devem constar de uma lista publicada no
sítio Web do laboratório nomeado para a realização do ensaio de
interoperabilidade.
2.123. RemoteCommunicationModuleSerialNumber
Geração 2:
O número de série do dispositivo de comunicação à distância.
2.124. RSAKeyModulus
Geração 1:
O módulo de um par de chaves RSA.
Valor atribuído: não especificado.
2.125. RSAKeyPrivateExponent
Geração 1:
O expoente privado de um par de chaves RSA.
Valor atribuído: não especificado.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 176
2.126. RSAKeyPublicExponent
Geração 1:
O expoente público de um par de chaves RSA.
Valor atribuído: não especificado.
2.127. RtmData
Geração 2:
Relativamente à definição deste tipo de dados, ver apêndice 14.
2.128. SealDataCard
Geração 2:
Este tipo de dado memoriza informações sobre os selos que estão
ligados aos diferentes componentes do veículo e destina-se a memori­
zação num cartão. Este tipo de dado está relacionado com o requisito
337 do anexo 1C.
noOfSealRecords é o número de registos em sealRecords.
sealRecords é um conjunto de registos dos selos.
2.129. SealDataVu
Geração 2:
Este tipo de dado memoriza informações sobre os selos que estão
ligados aos diferentes componentes do veículo e destina-se a memori­
zação numa unidade-veículo.
sealRecords é um conjunto de registos dos selos. Se houver menos de
cinco selos disponíveis, o valor de EquipmentType em todos os seal­
Records não utilizados deverá ser fixado em 16, isto é, não utilizado.
2.130. SealRecord
Geração 2:
Este tipo de dado memoriza informações sobre um selo que está ligado
a um componente. Este tipo de dado está relacionado com o requisito
337 do anexo 1C.
equipmentType identifica o tipo de equipamento a que o selo está
ligado.
extendedSealIdentifier é o identificador do selo ligado ao
equipamento.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 177
2.131. SensorApprovalNumber
Número de homologação de tipo do sensor.
Geração 1:
Valor atribuído: não especificado.
Geração 2:
Valor atribuído:
O número de homologação deve ser apresentado conforme publicação
no respetivo sítio Web da Comissão Europeia, ou seja, incluindo hífe­
nes, se existirem. O número de homologação deve estar alinhado à
esquerda.
2.132. SensorExternalGNSSApprovalNumber
Geração 2:
número de homologação de tipo do módulo GNSS externo.
Valor atribuído:
O número de homologação deve ser apresentado conforme publicação
no respetivo sítio Web da Comissão Europeia, ou seja, incluindo hífe­
nes, se existirem. O número de homologação deve estar alinhado à
esquerda.
2.133. SensorExternalGNSSCoupledRecord
Geração 2:
Informação memorizada numa unidade-veículo e relativa à identifica­
ção do módulo GNSS externo acoplado a ela (requisito 100 do
anexo 1C).
sensorSerialNumber é o número de série do módulo GNSS externo
acoplado à unidade-veículo.
sensorApprovalNumber é o número de homologação deste módulo
GNSS externo.
sensorCouplingDate é uma data de acoplamento deste módulo GNSS
externo à unidade-veículo.
2.134. SensorExternalGNSSIdentification
Geração 2:
Informação relativa à identificação do módulo GNSS externo (requisito
98 do anexo 1C).
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 178
sensorSerialNumber é o número de série alargado do módulo GNSS
externo.
sensorApprovalNumber é o número de homologação do módulo
GNSS externo.
sensorSCIdentifier é o identificador do componente de segurança do
módulo GNSS externo.
sensorOSIdentifier é o identificador do sistema operacional do mó­
dulo GNSS externo.
2.135. SensorExternalGNSSInstallation
Geração 2:
Informação memorizada num módulo GNSS externo e relativa à ins­
talação do sensor GNSS externo (requisito 123 do anexo 1C).
sensorCouplingDateFirst é a data do primeiro acoplamento do mó­
dulo GNSS externo à unidade-veículo.
firstVuApprovalNumber é o número de homologação da primeira
unidade-veículo acoplada ao módulo GNSS externo.
firstVuSerialNumber é o número de série da primeira unidade-veículo
emparelhada com o módulo GNSS externo.
sensorCouplingDateCurrent é a data do acoplamento atual do mó­
dulo GNSS externo à unidade-veículo.
currentVuApprovalNumber é o número de homologação da
unidade-veículo acoplada atualmente ao módulo GNSS externo.
currentVUSerialNumber é o número de série da unidade-veículo aco­
plada atualmente ao módulo GNSS externo.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 179
2.136. SensorExternalGNSSOSIdentifier
Geração 2:
Identificador do sistema operacional do módulo GNSS externo.
Valor atribuído: específico do fabricante.
2.137. SensorExternalGNSSSCIdentifier
Geração 2:
Este tipo utiliza-se, por exemplo, para identificar o módulo criptográ­
fico do módulo GNSS externo.
Identificador do componente de segurança do módulo GNSS externo.
Valor atribuído: específico do fabricante do componente.
2.138. SensorGNSSCouplingDate
Geração 2:
Data de um acoplamento do módulo GNSS externo a uma
unidade-veículo.
Valor atribuído: não especificado.
2.139. SensorGNSSSerialNumber
Geração 2:
Este tipo utiliza-se para memorizar o número de série do recetor GNSS,
quer esteja dentro da VU ou fora da VU.
Número de série do recetor GNSS.
2.140. SensorIdentification
Informação memorizada num sensor de movimentos e relativa à iden­
tificação do mesmo (requisito 077 do anexo 1B e requisito 95 do
anexo 1C).
sensorSerialNumber é o número de série alargado do sensor de mo­
vimentos (inclui número da peça e código do fabricante).
sensorApprovalNumber é o número de homologação do sensor de
movimentos.
sensorSCIdentifier é o identificador do componente de segurança do
sensor de movimentos.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 180
sensorOSIdentifier é o identificador do sistema operacional do sensor
de movimentos.
2.141. SensorInstallation
Informação memorizada num sensor de movimentos e relativa à ins­
talação do mesmo (requisito 099 do anexo 1B e requisito 122 do
anexo 1C).
sensorPairingDateFirst é a data do primeiro emparelhamento do sen­
sor de movimentos com uma VU.
firstVuApprovalNumber é o número de homologação da primeira
unidade-veículo emparelhada com o sensor de movimentos.
firstVuSerialNumber é o número de série da primeira unidade-veículo
emparelhada com o sensor de movimentos.
sensorPairingDateCurrent é a data do atual emparelhamento do sen­
sor de movimentos com a VU.
currentVuApprovalNumber é o número de homologação da
unidade-veículo atualmente emparelhada com o sensor de movimentos.
currentVUSerialNumber é o número de série da unidade-veículo
atualmente emparelhada com o sensor de movimentos.
2.142. SensorInstallationSecData
Informação memorizada num cartão de oficina e relativa aos dados de
segurança necessários para emparelhar sensores de movimentos com
unidades-veículo (requisitos 308 e 331 do anexo 1C).
Geração 1:
Valor atribuído: em conformidade com a norma ISO 16844-3.
Geração 2:
Conforme descrito no apêndice 11, um cartão de oficina deve memo­
rizar até três chaves para emparelhamento do sensor de movimentos
com a VU. Estas chaves têm diferentes versões principais.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 181
2.143. SensorOSIdentifier
Identificador do sistema operacional do sensor de movimentos.
Valor atribuído: específico do fabricante.
2.144. SensorPaired
Geração 1:
Informação memorizada numa unidade-veículo e relativa à identifica­
ção do sensor de movimentos emparelhado com ela (requisito 079 do
anexo 1B).
sensorSerialNumber é o número de série do sensor de movimentos
atualmente emparelhado com a unidade-veículo.
sensorApprovalNumber é o número de homologação do sensor de
movimentos atualmente emparelhado com a unidade-veículo.
sensorPairingDateFirst é a data em que o sensor de movimentos
atualmente emparelhado com a unidade-veículo foi emparelhado pela
primeira vez com uma VU.
2.145. SensorPairedRecord
Geração 2:
Informação memorizada numa unidade-veículo e relativa à identifica­
ção do sensor de movimentos emparelhado com ela (requisito 079 do
anexo 1C).
sensorSerialNumber: número de série de um sensor de movimentos
emparelhado com a unidade-veículo.
sensorApprovalNumber: número de homologação deste sensor de
movimentos.
sensorPairingDate: data do emparelhamento deste sensor de movi­
mentos com a unidade-veículo.
2.146. SensorPairingDate
Data do emparelhamento do sensor de movimentos com uma VU.
Valor atribuído: não especificado.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 182
2.147. SensorSCIdentifier
Identificador do componente de segurança do sensor de movimentos.
Valor atribuído: específico do fabricante do componente.
2.148. SensorSerialNumber
Número de série do sensor de movimentos.
2.149. Signature
Uma assinatura digital.
Geração 1:
Valor atribuído: em conformidade com o apêndice 11 (Mecanismos
comuns de segurança).
Geração 2:
Valor atribuído: em conformidade com o apêndice 11 (Mecanismos
comuns de segurança).
2.150. SignatureRecordArray
Geração 2:
Um conjunto de assinaturas, mais metadados utilizados no protocolo de
descarregamento.
recordType indica o tipo de registo (Signature). Valor atribuído: ver
RecordType
recordSize: tamanho de Signature, em bytes.
noOfRecords: número de registos nos registos definidos. O valor deve
ser fixado em 1, dado que as assinaturas podem ter diferentes
comprimentos.
records: conjunto de assinaturas.
2.151. SimilarEventsNumber
O número de eventos semelhantes para um determinado dia (requisito
094 do anexo 1B e requisito 117 do anexo 1C).
Valor atribuído: 0 não se utiliza, 1 significa que, no dia em questão,
apenas um incidente deste tipo foi memorizado, 2 significa que ocor­
reram dois incidentes deste tipo (memorizado apenas um), …, 255
significa que ocorreram 255 ou mais incidentes deste tipo no dia em
questão.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 183
2.152. SpecificConditionRecord
Informação memorizada num cartão de condutor ou de oficina ou
numa unidade-veículo e relativa a uma condição especial (requisitos
130, 276, 301, 328 e 355 do anexo 1C).
entryTime: data e hora da entrada.
specificConditionType: código que identifica a condição especial.
2.153. SpecificConditions
Informação memorizada num cartão de condutor ou de oficina ou
numa unidade-veículo e relativa a uma condição especial (requisitos
131, 277, 302, 329 e 356 do anexo 1C).
Geração 2:
conditionPointerNewestRecord é o índice do último registo atuali­
zado de condição especial.
Valor atribuído: o número correspondente ao numerador do registo da
condição especial, a começar por «0» na primeira ocorrência dos re­
gistos da condição especial na estrutura.
specificConditionRecords é o conjunto de registos que contém infor­
mações sobre as condições especiais gravadas.
2.154. SpecificConditionType
Código que identifica uma condição especial (requisitos 050b, 105a,
212a e 230a do anexo 1B e requisito 62 do anexo 1C).
Geração 1:
Valor atribuído:
«00»H RFU
«01»H Fora de âmbito — Início
«02»H Fora de âmbito — Final
«03»H Travessia de batelão/comboio
«04»H .. «FF»H RFU
Geração 2:
Valor atribuído:
«00»H RFU
«01»H Fora de âmbito — Início
«02»H Fora de âmbito — Final
«03»H Travessia de batelão/comboio — Início
«04»H Travessia de batelão/comboio — Final
«05»H .. «FF»H RFU
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 184
2.155. Speed
Velocidade do veículo (km/h).
Valor atribuído: quilómetros por hora no intervalo operacional de 0 a
220 km/h.
2.156. SpeedAuthorised
Velocidade máxima autorizada para o veículo [definição hh)].
2.157. SpeedAverage
Velocidade média num intervalo de duração previamente definido
(km/h).
2.158. SpeedMax
Velocidade máxima num intervalo de duração previamente definido.
▼M3
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 car­
tõ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.
▼B
2.159. TachographPayload
Geração 2:
Relativamente à definição deste tipo de dados, ver apêndice 14.
▼M1
2.160. Reservado para utilização futura
▼B
2.161. TDesSessionKey
Geração 1:
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 185
Uma chave tripla de sessão DES.
Valor atribuído: sem mais especificações.
▼M1
2.162. TimeReal
Código para um campo combinado de data e hora, em que a data e a
hora são expressas como segundos depois das 00h00m00s UTC de
1.1.1970.
Valor atribuído — Alinhamento de octetos: número de segundos a
partir da meia-noite UTC de 1.1.1970.
O valor máximo de data/hora situa-se no ano de 2106.
▼B
2.163. TyreSize
Designação das dimensões dos pneus.
Valor atribuído: em conformidade com a Diretiva 92/23/CEE de
31.3.92 (JO L 129, p. 95).
2.164. VehicleIdentificationNumber
Número de identificação do veículo (VIN), referente ao veículo como
um todo. Normalmente, número de série do chassi.
Valor atribuído: conforme definição na norma ISO 3779.
2.165. VehicleIdentificationNumberRecordArray
Geração 2:
O número de identificação do veículo, mais metadados utilizados no
protocolo de descarregamento.
recordType indica o tipo de registo (VehicleIdentificationNumber).
Valor atribuído: ver RecordType
recordSize: tamanho do VehicleIdentificationNumber, em bytes.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 186
noOfRecords: número de registos nos registos definidos.
records: conjunto de números de identificação de veículos.
2.166. VehicleRegistrationIdentification
Identificação de um veículo, única para a Europa (VRN e
Estado-Membro).
vehicleRegistrationNation é o país no qual o veículo está matriculado.
vehicleRegistrationNumber é o número de matrícula do
veículo (VRN).
▼M3
2.166-A. VehicleRegistrationIdentificationRecordArray
Geração 2, versão 2:
O número de matrícula do veículo, mais metadados utilizados no pro­
tocolo 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.
▼B
2.167. VehicleRegistrationNumber
Número de matrícula do veículo (VRN), atribuído pela autoridade
competente nesta matéria.
codePage especifica um conjunto de carateres definido no capítulo 4.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 187
vehicleRegNumber é um VRN codificado que utiliza o conjunto de
carateres especificado.
Valor atribuído: específico do país.
2.168. VehicleRegistrationNumberRecordArray
▼M3
Geração 2, versão 1:
▼B
O número de matrícula do veículo, mais metadados utilizados no pro­
tocolo de descarregamento.
recordType indica o tipo de registo (VehicleRegistrationNumber). Va­
lor atribuído: ver RecordType
recordSize: tamanho do VehicleRegistrationNumber, em bytes.
noOfRecords: número de registos nos registos definidos.
records: conjunto de números de matrícula dos veículos.
2.169. VuAbility
Geração 2:
As informações memorizadas numa VU sobre a sua capacidade para
utilizar ou não cartões tacográficos da geração 1 (requisito 121 do
anexo 1C).
Valor atribuído — Alinhamento de octetos: «xxxxxxxa»B (8 bits)
Para a capacidade de suporte da geração 1:
«a»B Capacidade para aceitar cartões tacográficos da gera­
ção 1:
«0»B: geração 1 é compatível,
«1»B: geração 1 não é compatível,
«xxxxxxx»B RFU
2.170. VuActivityDailyData
Geração 1:
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 188
Informação memorizada numa VU e relativa a mudanças na atividade
e/ou na situação da condução e/ou na situação do cartão num determi­
nado dia (requisito 084 do anexo 1B e requisito 105, 106 e 107 do
anexo 1C) e na situação das ranhuras às 00h00 desse dia.
noOfActivityChanges: número de palavras ActivityChangeInfo no con­
junto activityChangeInfos.
activityChangeInfos: conjunto de palavras ActivityChangeInfo memo­
rizadas na VU relativamente ao dia em questão. Inclui sempre duas
palavras ActivityChangeInfo que dão a situação das duas ranhuras às
00h00 desse dia.
2.171. VuActivityDailyRecordArray
Geração 2:
Informação memorizada numa VU e relativa a mudanças na atividade
e/ou na situação da condução e/ou na situação do cartão num determi­
nado dia (requisito 105, 106 e 107 do anexo 1C) e na situação das
ranhuras às 00h00 desse dia.
recordType indica o tipo de registo (ActivityChangeInfo). Valor atri­
buído: ver RecordType
recordSize: tamanho de ActivityChangeInfo, em bytes.
noOfRecords: número de registos nos registos definidos.
records: conjunto de palavras ActivityChangeInfo memorizadas na VU
relativamente ao dia em questão. Inclui sempre duas palavras Activity­
ChangeInfo que dão a situação das duas ranhuras às 00h00 desse dia.
2.172. VuApprovalNumber
Número de homologação de tipo da unidade-veículo.
Geração 1:
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 189
Valor atribuído: não especificado.
Geração 2:
Valor atribuído:
O número de homologação deve ser apresentado conforme publicação
no respetivo sítio Web da Comissão Europeia (por exemplo, incluindo
eventuais hífenes). Deve estar alinhado à esquerda.
2.173. VuCalibrationData
Geração 1:
Informação memorizada numa VU e relativa às calibrações do aparelho
de controlo (requisito 098 do anexo 1B).
noOfVuCalibrationRecords é o número de registos contidos no con­
junto vuCalibrationRecords.
vuCalibrationRecords é o conjunto de registos de calibração.
2.174. VuCalibrationRecord
Informação memorizada numa unidade-veículo e relativa à calibração do
aparelho de controlo (requisito 098 do anexo 1B e requisitos 119 e 120
do anexo 1C).
Geração 1:
calibrationPurpose é o objetivo da calibração.
workshopName, workshopAddress: nome e endereço da oficina.
workshopCardNumber identifica o cartão de oficina utilizado durante a
calibração.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 190
workshopCardExpiryDate: prazo de validade do cartão.
vehicleIdentificationNumber: VIN.
vehicleRegistrationIdentification contém o VRN e o Estado-Membro
de matrícula.
wVehicleCharacteristicConstant: coeficiente característico do veículo.
kConstantOfRecordingEquipment: constante do aparelho de controlo.
lTyreCircumference: perímetro efetivo dos pneus das rodas.
tyreSize: designação das dimensões dos pneus montados no veículo
authorisedSpeed: velocidade autorizada para o veículo.
oldOdometerValue, newOdometerValue: valores antigo e novo do
conta-quilómetros.
oldTimeValue, newTimeValue: valores antigo e novo da data e da
hora.
nextCalibrationDate: data da próxima calibração do tipo especificado
em CalibrationPurpose, a efetuar pela autoridade responsável pela ins­
peção.
▼M3
Geração 2, versão 1:
▼B
Utiliza-se o seguinte elemento de dados, além dos utilizados na gera­
ção 1:
sealDataVu: fornece informações sobre os selos ligados a diferentes
componentes do veículo.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 191
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 ex­
terno 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 utili­
zada para determinar o país em que a calibração foi realizada foi trans­
mitida pelo recetor GNSS.
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 192
2.175. VuCalibrationRecordArray
Geração 2:
Informação memorizada numa VU e relativa às calibrações do aparelho
de controlo (requisitos 119 e 120 do anexo 1C).
recordType indica o tipo de registo (VuCalibrationRecord). Valor atri­
buído: ver RecordType
recordSize: tamanho do VuCalibrationRecord, em bytes.
noOfRecords: número de registos nos registos definidos.
records: conjunto de registos de calibração.
2.176. VuCardIWData
Geração 1:
Informação memorizada numa unidade-veículo e relativa aos ciclos de
inserção e retirada de cartões de condutor ou de oficina nessa
unidade-veículo (requisito 081 do anexo 1B e requisito 103 do
anexo 1C).
noOfIWRecords: número de registos no conjunto vuCardIWRecords.
vuCardIWRecords: conjunto de registos relativos aos ciclos de inser­
ção e retirada de cartões.
2.177. VuCardIWRecord
Informação memorizada numa unidade-veículo e relativa a um ciclo de
inserção e retirada de um cartão de condutor ou de oficina nessa VU
(requisito 081 do anexo 1B e requisito 102 do anexo 1C).
Geração 1:
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 193
cardHolderName: apelido e nome próprio do titular do cartão de con­
dutor ou de oficina, memorizados no mesmo.
fullCardNumber: tipo, Estado-Membro emissor e número do cartão,
nele memorizados.
cardExpiryDate: prazo de validade do cartão, nele memorizado.
cardInsertionTime: data e hora a que o cartão foi inserido.
vehicleOdometerValueAtInsertion: valor no conta-quilómetros do veí­
culo no momento da inserção do cartão.
cardSlotNumber: ranhura na qual o cartão é inserido.
cardWithdrawalTime: data e hora a que o cartão foi retirado.
vehicleOdometerValueAtWithdrawal: valor no conta-quilómetros do
veículo no momento da retirada do cartão.
previousVehicleInfo contém informação, memorizada no cartão, acerca
do anterior veículo utilizado pelo condutor.
manualInputFlag: marcador que identifica se o titular do cartão intro­
duziu manualmente atividades de condutor no momento da inserção do
cartão.
Geração 2:
Em vez de fullCardNumber, a estrutura de dados da geração 2 recorre à
sequência do elemento de dados.
fullCardNumberAndGeneration: tipo, Estado-Membro emissor, nú­
mero e geração do cartão, nele memorizados.
2.178. VuCardIWRecordArray
Geração 2:
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 194
Informação memorizada numa unidade-veículo e relativa aos ciclos de
inserção e retirada de cartões de condutor ou de oficina nessa VU
(requisito 103 do anexo 1C).
recordType indica o tipo de registo (VuCardIWRecord). Valor atri­
buído: ver RecordType
recordSize: tamanho do VuCardIWRecord, em bytes.
noOfRecords: número de registos nos registos definidos.
records: conjunto de registos relativos aos ciclos de inserção e retirada
de cartões.
▼M1
2.179. VuCardRecord
Geração 2:
Informações memorizadas numa unidade-veículo sobre um cartão taco­
gráfico utilizado (requisito 132 do anexo IC).
cardNumberAndGenerationInformation refere-se ao número completo
do cartão e à geração do cartão utilizado (dados tipo 2.74).
cardExtendedSerialNumber lido no ficheiro EF_ICC sob o MF do
cartão.
cardStructureVersion lido no ficheiro EF_Application_Identification
sob o DF_Tachograph_G2.
cardNumber lido no ficheiro EF_Identification sob o DF_Tacho­
graph_G2.
▼B
2.180. VuCardRecordArray
Geração 2:
Informações memorizadas numa unidade-veículo sobre os cartões taco­
gráficos utilizados nesta VU. Estas informações destinam-se à análise de
problemas com cartões na VU (requisito 132 do anexo 1C).
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 195
recordType indica o tipo de registo (VuCardRecord). Valor atribuído:
ver RecordType
recordSize: tamanho do VuCardRecord, em bytes.
noOfRecords: número de registos nos registos definidos.
records: conjunto de registos relacionados com os cartões tacográficos
utilizados na VU.
2.181. VuCertificate
Certificado da chave pública de uma unidade-veículo.
2.182. VuCertificateRecordArray
Geração 2:
O certificado da VU, mais metadados utilizados no protocolo de
descarregamento.
recordType indica o tipo de registo (VuCertificate). Valor atribuído:
ver RecordType
recordSize: tamanho do VuCertificate, em bytes.
noOfRecords: número de registos nos registos definidos. O valor deve
ser fixado em 1, dado que os certificados podem ter diferentes
comprimentos.
records: conjunto de certificados da VU.
2.183. VuCompanyLocksData
Geração 1:
Informação memorizada numa unidade-veículo e relativa aos bloqueios
de uma empresa (requisito 104 do anexo 1B).
noOfLocks é o número de bloqueios que constam de VuCompany­
LocksRecords.
vuCompanyLocksRecords é o conjunto de registos de bloqueios da
empresa.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 196
2.184. VuCompanyLocksRecord
Informação memorizada numa unidade-veículo e relativa aos bloqueios
de uma empresa (requisito 104 do anexo 1B e requisito 128 do
anexo 1C).
Geração 1:
lockInTime, lockOutTime: data e hora de início do bloqueio e de
cessação do bloqueio.
companyName, companyAddress: nome e endereço da empresa rela­
cionada com o início do bloqueio.
companyCardNumber identifica o cartão utilizado no início do
bloqueio.
Geração 2:
Em vez de companyCardNumber, a estrutura de dados da geração 2
recorre à sequência do elemento de dados.
companyCardNumberAndGeneration identifica o cartão (incluindo a
sua geração) utilizado no início do bloqueio.
2.185. VuCompanyLocksRecordArray
Geração 2:
Informação memorizada numa unidade-veículo e relativa aos bloqueios
de uma empresa (requisito 128 do anexo 1C).
recordType indica o tipo de registo (VuCompanyLocksRecord). Valor
atribuído: ver RecordType
recordSize: tamanho do VuCompanyLocksRecord, em bytes.
noOfRecords: número de registos nos registos definidos. Valor 0, ...,
255.
records: conjunto de registos de bloqueios da empresa.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 197
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.
▼B
2.186. VuControlActivityData
Geração 1:
Informação memorizada numa unidade-veículo e relativa aos controlos
executados por meio da mesma (requisito 102 do anexo 1B).
noOfControls é o número de controlos que constam de vuControlAc­
tivityRecords.
vuControlActivityRecords: conjunto de registos da atividade de
controlo.
2.187. VuControlActivityRecord
Informação memorizada numa unidade-veículo e relativa aos controlos
executados por meio da mesma (requisito 102 do anexo 1B e requisito
126 do anexo 1C).
Geração 1:
controlType: tipo do controlo.
controlTime: data e hora do controlo.
controlCardNumber identifica o cartão de controlo utilizado para o
controlo.
downloadPeriodBeginTime: hora de início do período de eventual
descarregamento.
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 198
downloadPeriodEndTime: hora de final do período de eventual
descarregamento.
Geração 2:
Em vez de controlCardNumber, a estrutura de dados da geração 2
recorre à sequência do elemento de dados.
controlCardNumberAndGeneration identifica o cartão de controlo
(incluindo a sua geração) utilizado para o controlo.
2.188. VuControlActivityRecordArray
Geração 2:
Informação memorizada numa unidade-veículo e relativa aos controlos
executados por meio da mesma (requisito 126 do anexo 1C).
recordType indica o tipo de registo (VuControlActivityRecord). Valor
atribuído: ver RecordType
recordSize: tamanho do VuControlActivityRecord, em bytes.
noOfRecords: número de registos nos registos definidos.
records: conjunto de registos da atividade de controlo da VU.
2.189. VuDataBlockCounter
Contador memorizado num cartão e que identifica sequencialmente os
ciclos de inserção e retirada desse cartão em unidades-veículo.
Valor atribuído: número consecutivo, com o valor máximo de 9 999 e
a recomeçar em 0.
2.190. VuDetailedSpeedBlock
Informação memorizada numa unidade-veículo e relativa à velocidade
detalhada do veículo num minuto durante o qual o mesmo esteve em
movimento (requisito 093 do anexo 1B e requisito 116 do anexo 1C).
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 199
speedBlockBeginDate: data e hora do primeiro valor da velocidade no
bloco.
speedsPerSecond: sequência cronológica de velocidades medidas em
cada segundo, durante o minuto que começa em speedBlockBeginDate
(inclusive).
2.191. VuDetailedSpeedBlockRecordArray
Geração 2:
Informação memorizada numa unidade-veículo e relativa à velocidade
detalhada do veículo.
recordType indica o tipo de registo (VuDetailedSpeedBlock). Valor
atribuído
: ver RecordType
recordSize: tamanho do VuDetailedSpeedBlock, em bytes.
noOfRecords: número de registos nos registos definidos.
records: conjunto de blocos de velocidade detalhada.
2.192. VuDetailedSpeedData
Geração 1:
Informação memorizada numa unidade-veículo e relativa à velocidade
detalhada do veículo.
noOfSpeedBlocks: número de blocos de velocidade no conjunto vuDe­
tailedSpeedBlocks.
vuDetailedSpeedBlocks: conjunto de blocos de velocidade detalhada.
▼M3
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).
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 200
Valor atribuído: tal como especificado no sítio Web específico seguro
disponibilizado pela Comissão Europeia (requisito 133-K do anexo IC).
▼B
2.193. VuDownloadablePeriod
Datas mais antiga e mais recente relativamente às quais uma
unidade-veículo detém dados referentes às atividades dos condutores
(requisitos 081, 084 ou 087 do anexo 1B e requisitos 102, 105 e 108
do anexo 1C).
minDownloadableTime é a mais antiga data e hora de inserção do
cartão, de mudança de atividade ou de entrada de um local, memorizada
na VU.
maxDownloadableTime é a mais recente data e hora de retirada do
cartão, de mudança de atividade ou de entrada de um local, memorizada
na VU.
2.194. VuDownloadablePeriodRecordArray
Geração 2:
O VUDownloadablePeriod, mais metadados utilizados no protocolo de
descarregamento.
recordType indica o tipo de registo (VuDownloadablePeriod). Valor
atribuído: ver RecordType
recordSize: tamanho do VuDownloadablePeriod, em bytes.
noOfRecords: número de registos nos registos definidos.
records: conjunto dos registos VuDownloadablePeriod.
2.195. VuDownloadActivityData
Informação memorizada numa unidade-veículo e relativa ao seu último
descarregamento (requisito 105 do anexo 1B e requisito 129 do
anexo 1C).
Geração 1:
downloadingTime: data e hora do descarregamento.
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 201
fullCardNumber identifica o cartão utilizado para autorizar o
descarregamento.
companyOrWorkshopName: nome da empresa ou da oficina.
Geração 2:
Em vez de fullCardNumber, a estrutura de dados da geração 2 recorre à
sequência do elemento de dados.
fullCardNumberAndGeneration identifica o cartão (incluindo a sua
geração) utilizado para autorizar o descarregamento.
2.196. VuDownloadActivityDataRecordArray
Geração 2:
Informações relacionadas com o último descarregamento da VU (requi­
sito 129 do anexo 1C).
recordType indica o tipo de registo (VuDownloadActivityData). Valor
atribuído: ver RecordType
recordSize: tamanho do VuDownloadActivityData, em bytes.
noOfRecords: número de registos nos registos definidos.
records: conjunto de registos de descarregamento dos dados da
atividade.
2.197. VuEventData
Geração 1:
Informação memorizada numa unidade-veículo e relativa aos incidentes
(requisito 094 do anexo 1B, com exceção do incidente de excesso de
velocidade).
noOfVuEvents: número de incidentes que constam do conjunto vuE­
ventRecords.
vuEventRecords: conjunto de registos de incidentes.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 202
2.198. VuEventRecord
Informação memorizada numa unidade-veículo e relativa a um incidente
(requisito 094 do anexo 1B e requisito 117 do anexo 1C, com exceção
do incidente de excesso de velocidade).
Geração 1:
eventType: tipo de incidente.
eventRecordPurpose: objetivo pelo qual este incidente foi registado.
eventBeginTime: data e hora de início do incidente.
eventEndTime: data e hora de cessação do incidente.
cardNumberDriverSlotBegin identifica o cartão que se encontrava in­
serido na ranhura do condutor no momento em que o incidente teve
início.
cardNumberCodriverSlotBegin identifica o cartão que se encontrava
inserido na ranhura do ajudante no momento em que o incidente teve
início.
cardNumberDriverSlotEnd identifica o cartão que se encontrava inse­
rido na ranhura do condutor no momento em que terminou o incidente.
cardNumberCodriverSlotEnd identifica o cartão que se encontrava
inserido na ranhura do ajudante no momento em que terminou o
incidente.
similarEventsNumber: número de incidentes similares no dia em ques­
tão.
Esta sequência pode ser utilizada para quaisquer incidentes, com exce­
ção dos incidentes de excesso de velocidade.
Geração 2:
Utilizam-se os seguintes elementos de dados, além dos utilizados na
geração 1:
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 203
manufacturerSpecificEventFaultData contém informações adicionais,
específicas do fabricante sobre o incidente.
Em vez de cardNumberDriverSlotBegin, cardNumberCodriverSlotBe­
gin, cardNumberDriverSlotEnd e cardNumberCodriverSlotEnd, a estru­
tura de dados da geração 2 recorre aos seguintes elementos de dados:
cardNumberAndGenDriverSlotBegin identifica o cartão (incluindo a
sua geração) que se encontrava inserido na ranhura do condutor no
momento em que o incidente teve início.
cardNumberAndGenCodriverSlotBegin identifica o cartão (incluindo
a sua geração) que se encontrava inserido na ranhura do ajudante no
momento em que o incidente teve início.
cardNumberAndGenDriverSlotEnd identifica o cartão (incluindo a
sua geração) que se encontrava inserido na ranhura do condutor no
momento em que o incidente terminou.
cardNumberAndGenCodriverSlotEnd identifica o cartão (incluindo a
sua geração) que se encontrava inserido na ranhura do ajudante no
momento em que o incidente terminou.
Se o incidente for um conflito de tempo, eventBeginTime e eventEnd­
Time interpretam-se da seguinte forma:
eventBeginTime: data e hora do aparelho de controlo.
eventEndTime: data e hora do GNSS.
2.199. VuEventRecordArray
Geração 2:
Informação memorizada numa unidade-veículo e relativa aos incidentes
(requisito 117 do anexo 1C, com exceção do incidente de excesso de
velocidade).
recordType indica o tipo de registo (VuEventRecord). Valor atri­
buído: ver RecordType
recordSize: tamanho do VuEventRecord, em bytes.
noOfRecords: número de registos nos registos definidos.
records: conjunto de registos de incidentes.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 204
2.200. VuFaultData
Geração 1:
Informação memorizada numa unidade-veículo e relativa às falhas (re­
quisito 096 do anexo 1B).
noOfVuFaults: número de falhas que constam do conjunto vuFaultRe­
cords.
vuFaultRecords: conjunto de registos de falhas.
2.201. VuFaultRecord
Informação memorizada numa unidade-veículo e relativa a uma falha
(requisito 096 do anexo 1B e requisito 118 do anexo 1C).
Geração 1:
faultType: tipo de falha no aparelho de controlo.
faultRecordPurpose: objetivo pelo qual esta falha foi registada.
faultBeginTime: data e hora de início da falha.
faultEndTime: data e hora de cessação da falha.
cardNumberDriverSlotBegin identifica o cartão que se encontrava in­
serido na ranhura do condutor no momento em que a falha teve início.
cardNumberCodriverSlotBegin identifica o cartão que se encontrava
inserido na ranhura do ajudante no momento em que a falha teve início.
cardNumberDriverSlotEnd identifica o cartão que se encontrava inse­
rido na ranhura do condutor no momento em que a falha terminou.
cardNumberCodriverSlotEnd identifica o cartão que se encontrava
inserido na ranhura do ajudante no momento em que a falha terminou.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 205
Geração 2:
Utiliza-se o seguinte elemento de dados, além dos utilizados na gera­
ção 1:
manufacturerSpecificEventFaultData contém informações adicionais,
específicas do fabricante sobre a falha.
Em vez de cardNumberDriverSlotBegin, cardNumberCodriverSlotBe­
gin, cardNumberDriverSlotEnd e cardNumberCodriverSlotEnd, a estru­
tura de dados da geração 2 recorre aos seguintes elementos de dados:
cardNumberAndGenDriverSlotBegin identifica o cartão (incluindo a
sua geração) que se encontrava inserido na ranhura do condutor no
momento em que a falha teve início.
cardNumberAndGenCodriverSlotBegin identifica o cartão (incluindo
a sua geração) que se encontrava inserido na ranhura do ajudante no
momento em que a falha teve início.
cardNumberAndGenDriverSlotEnd identifica o cartão (incluindo a
sua geração), que se encontrava inserido na ranhura do condutor no
momento em que a falha terminou.
cardNumberAndGenCodriverSlotEnd identifica o cartão (incluindo a
sua geração) que se encontrava inserido na ranhura do ajudante no
momento em que a falha terminou.
2.202. VuFaultRecordArray
Geração 2:
Informação memorizada numa unidade-veículo e relativa às falhas (re­
quisito 118 do anexo 1C).
recordType indica o tipo de registo (VuFaultRecord). Valor atribuído:
ver RecordType
recordSize: tamanho do VuFaultRecord, em bytes.
noOfRecords: número de registos nos registos definidos.
records: conjunto de registos da falhas.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 206
2.203. VuGNSSADRecord
▼M3
Geração 2, versão 1:
▼M1
Informação memorizada numa unidade-veículo e relativa à posição
GNSS do veículo, se o tempo de condução acumulado atingir um
múltiplo de três horas (requisitos 108 e 110 do anexo IC).
timeStamp é a data e hora em que o tempo de condução acumulado
atinge um múltiplo de três horas.
cardNumberAndGenDriverSlot identifica o cartão (incluindo a sua
geração) que se encontrava inserido na ranhura do condutor.
cardNumberAndGenCodriverSlot identifica o cartão (incluindo a sua
geração) que se encontrava inserido na ranhura do ajudante.
gnssPlaceRecord contém informação relacionada com a posição do
veículo.
vehicleOdometerValue é o valor do conta-quilómetros no momento em
que o tempo de condução acumulado atinge um múltiplo de três horas.
▼M3
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 auten­
ticação.
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).
▼M1
02016R0799 — PT — 21.08.2023 — 003.002 — 207
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.
▼M1
2.204. VuGNSSADRecordArray
Geração 2:
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 208
Informação memorizada numa unidade-veículo e relativa à posição
GNSS do veículo, se o tempo de condução acumulado atingir um
múltiplo de três horas (requisitos 108 e 110 do anexo IC).
recordType indica o tipo de registo (VuGNSSADRecord).
Valor atribuído: Cf. RecordType.
recordSize: tamanho do VuGNSSADRecord, em bytes.
noOfRecords: número de registos nos registos definidos.
records: conjunto de registos GNSS da condução acumulada.
▼M3
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.
▼B
2.205. VuIdentification
Informação memorizada numa unidade-veículo e relativa à identificação
da mesma (requisito 075 do anexo 1B e requisitos 93 e 121 do
anexo 1C).
Geração 1:
vuManufacturerName: nome do fabricante da unidade-veículo.
vuManufacturerAddress: endereço do fabricante da unidade-veículo.
vuPartNumber: número de peça da unidade-veículo.
vuSerialNumber: número de série da unidade-veículo.
▼M1
02016R0799 — PT — 21.08.2023 — 003.002 — 209
vuSoftwareIdentification identifica o software implantado na
unidade-veículo.
vuManufacturingDate: data de fabrico da unidade-veículo.
vuApprovalNumber: número de homologação de tipo da
unidade-veículo.
▼M3
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).
▼B
2.206. VuIdentificationRecordArray
Geração 2:
A VuIdentification, mais metadados utilizados no protocolo de
descarregamento.
recordType indica o tipo de registo (VuIdentification). Valor atri­
buído: ver RecordType
recordSize: tamanho do VuIdentification, em bytes.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 210
noOfRecords: número de registos nos registos definidos.
records: conjunto de registos VuIdentification.
2.207. VuITSConsentRecord
Geração 2:
Informações memorizadas numa unidade-veículo e relativas ao consen­
timento de um condutor para a utilização de sistemas de transporte
inteligentes.
cardNumberAndGen identifica o cartão, incluindo a sua geração. O
cartão deve ser de condutor ou de oficina.
consent: marcador que indica se o condutor deu o seu consentimento
para a utilização de sistemas de transporte inteligentes neste veículo/
/unidade-veículo.
Valor atribuído:
TRUE indica o consentimento do condutor para a utiliza­
ção de sistemas de transporte inteligentes.
FALSE indica a recusa do condutor em utilizar sistemas de
transporte inteligentes.
2.208. VuITSConsentRecordArray
Geração 2:
Informações memorizadas numa unidade-veículo e relativas ao consen­
timento do condutor para a utilização de sistemas de transporte inteli­
gentes (requisito 200 do anexo 1C).
recordType indica o tipo de registo (VuITSConsentRecord). Valor atri­
buído: ver RecordType
recordSize: tamanho do VuITSConsentRecord, em bytes.
noOfRecords: número de registos nos registos definidos.
records: conjunto de registos de consentimento de ITS.
▼M3
2.208-A. VuLoadUnloadRecord
Geração 2, versão 2:
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 211
Informação memorizada na unidade-veículo relativa à operação de
carga/descarga introduzida (requisitos 133-E, 133-F e 133-G do ane­
xo 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.
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 212
2.209. VuManufacturerAddress
Endereço do fabricante da unidade-veículo.
Valor atribuído: não especificado.
2.210. VuManufacturerName
Nome do fabricante da unidade-veículo.
Valor atribuído: não especificado.
2.211. VuManufacturingDate
Data de fabrico da unidade-veículo.
Valor atribuído: não especificado.
2.212. VuOverSpeedingControlData
Informação memorizada numa unidade-veículo e relativa a incidentes de
excesso de velocidade desde o último controlo (requisito 095 do
anexo 1B e requisito 117 do anexo 1C).
lastOverspeedControlTime: data e hora do último controlo do excesso
de velocidade.
firstOverspeedSince: data e hora do primeiro excesso de velocidade
desde aquele controlo.
numberOfOverspeedSince: número de incidentes de excesso de velo­
cidade desde o último controlo do excesso de velocidade.
2.213. VuOverSpeedingControlDataRecordArray
Geração 2:
O VuOverSpeedingControlData, mais metadados utilizados no proto­
colo de descarregamento.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 213
recordType indica o tipo de registo (VuOverSpeedingControlData).
Valor atribuído: ver RecordType
recordSize: tamanho do VuOverSpeedingControlData, em bytes.
noOfRecords: número de registos nos registos definidos.
records: conjunto dos registos de dados do controlo do excesso de
velocidade.
2.214. VuOverSpeedingEventData
Geração 1:
Informação memorizada numa unidade-veículo e relativa a incidentes de
excesso de velocidade (requisito 094 do anexo 1B).
noOfVuOverSpeedingEvents: número de incidentes que constam do
conjunto vuOverSpeedingEventRecords.
vuOverSpeedingEventRecords: conjunto de registos de incidentes de
excesso de velocidade.
2.215. VuOverSpeedingEventRecord
▼C2
Geração 1:
Informação memorizada numa unidade-veículo e relativa a incidentes de
excesso de velocidade (requisito 094 do anexo 1B e requisito 117 do
anexo 1C).
eventType: tipo de incidente.
eventRecordPurpose: objetivo pelo qual este incidente foi registado.
eventBeginTime: data e hora de início do incidente.
eventEndTime: data e hora de cessação do incidente.
maxSpeedValue: velocidade máxima medida durante o incidente.
averageSpeedValue: média aritmética da velocidade medida durante o
incidente.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 214
cardNumberDriverSlotBegin: identifica o cartão que se encontrava
inserido na ranhura do condutor no momento em que o incidente teve
início.
similarEventsNumber: número de incidentes similares no dia em ques­
tão.
Geração 2:
Informação memorizada numa unidade-veículo e relativa a incidentes de
excesso de velocidade (requisito 094 do anexo 1B e requisito 117 do
anexo 1C).
Em vez de cardNumberDriverSlotBegin, a estrutura de dados da gera­
ção 2 recorre ao seguinte elemento de dados:
cardNumberAndGenDriverSlotBegin: identifica o cartão, incluindo a
respetiva geração, que está inserido na ranhura do condutor no início do
incidente.
▼B
2.216. VuOverSpeedingEventRecordArray
Geração 2:
Informação memorizada numa unidade-veículo e relativa a incidentes de
excesso de velocidade (requisito 117 do anexo 1C).
recordType indica o tipo de registo (VuOverSpeedingEventRecord).
Valor atribuído: ver RecordType
recordSize: tamanho do VuOverSpeedingEventRecord, em bytes.
noOfRecords: número de registos nos registos definidos.
records: conjunto de registos de incidentes de excesso de velocidade.
2.217. VuPartNumber
Número de peça da unidade-veículo.
Valor atribuído: específico do fabricante da VU.
▼C2
02016R0799 — PT — 21.08.2023 — 003.002 — 215
2.218. VuPlaceDailyWorkPeriodData
Geração 1:
Informação memorizada numa unidade-veículo e relativa aos locais
onde os condutores iniciam ou terminam um período de trabalho diário
(requisito 087 do anexo 1B e requisitos 108 e 110 do anexo 1C).
noOfPlaceRecords é o número de registos que constam do conjunto
vuPlaceDailyWorkPeriodRecords.
vuPlaceDailyWorkPeriodRecords: conjunto de registos relativos à lo­
calização.
2.219. VuPlaceDailyWorkPeriodRecord
Geração 1:
Informação memorizada numa unidade-veículo e 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).
fullCardNumber: tipo, Estado-Membro emissor e número do cartão do
condutor.
placeRecord contém a informação relativa ao local introduzido.
▼M3
Geração 2, versão 1:
▼B
Informação memorizada numa unidade-veículo e 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 fullCardNumber, a estrutura de dados da geração 2 recorre
ao seguinte elemento de dados:
fullCardNumberAndGeneration: tipo, Estado-Membro emissor, nú­
mero e geração do cartão, nele memorizados.
▼M3
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).
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 216
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.
▼B
2.220. VuPlaceDailyWorkPeriodRecordArray
Geração 2:
Informação memorizada numa unidade-veículo e relativa aos locais
onde os condutores iniciam ou terminam um período de trabalho diário
(requisitos 108 e 110 do anexo 1C).
recordType indica o tipo de registo (VuPlaceDailyWorkPeriodRecord).
Valor atribuído: ver RecordType
recordSize: tamanho do VuPlaceDailyWorkPeriodRecord, em bytes.
noOfRecords: número de registos nos registos definidos.
records: conjunto de registos relativos à localização.
2.221. VuPrivateKey
Geração 1:
A chave privada de uma unidade-veículo.
2.222. VuPublicKey
Geração 1:
A chave pública de uma unidade-veículo.
▼M3
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.
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 217
2.223. VuSerialNumber
O número de série da unidade-veículo (requisito 075 do anexo 1B e
requisito 93 do anexo 1C).
2.224. VuSoftInstallationDate
Data de instalação da versão de software na unidade-veículo.
Valor atribuído: não especificado.
2.225. VuSoftwareIdentification
Informação memorizada numa unidade-veículo e relativa ao software
nela instalado.
vuSoftwareVersion: número da versão do software da unidade-veículo.
vuSoftInstallationDate: data de instalação da versão de software.
2.226. VuSoftwareVersion
Número da versão de software da unidade-veículo.
Valor atribuído: não especificado.
2.227. VuSpecificConditionData
Geração 1:
Informação memorizada numa unidade-veículo e relativa às condições
especiais.
noOfSpecificConditionRecords: número de registos que constam do
conjunto specificConditionRecords.
specificConditionRecords: conjunto de registos relativos às condições
especiais.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 218
2.228. VuSpecificConditionRecordArray
Geração 2:
Informação memorizada numa unidade-veículo e relativa às condições
especiais (requisito 130 do anexo 1C).
recordType indica o tipo de registo (SpecificConditionRecord). Valor
atribuído: ver RecordType
recordSize: tamanho do SpecificConditionRecord, em bytes.
noOfRecords: número de registos nos registos definidos.
records: conjunto de registos relativos às condições especiais.
2.229. VuTimeAdjustmentData
Geração 1:
Informação memorizada numa unidade-veículo e relativa aos ajustamen­
tos do tempo executados fora do âmbito de uma calibração regular
(requisito 101 do anexo 1B).
noOfVuTimeAdjRecords: número de registos em vuTimeAdjustmen­
tRecords.
vuTimeAdjustmentRecords: conjunto de registos de ajustamento do
tempo.
▼M1
2.230. Reservado para utilização futura
2.231. Reservado para utilização futura
▼B
2.232. VuTimeAdjustmentRecord
Informação memorizada numa unidade-veículo e relativa a um ajusta­
mento do tempo executado fora do âmbito de uma calibração regular
(requisito 101 do anexo 1B e requisitos 124 e 125 do anexo 1C).
Geração 1:
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 219
oldTimeValue e newTimeValue: valores antigo e novo da data e da
hora.
workshopName e workshopAddress: nome e endereço da oficina.
workshopCardNumber identifica o cartão de oficina utilizado para
efetuar o ajustamento do tempo.
Geração 2:
Em vez de workshopCardNumber, a estrutura de dados da geração 2
recorre à sequência do elemento de dados.
workshopCardNumberAndGeneration identifica o cartão de oficina
(incluindo a sua geração) utilizado para executar o ajustamento do
tempo.
2.233. VuTimeAdjustmentRecordArray
Geração 2:
Informação memorizada numa unidade-veículo e relativa aos ajustamen­
tos do tempo executados fora do âmbito de uma calibração regular
(requisitos 124 e 125 do anexo 1C).
recordType indica o tipo de registo (VuTimeAdjustmentRecord). Va­
lor atribuído: ver RecordType
recordSize: tamanho do VuTimeAdjustmentRecord, em bytes.
noOfRecords: número de registos nos registos definidos.
records: conjunto de registos do ajustamento do tempo.
2.234. WorkshopCardApplicationIdentification
Informação memorizada num cartão de oficina e relativa à identificação
da aplicação do cartão (requisitos 307 e 330 do anexo 1C).
Geração 1:
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 220
typeOfTachographCardId especifica o tipo de cartão aplicado.
cardStructureVersion especifica a versão da estrutura aplicada no car­
tão.
noOfEventsPerType: número de incidentes, por tipo, que o cartão pode
registar.
noOfFaultsPerType: número de falhas, por tipo, que o cartão pode
registar.
activityStructureLength indica o número de bytes disponíveis para
memorizar registos de atividade.
noOfCardVehicleRecords: número de registos de veículo que o cartão
pode conter.
noOfCardPlaceRecords: número de locais que o cartão pode registar.
noOfCalibrationRecords: número de registos de calibração que o car­
tão pode memorizar.
Geração 2:
▼M1
Utilizam-se os seguintes elementos de dados, além dos utilizados na
geração 1:
noOfGNSSADRecords é o número de registos GNSS de condução
acumulados que o cartão pode memorizar.
noOfSpecificConditionRecords é o número dos registos de condição
especial que o cartão pode memorizar.
noOfCardVehicleUnitRecords é o número de registos de utilização de
unidades-veículo que o cartão pode memorizar.
▼M3
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).
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 221
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 taco­
grá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 adi­
cionais (ou seja, tipo de carga por defeito) introduzidos durante uma
calibração (requisito 356l do anexo IC).
calibrationPointerNewestRecord é o índice do último registo atuali­
zado 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).
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 222
oldTimeValue é o valor da data e hora antigos contido no Works­
hopCardCalibrationRecord 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 uti­
lizada para determinar este país foi transmitida pelo recetor GNSS.
▼B
2.235. WorkshopCardCalibrationData
Informação memorizada num cartão de oficina e relativa à atividade
dessa oficina, executada com o cartão (requisitos 314, 316, 337 e 339
do anexo 1C).
calibrationTotalNumber: número total de calibrações efetuadas com o
cartão.
calibrationPointerNewestRecord: índice do último registo atualizado
de calibração.
Valor atribuído: número correspondente ao numerador do registo de
calibração, a começar por «0» à primeira ocorrência de registos de
calibração na estrutura.
calibrationRecords: conjunto de registos que contêm informação rela­
tiva a calibração e/ou a ajustamento do tempo.
2.236. WorkshopCardCalibrationRecord
Informação memorizada num cartão de oficina e relativa a uma cali­
bração efetuada com esse cartão (requisitos 314 e 337 do anexo 1C).
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 223
Geração 1:
calibrationPurpose: objetivo da calibração.
vehicleIdentificationNumber: VIN.
vehicleRegistration contém o VRN e o Estado-Membro de matrícula.
wVehicleCharacteristicConstant: coeficiente característico do veículo.
kConstantOfRecordingEquipment: constante do aparelho de controlo.
lTyreCircumference: perímetro efetivo dos pneus das rodas.
tyreSize: designação das dimensões dos pneus montados no veículo.
authorisedSpeed: velocidade máxima autorizada para o veículo.
oldOdometerValue, newOdometerValue: valores antigo e novo do
conta-quilómetros.
oldTimeValue, newTimeValue: valores antigo e novo da data e da
hora.
nextCalibrationDate: data da próxima calibração do tipo especificado
em CalibrationPurpose, a efetuar pela autoridade responsável pela ins­
peção.
vuPartNumber, vuSerialNumber e sensorSerialNumber: elementos
de dados relativos à identificação do aparelho de controlo.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 224
Geração 2:
Utilizam-se os seguintes elementos de dados, além dos utilizados na
geração 1:
sensorGNSSSerialNumber identifica um módulo GNSS externo.
rcmSerialNumber identifica um módulo de comunicação à distância.
sealDataCard fornece informações sobre os selos que estão ligados a
diferentes componentes do veículo.
2.237. WorkshopCardHolderIdentification
Informação memorizada num cartão de oficina e relativa à identificação
do titular do cartão (requisitos 311 e 334 do anexo 1C).
workshopName é o nome da oficina do titular do cartão.
workshopAddress é o endereço da oficina do titular do cartão.
cardHolderName é o apelido e o nome próprio do titular (p. ex., o
nome do mecânico).
cardHolderPreferredLanguage é o idioma preferencial do titular do
cartão.
2.238. WorkshopCardPIN
Número de identificação pessoal do cartão de oficina (requisitos 309 e
332 do anexo 1C).
Valor atribuído: O PIN conhecido pelo titular do cartão, preenchido à
direita com bytes «FF» até um máximo de 8 bytes.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 225
2.239. W-VehicleCharacteristicConstant
Coeficiente característico do veículo [definição k)].
Valor atribuído: Impulsos por quilómetro no intervalo operacional de 0
a 64 255 impulsos/km.
2.240. VuPowerSupplyInterruptionRecord
Geração 2:
Informação memorizada numa unidade-veículo e relativa a incidentes de
interrupção da alimentação elétrica (requisito 117 do anexo 1C).
eventType: tipo do incidente.
eventRecordPurpose: objetivo pelo qual este incidente foi registado.
eventBeginTime: data e hora de início do incidente.
eventEndTime: data e hora de cessação do incidente.
cardNumberAndGenDriverSlotBegin identifica o cartão (incluindo a
sua geração) inserido na ranhura do condutor, no início do incidente.
cardNumberAndGenDriverSlotEnd identifica o cartão (incluindo a
sua geração) inserido na ranhura do condutor, no final do incidente.
cardNumberAndGenCodriverSlotBegin identifica o cartão (incluindo
a sua geração) inserido na ranhura do ajudante, no início do incidente.
cardNumberAndGenCodriverSlotEnd identifica o cartão (incluindo a
sua geração) inserido na ranhura do ajudante, no final do incidente.
similarEventsNumber: número de incidentes similares no dia em ques­
tão.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 226
2.241. VuPowerSupplyInterruptionRecordArray
Geração 2:
Informação memorizada numa unidade-veículo e relativa a incidentes de
interrupção da alimentação elétrica (requisito 117 do anexo 1C).
recordType indica o tipo de registo (VuPowerSupplyInterruptionRe­
cord). Valor atribuído: ver RecordType
recordSize: tamanho do VuPowerSupplyInterruptionRecord, em bytes.
noOfRecords: número de registos nos registos definidos.
records: conjunto de registos de incidentes de interrupção da alimenta­
ção elétrica.
2.242. VuSensorExternalGNSSCoupledRecordArray
Geração 2:
Conjunto de SensorExternalGNSSCoupledRecord, mais metadados uti­
lizados no protocolo de descarregamento.
recordType indica o tipo de registo (SensorExternalGNSSCoupledRe­
cord). Valor atribuído: ver RecordType
recordSize: tamanho do SensorExternalGNSSCoupledRecord, em
bytes.
noOfRecords: número de registos nos registos definidos.
records: conjunto de registos de Sensor External GNSS Coupled.
2.243. VuSensorPairedRecordArray
Geração 2:
Conjunto de SensorPairedRecord, mais metadados utilizados no proto­
colo de descarregamento.
recordType indica o tipo de registo (SensorPairedRecord). Valor atri­
buído: ver RecordType
recordSize: tamanho do SensorPairedRecord, em bytes.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 227
noOfRecords: número de registos nos registos definidos.
records: conjunto de registos do sensor emparelhado.
3. DEFINIÇÕES DOS VALORES E DOS INTERVALOS DE DIMEN­
SÃO
Definição dos valores variáveis utilizados nas definições da secção 2
deste apêndice.
4. CONJUNTOS DE CARATERES
IA5Strings utiliza os carateres ASCII definidos na norma ISO/
/IEC 8824-1. Por uma questão de legibilidade e de mais fácil referência,
indica-se abaixo a atribuição de valor. Na eventualidade de discrepân­
cia, a norma ISO/IEC 8824-1 prevalece sobre esta nota informativa.
Outras «character strings» ou cadeias de carateres (Address, Name,
VehicleRegistrationNumber) utilizam, adicionalmente, os carateres da
gama de códigos de carateres decimais de 161-255 dos seguintes con­
juntos de carateres normalizados de 8 bits, especificados pelo número de
página de código (Code Page):
Conjunto de carateres normalizado
Página de código
(decimal)
ISO/IEC 8859-1 Latim-1 Europa Ocidental 1
ISO/IEC 8859-2 Latim-2 Europa Central 2
ISO/IEC 8859-3 Latim-3 Europa Meridional 3
ISO/IEC 8859-5 Latim/Cirílico 5
ISO/IEC 8859-7 Latim/Grego 7
ISO/IEC 8859-9 Latim-5 Turco 9
ISO/IEC 8859-13 Latim-7 Báltico 13
ISO/IEC 8859-15 Latim-9 15
ISO/IEC 8859-16 Latim-10 Sudeste da Europa 16
KOI8-R Latim/Cirílico 80
KOI8-U Latim/Cirílico 85
5. CODIFICAÇÃO
Se a sua codificação for feita segundo as regras ASN.1, os tipos de
dados definidos devem ser codificados em conformidade com a norma
ISO/IEC 8825-2, variante alinhada.
6. IDENTIFICADORES DE OBJETO E IDENTIFICADORES DE APLI­
CAÇÃO
6.1. Identificadores de objeto
Os identificadores de objeto (OID) que constam do presente capítulo têm impor­
tância apenas para a geração 2. São especificados na orientação técnica TR-03110-
-3 e repetidos aqui por uma questão de exaustividade. Estão contidos na
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 228
subárvore de bsi-de:
Identificadores de protocolo de autenticação da VU
Exemplo: Supondo que a autenticação da VU deve ser efetuada com
SHA-384, o identificador do objeto a utilizar é (na notação ASN.1)
. O valor deste
identificador do objeto na notação de ponto é
.
Notação de ponto Notação de byte
«04 00 7F 00 07 02 02 02 02 03»
«04 00 7F 00 07 02 02 02 02 04»
«04 00 7F 00 07 02 02 02 02 05»
Identificadores de protocolo de autenticação da pastilha
Exemplo: Supondo que a autenticação da pastilha deve ser efetuada
utilizando o algoritmo ECDH, tal resulta num comprimento de
chave de sessão AES de 128 bits. Esta chave de sessão será
posteriormente utilizada no modo CBC de funcionamento para
garantir a confidencialidade de dados e com o algoritmo CMAC
para garantir a autenticidade dos dados. Por conseguinte, o iden­
tificador do objeto a utilizar é (na notação ASN.1)
. O valor
deste identificador do objeto na notação de ponto é
.
Notação de ponto Notação de byte
«04 00 7F 00 07 02 02 03 02 02»
«04 00 7F 00 07 02 02 03 02 03»
«04 00 7F 00 07 02 02 03 02 04»
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 229
6.2. Identificadores da aplicação
Geração 2:
O identificador de aplicação (AID) para o módulo GNSS externo (ge­
ração 2) é dado por «FF 44 54 45 47 4D». Este é um AID de pro­
prietário, em conformidade com a norma ISO/IEC 7816-4.
Nota: Os últimos 5 bytes codificam DTEGM para o módulo GNSS
externo dos tacógrafos inteligentes.
O identificador de aplicação para a aplicação do cartão tacográfico da
geração 2 é dado por «FF 53 4D 52 44 54». Este é um AID de
proprietário, em conformidade com a norma ISO/IEC 7816-4.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 230
Apêndice 2
ESPECIFICAÇÕES APLICÁVEIS AOS CARTÕES TACOGRÁFICOS
ÍNDICE
1. INTRODUÇÃO
1.1. Abreviaturas
1.2. Referências
2. CARACTERÍSTICAS ELÉTRICAS E FÍSICAS
2.1. Tensão de alimentação e consumo elétrico
2.2. Tensão de programação V pp
2.3. Geração e frequência do relógio
2.4. Contacto I/O
2.5. Estados do cartão
3. EQUIPAMENTO INFORMÁTICO E COMUNICAÇÃO
3.1. Introdução
3.2. Protocolo de transmissão
3.2.1 Protocolos
3.2.2 ATR
3.2.3 PTS
3.3. Regras de acesso
3.4. Descrição de comandos e códigos de erro
3.5. Descrição dos comandos
3.5.1 SELECT
3.5.2 READ BINARY
3.5.3 UPDATE BINARY
3.5.4 GET CHALLENGE
3.5.5 VERIFY
3.5.6 GET RESPONSE
3.5.7 PSO: VERIFY CERTIFICATE
3.5.8 INTERNAL AUTHENTICATE
3.5.9 EXTERNAL AUTHENTICATE
3.5.10 GENERAL AUTHENTICATE
3.5.11 MANAGE SECURITY ENVIRONMENT
3.5.12 PSO: HASH
3.5.13 PERFORM HASH of FILE
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 231
3.5.14 PSO: COMPUTE DIGITAL SIGNATURE
3.5.15 PSO: VERIFY DIGITAL SIGNATURE
3.5.16 PROCESS DSRC MESSAGE
4. ESTRUTURA DOS CARTÕES TACOGRÁFICOS
4.1. Ficheiro principal MF
4.2. Aplicações para cartão de condutor
4.2.1 Aplicação para cartão de condutor da geração 1
4.2.2 Aplicação para cartão de condutor da geração 2
4.3. Aplicações para cartão de oficina
4.3.1 Aplicação para cartão de oficina da geração 1
4.3.2 Aplicação para cartão de oficina da geração 2
4.4. Aplicações para cartão de controlo
4.4.1 Aplicação para cartão de controlo da geração 1
4.4.2 Aplicação para cartão de controlo da geração 2
4.5. Aplicações para cartão de empresa
4.5.1 Aplicação para cartão de empresa da geração 1
4.5.2 Aplicação para cartão de empresa da geração 2
1. INTRODUÇÃO
1.1. Abreviaturas
Para efeitos do presente apêndice, aplicam-se as seguintes
abreviaturas:
AC Condições de acesso
AES Norma avançada de cifragem
AID Identificador de aplicação
ALW Sempre
APDU Unidade de dados do protocolo de uma aplicação (estru­
tura de um comando)
ATR Answer To Reset
AUT Autenticado
C6, C7 Contactos n. os 6 e 7 do cartão conforme norma ISO/IEC
7816-2
CC Ciclos do relógio
▼M1
CHA Autorização do titular do certificado
▼B
CHV Informação sobre a verificação do titular do cartão
CLA Byte de classe de um comando APDU
▼M1
DO Objeto de dados
▼B
DSRC Comunicações dedicadas de curto alcance
DF Ficheiro dedicado; um DF pode conter outros ficheiros
(EF ou DF)
ECC Criptografia de curva elíptica
EF Ficheiro elementar
etu Unidade elementar de tempo
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 232
G1 Geração 1
G2 Geração 2
IC Circuito integrado
ICC Cartão com circuito integrado
ID Identificador
IFD Dispositivo de interface
IFS Dimensão do campo de informação
IFSC Dimensão do campo de informação para o cartão
IFSD Dispositivo de dimensão do campo de informação (para o
terminal)
INS Byte de instrução de um comando APDU
Lc Comprimento dos dados de entrada de um comando
APDU
Le Comprimento dos dados esperados (dados de saída para
um comando)
MF Ficheiro principal (DF raiz)
NAD Endereço de nó utilizado no protocolo T=1
NEV Nunca
P1-P2 Bytes de parâmetro
PIN Número de identificação pessoal
PRO SM Protegido com envio seguro de mensagens
PTS Seleção de transmissão de um protocolo
RFU Reservado para utilização futura
RST Reinicialização (do cartão)
SFID Identificador EF curto
SM Envio seguro de mensagens
SW1-SW2 Bytes de estatuto ou de situação
TS Caráter inicial de ATR
VPP Tensão de programação
VU Unidade-veículo
XXh Valor XX em notação hexadecimal
«XXh» Valor XX em notação hexadecimal
|| Símbolo de concatenação 03||04=0304
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 233
1.2. Referências
No presente apêndice, são utilizadas as seguintes referências:
ISO/IEC 7816-2 Identification cards — Integrated circuit cards —
Part 2: Dimensions and location of the contacts.
ISO/IEC 7816-2:2007.
ISO/IEC 7816-3 Identification cards — Integrated circuit cards —
Part 3: Electrical interface and transmission proto­
cols. ISO/IEC 7816-3:2006.
ISO/IEC 7816-4 Identification cards — Integrated circuit cards —
Part 4: Organization, security and commands for
interchange. ISO/IEC 7816-4:2013 + Cor 1: 2014.
ISO/IEC 7816-6 Identification cards — Integrated circuit cards —
Part 6: Interindustry data elements for interchange.
ISO/IEC 7816-6:2004 + Cor 1: 2006.
ISO/IEC 7816-8 Identification cards — Integrated circuit cards —
Part 8: Commands for security operations. ISO/IEC
7816-8:2004.
ISO/IEC 9797-2 Information technology — Security techniques —
Message Authentication Codes (MACs) — Part 2:
Mechanisms using a dedicated hash-function. ISO/
/IEC 9797-2:2011
2. CARACTERÍSTICAS ELÉTRICAS E FÍSICAS
TCS_01 Salvo especificação diversa, os sinais eletrónicos devem
cumprir o prescrito na norma ISO/IEC 7816-3.
TCS_02 A localização e as dimensões dos contactos do cartão de­
vem cumprir o prescrito na norma ISO/IEC 7816-2.
2.1. Tensão de alimentação e consumo elétrico
TCS_03 O cartão deve funcionar em conformidade com os limites
de consumo especificados na norma ISO/IEC 7816-3.
TCS_04 O cartão deve funcionar com Vcc = 3V (+/- 0,3V) ou com
Vcc = 5V (+/- 0,5V).
A seleção da tensão deve cumprir o prescrito na norma
ISO/IEC 7816-3.
2.2. Tensão de programação V pp
TCS_05 O cartão não deve carecer de tensão de programação no
pino C6. Espera-se que o pino C6 não esteja ligado a um
IFD. O contacto C6 pode ser ligado a V cc no cartão mas
não à terra. Esta tensão em caso nenhum deve ser
interpretada.
2.3. Geração e frequência do relógio
TCS_06 O cartão deve funcionar num alcance de frequência de 1 a
5 MHz, podendo aceitar frequências mais elevadas.
No âmbito de uma sessão de cartão, a frequência do relógio
pode variar ± 2 %. A frequência do relógio é gerada pela
unidade-veículo e não propriamente pelo cartão. O ciclo de
funcionamento pode variar entre 40 % e 60 %.
TCS_07 Nas condições contidas no ficheiro de cartão EF ICC, o
relógio exterior pode ser parado. O primeiro byte do corpo
do ficheiro EF ICC codifica as condições do modo Clocks­
top («paragem do relógio»):
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 234
Reduzido Elevado
Bit 3 Bit 2 Bit 1
0 0 1 Clockstop permitido, sem nível preferido
0 1 1 Clockstop permitido, preferido nível elevado
1 0 1 Clockstop permitido, preferido nível reduzido
0 0 0 Clockstop não permitido
0 1 0 Clockstop permitido somente no nível elevado
1 0 0 Clockstop permitido somente no nível reduzido
Os bits 4 a 8 não são utilizados.
2.4. Contacto I/O
TCS_08 O contacto I/O C7 é utilizado para receber dados do IFD e
transmitir-lhos. Durante o funcionamento apenas o cartão
ou o IFD estarão em modo de transmissão. Se ambas as
unidades estiverem em modo de transmissão, não ocorrerá
qualquer dano no cartão. Salvo se estiver a transmitir, o
cartão deve introduzir o modo de receção.
2.5. Estados do cartão
TCS_09 Enquanto lhe for aplicada a tensão de alimentação, o cartão
trabalha em dois estados:
▼M3
Estado de funcionamento durante a execução de comandos
ou ações de interface com a unidade-veículo,
▼B
Estado inativo em todas as outras ocasiões; neste estado, o
cartão reterá todos os dados.
3. EQUIPAMENTO INFORMÁTICO E COMUNICAÇÃO
3.1. Introdução
Esta secção refere as condições mínimas de funcionalidade requeridas
pelos cartões tacográficos e pelas VU, para garantir funcionamento e
interoperabilidade corretos.
Os cartões tacográficos cumprem o mais rigorosamente possível as
normas ISO/IEC aplicáveis (com destaque para a ISO/IEC 7816). Os
comandos e protocolos são, no entanto, referidos na íntegra, para
especificar algumas utilizações restritas ou diferenças eventuais. Salvo
indicação em contrário, os comandos especificados cumprem integral­
mente as normas referidas.
3.2. Protocolo de transmissão
TCS_10 O protocolo de transmissão deve cumprir a norma ISO/IEC
7816-3 para T = 0 e T = 1. Em particular, a VU deve
reconhecer extensões de tempo de espera enviadas pelo
cartão.
3.2.1 Protocolos
TCS_11 O cartão deve proporcionar quer o protocolo T=0 quer o
protocolo T=1. Além disso, é compatível com outros pro­
tocolos orientados para o contacto.
TCS_12 T=0 é o protocolo por defeito, pelo que é necessário um
comando PTS para o passar a T=1.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 235
TCS_13 Em ambos os protocolos haverá dispositivos de suporte a
«convenção direta»: a «convenção direta» é, pois, obriga­
tória para o cartão.
TCS_14 O byte presente no cartão que indica a dimensão do
campo de informação deve ser apresentado na ATR em
carateres TA3. Este valor será, pelo menos, «F0h» (= 240
bytes).
Aos protocolos aplicam-se as seguintes restrições:
TCS_15 T=0
— O dispositivo de interface deve ser compatível com uma
resposta em I/O depois da elevação do sinal em RST a
partir de 400 cc.
— O dispositivo de interface deve poder ler carateres se­
parados por 12 etu.
— O dispositivo de interface deve ler um caráter errado e a
sua repetição quando separados por 13 etu. Se for de­
tetado um caráter errado, o sinal de erro em I/O pode
ocorrer entre 1 etu e 2 etu. O dispositivo deve aceitar
um atraso de 1 etu.
— O dispositivo de interface deve aceitar uma ATR de 33
bytes (TS+32).
— Se na ATR estiver presente TC1, o Extra Guard Time
deve estar presente para carateres enviados pelo dispo­
sitivo de interface, embora os carateres enviados pelo
cartão possam estar ainda separados por 12 etu. O
mesmo se verifica relativamente ao caráter ACK en­
viado pelo cartão depois de um caráter P3 emitido
pelo dispositivo de interface.
— O dispositivo de interface deve ter em conta um caráter
NUL emitido pelo cartão.
— O dispositivo de interface deve aceitar o modo com­
plementar para ACK.
— O comando GET RESPONSE (obter resposta) não pode
ser utilizado em modo de encadeamento para obter um
dado com comprimento suscetível de exceder 255
bytes.
TCS_16 T=1
— Byte NAD: não utilizado (NAD deve ser colocado no
valor «00»).
— S-block ABORT: não utilizado.
— S-block VPP state error: não utilizado.
▼M3
__________
▼B
— O dispositivo de dimensão do campo de
informação (IFSD) deve ser indicado pelo IFD imedia­
tamente a seguir à ATR: o IFD transmite o pedido de
S-Block IFS a seguir à ATR, e o cartão devolve
S-Block IFS. O valor recomendado para o IFSD é de
254 bytes.
— O cartão não pede reajustamento da IFS.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 236
3.2.2 ATR
TCS_17 O dispositivo verifica os bytes da ATR, em conformidade
com a norma ISO/IEC 7816-3. Não é feita qualquer veri­
ficação aos carateres históricos da ATR.
Exemplo de biprotocolo ATR de base, em conformidade
com a norma ISO/IEC 7816-3
▼C2
Carater Valor Observações
TS «3Bh» Indica convenção direta.
T0 «85h» TD1 presente; 5 bytes históricos presentes.
TD1 «80h» TD2 presente; utilizar T = 0
TD2 «11h» TA3 presente; utilizar T = 1
TA3 «XXh» (pelo menos
«VF0h»)
Dimensão do campo de informação para o
cartão (IFSC)
TH1 a TH5 «XXh» Carateres históricos
TCK «XXh» Carater de controlo (OR exclusivo)
▼B
TCS_18 Depois de Answer To Reset [resposta à
reinicialização] (ATR), o ficheiro principal (MF) é implici­
tamente selecionado, tornando-se o diretório em curso.
3.2.3 PTS
TCS_19 O protocolo por defeito é T=0. Para obter o protocolo T=1,
o dispositivo deve enviar ao cartão uma PTS (também
conhecida como PPS).
TCS_20 Como ambos os protocolos T=0 e T=1 são obrigatórios
para o cartão, a PTS de base para a mudança de protocolo
é também obrigatória para o cartão.
Tal como indica a norma ISO/IEC 7816-3, a PTS pode ser
utilizada para passar a bauds mais elevados do que o de
defeito, eventualmente proposto pelo cartão na ATR [byte
TA(1)].
Bauds mais elevados são opcionais para o cartão.
TCS_21 Se somente o baud de defeito for aceite (ou se o baud
selecionado não for aceite), o cartão responderá correta­
mente à PTS, em conformidade com ISO/IEC 7816-3, omi­
tindo o byte PPS1.
Exemplos de PTS de base para seleção de protocolo:
▼C2
Carater Valor Observações
PPSS «FFh» Carater de iniciação.
PPS0 «00h» ou «01h» PPS1 a PPS3 não estão presentes; «00h» para selecionar
T0, «01h» para selecionar T1.
PK «XXh» Carater de controlo: «XXh» = «FFh» se PPS0 = «00h»,
«XXh» = «FEh» se PPS0 =
«01h».
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 237
3.3. Regras de acesso
TCS_22 Uma regra de acesso define os controlos de acesso corres­
pondentes para um modo de acesso, ou seja, comando. Se
os presentes controlos de acesso forem cumpridos, é pro­
cessado o comando correspondente.
TCS_23 No cartão tacográfico utilizam-se os controlos de acesso a
seguir indicados:
Abreviatura Significado
ALW A ação é sempre possível e pode ser executada sem qualquer restrição. A
APDU de comando e resposta é enviada em texto simples, ou seja, sem envio
seguro de mensagens.
NEV A ação nunca é possível.
PLAIN-C A APDU de comando é enviada em texto simples, ou seja, sem envio seguro
de mensagens.
PWD A ação só pode ser executada se o PIN do cartão da oficina tiver sido
verificado com êxito, ou seja, se estiver definido o estado de segurança
interna «PIN_Verified» do cartão. O comando deve ser enviado sem envio
seguro de mensagens.
EXT-AUT-G1 A ação só pode ser executada se o comando EXTERNAL AUTHENTICATE
para a autenticação da geração 1 (ver também apêndice 11, parte A) tiver sido
executado com êxito.
SM-MAC-G1 A APDU (comando e resposta) deve ser aplicada com o envio seguro de
mensagens da geração 1 no modo apenas de autenticação (ver apêndice 11,
parte A).
SM-C-MAC-G1 A APDU de comando deve ser aplicada com o envio seguro de mensagens da
geração 1 no modo só de autenticação (ver apêndice 11, parte A).
SM-R-ENC-G1 A APDU de resposta deve ser aplicada com o envio seguro de mensagens da
geração 1 no modo de encriptação (ver apêndice 11, parte A), ou seja,
nenhum código de autenticação de mensagem é devolvido.
SM-R-ENC-
-MAC-G1
A APDU de resposta deve ser aplicada com o envio seguro de mensagens da
geração 1 no modo encriptar depois autenticar (ver apêndice 11, parte A).
SM-MAC-G2 A APDU (comando e resposta) deve ser aplicada com o envio seguro de
mensagens da geração 2 no modo apenas de autenticação (ver apêndice 11,
parte B).
SM-C-MAC-G2 A APDU de comando deve ser aplicada com o envio seguro de mensagens da
geração 2 no modo só de autenticação (ver apêndice 11, parte B).
SM-R-ENC-
-MAC-G2
A APDU de resposta deve ser aplicada com o envio seguro de mensagens da
geração 2 no modo encriptar depois autenticar (ver apêndice 11, parte B).
▼M1
TCS_24 Estes controlos de acesso podem ser ligados das seguintes
formas:
E: Todos os controlos de acesso devem ser cumpridos
OU: Deve ser cumprido, pelo menos, um controlo de
acesso
As regras de acesso ao sistema de ficheiros, ou seja, os
comandos SELECT, READ BINARY e UPDATE BI­
NARY, são especificadas no capítulo 4. As regras de
acesso aos comandos restantes são especificadas nos qua­
dros seguintes. É utilizado o termo «não aplicável» sempre
que não houver requisito de apoio ao comando. Neste caso
o comando pode ou não ser apoiado, mas a condição de
acesso está fora de alcance.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 238
TCS_25 Na aplicação DF Tachograph G1 utilizam-se as seguintes
regras de acesso:
▼M1
Comando
Cartão de con­
dutor
Cartão de ofi­
cina
Cartão de con­
trolo
Cartão de em­
presa
EXTERNAL AUTHENTICATE
— Para autenticação da gera­
ção 1
ALW ALW ALW ALW
— Para autenticação da gera­
ção 2
ALW PWD ALW ALW
Internal Authenticate ALW PWD ALW ALW
General Authenticate ALW ALW ALW ALW
Get Challenge ALW ALW ALW ALW
MSE:SET AT ALW ALW ALW ALW
MSE:SET DST ALW ALW ALW ALW
Process DSRC Message Não aplicá­
vel
Não aplicá­
vel
Não aplicá­
vel
Não aplicável
PSO Compute Digital Signature ALW OR
SM-MAC-
-G2
ALW OR
SM-MAC-
-G2
Não aplicá­
vel
Não aplicável
PSO Hash Não aplicá­
vel
Não aplicá­
vel
ALW Não aplicável
PERFORM HASH OF FILE ALW OR
SM-MAC-
-G2
ALW OR
SM-MAC-
-G2
Não aplicá­
vel
Não aplicável
PSO VERIFY CERTIFICATE ALW ALW ALW ALW
PSO Verify Digital Signature Não aplicá­
vel
Não aplicá­
vel
ALW Não aplicável
Verify Não aplicá­
vel
ALW Não aplicá­
vel
Não aplicável
▼B
TCS_26 Na aplicação DF Tachograph G2 utilizam-se as seguintes
regras de acesso:
▼M1
Comando
Cartão de con­
dutor
Cartão de ofi­
cina
Cartão de con­
trolo
Cartão de em­
presa
EXTERNAL AUTHENTICATE
— Para autenticação da gera­
ção 1
Não aplicá­
vel
Não aplicá­
vel
Não aplicá­
vel
Não aplicável
— Para autenticação da gera­
ção 2
ALW PWD ALW ALW
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 239
Comando
Cartão de con­
dutor
Cartão de ofi­
cina
Cartão de con­
trolo
Cartão de em­
presa
Internal Authenticate Não aplicá­
vel
Não aplicá­
vel
Não aplicá­
vel
Não aplicável
General Authenticate ALW ALW ALW ALW
Get Challenge ALW ALW ALW ALW
MSE:SET AT ALW ALW ALW ALW
MSE:SET DST ALW ALW ALW ALW
Process DSRC Message Não aplicá­
vel
ALW ALW Não aplicável
PSO Compute Digital Signature ALW OR
SM-MAC-
-G2
ALW OR
SM-MAC-
-G2
Não aplicá­
vel
Não aplicável
PSO Hash Não aplicá­
vel
Não aplicá­
vel
ALW Não aplicável
PERFORM HASH OF FILE ALW OR
SM-MAC-
-G2
ALW OR
SM-MAC-
-G2
Não aplicá­
vel
Não aplicável
PSO VERIFY CERTIFICATE ALW ALW ALW ALW
PSO Verify Digital Signature Não aplicá­
vel
Não aplicá­
vel
ALW Não aplicável
Verify Não aplicá­
vel
ALW Não aplicá­
vel
Não aplicável
▼B
TCS_27 No MF utilizam-se as seguintes regras de acesso:
▼M1
Comando
Cartão de con­
dutor
Cartão de ofi­
cina
Cartão de con­
trolo
Cartão de em­
presa
EXTERNAL AUTHENTICATE
— Para autenticação da gera­
ção 1
Não aplicá­
vel
Não aplicá­
vel
Não aplicá­
vel
Não aplicável
— Para autenticação da gera­
ção 2
ALW PWD ALW ALW
Internal Authenticate Não aplicá­
vel
Não aplicá­
vel
Não aplicá­
vel
Não aplicável
General Authenticate ALW ALW ALW ALW
Get Challenge ALW ALW ALW ALW
MSE:SET AT ALW ALW ALW ALW
MSE:SET DST ALW ALW ALW ALW
▼M1
02016R0799 — PT — 21.08.2023 — 003.002 — 240
Comando
Cartão de con­
dutor
Cartão de ofi­
cina
Cartão de con­
trolo
Cartão de em­
presa
Process DSRC Message Não aplicá­
vel
Não aplicá­
vel
Não aplicá­
vel
Não aplicável
PSO Compute Digital Signature Não aplicá­
vel
Não aplicá­
vel
Não aplicá­
vel
Não aplicável
PSO Hash Não aplicá­
vel
Não aplicá­
vel
Não aplicá­
vel
Não aplicável
PERFORM HASH OF FILE Não aplicá­
vel
Não aplicá­
vel
Não aplicá­
vel
Não aplicável
PSO VERIFY CERTIFICATE ALW ALW ALW ALW
PSO Verify Digital Signature Não aplicá­
vel
Não aplicá­
vel
Não aplicá­
vel
Não aplicável
Verify Não aplicá­
vel
ALW Não aplicá­
vel
Não aplicável
▼B
TCS_28 Um cartão tacográfico pode ou não aceitar um comando
com nível de segurança superior ao especificado nos con­
trolos de acesso. Ou seja, se o controlo de acesso for ALW
(ou PLAIN-C), o cartão pode aceitar um comando com
envio seguro de mensagens (encriptação e/ou modo de au­
tenticação). Se o controlo de acesso exigir o envio seguro
de mensagens com modo de autenticação, o cartão tacográ­
fico pode aceitar um comando com envio seguro de men­
sagens da mesma geração no modo de autenticação e en­
criptação.
Nota: As descrições do comando fornecem informações
adicionais acerca do suporte dos comandos para os diferen­
tes tipos de cartões tacográficos e diferentes DF.
3.4. Descrição de comandos e códigos de erro
Os comandos e a organização dos ficheiros são deduzidos da norma
ISO/IEC 7816-4, à qual obedecem.
A presente secção incide nos pares comando-resposta de APDU infra.
Nas descrições do comando correspondentes, especificam-se as va­
riantes de comando compatíveis com uma aplicação das gerações 1
ou 2.
Comando INS
SELECT «A4h»
READ BINARY «B0h», «B1h»
UPDATE BINARY «D6h», «D7h»
GET CHALLENGE «84h»
VERIFY «20h»
GET RESPONSE «C0h»
▼M1
02016R0799 — PT — 21.08.2023 — 003.002 — 241
Comando INS
PERFORM SECURITY OPERA­
TION
«2Ah»
— VERIFY CERTIFICATE
— COMPUTE DIGITAL SIGNA­
TURE
— VERIFY DIGITAL SIGNA­
TURE
— HASH
— PERFORM HASH OF FILE
— PROCESS DSRC MESSAGE
INTERNAL AUTHENTICATE «88h»
EXTERNAL AUTHENTICATE «82h»
MANAGE SECURITY ENVIRON­
MENT
«22h»
— SET DIGITAL SIGNATURE
TEMPLATE
— SET AUTHENTICATION TEM­
PLATE
GENERAL AUTHENTICATE «86h»
▼M1
TCS_29 As palavras de estatuto ou situação SW1 e SW2 são emi­
tidas nas mensagens de resposta e denotam o estado de
processamento do comando.
SW1 SW2 Significado
90 00 Processamento normal
61 XX Processamento normal XX = número de bytes de resposta dispo­
níveis
62 81 Processamento de alerta. Possível corrupção de parte dos dados
devolvidos
63 00 Falha de autenticação (alerta)
63 CX CHV (PIN) errado. Contador de tentativas remanescentes forne­
cido por «X»
64 00 Erro de execução — Estado de memória não viva inalterado. Erro
de integridade
65 00 Erro de execução — Estado de memória não viva alterado
65 81 Erro de execução — Estado de memória não viva alterado —
Falha de memória
66 88 Erro de segurança: soma criptográfica de teste errada (durante
envio seguro de mensagens) ou
certificado errado (durante a verificação do
certificado) ou
criptograma errado (durante autenticação ex­
terna) ou
assinatura errada (durante a verificação de
assinatura)
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 242
SW1 SW2 Significado
67 00 Comprimento errado (Lc ou Le errados)
68 83 Último comando esperado da cadeia
69 00 Comando proibido (não há resposta disponível em T=0)
69 82 Estatuto de segurança não satisfeito
69 83 Método de autenticação bloqueado
69 85 Condições de utilização não satisfeitas
69 86 Comando não permitido (nenhum EF em curso)
69 87 Inexistentes os objetos de dados esperados do envio seguro de
mensagens
69 88 Incorretos os objetos de dados do envio seguro de mensagens
6A 80 Parâmetros incorretos no campo de dados
6A 82 Ficheiro não encontrado
6A 86 Parâmetros P1-P2 errados
6A 88 Dados referenciados não encontrados
6B 00 Parâmetros errados (deslocamento fora de EF)
6C XX Comprimento errado; SW2 indica o comprimento exato. Sem
devolução de campo de dados
6D 00 Código de instrução não aceite ou inválido
6E 00 Classe não aceite
6F 00 — Outros erros de verificação
Podem ser devolvidas palavras de estatuto adicionais con­
forme definido na ISO/IEC 7816-4, caso o seu comporta­
mento não seja expressamente referido no presente apên­
dice.
Por exemplo, podem ser eventualmente devolvidas as se­
guintes palavras de estatuto:
6881: Canal lógico não aceite
6882: Envio seguro de mensagens não aceite
▼B
TCS_30 Se num comando APDU estiver preenchida mais do que
uma condição de erro, o cartão pode devolver qualquer
uma das palavras de estatuto adequadas.
3.5. Descrição dos comandos
O presente capítulo incide nos comandos obrigatórios para os cartões
tacográficos.
O apêndice 11 (Mecanismos comuns de segurança para os tacógrafos
da geração 1 e da geração 2) indica elementos adicionais, com im­
portância para as operações criptográficas em causa.
Todos os comandos são descritos independentemente do protocolo
utilizado (T=0 ou T=1). Os bytes de APDU CLA, INS, P1, P2, Lc
e Le são sempre indicados. Se Lc ou Le não forem necessários para o
comando descrito, surgem em branco os respetivos valor, compri­
mento e descrição.
▼M1
02016R0799 — PT — 21.08.2023 — 003.002 — 243
TCS_31 Sendo pedidos ambos os bytes de comprimento (Lc e Le),
o comando descrito tem de ser dividido em duas partes se o
IFD utilizar o protocolo T=0: o IFD envia o comando tal
como descrito com P3=Lc+dados e, em seguida, envia um
comando GET RESPONSE (ver ponto 3.5.6) com P3=Le.
TCS_32 Sendo pedidos ambos os bytes de comprimento e Le=0
(envio seguro de mensagens):
— ao utilizar o protocolo T=1, o cartão responde a Le=0
enviando todos os dados de saída disponíveis;
— ao utilizar o protocolo T=0, o IFD envia o primeiro
comando com P3=Lc+dados e o cartão responde (a
este Le=0 implícito) pelos bytes de estatuto «61La»,
onde La é o número de bytes de resposta disponíveis.
O IFD gera então um comando GET RESPONSE com
P3=La para ler os dados.
TCS_33 Como recurso opcional, um cartão tacográfico pode aceitar
o aumento dos campos de comprimento em conformidade
com a norma ISO/IEC 7816-4. Um cartão tacográfico que
aceite o aumento dos campos de comprimento deve:
— Indicar o suporte do aumento do campo de compri­
mento na ATR;
— Fornecer as dimensões da margem de segurança aceites
por meio da informação do aumento do comprimento
na EF ATR/INFO (ver TCS_146);
— Indicar se aceita o aumento dos campos de compri­
mento para T=1 e/ou T=0 no aumento do comprimento
EF (ver TCS_147);
— Aceitar o aumento dos campos de comprimento para a
aplicação tacográfica das gerações 1 e 2.
Notas:
Todos os comandos são especificados para campos de com­
primento curto. A utilização de APDU de aumento do com­
primento decorre da norma ISO/IEC 7816-4.
De um modo geral, os comandos são especificados para o
modo normal, ou seja, sem envio seguro de mensagens, tal
como a camada do envio seguro de mensagens é especifi­
cada no apêndice 11. A partir das regras de acesso para um
comando, é evidente se o comando deve aceitar o envio
seguro de mensagens ou não e se o comando deve aceitar o
envio seguro de mensagens da geração 1 e/ou da geração 2.
Algumas variantes do comando são descritas com envio
seguro de mensagens para ilustrar a utilização do envio
seguro de mensagens.
TCS_34 A VU executa o protocolo total de autenticação mútua do
cartão da VU da geração 2 para uma sessão, incluindo a
verificação do certificado (quando necessário) quer no DF
Tachograph, no DF Tachograph_G2 ou no MF.
3.5.1 SELECT
Este comando cumpre a norma ISO/IEC 7816-4, mas tem uma utili­
zação restrita, em comparação com o comando definido na norma.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 244
O comando SELECT é utilizado para:
— selecionar uma aplicação DF (tem de se utilizar seleção por nome)
— selecionar um ficheiro elementar correspondente ao ID do ficheiro
apresentado
3.5.1.1 S e l e ç ã o p o r n o m e ( A I D )
Este comando permite selecionar um DF de aplicação no cartão.
TCS_35 Este comando pode ser executado a partir de qualquer
ponto na estrutura do ficheiro (depois da ATR ou em qual­
quer momento).
TCS_36 A seleção de uma aplicação reinicializa o ambiente de
segurança vigente. Depois de se selecionar a aplicação,
não volta a ser selecionada nenhuma chave pública vigente.
É igualmente perdida a condição de acesso EXT-AUT-G1.
Se o comando tiver sido executado sem o envio seguro de
mensagens, as antigas chaves de sessão do envio seguro de
mensagens deixam de estar disponíveis.
TCS_37 Mensagem de comando
Byte
Compri­
mento
Valor Descrição
CLA 1 «00h»
INS 1 «A4h»
P1 1 «04h» Seleção por nome (AID)
P2 1 «0Ch» Nenhuma resposta esperada
Lc 1 «NNh» Número de bytes enviados ao cartão (comprimento da
AID):
«06h» para a aplicação tacográfica
#6-#(5+NN) NN «XX..XXh» AID: «FF 54 41 43 48 4F» para a aplicação tacográfica
da geração 1
AID: «FF 53 4D 52 44 54» para a aplicação tacográfica
da geração 2
Não é necessária resposta ao comando SELECT (Le au­
sente em T=1 ou não é pedida resposta em T=0).
TCS_38 Mensagem de resposta (não é pedida resposta)
Byte
Compri­
mento
Valor Descrição
SW 2 «XXXXh» Palavras de estatuto (SW1, SW2)
— Se o comando for bem sucedido, o cartão devolve
«9000».
— Se a aplicação correspondente ao AID não for encon­
trada, o estado de processamento devolvido é «6A82».
— Em T=1, se o byte Le estiver presente, o estado devol­
vido é «6700».
— Em T=0, se for pedida uma resposta depois do co­
mando SELECT, o estado devolvido é «6900».
▼M1
— Se a aplicação selecionada for considerada corrompida
(o erro de integridade é detetado nos atributos do fi­
cheiro), o estado de processamento devolvido é «6400»
ou «6500».
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 245
3.5.1.2 S e l e ç ã o d e u m f i c h e i r o e l e m e n t a r u t i l i z a n d o o s e u
i d e n t i f i c a d o r d e f i c h e i r o
TCS_39 Mensagem de comando
TCS_40 Conforme especificado no apêndice 11, parte B, um cartão
tacográfico deve aceitar o envio seguro de mensagens da
geração 2 para esta variante de comando.
Byte
Compri­
mento
Valor Descrição
CLA 1 «00h»
INS 1 «A4h»
P1 1 «02h» Seleção de um EF sob o DF em curso
P2 1 «0Ch» Nenhuma resposta esperada
Lc 1 «02h» Número de bytes enviados ao cartão
#6-#7 2 «XXXXh» Identificador de ficheiro
Não é necessária resposta ao comando SELECT (Le au­
sente em T=1 ou não é pedida resposta em T=0).
TCS_41 Mensagem de resposta (não é pedida resposta)
Byte
Compri­
mento
Valor Descrição
SW 2 «XXXXh» Palavras de estatuto (SW1, SW2)
— Se o comando for bem sucedido, o cartão devolve
«9000».
— Se o ficheiro correspondente ao identificador de ficheiro
não for encontrado, o estado de processamento devol­
vido é «6A82».
— Em T=1, se o byte Le estiver presente, o estado devol­
vido é «6700».
— Em T=0, se for pedida uma resposta depois do co­
mando SELECT, o estado devolvido é «6900».
▼M1
— Se o ficheiro selecionado for considerado corrompido
(o erro de integridade é detetado nos atributos do fi­
cheiro), o estado de processamento devolvido é «6400»
ou «6500».
▼B
3.5.2 READ BINARY
Este comando cumpre a norma ISO/IEC 7816-4, mas tem uma utili­
zação restrita, em comparação com o comando definido na norma.
O comando READ BINARY é utilizado para ler dados de ficheiros
transparentes.
A resposta do cartão consiste em devolver os dados lidos, opcional­
mente encapsulados numa estrutura de envio seguro de mensagens.
3.5.2.1 C o m a n d o c o m d e s l o c a m e n t o e m P 1 - P 2
Este comando permite ao IFD ler dados do EF selecionado de mo­
mento, sem envio seguro de mensagens.
Nota: Este comando sem envio seguro de mensagens pode ser utili­
zado apenas para ler um ficheiro que aceite o controlo de acesso
ALW para o modo de acesso Read.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 246
TCS_42 Mensagem de comando
Byte
Compri­
mento
Valor Descrição
CLA 1 «00h»
INS 1 «B0h» Read Binary
P1 1 «XXh» Deslocamento em bytes desde o início do ficheiro: Byte
mais significativo
P2 1 «XXh» Deslocamento em bytes desde o início do ficheiro: Byte
menos significativo
Le 1 «XXh» Comprimento dos dados esperados. Número de bytes a
ler
Nota: O bit 8 de P1 deve ser fixado em 0.
TCS_43 Mensagem de resposta
Byte
Compri­
mento
Valor Descrição
#1-#X X «XX..XXh» Dados lidos
SW 2 «XXXXh» Palavras de estatuto (SW1, SW2)
— Se o comando for bem sucedido, o cartão devolve
«9000».
— Se não for selecionado nenhum EF, o estado de pro­
cessamento devolvido é «6986».
— Se o controlo de acesso do ficheiro selecionado não for
satisfeito, o comando é interrompido com «6982».
— Se o deslocamento não for compatível com a dimensão
do EF (deslocamento > dimensão EF), o estado de
processamento devolvido é «6B00».
— Se a dimensão dos dados a ler não for compatível com
a dimensão do EF (deslocamento + Le > dimensão EF),
o estado de processamento devolvido é «6700» ou
«6Cxx», onde «xx» indica o comprimento exato.
▼M1
— Se for detetado um erro de integridade nos atributos do
ficheiro, o cartão considera o ficheiro corrompido e
irrecuperável e o estado de processamento devolvido
é «6400» ou «6500».
▼B
— Se for detetado um erro de integridade nos dados me­
morizados, o cartão devolve os dados pedidos e o es­
tado de processamento devolvido é «6281».
3.5.2.1.1 C o m a n d o c o m e n v i o s e g u r o d e m e n s a g e n s ( e x e m ­
p l o s )
Este comando permite ao IFD ler dados do EF selecionado de mo­
mento, com envio seguro de mensagens, a fim de verificar a integri­
dade dos dados recebidos e proteger a sua confidencialidade caso seja
aplicado o controlo de acesso SM-R-ENC-MAC-G1 (geração 1) ou
SM-R-ENC-MAC-G2 (geração 2).
TCS_44 Mensagem de comando
Byte
Compri­
mento
Valor Descrição
CLA 1 «0Ch» Pedido envio seguro de mensagens
INS 1 «B0h» Read Binary
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 247
Byte
Compri­
mento
Valor Descrição
P1 1 «XXh» P1 (deslocamento em bytes desde o início do ficheiro):
Byte mais significativo
P2 1 «XXh» P2 (deslocamento em bytes desde o início do ficheiro):
Byte menos significativo
Lc 1 «XXh» Comprimento dos dados de entrada para envio seguro de
mensagens
#6 1 «97h» T LE : Marcador para a especificação do comprimento es­
perado
#7 1 «01h» L LE : Comprimento do comprimento esperado
#8 1 «NNh» Especificação do comprimento esperado (Le original):
Número de bytes a ler
#9 1 «8Eh» T CC : Marcador para soma criptográfica de teste
#10 1 «XXh» L CC : Comprimento da soma criptográfica de teste infra
«04h» para envio seguro de mensagens da geração 1 (ver
apêndice 11, parte A)
«08h», «0Ch» ou «10h», dependendo do comprimento
da chave AES para o envio seguro de mensagens da
geração 2 (ver apêndice 11, parte B)
#11-#(10+L) L «XX..XXh» Soma criptográfica de teste
Le 1 «00h» Conforme a norma ISO/IEC 7816-4
TCS_45 Mensagem de resposta se não for necessário SM-R-
-ENC-MAC-G1 (geração 1) ou SM-R-ENC-MAC-G2
(geração 2) e se o formato de entrada do envio seguro
de mensagens estiver correto:
▼M1
Byte
Com­
pri­
mento
Valor Descrição
#1 1 «81h» T PV : Marcador para dados de valor simples
#2 L «NNh» ou
«81 NNh»
L PV : comprimento dos dados devolvidos
(= Le original).
L é 2 bytes se L PV >127 bytes.
#(2+L)-#(1+L+NN) NN «XX..XXh» Valor de dado simples
#(2+L+NN) 1 «99h» Marcador do estado de processamento
(SW1-SW2) — opcional para o envio se­
guro de mensagens da geração 1
#(3+L+NN) 1 «02h» Marcador do estado de processamento —
opcional para o envio seguro de mensagens
da geração 1
#(4+L+NN) — #(5+L+NN) 2 «XX XXh» Estado de processamento da APDU de res­
posta desprotegida — opcional para o envio
seguro de mensagens da geração 1
#(6+L+NN) 1 «8Eh» TCC: Marcador para soma criptográfica de
teste
#(7+L+NN) 1 «XXh» LCC: Comprimento da soma criptográfica
de teste infra
«04h» para envio seguro de mensagens da
geração 1 (ver apêndice 11, parte A)
«08h», «0Ch» ou «10h», dependendo do
comprimento da chave AES para o envio
seguro de mensagens da geração 2 (ver
apêndice 11, parte B)
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 248
Byte
Com­
pri­
mento
Valor Descrição
#(8+L+NN)-#(7+M+L+NN) M «XX..XXh» Soma criptográfica de teste
SW 2 «XXXXh» Palavras de estatuto (SW1, SW2)
▼B
TCS_46 Mensagem de resposta se for necessário SM-R-ENC-
-MAC-G1 (geração 1) ou SM-R-ENC-MAC-G2 (gera­
ção 2) e se o formato de entrada do envio seguro de
mensagens estiver correto:
▼M1
Byte
Com­
pri­
mento
Valor Descrição
#1 1 «87h» T PI CG : Marcador para dados encriptados
(criptograma)
#2 L «MMh» ou
«81 MMh»
LPI CG : comprimento dos dados encriptados
devolvidos (diferente do Le original do co­
mando devido a preenchimento).
L é 2 bytes se LPI CG > 127 bytes.
#(2+L)-#(1+L+MM) MM «01XX..XXh» Dados encriptados: Indicador de preenchi­
mento e criptograma
#(2+L+MM) 1 «99h» Marcador do estado de processamento
(SW1-SW2) — opcional para o envio se­
guro de mensagens da geração 1
#(3+L+MM) 1 «02h» Marcador do estado de processamento —
opcional para o envio seguro de mensagens
da geração 1
#(4+L+MM) —
#(5+L+MM)
2 «XX XXh» Estado de processamento da APDU de res­
posta desprotegida — opcional para o envio
seguro de mensagens da geração 1
#(6+L+MM) 1 «8Eh» TCC: Marcador para soma criptográfica de teste
#(7+L+MM) 1 «XXh» LCC: Comprimento da soma criptográfica
de teste infra
«04h» para envio seguro de mensagens da
geração 1 (ver apêndice 11, parte A)
«08h», «0Ch» ou «10h», dependendo do
comprimento da chave AES para o envio
seguro de mensagens da geração 2 (ver
apêndice 11, parte B)
#(8+L+MM)-
-#(7+N+L+MM)
N «XX..XXh» Soma criptográfica de teste
SW 2 «XXXXh» Palavras de estatuto (SW1, SW2)
▼B
O comando READ BINARY pode devolver estados de
processamento regulares enumerados no TCS_43 sob o
marcador «99h», conforme descrito no TCS_59, utilizando
a estrutura de resposta do envio seguro de mensagens.
Podem ocorrer alguns erros especificamente relacionados com o
envio seguro de mensagens. Em tal caso, o estado de processa­
mento é simplesmente devolvido, sem ser envolvida nenhuma
estrutura de envio seguro de mensagens:
▼M1
02016R0799 — PT — 21.08.2023 — 003.002 — 249
TCS_47 Mensagem de resposta se o formato de entrada do envio
seguro de mensagens estiver incorreto
Byte
Compri­
mento
Valor Descrição
SW 2 «XXXXh» Palavras de estatuto (SW1, SW2)
— Se não estiver disponível nenhuma chave de sessão em
curso, o estado de processamento «6A88» é devolvido,
o que acontece se a chave de sessão não tiver ainda
sido gerada ou se a sua validade tiver expirado (neste
caso, o IFD deve voltar a desencadear um processo de
autenticação mútua para criar uma nova chave de ses­
são).
— Se no formato de envio seguro de mensagens faltarem
alguns objetos de dados esperados (cf. especificação
supra), o estado de processamento «6987» é devolvido:
este erro ocorre se faltar um marcador esperado ou se o
corpo do comando não for construído adequadamente.
— Se alguns objetos de dado estiverem incorretos, o es­
tado de processamento devolvido é «6988»: este erro
ocorre se todos os marcadores necessários estiverem
presentes mas alguns comprimentos forem diferentes
dos esperados.
— Se falhar a verificação da soma criptográfica de teste, o
estado de processamento devolvido é «6688».
3.5.2.2 C o m a n d o c o m i d e n t i f i c a d o r E F ( E l e m e n t a r y F i l e )
c u r t o
Esta variante de comando permite ao IFD selecionar um EF por meio
de um identificador EF curto e ler dados deste EF.
TCS_48 Um cartão tacográfico deve aceitar esta variante de co­
mando para todos os ficheiros elementares que contenham
um determinado identificador EF curto. Os presentes iden­
tificadores EF curtos são especificados no capítulo 4.
TCS_49 Mensagem de comando
Byte
Compri­
mento
Valor Descrição
CLA 1 «00h»
INS 1 «B0h» Read Binary
P1 1 «XXh» O bit 8 é fixado em 1
Os bits 7 e 6 são fixados em 00
O bit 5-1 codifica o identificador EF curto do EF cor­
respondente
P2 1 «XXh» Codifica um deslocamento de 0 a 255 bytes no EF re­
ferenciado por P1
Le 1 «XXh» Comprimento dos dados esperados. Número de bytes a
ler
Nota: Os identificadores EF curtos utilizados para a apli­
cação tacográfica da geração 2 são especificados no capí­
tulo 4.
Se P1 codificar um identificador EF curto e o comando for
bem sucedido, o EF identificado passa a ser o EF selecio­
nado no momento (EF atual).
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 250
TCS_50 Mensagem de resposta
Byte
Compri­
mento
Valor Descrição
#1-#L L «XX..XXh» Dados lidos
SW 2 «XXXXh» Palavras de estatuto (SW1, SW2)
— Se o comando for bem sucedido, o cartão devolve
«9000».
— Se o ficheiro correspondente ao identificador EF curto
não for encontrado, o estado de processamento devol­
vido é «6A82».
— Se o controlo de acesso do ficheiro selecionado não for
satisfeito, o comando é interrompido com «6982».
— Se o deslocamento não for compatível com a dimensão
do EF (deslocamento > dimensão EF), o estado de
processamento devolvido é «6B00».
— Se a dimensão dos dados a ler não for compatível com
a dimensão do EF (deslocamento + Le > dimensão EF),
o estado de processamento devolvido é «6700» ou
«6Cxx» onde «xx» indica o comprimento exato.
▼M1
— Se for detetado um erro de integridade nos atributos do
ficheiro, o cartão considera o ficheiro corrompido e
irrecuperável e o estado de processamento devolvido
é «6400» ou «6500».
▼B
— Se for detetado um erro de integridade nos dados me­
morizados, o cartão devolve os dados pedidos e o es­
tado de processamento devolvido é «6281».
3.5.2.3 C o m a n d o c o m b y t e d e i n s t r u ç ã o í m p a r
Esta variante de comando permite ao IFD ler dados de um EF com
32 768 bytes ou mais.
TCS_51 Um cartão tacográfico que aceite EF com 32 768 bytes ou
mais deve aceitar esta variante de comando para esses EF.
Um cartão tacográfico pode ou não aceitar esta variante de
comando para outros EF, com exceção do EF Sensor_Ins­
tallation_Data (ver TCS_156 e TCS_160).
TCS_52 Mensagem de comando
Byte
Compri­
mento
Valor Descrição
CLA 1 «00h»
INS 1 «B1h» Read Binary
P1 1 «00h» EF atual
P2 1 «00h»
Lc 1 «NNh» Comprimento Lc do deslocamento do objeto de dados
#6-#(5+NN) NN «XX..XXh» Objeto de dados do deslocamento:
Marcador «54h»
Comprimento «01h» ou «02h»
Valor deslocamento
▼M1
Le 1 «XXh» Conforme a norma ISO/IEC 7816-4
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 251
O IFD deve codificar o comprimento do objeto de dados
do deslocamento com um número mínimo possível de oc­
tetos, ou seja, ao utilizar o byte de comprimento «01h», o
IFD deve codificar um deslocamento de 0 a 255 e, ao
utilizar o byte de comprimento «02h», um deslocamento
de «256» até «65 535» bytes.
▼M1
Quando T = 0 o cartão assume o valor Le = «00h» caso
não for aplicado o envio seguro de mensagens.
Quando T = 1 o estado de processamento devolvido é
«6700» se Le= «01h».
▼B
TCS_53 Mensagem de resposta
Byte
Compri­
mento
Valor Descrição
#1-#L L «XX..XXh» Dados lidos encapsulados num objeto de dados discricio­
nário com marcador «53h».
SW 2 «XXXXh» Palavras de estatuto (SW1, SW2)
— Se o comando for bem sucedido, o cartão devolve
«9000».
— Se não for selecionado nenhum EF, o estado de pro­
cessamento devolvido é «6986».
— Se o controlo de acesso do ficheiro selecionado não for
satisfeito, o comando é interrompido com «6982».
— Se o deslocamento não for compatível com a dimensão
do EF (deslocamento > dimensão EF), o estado de
processamento devolvido é «6B00».
— Se a dimensão dos dados a ler não for compatível com
a dimensão do EF (deslocamento + Le > dimensão EF),
o estado de processamento devolvido é «6700» ou
«6Cxx», onde «xx» indica o comprimento exato.
▼M1
— Se for detetado um erro de integridade nos atributos do
ficheiro, o cartão considera o ficheiro corrompido e
irrecuperável e o estado de processamento devolvido
é «6400» ou «6500».
▼B
— Se for detetado um erro de integridade nos dados me­
morizados, o cartão devolve os dados pedidos e o es­
tado de processamento devolvido é «6281».
3.5.2.3.1 C o m a n d o c o m e n v i o s e g u r o d e m e n s a g e n s ( e x e m ­
p l o )
O exemplo que se segue ilustra a utilização do envio seguro de
mensagens caso se aplique o controlo de acesso SM-MAC-G2.
TCS_54 Mensagem de comando
Byte
Compri­
mento
Valor Descrição
CLA 1 «0Ch» Pedido envio seguro de mensagens
INS 1 «B1h» Read Binary
P1 1 «00h» EF atual
P2 1 «00h»
Lc 1 «XXh» Comprimento do campo de dados securizado
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 252
Byte
Compri­
mento
Valor Descrição
#6 1 «B3h» Marcador para dados de valor simples codificados em
BER-TLV
#7 1 «NNh» L PV : comprimento dos dados transmitidos
#(8)-#(7+NN) NN «XX..XXh» Dados simples codificados em BER-TLV, ou seja, o
objeto de dados do deslocamento com marcador «54»
#(8+NN) 1 «97h» T LE : Marcador para a especificação do comprimento
esperado.
#(9+NN) 1 «01h» L LE : Comprimento do comprimento esperado
#(10+NN) 1 «XXh» Especificação do comprimento esperado (Le original):
Número de bytes a ler
#(11+NN) 1 «8Eh» T CC : Marcador para soma criptográfica de teste
#(12+NN) 1 «XXh» L CC : Comprimento da soma criptográfica de teste infra
«08h», «0Ch» ou «10h», dependendo do comprimento
da chave AES para o envio seguro de mensagens da
geração 2 (ver apêndice 11, parte B)
#(13+NN)-
-#(12+M+
NN)
M «XX..XXh» Soma criptográfica de teste
Le 1 «00h» Conforme a norma ISO/IEC 7816-4
TCS_55 Mensagem de resposta se o comando for bem sucedido
Byte
Compri­
mento
Valor Descrição
#1 1 «B3h» Dados simples codificados em BER-TLV
#2 L «NNh» or
«81 NNh»
L PV : comprimento dos dados devolvidos (= Le original).
L é 2 bytes se L PV >127 bytes
#(2+L)-
-#(1+L+NN)
NN «XX..XXh» Valor de dado simples codificado em BER-TLV, ou seja,
dados lidos encapsulados num objeto de dados discricio­
nário com marcador «53h»
#(2+L+NN) 1 «99h» Estado de processamento da APDU de resposta despro­
tegida
#(3+L+NN) 1 «02h» Comprimento do estado de processamento
#(4+L+NN) —
#(5+L+NN)
2 «XX XXh» Estado de processamento da APDU de resposta despro­
tegida
#(6+L+NN) 1 «8Eh» T CC : Marcador para soma criptográfica de teste
#(7+L+NN) 1 «XXh» L CC : Comprimento da soma criptográfica de teste infra
«08h», «0Ch» ou «10h», dependendo do comprimento
da chave AES para o envio seguro de mensagens da
geração 2 (ver apêndice 11, parte B)
#(8+L+NN)-
-#(7+M+L+
NN)
M «XX..XXh» Soma criptográfica de teste
SW 2 «XXXXh» Palavras de estatuto (SW1, SW2)
3.5.3 UPDATE BINARY
Este comando cumpre a norma ISO/IEC 7816-4, mas tem utilização
restrita, em comparação com o comando definido na norma.
A mensagem de comando UPDATE BINARY inicia a atualização
(apagar + escrever) dos bits já presentes num binário EF com os
bits dados no comando APDU.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 253
3.5.3.1 C o m a n d o c o m d e s l o c a m e n t o e m P 1 - P 2
Este comando permite ao IFD escrever dados no EF selecionado de
momento, sem o cartão verificar a integridade dos dados recebidos.
Nota: Este comando sem envio seguro de mensagens pode ser utili­
zado apenas para atualizar um ficheiro que aceite o controlo de acesso
ALW para o modo de acesso Update.
TCS_56 Mensagem de comando
Byte
Compri­
mento
Valor Descrição
CLA 1 «00h»
INS 1 «D6h» UPDATE BINARY
P1 1 «XXh» Deslocamento em bytes desde o início do ficheiro: Byte
mais significativo
P2 1 «XXh» Deslocamento em bytes desde o início do ficheiro: Byte
menos significativo
Lc 1 «NNh» Comprimento Lc dos dados a atualizar. Número de bytes
a escrever
#6-#(5+NN) NN «XX..XXh» Dados a escrever
Nota: O bit 8 de P1 deve ser fixado em 0.
TCS_57 Mensagem de resposta
Byte
Compri­
mento
Valor Descrição
SW 2 «XXXXh» Palavras de estatuto (SW1, SW2)
— Se o comando for bem sucedido, o cartão devolve
«9000».
— Se não for selecionado nenhum EF, o estado de pro­
cessamento devolvido é «6986».
— Se o controlo de acesso do ficheiro selecionado não for
satisfeito, o comando é interrompido com «6982».
— Se o deslocamento não for compatível com a dimensão
do EF (deslocamento > dimensão EF), o estado de
processamento devolvido é «6B00».
— Se a dimensão dos dados a escrever não for compatível
com a dimensão do EF (deslocamento + Lc > dimensão
EF), o estado de processamento devolvido é «6700».
— Se for detetado um erro de integridade nos atributos do
ficheiro, o cartão considera o ficheiro corrompido e
irrecuperável e o estado de processamento devolvido
é «6400» ou «6500».
— Se a escrita não tiver êxito, o estado de processamento
devolvido é «6581».
3.5.3.1.1 C o m a n d o c o m e n v i o s e g u r o d e m e n s a g e n s ( e x e m ­
p l o s )
Este comando permite ao IFD escrever dados no EF selecionado de
momento, com o cartão a verificar a integridade dos dados recebidos.
Como não é exigida confidencialidade, os dados não são encriptados.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 254
TCS_58 Mensagem de comando
Byte
Compri­
mento
Valor Descrição
CLA 1 «0Ch» Pedido envio seguro de mensagens
INS 1 «D6h» Update Binary
P1 1 «XXh» Deslocamento em bytes desde o início do ficheiro:
Byte mais significativo
P2 1 «XXh» Deslocamento em bytes desde o início do ficheiro:
Byte menos significativo
Lc 1 «XXh» Comprimento do campo de dados securizado
#6 1 «81h» T PV : Marcador para dados de valor simples
#7 L «NNh» or
«81 NNh»
L PV : comprimento dos dados transmitidos.
L é 2 bytes se L PV > 127 bytes
#(7+L)-
-#(6+L+NN)
NN «XX..XXh» Valor de dado simples (dados a escrever)
#(7+L+NN) 1 «8Eh» T CC : Marcador para soma criptográfica de teste
#(8+L+NN) 1 «XXh» L CC : Comprimento da soma criptográfica de teste infra
«04h» para o envio seguro de mensagens da geração 1
(ver apêndice 11, parte A)
«08h», «0Ch» ou «10h», dependendo do comprimento
da chave AES para o envio seguro de mensagens da
geração 2 (ver apêndice 11, parte B)
#(9+L+NN)-
-#(8+M+L+
NN)
M «XX..XXh» Soma criptográfica de teste
Le 1 «00h» Conforme a norma ISO/IEC 7816-4
TCS_59 Mensagem de resposta se o formato de entrada do envio
seguro de mensagens estiver correto:
Byte
Compri­
mento
Valor Descrição
#1 1 «99h» T SW : Marcador para palavras de estatuto (a proteger por
CC)
#2 1 «02h» L SW : comprimento das palavras de estatuto devolvidas
#3-#4 2 «XXXXh» Estado de processamento da APDU de resposta despro­
tegida
#5 1 «8Eh» T CC : Marcador para soma criptográfica de teste
#6 1 «XXh» L CC : Comprimento da soma criptográfica de teste infra
«04h» para envio seguro de mensagens da geração 1 (ver
apêndice 11, parte A)
«08h», «0Ch» ou «10h», dependendo do comprimento
da chave AES para o envio seguro de mensagens da
geração 2 (ver apêndice 11, parte B)
#7-#(6+L) L «XX..XXh» Soma criptográfica de teste
SW 2 «XXXXh» Palavras de estatuto (SW1, SW2)
Os estados de processamento «regular», descritos relativa­
mente ao comando UPDATE BINARY sem envio seguro
de mensagens (ver ponto 3.5.3.1), podem ser devolvidos
utilizando as estruturas de mensagem de resposta acima
descritas.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 255
Podem ocorrer alguns erros especificamente relacionados
com o envio seguro de mensagens. Em tal caso, o estado
de processamento é simplesmente devolvido, sem envolvi­
mento de nenhuma estrutura de envio seguro de
mensagens:
TCS_60 Mensagem de resposta se houver erro no envio seguro
de mensagens
Byte
Compri­
mento
Valor Descrição
SW 2 «XXXXh» Palavras de estatuto (SW1, SW2)
— Se não estiver disponível nenhuma chave de sessão em
curso, o estado de processamento «6A88» é devolvido.
— Se no formato de envio seguro de mensagens faltarem
alguns objetos de dados esperados (cf. especificação
supra), o estado de processamento «6987» é devolvido:
este erro ocorre se faltar um marcador esperado ou se o
corpo do comando não for construído adequadamente.
— Se alguns objetos de dados estiverem incorretos, o es­
tado de processamento devolvido é «6988»: este erro
ocorre se todos os marcadores necessários estiverem
presentes mas alguns comprimentos forem diferentes
dos esperados.
— Se falhar a verificação da soma criptográfica de teste, o
estado de processamento devolvido é «6688».
3.5.3.2 C o m a n d o c o m i d e n t i f i c a d o r E F c u r t o
Esta variante de comando permite ao IFD selecionar um EF por meio
de um identificador EF curto e escrever dados deste EF.
TCS_61 Um cartão tacográfico deve aceitar esta variante de co­
mando para todos os ficheiros elementares que contenham
um determinado identificador EF curto. Os presentes iden­
tificadores EF curtos são especificados no capítulo 4.
TCS_62 Mensagem de comando
Byte
Compri­
mento
Valor Descrição
CLA 1 «00h»
INS 1 «D6h» Update Binary
P1 1 «XXh» O bit 8 é fixado em 1
Os bits 7 e 6 são fixados em 00
O bit 5-1 codifica o identificador EF curto do EF cor­
respondente
P2 1 «XXh» Codifica um deslocamento de 0 a 255 bytes no EF re­
ferenciado por P1
Lc 1 «NNh» Comprimento Lc dos dados a atualizar. Número de bytes
a escrever
#6-#(5+NN) NN «XX..XXh» Dados a escrever
TCS_63 Mensagem de resposta
Byte
Compri­
mento
Valor Descrição
SW 2 «XXXXh» Palavras de estatuto (SW1, SW2)
Nota: Os identificadores EF curtos utilizados para a apli­
cação tacográfica da geração 2 são especificados no capí­
tulo 4.
Se P1 codificar um identificador EF curto e o comando for
bem sucedido, o EF identificado passa a ser o EF selecio­
nado no momento (EF atual).
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 256
— Se o comando for bem sucedido, o cartão devolve
«9000».
— Se o ficheiro correspondente ao identificador EF curto
não for encontrado, o estado de processamento devol­
vido é «6A82».
— Se o controlo de acesso do ficheiro selecionado não for
satisfeito, o comando é interrompido com «6982».
— Se o deslocamento não for compatível com a dimensão
do EF (deslocamento > dimensão EF), o estado de
processamento devolvido é «6B00».
— Se a dimensão dos dados a escrever não for compatível
com a dimensão do EF (deslocamento + Lc > dimensão
EF), o estado de processamento devolvido é «6700».
▼M1
— Se for detetado um erro de integridade nos atributos do
ficheiro, o cartão considera o ficheiro corrompido e
irrecuperável e o estado de processamento devolvido
é «6400» ou «6500».
▼B
— Se a escrita não tiver êxito, o estado de processamento
devolvido é «6581».
3.5.3.3 C o m a n d o c o m b y t e d e i n s t r u ç ã o í m p a r
Esta variante de comando permite ao IFD escrever dados num EF
com 32 768 bytes ou mais.
TCS_64 Um cartão tacográfico que aceite EF com 32 768 bytes ou
mais deve aceitar esta variante de comando para esses EF.
Um cartão tacográfico pode ou não aceitar esta variante de
comando para outros EF.
TCS_65 Mensagem de comando
Byte
Compri­
mento
Valor Descrição
CLA 1 «00h»
INS 1 «D7h» Update Binary
P1 1 «00h» EF atual
P2 1 «00h»
Lc 1 «NNh» Comprimento Lc de dados no campo de dados de co­
mando
#6-#(5+NN) NN «XX..XXh» Objeto de dados do deslocamento com marcador «54h» ||
Objeto de dados discricionário com marcador «53h» que
encapsula os dados a escrever
O IFD codifica o comprimento do objeto de dados do
deslocamento e do objeto de dados discricionário com
um número mínimo possível de octetos, ou seja, ao utilizar
o byte de comprimento «01h», o IFD codifica um desloca­
mento/ comprimento de 0 a 255 e, ao utilizar o byte de
comprimento «02h», um deslocamento/ comprimento de
«256» até «65 535» bytes.
TCS_66 Mensagem de resposta
Byte
Compri­
mento
Valor Descrição
SW 2 «XXXXh» Palavras de estatuto (SW1, SW2)
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 257
— Se o comando for bem sucedido, o cartão devolve
«9000».
— Se não for selecionado nenhum EF, o estado de pro­
cessamento devolvido é «6986».
— Se o controlo de acesso do ficheiro selecionado não for
satisfeito, o comando é interrompido com «6982».
— Se o deslocamento não for compatível com a dimensão
do EF (deslocamento > dimensão EF), o estado de
processamento devolvido é «6B00».
— Se a dimensão dos dados a escrever não for compatível
com a dimensão do EF (deslocamento + Lc > dimensão
EF), o estado de processamento devolvido é «6700».
— Se for detetado um erro de integridade nos atributos do
ficheiro, o cartão considera o ficheiro corrompido e
irrecuperável e o estado de processamento devolvido
é «6400» ou «6500».
— Se a escrita não tiver êxito, o estado de processamento
devolvido é «6581».
3.5.3.3.1 C o m a n d o c o m e n v i o s e g u r o d e m e n s a g e n s ( e x e m ­
p l o )
O exemplo a seguir ilustra a utilização do envio seguro de mensagens
caso se aplique o controlo de acesso SM-MAC-G2.
TCS_67 Mensagem de comando
Byte
Compri­
mento
Valor Descrição
CLA 1 «0Ch» Pedido envio seguro de mensagens
INS 1 «D7h» Update Binary
P1 1 «00h» EF atual
P2 1 «00h»
Lc 1 «XXh» Comprimento do campo de dados securizado
#6 1 «B3h» Marcador para dados de valor simples codificados em
BER-TLV
#7 L «NNh» or
«81 NNh»
L PV : comprimento dos dados transmitidos.
L é 2 bytes se L PV > 127 bytes.
#(7+L)-
-#(6+L+NN)
NN «XX..XXh» Dados simples codificados em BER-TLV, ou seja, objeto
de dados do deslocamento com marcador «54h» || Objeto
de dados discricionário com marcador «53h» que encap­
sula os dados a escrever
#(7+L+NN) 1 «8Eh» T CC : Marcador para soma criptográfica de teste
#(8+L+NN) 1 «XXh» L CC : Comprimento da soma criptográfica de teste infra
«08h», «0Ch» ou «10h», dependendo do comprimento
da chave AES para o envio seguro de mensagens da
geração 2 (ver apêndice 11, parte B)
#(9+L+NN)-
-#(8+M+L+
NN)
M «XX..XXh» Soma criptográfica de teste
Le 1 «00h» Conforme a norma ISO/IEC 7816-4
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 258
TCS_68 Mensagem de resposta se o comando for bem sucedido
Byte
Compri­
mento
Valor Descrição
#1 1 «99h» T SW : Marcador para palavras de estatuto (a proteger por
CC)
#2 1 «02h» L SW : comprimento das palavras de estatuto devolvidas
#3-#4 2 «XXXXh» Estado de processamento da APDU de resposta despro­
tegida
#5 1 «8Eh» T CC : Marcador para soma criptográfica de teste
#6 1 «XXh» L CC : Comprimento da soma criptográfica de teste infra
«08h», «0Ch» ou «10h», dependendo do comprimento
da chave AES para o envio seguro de mensagens da
geração 2 (ver apêndice 11, parte B)
#7-#(6+L) L «XX..XXh» Soma criptográfica de teste
SW 2 «XXXXh» Palavras de estatuto (SW1, SW2)
3.5.4 GET CHALLENGE
Este comando cumpre a norma ISO/IEC 7816-4, mas tem utilização
restrita, em comparação com o comando definido na norma.
O comando GET CHALLENGE pede ao cartão que emita um desafio,
a fim de o utilizar num procedimento de segurança no âmbito do qual
são enviados ao cartão um criptograma ou alguns dados cifrados.
TCS_69 O desafio emitido pelo cartão só é válido para o comando
seguinte enviado ao cartão e que utiliza desafio.
TCS_70 Mensagem de comando
Byte
Compri­
mento
Valor Descrição
CLA 1 «00h»
INS 1 «84h» INS
P1 1 «00h» P1
P2 1 «00h» P2
Le 1 «08h» Le (comprimento do desafio esperado)
TCS_71 Mensagem de resposta
Byte
Compri­
mento
Valor Descrição
#1-#8 8 «XX..XXh» Desafio
SW 2 «XXXXh» Palavras de estatuto (SW1, SW2)
— Se o comando for bem sucedido, o cartão devolve
«9000».
— Se Le for diferente de «08h», o estado de processa­
mento é «6700».
— Se os parâmetros P1-P2 forem incorretos, o estado de
processamento é «6A86».
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 259
3.5.5 VERIFY
Este comando cumpre a norma ISO/IEC 7816-4, mas tem utilização
restrita, em comparação com o comando definido na norma.
Basta o cartão da oficina para aceitar este comando.
Outros tipos de cartões tacográficos podem ou não executar este
comando, mas para esses cartões não é personalizada qualquer refe­
rência CHV. Portanto, não podem executar este comando com êxito.
No caso de outros tipos de cartões tacográficos além dos cartões dos
centros de ensaio, o comportamento, ou seja, o código de erro devol­
vido, fica fora do âmbito desta especificação se o comando for
enviado.
O comando Verify inicia a comparação, no cartão, entre os dados
CHV (PIN) enviados do comando e a CHV de referência memorizada
no cartão.
▼M1
TCS_72 O PIN introduzido pelo utilizador deve ser codificado AS­
CII e preenchido à direita com bytes «FFh» até um com­
primento de 8 bytes pelo IFD (ver também o tipo de dados
WorkshopCardPIN no apêndice 1).
▼B
TCS_73 As aplicações tacográficas das gerações 1 e 2 utilizam o
mesmo CHV de referência.
TCS_74 O cartão tacográfico verifica se o comando está correta­
mente codificado. Em caso negativo, o cartão não compara
os valores CHV, não diminui o contador de tentativas re­
manescentes da CHV nem reinicializa o estatuto de segu­
rança «PIN_Verified», mas interrompe-se o comando. Um
comando é corretamente codificado se os bytes CLA, INS,
P1, P2 e Lc tiverem os valores especificados, Le estiver
ausente e o campo de dados de comando tiver o compri­
mento correto.
TCS_75 Se o comando for bem sucedido, reinicializa-se o contador
de tentativas remanescentes da CHV. O valor inicial do
contador de tentativas remanescentes da CHV é 5. Se o
comando for bem sucedido, o cartão define o estatuto da
segurança interna «PIN_Verified». O cartão reinicializa este
estatuto de segurança se for reinicializado ou se o código
CHV transmitido no comando não coincidir com a CHV de
referência memorizada.
Nota: A utilização da mesma CHV de referência e de um
estatuto de segurança global impede que um funcionário da
oficina reintroduza o PIN após a seleção de outro DF da
aplicação tacográfica.
TCS_76 Uma comparação mal sucedida é registada no cartão, ou
seja, o contador de tentativas remanescentes da CHV é
diminuído de um valor, a fim de limitar a quantidade de
novas tentativas de utilização da CHV de referência.
TCS_77 Mensagem de comando
Byte
Compri­
mento
Valor Descrição
CLA 1 «00h»
INS 1 «20h» INS
P1 1 «00h» P1
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 260
Byte
Compri­
mento
Valor Descrição
P2 1 «00h» P2 (a CHV verificada é implicitamente conhecida)
Lc 1 «08h» Comprimento do código CHV transmitido
#6-#13 8 «XX..XXh» CHV
TCS_78 Mensagem de resposta
Byte
Compri­
mento
Valor Descrição
SW 2 «XXXXh» Palavras de estatuto (SW1, SW2)
— Se o comando for bem sucedido, o cartão devolve
«9000».
— Se a CHV de referência não for encontrada, o estado de
processamento devolvido é «6A88».
— Se a CHV estiver bloqueada (o contador de tentativas
remanescentes da CHV é nulo), o estado de processa­
mento devolvido é «6983». Uma vez nesse estado, a
CHV não poderá voltar a ser apresentada com êxito.
— Se a comparação não for bem sucedida, o contador de
tentativas remanescentes decresce e é devolvido o esta­
tuto «63CX» (X>0 e X igual ao contador de tentativas
remanescentes da CHV.
— Se a CHV de referência for considerada corrompida, o
estado de processamento devolvido é «6400» ou
«6581».
— Se Lc for diferente de «08h», o estado de processa­
mento é «6700».
3.5.6 GET RESPONSE
Este comando cumpre a norma ISO/IEC 7816-4.
Este comando (necessário e disponível somente para o protocolo T=0)
é utilizado para transmitir dados do cartão ao dispositivo de interface
(caso em que um comando tivesse incluído tanto Lc como Le).
O comando GET RESPONSE tem de ser emitido imediatamente após
o comando que prepara os dados, sob pena de estes se perderem. Uma
vez executado o comando GET RESPONSE (a menos que ocorram os
erros «61xx» ou «6Cxx» — ver infra), os dados preparados anterior­
mente deixam de estar disponíveis.
TCS_79 Mensagem de comando
Byte
Compri­
mento
Valor Descrição
CLA 1 «00h»
INS 1 «C0h»
P1 1 «00h»
P2 1 «00h»
Le 1 «XXh» Número esperado de bytes
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 261
TCS_80 Mensagem de resposta
Byte
Compri­
mento
Valor Descrição
#1-#X X «XX..XXh» Dados
SW 2 «XXXXh» Palavras de estatuto (SW1, SW2)
— Se o comando for bem sucedido, o cartão devolve
«9000».
— Se não tiverem sido preparados dados pelo cartão, o
estado de processamento devolvido é «6900» ou
«6F00».
— Se Le exceder o número de bytes disponíveis ou for
nulo, o estado de processamento devolvido é «6Cxx»,
onde «xx» indica o número exato de bytes disponíveis.
Nesse caso, os dados preparados estão ainda disponí­
veis para um comando GET RESPONSE subsequente.
— Se Le não for nulo e for menor do que o número de
bytes disponíveis, os dados requeridos são enviados
normalmente pelo cartão e o estado de processamento
devolvido é «61xx», onde «xx» indica um número de
bytes extra ainda disponíveis para um comando GET
RESPONSE subsequente.
— Se o comando não for aceite (protocolo T=1), o cartão
devolve «6D00».
3.5.7 PSO: VERIFY CERTIFICATE
Este comando cumpre a norma ISO/IEC 7816-8, mas tem utilização
restrita, em comparação com o comando definido na norma.
O comando VERIFY CERTIFICATE é utilizado pelo cartão para
obter uma chave pública do exterior e verificar a sua validade.
3.5.7.1 C o m a n d o d a g e r a ç ã o 1 — p a r d e r e s p o s t a
TCS_81 Esta variante de comando é aceite apenas por uma aplica­
ção tacográfica da geração 1.
TCS_82 Quando um comando VERIFY CERTIFICATE é bem su­
cedido, a chave pública é memorizada para futura utilização
no ambiente de segurança. Esta chave é explicitamente
estabelecida para utilização em comandos relativos à segu­
rança (INTERNAL AUTHENTICATE, EXTERNAL AUT­
HENTICATE ou VERIFY CERTIFICATE) pelo comando
MSE (ver ponto 3.5.11), recorrendo ao seu identificador de
chave.
TCS_83 Em qualquer caso, o comando VERIFY CERTIFICATE
utiliza a chave pública previamente selecionada pelo co­
mando MSE para abrir o certificado. Esta chave pública
deve ser a de um Estado-Membro ou da Europa.
TCS_84 Mensagem de comando
Byte
Compri­
mento
Valor Descrição
CLA 1 «00h»
INS 1 «2Ah» Executar operação de segurança
P1 1 «00h» P1
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 262
Byte
Compri­
mento
Valor Descrição
P2 1 «AEh» P2: dados codificados não BER-TLV (concatenação de
elementos dos dados)
Lc 1 «C2h» Lc: Comprimento do certificado, 194 bytes
#6-#199 194 «XX..XXh» Certificado: concatenação de elementos dos dados (cf.
apêndice 11)
TCS_85 Mensagem de resposta
Byte
Compri­
mento
Valor Descrição
SW 2 «XXXXh» Palavras de estatuto (SW1, SW2)
— Se o comando for bem sucedido, o cartão devolve
«9000».
— Se a verificação do certificado falhar, o estado de pro­
cessamento devolvido é «6688». O processo de verifi­
cação e desmontagem do certificado para G1 e G2 é
descrito no apêndice 11.
— Se nenhuma chave pública estiver presente no ambiente
de segurança, é devolvido «6A88».
— Se a chave pública selecionada (utilizada para desmon­
tar o certificado) for considerada corrompida, o estado
de processamento devolvido é «6400» ou «6581».
— Apenas geração 1: Se a chave pública selecionada (uti­
lizada
para desmontar o certificado) tiver um CHA.LSB (­
)
diferente de «00» (ou seja, não for a de um
Estado-Membro ou da Europa), o estado de processa­
mento devolvido é «6985».
3.5.7.2 C o m a n d o d a g e r a ç ã o 2 — p a r d e r e s p o s t a
Dependendo da dimensão da curva, os certificados ECC podem ser
tão extensos que se torna impossível transmiti-los numa APDU única.
Neste caso, de acordo com a norma ISO/IEC 7816-4, deve aplicar-se
o encadeamento do comando e o certificado transmitido em dois PSO
consecutivos: APDU de verificação do certificado.
A estrutura do certificado e os parâmetros de domínio são definidos
no apêndice 11.
▼M3
TCS_86 O comando pode ser executado no MF, no DF Tachograph
e no DF Tachograph_G2 (ver também TCS_34).
▼B
TCS_87 Mensagem de comando
Byte
Compri­
mento
Valor Descrição
CLA 1 «X0h» Byte CLA que indica encadeamento de comando:
«00h» o único ou o último comando da cadeia
«10h» não é o último comando de uma cadeia
INS 1 «2Ah» Executar operação de segurança
P1 1 «00h»
P2 1 «BEh» Verificar certificado autodescritivo
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 263
Byte
Compri­
mento
Valor Descrição
Lc 1 «XXh» Comprimento do campo de dados de comando, ver
TCS_88 e TCS_89
#6-#5+L L «XX..XXh» Dados codificados DER-TLV: Objeto de dados do corpo
do certificado ECC como primeiro objeto de dados con­
catenado com o objeto de dados de assinatura do certi­
ficado ECC como segundo objeto de dados ou uma parte
dessa concatenação. O marcador «7F21» e o compri­
mento correspondente não devem ser transmitidos.
A ordem desses objetos de dados é fixa.
▼M3
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 co­
mando. No entanto, o cartão deve aceitar qualquer valor
de «Lc» até 255 bytes.
TCS_89 Às APDU de comprimento aumentado aplicam-se as dis­
posiçõ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 trans­
mitir 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 certifi­
cado 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.
▼B
TCS_90 Além dos códigos de erro listados em TCS_85, o cartão
pode devolver os seguintes códigos de erro:
— Se a chave pública selecionada (utilizada para desmon­
tar o certificado) tiver um CHA.LSB (CertificateHolde­
rAuthorisation.equipmentType) que não se adeque à
verificação do certificado, o estado de processamento
devolvido é «6985», de acordo com o apêndice 11.
— Se o currentAuthenticatedTime do cartão for posterior à
data de validade do certificado, o estado de processa­
mento devolvido é «6985».
— Se for esperado o último comando da cadeia, o cartão
devolve «6883».
— Se forem enviados parâmetros incorretos no campo de
dados de comando, o cartão devolve «6A80» (utilizado
igualmente no caso de os objetos de dados não serem
enviados na ordem especificada).
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 264
3.5.8 INTERNAL AUTHENTICATE
Este comando cumpre a norma ISO/IEC 7816-4.
TCS_91 No DF Tachograph geração 1, todos os cartões tacográficos
são compatíveis com este comando. O comando pode ou
não estar acessível no MF e/ou no DF Tachograph_G2. Em
caso afirmativo, o comando interrompe-se com um código
de erro adequado como a chave privada do cartão
(Card.SK), já que o protocolo de autenticação da geração 1
está acessível apenas no DF_Tachograph geração 1.
É por intermédio do comando INTERNAL AUTHENTI­
CATE que o IFD pode autenticar o cartão. O processo
de autenticação, descrito no apêndice 11, inclui as seguintes
declarações:
TCS_92 O comando INTERNAL AUTHENTICATE utiliza a chave
privada do cartão (implicitamente selecionada) para assinar
dados de autenticação, incluindo K1 (primeiro elemento
para acordo de chave de sessão) e RND1, e utiliza a chave
pública selecionada no momento (através do último co­
mando MSE) para encriptar a assinatura e formar o teste­
munho de autenticação (mais pormenores no apêndice 11).
TCS_93 Mensagem de comando
Byte
Compri­
mento
Valor Descrição
CLA 1 «00h» CLA
INS 1 «88h» INS
P1 1 «00h» P1
P2 1 «00h» P2
Lc 1 «10h» Comprimento dos dados enviados ao cartão
#6 — #13 8 «XX..XXh» Desafio utilizado para autenticar o cartão
#14 -#21 8 «XX..XXh» VU.CHR (ver apêndice 11)
Le 1 «80h» Comprimento dos dados esperados do cartão
TCS_94 Mensagem de resposta
Byte
Compri­
mento
Valor Descrição
#1-#128 128 «XX..XXh» Testemunho de autenticação do cartão (ver apêndice 11)
SW 2 «XXXXh» Palavras de estatuto (SW1, SW2)
— Se o comando for bem sucedido, o cartão devolve
«9000».
— Se nenhuma chave pública estiver presente no ambiente
de segurança, o estado de processamento devolvido é
«6A88».
— Se nenhuma chave privada estiver presente no ambiente
de segurança, o estado de processamento devolvido é
«6A88».
— Se VU.CHR não corresponder ao identificador de chave
pública em curso, o estado de processamento devolvido
é «6A88».
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 265
— Se a chave privada selecionada for considerada corrom­
pida, o estado de processamento devolvido é «6400» ou
«6581».
▼M1
TCS_95 Se o comando INTERNAL AUTHENTICATE for bem-
sucedido, a chave de sessão de geração 1 em curso, a
existir, é apagada e deixa de estar disponível. Para dispor
de uma nova chave de sessão de geração 1, tem de se
executar com êxito o comando EXTERNAL AUTHENTI­
CATE para o mecanismo de autenticação da geração 1.
Nota: Para chaves de sessão de geração 2 ver apêndice 11
CSM_193 e CSM_195. Se houver chaves de sessão de
geração 2 e o cartão tacográfico receber o comando
APDU simples INTERNAL AUTHENTICATE, a sessão
de envio seguro de mensagens de geração 2 é abortada e
as chaves de sessão de geração 2 são destruídas.
▼B
3.5.9 EXTERNAL AUTHENTICATE
Este comando cumpre a norma ISO/IEC 7816-4.
É por intermédio do comando EXTERNAL AUTHENTICATE que o
cartão pode autenticar o IFD. O processo de autenticação para os
tacógrafos G1 e G2 (autenticação VU) é descrito no apêndice 11.
TCS_96 A variante de comando para o mecanismo de autenticação
mútua da geração 1 é compatível apenas com aplicações
tacográficas da geração 1.
▼M1
TCS_97 A variante de comando destinada a autenticação mútua do
cartão VU da segunda geração pode ser executada no MF,
no DF Tachograph e no DF Tachograph_G2 (ver igual­
mente TCS_34). Se o comando EXTERNAL AUTHENTI­
CATE desta geração 2 for bem-sucedido, a chave de sessão
de geração 1 em curso, a existir, é apagada e deixa de estar
disponível.
Nota: Para chaves de sessão de geração 2 ver apêndice 11
CSM_193 e CSM_195. Se houver chaves de sessão de
geração 2 e o cartão tacográfico receber o comando
APDU simples EXTERNAL AUTHENTICATE, a sessão
de envio seguro de mensagens de geração 2 é abortada e as
chaves de sessão de geração 2 são destruídas.
▼B
TCS_98 Mensagem de comando
Byte
Compri­
mento
Valor Descrição
CLA 1 «00h» CLA
INS 1 «82h» INS
P1 1 «00h» Chaves e algoritmos implicitamente conhecidos
P2 1 «00h»
Lc 1 «XXh» Lc (comprimento dos dados enviados ao cartão)
#6-#(5+L) L «XX..XXh» Autenticação da geração 1: Criptograma (ver apên­
dice 11, parte A)
Autenticação da geração 2: Assinatura gerada pelo IFD
(ver apêndice 11, parte B)
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 266
TCS_99 Mensagem de resposta
Byte
Compri­
mento
Valor Descrição
SW 2 «XXXXh» Palavras de estatuto (SW1, SW2)
— Se o comando for bem sucedido, o cartão devolve
«9000».
— Se o CHA da chave pública estabelecida não for a
concatenação do AID da aplicação tacográfica e de
um tipo de equipamento VU, o estado de processa­
mento devolvido é «6F00».
— Se o comando não for imediatamente precedido por um
comando GET CHALLENGE, o estado de processa­
mento devolvido é «6985».
A aplicação tacográfica da geração 1 pode devolver outros
códigos de erro a seguir indicados:
— Se nenhuma chave pública estiver presente no ambiente
de segurança, é devolvido «6A88».
— Se nenhuma chave privada estiver presente no ambiente
de segurança, o estado de processamento devolvido é
«6A88».
— Se a verificação do criptograma estiver errada, o estado
de processamento devolvido é «6688».
— Se a chave privada selecionada for considerada corrom­
pida, o estado de processamento devolvido é «6400» ou
«6581».
A variante de comando para a autenticação da geração 2
pode devolver ainda o seguinte código de erro:
— Se a verificação da assinatura falhar, o cartão devolve
«6300».
3.5.10 GENERAL AUTHENTICATE
Este comando, que cumpre a norma ISO/IEC 7816-4, é utilizado para
o protocolo de autenticação da pastilha (chip) da geração 2 especifi­
cada no apêndice 11, parte B.
TCS_100 O comando pode ser executado no MF, no DF Tachograph
e no DF Tachograph_G2 (ver também TCS_34).
TCS_101 Mensagem de comando
Byte
Compri­
mento
Valor Descrição
CLA 1 «00h»
INS 1 «86h»
P1 1 «00h» Chaves e protocolo implicitamente conhecidos
P2 1 «00h»
Lc 1 «NNh» Lc: comprimento do campo de dados subsequente
#6-#(5+L) L «7Ch» + L 7C +
«80h» + L 80 +
«XX..XXh»
Valor da chave pública efémera codificada DER-TLV
(ver apêndice 11)
A VU envia os objetos de dados por esta ordem.
▼M3
Le 1 «00h» Conforme a norma ISO/IEC 7816-4
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 267
TCS_102 Mensagem de resposta
Byte
Compri­
mento
Valor Descrição
#1-#L L «7Ch» + L 7C +
«81h» + «08h» +
«XX..XXh» + «82h»
+ L 82 + «XX..XXh»
Dados de autenticação dinâmica codificados
DER-TLV: nonce e testemunho de autenticação
(ver apêndice 11)
SW 2 «XXXXh» Palavras de estatuto (SW1, SW2)
— Se o comando for bem sucedido, o cartão devolve
«9000».
— O cartão devolve «6A80» para indicar parâmetros in­
corretos no campo de dados.
— O cartão devolve «6982» se o comando EXTERNAL
AUTHENTICATE não tiver sido executado com êxito
A resposta «7Ch» objeto de dados de autenticação dinâ­
mica:
— deve esta presente se a operação for bem sucedida, ou
seja, as palavras de estatuto são «9000»;
— deve estar ausente no caso de um erro de execução ou
erro de verificação, ou seja, se as palavras de estatuto
estiverem no intervalo «6400»-«6FFF», e
— pode estar ausente em caso de alerta, ou seja, se as
palavras de estatuto estiverem no intervalo «6200»-
-«63FF».
3.5.11 MANAGE SECURITY ENVIRONMENT
Utiliza-se este comando para estabelecer uma chave pública com fins
de autenticação.
3.5.11.1 C o m a n d o d a g e r a ç ã o 1 — p a r d e r e s p o s t a
Este comando cumpre a norma ISO/IEC 7816-4. A comparar com a
norma, a sua utilização é restrita.
TCS_103 Este comando é aceite apenas por uma aplicação tacográ­
fica da geração 1.
TCS_104 A chave referenciada no campo de dados MSE mantém-se
como chave pública em curso até ao próximo comando
MSE correto, até ser selecionado um DF ou até o cartão
ser reinicializado.
TCS_105 Se a chave referenciada não estiver (já) presente no cartão,
o ambiente de segurança mantém-se inalterado.
TCS_106 Mensagem de comando
Byte
Compri­
mento
Valor Descrição
CLA 1 «00h» CLA
INS 1 «22h» INS
P1 1 «C1h» P1: chave referenciada válida para todas as operações
criptográficas
P2 1 «B6h» P2 (dados referenciados relativos à assinatura digital)
Lc 1 «0Ah» Lc: comprimento do campo de dados subsequente
#6 1 «83h» Marcador para referenciar uma chave pública em casos
assimétricos
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 268
Byte
Compri­
mento
Valor Descrição
#7 1 «08h» Comprimento da referência da chave (identificador da
chave)
#8-#15 8 «XX..XXh» Identificador de chave, conforme especifica o apên­
dice 11
TCS_107 Mensagem de resposta
Byte
Compri­
mento
Valor Descrição
SW 2 «XXXXh» Palavras de estatuto (SW1, SW2)
— Se o comando for bem sucedido, o cartão devolve
«9000».
— Se a chave referenciada não estiver presente no cartão,
o estado de processamento devolvido é «6A88».
— Se no formato de envio seguro de mensagens faltarem
alguns objetos de dados esperados, o estado de proces­
samento «6987» é devolvido. O que pode ocorrer se
faltar o marcador «83h».
— Se alguns objetos de dados estiverem incorretos, o es­
tado de processamento devolvido é «6988». O que pode
ocorrer se o comprimento do identificador de chave não
for «08h».
— Se a chave selecionada for considerada corrompida, o
estado de processamento devolvido é «6400» ou
«6581».
3.5.11.2 C o m a n d o d a g e r a ç ã o 2 — p a r e s d e r e s p o s t a
Para a autenticação da geração 2 o cartão tacográfico é compatível
com as versões infra do comando MSE:SET, que cumprem a norma
ISO/IEC 7816-4. Estas versões de comando não são compatíveis com
a autenticação da geração 1.
3.5.11.2.1 M S E : S E T A T p a r a a u t e n t i c a ç ã o d a p a s t i l h a ( c h i p )
Utiliza-se o comando MSE:SET AT a seguir indicado para selecionar
os parâmetros da autenticação da pastilha que são executados por um
comando GENERAL AUTHENTICATE subsequente.
TCS_108 O comando pode ser executado no MF, no DF Tachograph
e no DF Tachograph_G2 (ver também TCS_34).
TCS_109 Mensagem de comando MSE:SET AT para autentica­
ção da pastilha
Byte
Compri­
mento
Valor Descrição
CLA 1 «00h»
INS 1 «22h»
P1 1 «41h» Definir para autenticação interna
P2 1 «A4h» Autenticação
Lc 1 «NNh» Lc: comprimento do campo de dados subsequente
#6-#(5+L) L «80h» +
«0Ah» +
«XX..XXh»
Referência do mecanismo criptográfico codificado
DER-TLV: Identificador de objeto de autenticação da
pastilha (apenas valor, o marcador «06h» é omitido).
Ver apêndice 1 acerca dos valores dos identificadores de
objeto; deve ser utilizada a notação de byte. Ver apên­
dice 11 a título de orientação sobre como selecionar um
destes identificadores de objeto.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 269
3.5.11.2.2 M S E : S E T A T p a r a a u t e n t i c a ç ã o V U
Utiliza-se o comando MSE:SET AT a seguir indicado para selecionar
os parâmetros e as chaves da autenticação VU que são executados por
um comando EXTERNAL AUTHENTICATE subsequente.
TCS_110 O comando pode ser executado no MF, no DF Tachograph
e no DF Tachograph_G2 (ver também TCS_34).
TCS_111 Mensagem de comando MSE:SET AT para autentica­
ção VU
Byte
Compri­
mento
Valor Descrição
CLA 1 «00h»
INS 1 «22h»
P1 1 «81h» Definir para autenticação externa
P2 1 «A4h» Autenticação
Lc 1 «NNh» Lc: comprimento do campo de dados subsequente
#6-#(5+L) L «80h» +
«0Ah» +
«XX..XXh»
Referência do mecanismo criptográfico codificado
DER-TLV: Identificador de objeto de autenticação VU
(apenas valor, o marcador «06h» é omitido).
Ver apêndice 1 acerca dos valores dos identificadores de
objeto; deve ser utilizada a notação de byte. Ver apên­
dice 11 a título de orientação sobre como selecionar um
destes identificadores de objeto.
«83h» +
«08h» +
«XX..XXh»
Referência codificada DER-TLV da chave pública VU
pela referência do titular do certificado mencionada no
respetivo certificado.
«91h» + L 91 +
«XX..XXh»
Representação comprimida codificada DER-TLV da
chave pública efémera da VU que será utilizada durante
a autenticação da pastilha (ver apêndice 11)
3.5.11.2.3 M S E : S E T D S T
Utiliza-se o comando MSE:SET DST para definir uma chave pública:
— quer para a verificação de uma assinatura fornecida num comando
PSO: VERIFY DIGITAL SIGNATURE subsequente
— quer para a verificação da assinatura de um certificado fornecido
num comando PSO: VERIFY CERTIFICATE subsequente.
TCS_112 O comando pode ser executado no MF, no DF Tachograph
e no DF Tachograph_G2 (ver também TCS_33).
TCS_113 Mensagem de comando MSE:SET DST
Byte
Compri­
mento
Valor Descrição
CLA 1 «00h»
INS 1 «22h»
P1 1 «81h» Definir para verificação
P2 1 «B6h» Assinatura digital
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 270
Byte
Compri­
mento
Valor Descrição
Lc 1 «NNh» Lc: comprimento do campo de dados subsequente
#6-#(5+L) L «83h» +
«08h» +
«XX...XXh»
Referência codificada DER-TLV de uma chave pública,
ou seja, a referência do titular do certificado no certifi­
cado da chave pública (ver apêndice 11)
A estrutura da mensagem de resposta e as palavras de estatuto de
todas as versões de comando são dadas por:
TCS_114 Mensagem de resposta
Byte
Compri­
mento
Valor Descrição
SW 2 «XXXXh» Palavras de estatuto (SW1, SW2)
— Se o comando for bem sucedido, o cartão devolve
«9000». O protocolo foi selecionado e inicializado.
— «6A80» indica parâmetros incorretos no campo de da­
dos de comando.
— «6A88» indica que os dados referenciados (ou seja,
uma chave referenciada) não estão disponíveis.
▼M1
— Se o currentAuthenticatedTime do cartão for posterior à
data de validade da chave pública selecionada o estado
de processamento devolvido é «6A88».
Nota: No caso de um comando MSE: SET AT para auten­
ticação VU, a chave referenciada é a chave pública
VU_MA. O cartão fixa a chave pública VU_MA para uti­
lização, se esta estiver disponível na sua memória, que
combina com a referência do titular do certificado (CHR)
dada no campo de dados de comando (o cartão pode iden­
tificar as chaves públicas VU_MA através do campo CHA
do certificado). O cartão só devolve «6A 88» a este co­
mando quando apenas estiver disponível a chave pública
VU_Sign ou não houver nenhuma chave pública de
unidade-veículo disponível. Ver a definição do campo
CHA no apêndice 11 e do tipo de dados equipmentType
no apêndice 1.
Da mesma forma, no caso de um comando MSE: SET DST
que referencie um EQT (ou seja, uma VU ou um cartão)
que seja enviado para um cartão de controlo, de acordo
com o CSM_234, a chave referenciada é sempre uma chave
EQT_Sign que foi utilizada para verificação de uma assi­
natura digital. De acordo com a figura 13 do apêndice 11, o
cartão de controlo terá sempre memorizado a chave pública
EQT_Sign relevante. Em alguns casos, o cartão de controlo
pode ter memorizado a chave pública EQT_MA correspon­
dente. O cartão de controlo regula sempre a chave pública
EQT_Sign para utilização quando recebe um comando
MSE: SET DST.
▼B
3.5.12 PSO: HASH
Utiliza-se este comando para transferir, para o cartão, o resultado de
um cálculo HASH sobre alguns dados. Serve para a verificação de
assinaturas digitais. O valor de HASH é memorizado temporariamente
para o comando PSO: VERIFY DIGITAL SIGNATURE subsequente.
Este comando cumpre a norma ISO/IEC 7816-8. A comparar com a
norma, a sua utilização é restrita.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 271
Para aceitar este comando em DF Tachograph e DF Tachograph_G2 é
necessário apenas o cartão de controlo.
Outros tipos de cartões tacográficos podem ou não executar este
comando. O comando pode estar acessível ou não no MF.
A aplicação do cartão de controlo da geração 1 aceita apenas SHA-1.
TCS_115 O valor HASH memorizado temporariamente será apagado
se for calculado um novo valor HASH por meio do co­
mando PSO: HASH, se for selecionado um DF ou se o
cartão tacográfico for reinicializado.
TCS_116 Mensagem de comando
Byte
Compri­
mento
Valor Descrição
CLA 1 «00h» CLA
INS 1 «2Ah» Executar operação de segurança
P1 1 «90h» Devolver HASH CODE
P2 1 «A0h» Marcador: o campo de dados contém DO com interesse
para a função hash
Lc 1 «XXh» Comprimento Lc do campo de dados subsequente
#6 1 «90h» Marcador para HASH CODE
#7 1 «XXh» Comprimento L do HASH CODE:
«14h» na aplicação da geração 1 (ver apêndice 11,
parte A)
«20h», «30h» ou «40h» na aplicação da geração 2 (ver
apêndice 11, parte B)
#8-#(7+L) L «XX..XXh» HASH CODE
TCS_117 Mensagem de resposta
Byte
Compri­
mento
Valor Descrição
SW 2 «XXXXh» Palavras de estatuto (SW1, SW2)
— Se o comando for bem sucedido, o cartão devolve
«9000».
— Se faltarem alguns objetos de dados esperados (cf. es­
pecificação supra), o estado de processamento «6987»
é devolvido. O que pode ocorrer se faltar um dos mar­
cadores «90h».
— Se alguns objetos de dados estiverem incorretos, o es­
tado de processamento devolvido é «6988». Este erro
ocorre se o marcador necessário estiver presente mas
com comprimento diferente de «14h» para SHA-1,
«20h» para SHA-256, «30h» para SHA-384, «40h»
para SHA-512 (aplicação da geração 2).
3.5.13 PERFORM HASH of FILE
Este comando não cumpre a norma ISO/IEC 7816-8. Por conseguinte,
o seu byte CLA indica que existe uma utilização privada do PER­
FORM SECURITY OPERATION / HASH.
Para aceitar este comando em DF Tachograph e DF Tachograph_G2
são necessários apenas o cartão de condutor e o cartão da oficina.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 272
Outros tipos de cartões tacográficos podem ou não executar este
comando. Se uma empresa ou cartão de controlo o executar, o co­
mando será executado conforme se especifica neste capítulo.
O comando pode ou não estar acessível no MF. Em caso afirmativo, é
executado conforme se especifica neste capítulo, ou seja, não permite
o cálculo de um valor HASH, mas interrompe-se com um código de
erro adequado.
TCS_118 O comando PERFORM HASH OF FILE utiliza-se para
controlar a área de dados do EF transparente selecionado
no momento.
TCS_119 Um cartão tacográfico aceita este comando apenas para os
EF enumerados no capítulo 4 em DF_Tachograph e
DF_Tachograph_G2, com a seguinte exceção: um cartão
tacográfico não é compatível com o comando para o EF
Sensor_Installation_Data do DF Tachograph_G2.
TCS_120 O resultado da operação HASH é memorizado temporaria­
mente no cartão, podendo ser utilizado para obter uma
assinatura digital do ficheiro, por intermédio do comando
PSO: COMPUTE DIGITAL SIGNATURE.
▼M1
TCS_121 O valor HASH OF FILE memorizado temporariamente será
apagado se for calculado um novo valor HASH OF FILE
por meio do comando PERFORM HASH OF FILE, se for
selecionado um DF ou se o cartão tacográfico for
reinicializado.
▼B
TCS_122 A aplicação tacográfica da geração 1 é compatível com
SHA-1.
▼M1
TCS_123 A aplicação tacográfica da geração 2 é compatível com o
algoritmo SHA-2 (SHA-256, SHA-384 ou SHA-512), es­
pecificado pela sequência de cifras constante do apêndice
11 parte B para a chave de assinatura do cartão Card_Sign.
▼B
TCS_124 Mensagem de comando
▼M1
Byte
Compri­
mento
Valor Descrição
CLA 1 «80h» CLA
INS 1 «2Ah» Executar operação de segurança
P1 1 «90h» Marcador: Hash
P2 1 «00h» Algoritmo implicitamente conhecido
Para a aplicação tacográfica de geração 1: SHA-1
Para a aplicação tacográfica de geração 2: algoritmo
SHA-2 (SHA-256, SHA-384 ou SHA-512), definido
pela sequência de cifras constante do apêndice 11 parte
B para a chave de assinatura do cartão Card_Sign
▼B
TCS_125 Mensagem de resposta
Byte
Compri­
mento
Valor Descrição
SW 2 «XXXXh» Palavras de estatuto (SW1, SW2)
— Se o comando for bem sucedido, o cartão devolve
«9000».
— Se o EF atual não permitir este comando (EF Sen­
sor_Installation_Data no DF Tachograph_G2), o estado
de processamento «6985» é devolvido.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 273
— Se o EF selecionado for considerado corrompido (erros
de integridade nos atributos do ficheiro ou nos dados
memorizados), o estado de processamento devolvido é
«6400» ou «6581».
— Se o ficheiro selecionado não for transparente ou se não
houver EF no momento, o estado de processamento
devolvido é «6986».
3.5.14 PSO: COMPUTE DIGITAL SIGNATURE
▼M1
Utiliza-se este comando para calcular a assinatura digital do código
HASH previamente calculado (ver PERFORM HASH OF FILE,
ponto 3.5.13.
Para aceitar este comando em DF Tachograph e DF Tachograph_G2
são necessários apenas o cartão de condutor e o cartão da oficina.
Outros tipos de cartões tacográficos podem ou não executar este
comando. No caso da aplicação tacográfica de geração 2, só o cartão
de condutor e o cartão de oficina possuem uma chave de assinatura de
geração 2, os restantes cartões não conseguem executar com sucesso o
comando e terminar com um código de erro adequado.
O comando pode estar ou não acessível no MF. Se não estiver aces­
sível no MF, interrompe-se com um código de erro adequado.
Este comando cumpre a norma ISO/IEC 7816-8. A comparar com a
norma, a sua utilização é restrita.
▼B
TCS_126 Este comando não calcula uma assinatura digital de código
HASH previamente calculado com o comando PSO:
HASH.
TCS_127 A chave privada do cartão é utilizada para calcular a assi­
natura digital e é implicitamente conhecida pelo cartão.
TCS_128 A aplicação tacográfica da geração 1 executa uma assina­
tura digital por um método de preenchimento que cumpre
PKCS1 (ver apêndice 11 para mais pormenores).
TCS_129 A aplicação tacográfica da geração 2 calcula uma assinatura
digital baseada na curva elíptica (ver apêndice 11 para mais
pormenores).
TCS_130 Mensagem de comando
Byte
Compri­
mento
Valor Descrição
CLA 1 «00h» CLA
INS 1 «2Ah» Executar operação de segurança
P1 1 «9Eh» Assinatura digital a devolver
P2 1 «9Ah» Marcador: o campo de dados contém dados a assinar.
Como nenhum campo de dados é incluído, assume-se
que os dados estão já presentes no cartão (HASH OF
FILE)
Le 1 «NNh» Comprimento da assinatura esperada
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 274
TCS_131 Mensagem de resposta
Byte
Compri­
mento
Valor Descrição
#1-#L L «XX..XXh» Assinatura do HASH previamente calculado
SW 2 «XXXXh» Palavras de estatuto (SW1, SW2)
— Se o comando for bem sucedido, o cartão devolve
«9000».
— Se a chave privada implicitamente selecionada for con­
siderada corrompida, o estado de processamento devol­
vido é «6400» ou «6581».
— Se o HASH calculado num comando PERFORM
HASH OF FILE anterior não estiver disponível, o es­
tado de processamento devolvido é «6985».
3.5.15 PSO: VERIFY DIGITAL SIGNATURE
Utiliza-se este comando para verificar a assinatura digital, fornecida
sob a forma de entrada, cujo HASH é conhecido pelo cartão. O
algoritmo da assinatura é implicitamente conhecido pelo cartão.
Este comando cumpre a norma ISO/IEC 7816-8. A comparar com a
norma, a sua utilização é restrita.
Para aceitar este comando em DF Tachograph e DF Tachograph_G2 é
necessário apenas o cartão de controlo.
Outros tipos de cartões tacográficos podem executar ou não este
comando. O comando pode estar acessível ou não no MF.
TCS_132 O comando VERIFY DIGITAL SIGNATURE utiliza sem­
pre a chave pública selecionada pelo anterior comando
MANAGE SECURITY ENVIRONMENT MSE: SET
DST e o anterior HASH CODE introduzido por um co­
mando PSO: HASH.
TCS_133 Mensagem de comando
▼M1
Byte
Compri­
mento
Valor Descrição
CLA 1 «00h» CLA
INS 1 «2Ah» Executar operação de segurança
P1 1 «00h»
P2 1 «A8h» Marcador: campo de dados contém DO com interesse
para verificação
Lc 1 «XXh» Comprimento Lc do campo de dados subsequente
#6 1 «9Eh» Marcador para assinatura digital
#7 ou
#7-#8
L «NNh» ou
«81 NNh»
Comprimento da assinatura digital (L tem 2 bytes se a
assinatura digital for superior a 127 bytes):
128 bytes codificados em conformidade com o apêndice
11, parte A, para a aplicação tacográfica da geração 1
Dependendo da curva selecionada para a aplicação taco­
gráfica da geração 2 (ver apêndice 11, parte B).
#(7+L)-
-#(6+L+NN)
NN «XX..XXh» Conteúdo da assinatura digital
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 275
TCS_134 Mensagem de resposta
Byte
Compri­
mento
Valor Descrição
SW 2 «XXXXh» Palavras de estatuto (SW1, SW2)
— Se o comando for bem sucedido, o cartão devolve
«9000».
— Se a verificação da assinatura falhar, o estado de pro­
cessamento devolvido é «6688». O processo de verifi­
cação é descrito no apêndice 11.
— Se nenhuma chave pública for selecionada, o estado de
processamento devolvido é «6A88».
— Se faltarem alguns objetos de dados esperados (cf. es­
pecificação supra), o estado de processamento «6987» é
devolvido. O que pode ocorrer se faltar um dos marca­
dores exigidos.
— Se não estiver disponível nenhum HASH CODE para
processar o comando (em resultado de um anterior co­
mando PSO: HASH), o estado de processamento devol­
vido é «6985».
— Se alguns objetos de dados estiverem incorretos, o es­
tado de processamento devolvido é «6988». O que pode
ocorrer se o comprimento de um dos objetos de dados
exigidos for incorreto.
— Se a chave pública selecionada for considerada corrom­
pida, o estado de processamento devolvido é «6400» ou
«6581».
▼M1
— Se a chave pública selecionada (utilizada para verificar
a assinatura digital) tiver um CHA.LSB (CertificateHol­
derAuthorisation.equipmentType) que não se adeque à
verificação da assinatura digital de acordo com o apên­
dice 11, o estado de processamento devolvido é
«6985».
▼B
3.5.16 PROCESS DSRC MESSAGE
Utiliza-se este comando para verificar a integridade e a autenticidade
da mensagem DSRC e para decifrar os dados comunicados a partir de
uma VU a uma autoridade de controlo ou a uma oficina, através da
ligação DSRC. O cartão deriva a chave de encriptação e a chave
MAC utilizada para proteger a mensagem DSRC, conforme descrito
no apêndice 11, parte B, capítulo 13.
Para aceitar este comando em DF Tachograph_G2 são necessários
apenas o cartão de controlo e o cartão da oficina.
Outros tipos de cartões tacográficos podem executar ou não este
comando, mas não terão uma chave de segurança DSRC. Por conse­
guinte, estes cartões não podem executar o comando com êxito, mas
interrompem-se com um código de erro adequado.
O comando pode estar acessível ou não no MF e/ou no DF Tacho­
graph. Em caso afirmativo, interrompe-se com um código de erro
adequado.
TCS_135 A chave de segurança DSRC é acessível apenas no DF
Tachograph_G2, ou seja, o cartão de controlo e de oficina
é compatível com uma execução bem sucedida do comando
apenas no DF Tachograph_G2.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 276
TCS_136 O comando apenas decifra os dados DSRC e verifica a
soma criptográfica de teste, mas não interpreta os dados
de entrada.
TCS_137 A ordem dos objetos de dados no campo de dados de
comando é fixada por esta especificação.
TCS_138 Mensagem de comando
Byte
Compri­
mento
Valor Descrição
CLA 1 «80h» CLA de uso privado
INS 1 «2Ah» Executar operação de segurança
P1 1 «80h» Dados da resposta: valor simples
P2 1 «B0h» Dados do comando: valor simples codificado em
BER-TLV e que inclui SM DO
Lc 1 «NNh» Comprimento Lc do campo de dados subsequente
#6-#(5+L) L «87h» + L 87 +
«XX..XXh»
Byte indicador de preenchimento do conteúdo codificado
DER-TLV seguido por carga útil do tacógrafo encrip­
tada. Para o byte indicador de preenchimento do con­
teúdo utiliza-se o valor «00h» («nenhuma indicação adi­
cional», de acordo com a norma ISO/IEC 7816-4:2013,
quadro 52). Relativamente ao mecanismo de criptografia
ver apêndice 11, parte B, capítulo 13.
Os valores permitidos para o comprimento L 87 são os
múltiplos do comprimento de bloco AES mais 1 para o
byte indicador de preenchimento do conteúdo, ou seja,
de 17 a 193 bytes, inclusive.
Nota: Ver ISO/IEC 7816-4:2013, quadro 49, para o ob­
jeto de dados SM com marcador «87h».
«81h» +
«10h»
Modelo de referência do controlo codificado DER-TLV
para a confidencialidade que encadeia a concatenação
dos elementos de dados seguintes (ver apêndice 1
DSRCSecurityData e apêndice 11, parte B, capítulo 13):
— validação cronológica de 4 bytes
— contador de 3 bytes
— número de série da VU de 8 bytes
— versão da chave de segurança DSRC de 1 byte
Nota: Ver ISO/IEC 7816-4:2013, quadro 49, para o ob­
jeto de dados SM com marcador «81h».
«8Eh» +
L 8E +
«XX..XXh»
MAC codificado DER-TLV através da mensagem
DSRC. Relativamente ao algoritmo e ao cálculo MAC,
ver apêndice 11, parte B, capítulo 13.
Nota: Ver ISO/IEC 7816-4:2013, quadro 49, para o ob­
jeto de dados SM com marcador «8Eh».
▼M3
Le 1 «00h» Conforme a norma ISO/IEC 7816-4
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 277
TCS_139 Mensagem de resposta
Byte
Compri­
mento
Valor Descrição
#1-#L L «XX..XXh» Ausente (no caso de um erro) ou dados decifrados
(preenchimento removido)
SW 2 «XXXXh» Palavras de estatuto (SW1, SW2)
— Se o comando for bem sucedido, o cartão devolve
«9000».
— «6A80» indica parâmetros incorretos no campo de da­
dos de comando (utilizado igualmente no caso de os
objetos de dados não serem enviados na ordem especi­
ficada).
— «6A88» indica que os dados referenciados não estão
disponíveis, ou seja, a chave de segurança DSRC refe­
renciada não está disponível.
— «6900» indica que a verificação da soma criptográfica
de teste ou a desencriptação dos dados falhou.
▼M1
— «6985» indica que o selo temporal de 4-bytes fornecido
no campo de dados do comando é anterior ao cardVa­
lidityBegin ou posterior à cardExpiryDate.
▼B
4. ESTRUTURA DOS CARTÕES TACOGRÁFICOS
Esta secção especifica as estruturas de ficheiro dos cartões tacográfi­
cos para memorização de dados acessíveis.
Não especifica estruturas internas dependentes do fabricante do cartão,
como, por exemplo, cabeçalhos do ficheiro, nem a memorização ou o
manuseamento de elementos de dados necessários unicamente para uti­
lização interna, como , ,­
ou .
TCS_140 Um cartão tacográfico da geração 2 acolhe o ficheiro prin­
cipal MF e uma aplicação tacográfica da geração 1 e da
geração 2 do mesmo tipo (por exemplo, aplicações para
cartão de condutor).
TCS_141 Um cartão tacográfico aceita, pelo menos, o número mí­
nimo de registos especificados para as aplicações corres­
pondentes e não aceita mais registos do que o número
máximo de registos especificados para as aplicações
correspondentes.
▼M3
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 especi­
ficado em TCS_150 e TCS_158.
▼B
Relativamente ao controlo de acesso utilizado nas regras de
acesso ao longo deste capítulo, consultar o capítulo 3.3. De
um modo geral, o modo de acesso «read» denota o co­
mando READ BINARY com byte INS par e, se aceite,
ímpar, à exceção do EF Sensor_Installation_Data no cartão
da oficina (ver TCS_156 e TCS_160). O modo de acesso
«update» denota o comando UPDATE BINARY com byte
INS par e, se aceite, ímpar, e o modo de acesso «select» o
comando SELECT.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 278
4.1. Ficheiro principal MF
TCS_142 Uma vez personalizado, o ficheiro principal MF terá per­
manentemente as seguintes estrutura de ficheiro e regras de
acesso do ficheiro:
Nota: Ao SFID do identificador EF curto é atribuído um
número decimal: por exemplo, o valor 30 corresponde a
11110 em binário.
Neste quadro, utiliza-se a seguinte abreviatura para o con­
trolo de acesso:
SC1 ALW OR SM-MAC-G2
TCS_143 Todas as estruturas de EF são transparentes.
TCS_144 O ficheiro principal MF tem a seguinte estrutura de dados:
TCS_145 O ficheiro elementar EF DIR contém os seguintes objetos
de dados relacionados com a aplicação: «61 08 4F 06 FF
54 41 43 48 4F 61 08 4F 06 FF 53 4D 52 44 54»
TCS_146 O ficheiro elementar EF ATR/INFO estará presente se o
cartão tacográfico indicar no seu ATR que aceita o au­
mento dos campos de comprimento. Neste caso, o EF
ATR/INFO conterá o aumento do objeto de dados da in­
formação de comprimento (DO«7F66»), conforme a norma
ISO/IEC 7816-4:2013 (cláusula 12.7.1).
TCS_147 O ficheiro elementar EF Extended_Length está presente se
o cartão tacográfico indicar no seu ATR que aceita o au­
mento dos campos de comprimento. Neste caso, o EF con­
tém o seguinte objeto de dados: «02 01 xx», onde o valor
«xx» indica se o aumento dos campos de comprimento é
aceite para o protocolo T = 1 e/ou T = 0.
O valor «01» indica suporte do aumento do campo de
comprimento para o protocolo T = 1.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 279
O valor «10» indica suporte do aumento do campo de
comprimento para o protocolo T = 0.
O valor «11» indica suporte do aumento do campo de
comprimento para o protocolo T = 1 e o T = 0.
4.2. Aplicações para cartão de condutor
4.2.1 Aplicação para cartão de condutor da geração 1
TCS_148 Uma vez personalizada, a aplicação para cartão de condutor
da geração 1 terá permanentemente as seguintes estrutura
de ficheiro e regras de acesso do ficheiro:
Neste quadro utilizam-se as seguintes abreviaturas para o
controlo de acesso:
SC1 ALW OR SM-MAC-G2
SC2 ALW OR SM-MAC-G1 OR SM-MAC-G2
SC3 SM-MAC-G1 OR SM-MAC-G2
TCS_149 Todas as estruturas de EF são transparentes.
TCS_150 A aplicação para cartão de condutor da geração 1 tem a
seguinte estrutura de dados:
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 280
► (1) (2) M3
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 281
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 282
TCS_151 Os valores seguintes, que servem para fornecer as dimen­
sões no quadro anterior, são os valores mínimos e máximos
do número de registos que a estrutura de dados do cartão
de condutor deve utilizar para a aplicação da geração 1:
4.2.2 Aplicação para cartão de condutor da geração 2
▼M3
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_Authenti­
cation, EF GNSS_Places_Authentication, EF Bor­
der_Crossings, EF Load_Unload_Operations, EF
VU_Configuration e EF Load_Type_Entries apenas es­
tã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.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 283
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
▼B
TCS_153 Todas as estruturas de EF são transparentes.
▼M3
TCS_154 A aplicação para cartão de condutor da geração 2 tem a
seguinte estrutura de dados:
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 284
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 285
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 286
TCS_155 Os valores seguintes, que servem para fornecer as dimen­
sões no quadro anterior, são os valores mínimos e máximos
do número de registos que a estrutura de dados do cartão
de condutor deve utilizar numa aplicação da geração 2:
▼M3
Mín. Máx.
n 1 NoOfEventsPerType 12 12
n 2 NoOfFaultsPerType 24 24
n 3 NoOfCardVehicleRecords 200 200
n 4 NoOfCardPlaceRecords 112 112
n 6 CardActivityLengthRange 13776 bytes
(56 dias * 117 mudan­
ças de atividade)
13776 bytes
(56 dias * 117 mudan­
ças de atividade)
n 7 NoOfCardVehicleUnitRecords 200 200
n 8 NoOfGNSSADRecords 336 336
n 9 NoOfSpecificConditionRecords 112 112
n 10 NoOfBorderCrossingRecords 1120 1120
n 11 NoOfLoadUnloadRecords 1624 1624
n 12 NoOfLoadTypeEntryRecords 336 336
n 13 VuConfigurationLengthRange 3072 bytes 3072 bytes
▼B
4.3. Aplicações para cartão de oficina
4.3.1 Aplicação para cartão de oficina da geração 1
TCS_156 Uma vez personalizada, a aplicação para cartão de oficina
da geração 1 terá permanentemente as seguintes estrutura
de ficheiro e regras de acesso do ficheiro:
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 287
Neste quadro utilizam-se as abreviaturas seguintes para o
controlo de acesso:
SC1 ALW OR SM-MAC-G2
SC2 ALW OR SM-MAC-G1 OR SM-MAC-G2
SC3 SM-MAC-G1 OR SM-MAC-G2
▼M1
SC4 Para o comando READ BINARY com byte INS par:
(SM-C-MAC-G1 E SM-R-ENC-MAC-G1) OU
(SM-C-MAC-G2 E SM-R-ENC-MAC-G2)
Para o comando READ BINARY com byte INS
ímpar (quando aceite): NEV
▼B
TCS_157 Todas as estruturas de EF são transparentes.
TCS_158 A aplicação para cartão de oficina da geração 1 tem a
seguinte estrutura de dados:
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 288
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 289
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 290
TCS_159 Os valores seguintes, que servem para fornecer as dimen­
sões no quadro anterior, são os valores mínimos e máximos
do número de registos que a estrutura de dados do cartão
de oficina deve utilizar para a aplicação da geração 1:
4.3.2 Aplicação para cartão de oficina da geração 2
▼M3
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_Authenti­
cation, EF GNSS_Places_Authentication, EF Bor­
der_Crossings, EF Load_Unload_Operations, EF
VU_Configuration e EF Load_Type_Entries apenas es­
tã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.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 291
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
▼B
TCS_161 Todas as estruturas de EF são transparentes.
TCS_162 A aplicação para cartão de oficina da geração 2 tem a
seguinte estrutura de dados:
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 292
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 293
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 294
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 295
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 296
TCS_163 Os valores seguintes, que servem para fornecer as dimensões
no quadro anterior, são os valores mínimos e máximos do
número de registos que a estrutura de dados do cartão de
oficina deve utilizar numa aplicação da geração 2:
▼M3
Mín. Máx.
n 1 NoOfEventsPerType 3 3
n 2 NoOfFaultsPerType 6 6
n 3 NoOfCardVehicleRecords 8 8
n 4 NoOfCardPlaceRecords 8 8
n 5 NoOfCalibrationRecords 255 255
n 6 CardActivityLengthRange 492 bytes (1 dia * 240
mudanças de atividade)
492 bytes (1 dia *
240 mudanças de ativi­
dade)
n 7 NoOfCardVehicleUnitRecords 8 8
n 8 NoOfGNSSADRecords 24 24
n 9 NoOfSpecificConditionRecords 4 4
n 10 NoOfBorderCrossingRecords 4 4
n 11 NoOfLoadUnloadRecords 8 8
n 12 NoOfLoadTypeEntryRecords 4 4
n 13 VuConfigurationLengthRange 3072 bytes 3072 bytes
▼B
4.4. Aplicações para cartão de controlo
4.4.1 Aplicação para cartão de controlo da geração 1
TCS_164 Uma vez personalizada, a aplicação para cartão de controlo
da geração 1 terá permanentemente as seguintes estrutura
de ficheiro e regras de acesso do ficheiro do ficheiro:
Neste quadro utilizam-se as abreviaturas seguintes para o
controlo de acesso:
SC1 ALW OR SM-MAC-G2
SC2 ALW OR SM-MAC-G1 OR SM-MAC-G2
SC3 SM-MAC-G1 OR SM-MAC-G2
SC6 EXT-AUT-G1 OU SM-MAC-G1 OR SM-MAC-G2
TCS_165 Todas as estruturas de EF são transparentes.
TCS_166 A aplicação para cartão de controlo da geração 1 tem a
seguinte estrutura de dados:
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 297
TCS_167 Os valores seguintes, que servem para fornecer as dimen­
sões no quadro anterior, são os valores mínimos e máximos
do número de registos que a estrutura de dados do cartão
de controlo deve utilizar para a aplicação da geração 1:
4.4.2 Aplicação para cartão de controlo da geração 2
▼M3
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.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 298
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_Configura­
tion 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
▼B
TCS_169 Todas as estruturas de EF são transparentes.
TCS_170 A aplicação para cartão de controlo da geração 2 tem a
seguinte estrutura de dados:
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 299
▼B
TCS_171 Os valores seguintes, que servem para fornecer as dimen­
sões no quadro anterior, são os valores mínimos e máximos
do número de registos que a estrutura de dados do cartão
de controlo deve utilizar numa aplicação da geração 2:
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 300
Mín. Máx.
n 7 NoOfControlActivityRecords 230 520
n 13 VuConfigurationLengthRange 3072 bytes 3072 bytes
▼B
4.5. Aplicações para cartão de empresa
4.5.1 Aplicação para cartão de empresa da geração 1
TCS_172 Uma vez personalizada, a aplicação para cartão de empresa
da geração 1 terá permanentemente as seguintes estrutura
de ficheiro e regras de acesso do ficheiro:
Neste quadro utilizam-se as abreviaturas se­
guintes para o controlo de acesso:
SC1 ALW OR SM-MAC-G2
SC2 ALW OR SM-MAC-G1 OR SM-MAC-
-G2
SC3 SM-MAC-G1 OR SM-MAC-G2
SC6 EXT-AUT-G1 OU SM-MAC-G1 OR
SM-MAC-G2
TCS_173 Todas as estruturas de EF são transparentes.
TCS_174 A aplicação para cartão de empresa da geração 1 tem a
seguinte estrutura de dados:
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 301
TCS_175 Os valores seguintes, que servem para fornecer as dimen­
sões no quadro anterior, são os valores mínimos e máximos
do número de registos que a estrutura de dados do cartão
de empresa deve utilizar numa aplicação da geração 1:
4.5.2 Aplicação para cartão de empresa da geração 2
▼M3
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_Configura­
tion 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
▼B
TCS_177 Todas as estruturas de EF são transparentes.
TCS_178 A aplicação para cartão de empresa da geração 2 tem a
seguinte estrutura de dados:
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 302
▼B
TCS_179 Os valores seguintes, que servem para fornecer as dimen­
sões no quadro anterior, são os valores mínimos e máximos
do número de registos que a estrutura de dados do cartão
de empresa deve utilizar numa aplicação da geração 2:
▼M3
Mín. Máx.
n 8 NoOfCompanyActivityRecords 230 520
n 13 VuConfigurationLengthRange 3072 bytes 3072 bytes
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 303
Apêndice 3
PICTOGRAMAS
PIC_001 O tacógrafo pode, opcionalmente, utilizar os seguintes pictogramas e
combinações de pictograma (ou pictogramas e combinação de picto­
gramas suficientemente semelhantes para serem inequivocamente
identificáveis com estes):
1. PICTOGRAMAS BÁSICOS
Pessoas Ações Modos de funciona­mento
Empresa Modo de empresa
Controlador Controlo Modo de controlo
Condutor Condução Modo de operação
Oficina/estação de ensaio Inspeção/calibração Modo de calibração
Fabricante
Atividades Duração
Disponível Período de disponibilidade em curso
Condução Tempo de condução contínuo
Descanso Período de descanso em curso
Outro trabalho Período de trabalho em curso
Pausa Tempo acumulado de pausas
Desconhecido
Equipamento Funções
Ranhura do condutor
Ranhura do ajudante
Cartão
Relógio
Visor Visualização
Memorização externa Descarregamento
Alimentação elétrica
Impressora Impressão
Sensor
Medida do pneumático
Veículo/ unidade-veículo
Módulo GNSS
Sistema de deteção à distância
Interface ITS
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 304
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
▼B
Diversos
Incidentes Falhas
Início do período de trabalho diário Final do período de trabalho
diário
Localização
Introdução manual das atividades do
condutor
▼M3
Segurança/dados autenticados/selos
▼B
Velocidade
Hora
Total/síntese
▼M3
Mapa digital/travessia de fronteiras
▼B
Qualificadores
24h Diariamente
Semanalmente
Quinzenalmente
De ou para
2. COMBINAÇÕES DE PICTOGRAMAS
Diversos
Lugar do controlo
Local de início do período de trabalho
diário
Local de final do período de tra­
balho diário
▼M1
Posição após três horas de tempo de
condução acumulado
▼B
Das horas Às horas
Do veículo
Início de fora de âmbito Final de fora de âmbito
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 305
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
▼B
Cartões
Cartão de condutor
Cartão de empresa
Cartão de controlo
Cartão de oficina
Ausência de cartão
Condução
Condução em regime de tripulação
Tempo de condução por uma semana
Tempo de condução por duas semanas
Impressão
Atividades do condutor, com base na impressão diária do cartão
Atividades do condutor, com base na impressão diária da VU
Incidentes e falhas, com base na impressão do cartão
Incidentes e falhas, com base na impressão da VU
Impressão de dados técnicos
Impressão de excesso de velocidade
▼M3
Impressão do histórico de cartões inseridos
▼B
Incidentes
Inserção de cartão não válido
Conflito de cartões
Sobreposição de tempos
Condução sem cartão adequado
Inserção de cartão durante a condução
Última sessão de cartão encerrada incorretamente
Excesso de velocidade
Interrupção da alimentação elétrica
Erro nos dados de movimento
Conflito relativo ao movimento do veículo
Violação da segurança
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 306
Conflito de tempos ou ajustamento do tempo (pela oficina)
▼B
Controlo do excesso de velocidade
▼M1
Ausência de informações sobre a posição do recetor GNSS ou Erro de
comunicação com o módulo GNSS externo
Erro de comunicação com o módulo de comunicação à distância
▼M3
Anomalia do GNSS
▼B
Falhas
Falha do cartão (ranhura do condutor)
Falha do cartão (ranhura do ajudante)
Falha do visor
Falha do descarregamento
Falha da impressora
Falha do sensor
Falha interna da VU
Falha do GNSS
Falha da deteção à distância
Procedimento de introdução manual de dados
Ainda o mesmo período de trabalho diário?
Final do anterior período de trabalho?
Confirmar ou introduzir local do final do período de trabalho
Introduzir hora do início
Introduzir local do início do período de trabalho.
Nota: O apêndice 4 apresenta outras combinações de pictogramas para
formar carateres de impressão ou identificadores de registo.
▼M1
02016R0799 — PT — 21.08.2023 — 003.002 — 307
Apêndice 4
IMPRESSÃO
ÍNDICE
1. GENERALIDADES
2. ESPECIFICAÇÕES RELATIVAS AOS BLOCOS DE DADOS
3. ESPECIFICAÇÕES APLICÁVEIS À IMPRESSÃO
3.1. Atividades de condutor, na impressão diária dos cartões
3.2. Atividades de condutor, na impressão diária da VU
3.3. Incidentes e falhas, da impressão dos cartões
3.4. Incidentes e falhas, da impressão da VU
3.5. Impressão de dados técnicos
3.6. Impressão do excesso de velocidade
3.7 Histórico de cartões inseridos
1. GENERALIDADES
Cada impressão é concretizada encadeando diversos blocos de dados,
eventualmente identificados por um identificador de bloco.
Um bloco de dados contém um ou mais registos, eventualmente iden­
tificados por um identificador de registo.
PRT_001 Se um identificador de bloco preceder imediatamente um
identificador de registo, este último não é impresso.
PRT_002 Caso um atributo de dado seja desconhecido ou não deva ser
impresso por razões associadas a direitos de acesso aos da­
dos, são impressos espaços no seu lugar.
PRT_003 Se o conteúdo de uma linha inteira for desconhecido ou não
precisar de ser impresso, a linha inteira é omitida.
PRT_004 Os campos relativos a dados numéricos são impressos com
alinhamento à direita, com um espaço de separação entre
milhares e milhões e sem zeros não significativos.
▼M3
PRT_005 Os campos relativos a dados em sequência são impressos
com alinhamento à esquerda e, conforme necessário, preen­
chidos 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
PRT_006 No caso de uma quebra de linha devido a texto longo, deve
ser impresso um caráter especial (ponto a meia altura da
linha, «•») como primeiro caráter na nova linha.
2. ESPECIFICAÇÕES RELATIVAS AOS BLOCOS DE DADOS
Nesta secção, aplicam-se as seguintes convenções à notação de formato:
— carateres a negro (bold) indicam texto normal a imprimir (a impres­
são vem em carateres normais),
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 308
— carateres normais indicam variáveis (pictogramas ou dados) a subs­
tituir pelos seus valores para impressão
— ao lado dos nomes das variáveis acrescentam-se travessões que in­
dicam o comprimento de atributo de dados disponível para cada
variável
— as datas são especificadas pelo formato «dd/mm/aaaa» (dia, mês,
ano), podendo também utilizar-se um formato «dd.mm.aaaa»
— o termo «identificação do cartão» traduz-se pela seguinte composi­
ção: tipo do cartão, mediante uma combinação de pictogramas; có­
digo do Estado-Membro emissor do cartão; barra inclinada para a
frente; número do cartão (com os índices de substituição e de reno­
vação separados por um espaço:
P x x x / x x x x x x x x x x x x x x x x
C
om
bi
na
çõ
es
d
e
pi
ct
og
ra
m
as
d
o
ca
r-

tã
o
C
ód
ig
o
do

E
st
ad
o-
M
em
br
o
em
is
so
r
Primeiros 14 carateres do número do cartão
(que inclui eventualmente um índice consecutivo)
Ín
di
ce
d
e
su
bs
ti
tu
iç
ão

Ín
di
ce
d
e
re
no
va
çã
o
▼M3
— 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 determi­
nada, 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 ver­
sões),
— ** dados apenas disponíveis na GEN2, versão 2.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 309
PRT_007 Na impressão utilizam-se os seguintes blocos de dados e/ou registos de
dados, com os seguintes significados e formatos:
► (1) (2) (3) (4) (5) M3
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 310
► (1) (2) (3) M3
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 311
► (1) (2) M3
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 312
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 313
► (1) (2) (3) (4) M3
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 314
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 315
► (1) M3
3. ESPECIFICAÇÕES APLICÁVEIS À IMPRESSÃO
Nesta secção aplicam-se as seguintes convenções de notação:
N Número de bloco ou de registo de impressão N
N
Número de bloco ou de registo de impressão N, repetido as vezes
necessárias
X/Y
Blocos ou registos de impressão X e/ou Y, conforme necessário e
repetidos as vezes necessárias
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 316
3.1. Atividades de condutor, na impressão diária dos cartões
▼M3
PRT_008 As atividades de condutor, na impressão diária do cartão,
devem respeitar o seguinte formato:
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 317
3.2. Atividades de condutor, na impressão diária da VU
▼M3
PRT_009 As atividades de condutor, na impressão diária da VU, de­
vem respeitar o seguinte formato:
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 318
3.3. Incidentes e falhas, da impressão dos cartões
PRT_010 Os incidentes e falhas, na impressão diária do cartão, devem
respeitar o seguinte formato:
1 Data e hora de impressão do documento
2 Tipo de impressão
3 Identificação do controlador (se inserido um cartão de controlo na
VU + GEN)
3 Identificação do condutor (com base no cartão que é alvo da impres­
são)
4 Identificação do veículo (veículo do qual a impressão é tomada)
12.2 Delimitador de incidentes
12.4 Registos de incidentes (todos os incidentes memorizados no cartão)
12.3 Delimitador de falhas
12.4
Registos de falhas (todas as falhas memorizadas no cartão)
22.1 Local do controlo
22.2 Assinatura do controlador
22.5 Assinatura do condutor
3.4. Incidentes e falhas, da impressão da VU
PRT_011 Os incidentes e falhas, na impressão diária da VU, devem
respeitar o seguinte formato:
1 Data e hora de impressão do documento
2 Tipo de impressão
3
Identificação do titular do cartão (para todos os cartões inseridos na
VU + GEN)
4 Identificação do veículo (veículo do qual a impressão é tomada)
13.2 Delimitador de incidentes
13.4
Registos de incidentes (todos os incidentes memorizados ou em curso
na VU)
13.3 Delimitador de falhas
13.4
Registos de falhas (todas as falhas memorizadas ou em curso na VU)
22.1 Local do controlo
22.2 Assinatura do controlador
22.5 Assinatura do condutor
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 319
3.5. Impressão de dados técnicos
▼M3
PRT_012 A impressão de dados técnicos deve respeitar o seguinte
formato:
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 320
3.6. Impressão do excesso de velocidade
PRT_013 A impressão do excesso de velocidade deve respeitar o se­
guinte formato:
1 Data e hora de impressão do documento
2 Tipo de impressão
3
Identificação do titular do cartão (para todos os cartões inseridos na
VU + GEN)
4 Identificação do veículo (veículo do qual a impressão é tomada)
20 Informação relativa ao controlo do excesso de velocidade
21.1 Identificador dos dados de excesso de velocidade
21.4 / 21.5 Primeiro excesso de velocidade desde a última calibração
21.2 Identificador dos dados de excesso de velocidade
21.4 / 21.5
Os cinco incidentes mais graves de excesso de velocidade dos últimos
365 dias
21.3 Identificador dos dados de excesso de velocidade
21.4 / 21.5 O mais grave excesso de velocidade de cada um dos últimos 10 dias
22.1 Local do controlo
22.2 Assinatura do controlador
22.5 Assinatura do condutor
3.7. Histórico de cartões inseridos
PRT_014 A impressão do histórico de cartões inseridos deve respeitar
o seguinte formato:
▼M3
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 321
Apêndice 5
VISUALIZAÇÃO
No presente apêndice, aplicam-se as seguintes convenções à notação de formato:
— carateres a negro (bold) indicam texto normal a visualizar (a visualização
vem em carateres normais),
— carateres normais indicam variáveis (pictogramas ou dados) a substituir pelos
seus valores na visualização,
— dd mm aaaa: dia, mês, ano
— hh: horas
— mm: minutos
— D: pictograma de duração
— EF: combinação de pictogramas de incidente ou falha
— O: pictograma de modo de funcionamento
DIS_001 O tacógrafo deve exibir os dados mediante os seguintes formatos:
Dados Formato
Visualização por defeito
Hora local
Modo de funcionamento
Informação relativa ao condutor
Informação relativa ao ajudante
Condição «fora de âmbito» aberta
Visualização de alerta
Ultrapassagem do tempo de condução contínua
Incidente ou falha
Outras visualizações
Data UTC
tempo
Tempo de condução contínua e pausas acumuladas do con­
dutor
Tempo de condução contínua e pausas acumuladas do aju­
dante
Tempo acumulado de condução contínua do condutor nas
semanas anterior e em curso
Tempo acumulado de condução contínua do ajudante nas
semanas anterior e em curso
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 322
Apêndice 6
CONECTOR DA FRENTE PARA CALIBRAÇÃO E DESCARREGA­
MENTO
ÍNDICE
1. EQUIPAMENTO INFORMÁTICO
1.1. Connector
1.2. Distribuição dos contactos
1.3. Diagrama de blocos
2. INTERFACE DE DESCARREGAMENTO
3. INTERFACE DE CALIBRAÇÃO
1. EQUIPAMENTO INFORMÁTICO
1.1. Conector
INT_001 O conector de descarregamento/calibração deve ser de 6 pinos,
acessível no painel frontal sem necessidade de desligar qualquer
peça do tacógrafo, e deve corresponder ao seguinte esquema
(dimensões em milímetros):
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 323
O diagrama seguinte indica uma ficha de ligação de 6 pinos
típica:
1.2. Distribuição dos contactos
INT_002 Os contactos distribuem-se em conformidade com a seguinte
tabela:
Pino Descrição Observação
1 Polo negativo da bateria Ligado ao polo negativo da bateria do veículo
2 Comunicação de dados Linha-K (ISO 14230-1)
3 Descarregamento RxD Entrada de dados no tacógrafo
4 Sinal de entrada/saída Calibração
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 324
Pino Descrição Observação
5 Valor permanente de potência
de saída
A tensão nominal é igual à do veículo subtraída de 3 V,
tendo em conta a queda de tensão através do circuito de
proteção
Saída de 40 mA
6 Descarregamento TxD Saída de dados do tacógrafo
1.3. Diagrama de blocos
INT_003 O diagrama de blocos deve obedecer ao seguinte esquema:
2. INTERFACE DE DESCARREGAMENTO
INT_004 A interface de descarregamento deve cumprir as especificações
RS232.
INT_005 A interface de descarregamento deve utilizar 1 bit de início, 8
bits de dados LSB first, 1 bit de paridade e 1 bit de paragem.
Organização dos bytes de dados
Bit de início: um bit com nível lógico 0
Bits de dados: transmitidos com LSB first
Bit de paridade: paridade par
Bit de paragem: um bit com nível lógico 1
Se forem transmitidos dados numéricos compostos por mais de um byte, o
byte mais significativo é transmitido em primeiro lugar e o menos signi­
ficativo em último lugar.
INT_006 A frequência dos báudios de transmissão deve ser ajustável de
9 600 bps a 115 200 bps. A transmissão deve ser concretizada à
velocidade mais elevada possível, fixando-se a frequência em
9 600 bps uma vez iniciada a comunicação.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 325
3. INTERFACE DE CALIBRAÇÃO
INT_007 A comunicação de dados deve obedecer à norma ISO 14230-1
Road Vehicles — Diagnostic systems — Keyword protocol
2000 — Part 1: Physical layer, First edition: 1999.
INT_008 O sinal de entrada/saída deve cumprir a seguinte especificação
elétrica:
Parâmetro Mínimo Típico Máximo Observação
U low (in) 1,0 V I = 750 μA
U high (in) 4 V I = 200 μA
Frequência 4 kHz
U low (out) 1,0 V I = 1 mA
U high (out) 4 V I = 1 mA
INT_009 O sinal de entrada/saída deve cumprir os seguintes diagramas
cronológicos:
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 326
Apêndice 7
PROTOCOLOS APLICÁVEIS AO DESCARREGAMENTO DE DADOS
ÍNDICE
1. INTRODUÇÃO
1.1. Âmbito de aplicação
1.2. Acrónimos e notações
2. DESCARREGAMENTO DE DADOS DE UMA VU
2.1. Procedimento relativo ao descarregamento
2.2. Protocolo de descarregamento dos dados
2.2.1 Estrutura da mensagem
2.2.2 Tipos de mensagens
2.2.2.1 Start Communication Request (SID 81)
2.2.2.2 Positive Response Start Communication (SID C1)
2.2.2.3 Start Diagnostic Session Request (SID 10)
2.2.2.4 Positive Response Start Diagnostic (SID 50)
2.2.2.5 Link Control Service (SID 87)
2.2.2.6 Link Control Positive Response (SID C7)
2.2.2.7 Request Upload (SID 35)
2.2.2.8 Positive Response Request Upload (SID 75)
2.2.2.9 Transfer Data Request (SID 36)
2.2.2.10 Positive Response Transfer Data (SID 76)
2.2.2.11 Request Transfer Exit (SID 37)
2.2.2.12 Positive Response Request Transfer Exit (SID 77)
2.2.2.13 Stop Communication Request (SID 82)
2.2.2.14 Positive Response Stop Communication (SID C2)
2.2.2.15 Acknowledge Sub Message (SID 83)
2.2.2.16 Negative Response (SID 7F)
2.2.3 Fluxo de mensagens
2.2.4 Temporização
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 327
2.2.5 Tratamento de erros
2.2.5.1 Fase de início da comunicação
2.2.5.2 Fase de Comunicação
2.2.6 Conteúdo da mensagem de resposta
▼M3
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)
2.2.6.6 Positive Response Transfer Data Technical Data (Dados técnicos dos
dados de transferência de resposta posiviva)
▼B
2.3. Memorização de ficheiros ESM
3. PROTOCOLO APLICÁVEL AO DESCARREGAMENTO DE DA­
DOS DE CARTÕES TACOGRÁFICOS
3.1. Âmbito de aplicação
3.2. Definições
3.3. Descarregamento do cartão
3.3.1 Sequência de inicialização
3.3.2 Sequência para ficheiros de dados não assinados
3.3.3 Sequência para ficheiros de dados assinados
3.3.4 Sequência para reinicializar o contador de calibração.
3.4. Formato de memorização dos dados
3.4.1 Introdução
3.4.2 Formato do ficheiro
4. DESCARREGAMENTO DE UM CARTÃO TACOGRÁFICO VIA
UMA UNIDADE-VEÍCULO.
1. INTRODUÇÃO
O presente apêndice especifica os procedimentos a adotar na execução
dos diversos tipos de descarregamento de dados para meios externos de
memorização ou armazenamento (ESM), juntamente com os protocolos
que se devem aplicar para assegurar a transferência correta dos dados e
a compatibilidade total do formato dos dados descarregados, a fim de
que um controlador, antes de os analisar, possa inspecioná-los e con­
trolar a sua autenticidade e a sua integridade.
▼M1
1.1. Âmbito de aplicação
Pode haver descarregamento de dados para um ESM:
— a partir de uma unidade-veículo, por meio de um equipamento
dedicado inteligente (IDE) ligado à unidade-veículo (VU),
— a partir de um cartão tacográfico, por meio de um IDE equipado
com dispositivo de interface para o cartão (IFD),
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 328
— a partir de um cartão tacográfico, via uma unidade-veículo, por
meio de um IDE ligado a essa VU.
Para possibilitar a verificação da autenticidade e da integridade dos
dados descarregados memorizados num ESM, o descarregamento é
feito com uma assinatura apensa em conformidade com o apêndice
11 (Mecanismos comuns de segurança). A identificação do
equipamento-fonte (VU ou cartão) e os respetivos certificados de se­
gurança (Estado-Membro e equipamento) são também descarregados. O
verificador dos dados deve possuir, independentemente, uma chave
pública europeia aprovada.
Os dados descarregados de uma VU são assinados utilizando os Me­
canismos comuns de segurança, Parte B (sistema tacográfico de se­
gunda geração) do apêndice 11, exceto quando o controlo dos condu­
tores é efetuado por uma autoridade de controlo que não pertença à
UE, utilizando um cartão de controlo de primeira geração, em cujo
caso os dados são assinados utilizando os Mecanismos comuns de
segurança, Parte A (sistema tacográfico de primeira geração) do apên­
dice 11, tal como solicitado pelo requisito MIG_015 Migração do
apêndice 15.
O presente apêndice especifica, por conseguinte, dois tipos de descar­
regamento de dados da VU:
— Dados descarregados da VU de geração 2, com a estrutura de dados
da geração 2, assinados com os Mecanismos comuns de segurança,
Parte B do apêndice 11,
— Dados descarregados da VU de geração 1, com a estrutura de dados
da geração 1, assinados com os Mecanismos comuns de segurança,
Parte A do apêndice 11.
Da mesma maneira, há dois tipos de dados de descarregamentos de
cartões de condutor de segunda geração inseridos numa VU, tal como
se especifica nos pontos 3 e 4 do presente apêndice.
▼B
1.2. Acrónimos e notações
No presente apêndice, utilizam-se os seguintes acrónimos:
AID Identificador de aplicação
ATR Resposta à reinicialização
CS Byte de soma de teste
DF Ficheiro dedicado
DS_ Sessão de diagnóstico
EF Ficheiro elementar
ESM Meio externo de memorização ou armazenamento
FID Identificador de ficheiro (ID de ficheiro)
FMT Byte de formato (primeiro byte de um cabeçalho de mensa­
gem)
ICC Cartão com circuito integrado
IDE Equipamento dedicado inteligente: o equipamento utilizado
para executar o descarregamento dos dados para o ESM (por
exemplo, computador pessoal)
IFD Dispositivo de interface
KWP Protocolo de palavra-chave 2000
LEN Byte de comprimento (último byte de um cabeçalho de men­
sagem)
PPS Seleção dos parâmetros do protocolo
PSO Executar operação de segurança
SID Identificador de serviço
SRC Byte-fonte
TGT Byte-alvo
▼M1
02016R0799 — PT — 21.08.2023 — 003.002 — 329
TLV Valor do comprimento de um marcador
TREP Parâmetro de resposta de transferência
TRTP Parâmetro de pedido de transferência
VU Unidade-veículo
2. DESCARREGAMENTO DE DADOS DE UMA VU
2.1. Procedimento relativo ao descarregamento
Para descarregar dados de uma VU, o utilizador executa as seguintes
operações:
— inserir o cartão tacográfico numa ranhura da VU (*)
— ligar o IDE ao conector de descarregamento da VU
— estabelecer a ligação entre o IDE e a VU
— selecionar no IDE os dados a descarregar e enviar o pedido à VU
— encerrar a sessão de descarregamento.
2.2. Protocolo de descarregamento dos dados
O protocolo é estruturado numa base «mestre-escravo» (ou principal/
/secundário), em que o IDE desempenha o papel de mestre e a VU o de
escravo.
A estrutura, os tipos e o fluxo da mensagem baseiam-se principalmente
no Protocolo de palavra-chave 2000 (KWP) (norma ISO 14230-2 Road
vehicles — Diagnostic systems — Keyword protocol 2000 — Part 2:
Data link layer).
O nível de aplicação (application layer) baseia-se principalmente no
atual projeto da norma ISO 14229-1 (Road vehicles — Diagnostic
systems — Part 1: Diagnostic services, versão 6, de 22 de fevereiro
de 2001).
2.2.1 Estrutura da mensagem
DDP_002 Todas as mensagens trocadas entre o IDE e a VU são
formatadas com uma estrutura dividida em três partes:
— cabeçalho, composto por um byte de formato (FMT),
um byte-alvo (TGT), um byte-fonte (SRC) e, possivel­
mente, um byte de comprimento (LEN)
— campo de dados, composto por um byte de identificador
de serviço (SID) e um número variável de bytes de
dados, que podem incluir um byte opcional de sessão
de diagnóstico (DS_) ou um byte opcional de parâmetro
de transferência (TRTP ou TREP)
— soma de teste, composta por um byte de soma de
teste (CS).
Cabeçalho Campo de dados Soma de teste
FMT TGT SRC LEN SID
DA­
DOS
… … … CS
4 bytes Máx. 255 bytes 1 byte
Os bytes TGT e SRC representam o endereço físico do
destinatário e do emitente da mensagem. Os valores são
F0 Hex para o IDE e EE Hex para a VU.
O byte LEN é o comprimento da parte campo de dados.
▼B
(*) O cartão inserido desencadeia os devidos direitos de acesso à função de descarregamento
e aos dados. Contudo, deve ser possível descarregar dados de um cartão de condutor
inserido numa das ranhuras da VU quando não está inserido outro tipo de cartão na
outra ranhura.
02016R0799 — PT — 21.08.2023 — 003.002 — 330
O byte soma de teste é o módulo 256 da série soma de 8 bits de
todos os bytes da mensagem, excluindo o próprio CS.
Os bytes FMT, SID, DS_, TRTP e TREP serão definidos
adiante.
DDP_003 Nos casos em que os dados a transportar pela mensagem
sejam superiores ao espaço disponível na parte campo de
dados, a mensagem é dividida em várias submensagens,
cada uma das quais contém um cabeçalho, os mesmos
SID e TREP e um contador de submensagem de 2 bytes
indicando o número da submensagem no contexto da men­
sagem total. Para verificar erros e abortar, o IDE reconhece
cada uma das submensagens. O IDE pode aceitar a submen­
sagem, pedir a sua retransmissão, pedir o recomeço à VU ou
abortar a transmissão.
DDP_004 Se a última submensagem contiver exatamente 255 bytes no
campo de dados, deve ser apensa uma submensagem final com
um campo de dados vazio (excetuando SID, TREP e o contador
dessa submensagem), para indicar que terminou a mensagem.
Exemplo:
Cabeçalho SID TREP Mensagem CS
4 bytes Comprimento superior a 255 bytes
é transmitido sob a seguinte forma:
Cabeçalho SID TREP 00 01 Submensagem 1 CS
4 bytes 255 bytes
Cabeçalho SID TREP 00 02 Submensagem 2 CS
4 bytes 255 bytes
…
Cabeçalho SID TREP xx yy Submensagem n CS
4 bytes Menos de 255 bytes
ou sob a seguinte forma:
Cabeçalho SID TREP 00 01 Submensagem 1 CS
4 bytes 255 bytes
Cabeçalho SID TREP 00 02 Submensagem 2 CS
4 bytes 255 bytes
…
Cabeçalho SID TREP xx yy Submensagem n CS
4 bytes 255 bytes
Cabeçalho SID TREP xx yy + 1 CS
4 bytes 4 bytes
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 331
2.2.2 Tipos de mensagens
O protocolo de comunicação para descarregamento de dados entre a
VU e o IDE exige o intercâmbio de 8 tipos diferentes de mensagens.
O quadro seguinte sintetiza essas mensagens.
▼M3
Estrutura da mensagem Máx. 4 Bytes Máx. 255 Bytes 1 byte
Cabeçalho Dados
Soma de
teste
IDE ->
Start Communication Request 81 EE F0 81 E0
Positive Response Start Communica­
tion
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
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 332
Estrutura da mensagem Máx. 4 Bytes Máx. 255 Bytes 1 byte
Cabeçalho Dados
Soma de
teste
IDE ->
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 Communica­
tion
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 se­
quence 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 compati­
bilidade com a norma ISO 14229. Significa o mesmo que «descar­
regamento» (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.
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 333
— 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 des­
carregamento 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 descarre­
gamento 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 descarrega­
mento específicos do fabricante.
▼B
2.2.2.1 S t a r t C o m m u n i c a t i o n R e q u e s t ( S I D 8 1 )
DDP_005 Esta mensagem é emitida pelo IDE para estabelecer o elo de
comunicação com a VU. As comunicações iniciais são sem­
pre executadas a 9 600 bauds (até o número de bauds ser
alterado por meio dos serviços competentes de controlo de
elo).
2.2.2.2 P o s i t i v e R e s p o n s e S t a r t C o m m u n i c a t i o n ( S I D C 1 )
DDP_006 Esta mensagem é emitida pela VU em resposta positiva a
um pedido de começo da comunicação. Inclui os 2
bytes-chave «EA» e «8F», o que indica que a unidade é
compatível com o protocolo com cabeçalho, incluindo in­
formação sobre o alvo, a fonte e o comprimento.
2.2.2.3 S t a r t D i a g n o s t i c S e s s i o n R e q u e s t ( S I D 1 0 )
DDP_007 A mensagem Start Diagnostic Session Request é emitida
pelo IDE para pedir uma nova sessão de diagnóstico com
a VU. A subfunção «default session» ou «sessão por de­
feito» (81 Hex) indica que vai ser aberta uma sessão normal
de diagnóstico.
2.2.2.4 P o s i t i v e R e s p o n s e S t a r t D i a g n o s t i c ( S I D 5 0 )
DDP_008 A mensagem Positive Response Start Diagnostic é enviada
pela VU em resposta positiva ao Diagnostic Session Re­
quest.
2.2.2.5 L i n k C o n t r o l S e r v i c e ( S I D 8 7 )
DDP_052 O Link Control Service é utilizado pelo IDE para iniciar
uma modificação no número de bauds, o que ocorre em
duas fases. Na primeira fase, o IDE propõe a modificação
do número de bauds, indicando o novo ritmo. Ao receber
uma mensagem positiva da VU, o IDE envia-lhe a confir­
mação da modificação no número de bauds (segunda fase) e
adota o novo ritmo. Depois de receber a confirmação, a VU
passa, por sua vez, para o novo número de bauds.
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 334
2.2.2.6 L i n k C o n t r o l P o s i t i v e R e s p o n s e ( S I D C 7 )
DDP_053 A VU emite a mensagem Link Control Positive Response
em resposta positiva ao pedido de Link Control Service
(primeira fase). Note-se que não é dada resposta ao pedido
de confirmação (segunda fase).
2.2.2.7 R e q u e s t U p l o a d ( S I D 3 5 )
DDP_009 O IDE emite a mensagem Request Upload para especificar à
VU que é pedida uma operação de descarregamento. Em
cumprimento da norma ISO 14229, são incluídos elementos
sobre o endereço, o tamanho e o formato dos dados pedidos.
Como o IDE os desconhece antes de um descarregamento, o
endereço da memória é colocado a 0, o formato é desen­
criptado e descomprimido e o tamanho da memória é fixado
no máximo.
2.2.2.8 P o s i t i v e R e s p o n s e R e q u e s t U p l o a d ( S I D 7 5 )
DDP_010 Esta mensagem é enviada pela VU para indicar ao IDE que
está pronta para descarregar dados. Em cumprimento da
norma ISO 14229, nesta mensagem de resposta positiva
são incluídos dados que indicam ao IDE que as futuras
mensagens de Positive Response Transfer Data (resposta
positiva ao pedido de transferência de dados) incluirão no
máximo 00FF hex bytes.
2.2.2.9 T r a n s f e r D a t a R e q u e s t ( S I D 3 6 )
▼M1
DDP_011 Esta mensagem (pedido de transferência de dados) é enviada
pelo IDE para especificar à VU o tipo dos dados que devem
ser descarregados. O tipo de transferência é indicado por um
Transfer Request Parameter (TRTP ou parâmetro de pedido
de transferência) de um byte.
▼M3
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 trans­
ferência:
Tipo de transferência de dados
Valor TRTP para o descarrega­
mento de dados
da VU de tipo geração 1
Valor TRTP para o descarrega­
mento de dados
da VU de tipo geração 2, ver­
são 1
Valor TRTP para o descarrega­
mento de dados
da VU de tipo geração 2, ver­
são 2
Versão da interface de des­
carregamento
Não utilizado Não utilizado 00
Panorâmica 01 21 31
Atividades de uma data espe­
cificada
02 22 32
Incidentes e falhas 03 23 33
Velocidade detalhada 04 24 24
Dados técnicos 05 25 35
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 335
Data transfer
type
TRTP value
Card download 06
▼M3
DDP_054 Durante uma sessão de descarregamento, o IDE tem obri­
gatoriamente 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)
▼B
2.2.2.10 P o s i t i v e R e s p o n s e T r a n s f e r D a t a ( S I D 7 6 )
DDP_012 Esta mensagem é enviada pela VU em resposta positiva a
Transfer Data Request (pedido de transferência de dados).
Contém os dados pedidos, com um TREP (Transfer Res­
ponse Parameter ou parâmetro de resposta de transferência)
correspondente ao TRTP do pedido.
▼M3
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 mensa­
gem é a seguinte:
▼M1
— certificados de segurança,
— identificação do veículo,
— data e hora atuais da VU,
— data descarregável mínima e máxima (dados da VU),
— indicação de presença de cartões na VU,
— descarregamento prévio para uma empresa,
— bloqueios de empresa,
— controlos prévios.
▼B
2.2.2.11 R e q u e s t T r a n s f e r E x i t ( S I D 3 7 )
DDP_013 A mensagem Request Transfer Exit (saída do pedido de
transferência) é enviada pelo IDE para informar a VU de
que a sessão de descarregamento está terminada.
2.2.2.12 P o s i t i v e R e s p o n s e R e q u e s t T r a n s f e r E x i t ( S I D 7 7 )
DDP_014 Esta mensagem é enviada pela VU para acusar a mensagem
Request Transfer Exit.
▼M1
02016R0799 — PT — 21.08.2023 — 003.002 — 336
2.2.2.13 S t o p C o m m u n i c a t i o n R e q u e s t ( S I D 8 2 )
DDP_015 Esta mensagem é enviada pelo IDE para desligar o elo de
comunicação com a VU.
2.2.2.14 P o s i t i v e R e s p o n s e S t o p C o m m u n i c a t i o n ( S I D C 2 )
DDP_016 Esta mensagem é enviada pela VU para acusar a mensagem
Stop Communication Request.
2.2.2.15 A c k n o w l e d g e S u b M e s s a g e ( S I D 8 3 )
DDP_017 Esta mensagem é enviada pelo IDE para confirmar a rece­
ção de cada parte de uma mensagem que seja transmitida
sob a forma de diversas submensagens. O campo de dados
contém o SID recebido da VU e um código de 2 bytes, a
saber:
— MsgC + 1 acusa a receção correta da submensagem
n. o MsgC.
Pedido do IDE à VU para que envie a submensagem
seguinte
— MsgC indica um problema na receção da submensagem
n. o MsgC.
Pedido do IDE à VU para que envie novamente a
submensagem.
— FFFF pede que a mensagem seja interrompida.
O IDE pode recorrer a este código para parar, por al­
guma razão, a transmissão da mensagem da VU.
A última submensagem de uma mensagem (byte LEN

destes códigos, ou não ser acusada.
A resposta da VU que consiste em diversas submensagens é
a seguinte:
— Positive Response Transfer Data (SID 76)
2.2.2.16 N e g a t i v e R e s p o n s e ( S I D 7 F )
DDP_018 Quando a VU não consegue satisfazer os pedidos contidos
nas mensagens supramencionadas, envia esta mensagem. O
campo de dados desta mensagem contém o SID da resposta
(7F), o SID do pedido e um código que especifica a razão
da resposta negativa. São os seguintes os códigos disponí­
veis:
— 10 rejeição geral
A ação não pode ser executada por uma razão não con­
templada adiante.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 337
— 11 serviço não compatível
O SID do pedido não é entendido.
— 12 subfunção não compatível
O DS_ ou o TRTP do pedido não são entendidos ou não
há mais submensagens a transmitir.
— 13 comprimento de mensagem incorreto
O comprimento da mensagem recebida está errado.
— 22 condições incorretas ou erro de sequência do pedido
O serviço requerido não está ativo ou a sequência das
mensagens de pedido não é correta.
— 31 pedido fora de alcance
O registo do parâmetro de pedido (campo de dados) não
é válido.
— 50 carregamento não aceite
O pedido não pode ser executado (VU num modo de
funcionamento inadequado ou falha interna da VU).
— 78 resposta pendente
A ação pedida não pode ser completada a tempo e a VU
não está preparada para aceitar outro pedido.
▼M1
— FA dados não disponíveis
O objeto de um pedido de transferência de dados não
está disponível na VU (por exemplo, não há cartão in­
serido, descarregamento de dados de geração 1 solici­
tado da VU fora do quadro de controlo do condutor por
autoridade de controlo de país terceiro, etc.).
▼B
2.2.3 Fluxo de mensagens
O fluxo típico de mensagens durante um procedimento normal de
descarregamento de dados é o seguinte:
IDE VU
Start Communication Request ⇨
⇦ Positive Response
Start Diagnostic Service Request ⇨
⇦ Positive Response
Request Upload ⇨
⇦ Positive Response
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 338
IDE VU
Transfer Data Request Overview ⇨
⇦ Positive Response
Transfer Data Request #2 ⇨
⇦ Positive Response #1
Acknowledge Sub Message #1 ⇨
⇦ Positive Response #2
Acknowledge Sub Message #2 ⇨
⇦ Positive Response #m
Acknowledge Sub Message #m ⇨
⇦ Positive Response (Data Field
Acknowledge Sub Message (optional) ⇨
…
Transfer Data Request #n ⇨
⇦ Positive Response
Request Transfer Exit ⇨
⇦ Positive Response
Stop Communication Request ⇨
⇦ Positive Response
2.2.4 Temporização
DDP_019 Durante o funcionamento normal, destacam-se os parâme­
tros de temporização indicados no esquema seguinte:
Esquema 1
Fluxo de mensagens, temporização
Em que:
P1 = intervalo interbytes para a resposta da VU.
P2 = intervalo entre o final do pedido do IDE e o começo
da resposta da VU, ou entre o final da acusação por
parte do IDE e o começo da resposta seguinte da VU.
P3 = intervalo entre o final da resposta da VU e o começo
do novo pedido do IDE ou entre o final da resposta
da VU e o começo da acusação por parte do IDE ou
ainda entre o final do pedido do IDE e o começo de
novo pedido do IDE se a VU não responder.
P4 = intervalo interbytes para o pedido do IDE.
P5 = valor alargado de P3 para descarregamento de cartões.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 339
Os valores autorizados para os parâmetros de temporização
são indicados no quadro seguinte (conjunto de parâmetros
de temporização alargado do KWP, utilizado em caso de
endereçamento físico para maior rapidez de comunicação):
Parâmetro de temporização
Valor do limite inferior
(mm)
Valor do limite máximo
(mm)
P1 0 20
P2 20 1 000 (*)
P3 10 5 000
P4 5 20
P5 10 20 minutos
(*) Se a VU responder com uma Negative Response contendo um código que signifique «pedido corretamente
recebido, resposta pendente», este valor é alargado para o mesmo limite superior de P3.
2.2.5 Tratamento de erros
Se ocorrer um erro durante o intercâmbio de mensagens, o fluxo é
modificado, consoante o equipamento que tiver detetado o erro e a
mensagem que lhe tiver dado origem.
Nos esquemas 2 e 3 são indicados os procedimentos de tratamento de
erros, respetivamente para a VU e para o IDE.
2.2.5.1 F a s e d e i n í c i o d a c o m u n i c a ç ã o
DDP_020 Se o IDE detetar um erro durante a fase de início da comu­
nicação, quer pela temporização quer pela sucessão de bits,
aguarda durante um período P3mín antes de emitir nova­
mente o pedido.
DDP_021 Se a VU detetar um erro na sequência proveniente do IDE,
não envia qualquer resposta e aguarda nova mensagem Start
Communication Request durante um período P3máx.
2.2.5.2 F a s e d e C o m u n i c a ç ã o
Podem definir-se duas áreas distintas de tratamento de erros:
1. A VU deteta um erro de transmissão do IDE
DDP_022 Por cada mensagem recebida, a VU deteta erros de tem­
porização, erros de formato dos bytes (por exemplo, vio­
lações nos bits de início e de fim) e erros de enquadra­
mento (número errado de bytes recebidos, byte errado de
soma de teste).
DDP_023 Se a VU detetar um dos erros supra, não envia qualquer
resposta e ignora a mensagem recebida.
DDP_024 A VU pode detetar outros erros no formato ou no con­
teúdo da mensagem recebida (por exemplo, mensagem
não aceite), mesmo que a mensagem satisfaça os requisi­
tos de comprimento e de soma de teste. Em tal caso, a
VU responde ao IDE com uma mensagem Negative Res­
ponse, especificando a natureza do erro.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 340
Figura 2
Tratamento de erros por parte da VU
▼B
2. O IDE deteta um erro de transmissão da VU
DDP_025 Por cada mensagem recebida, o IDE deteta erros de tem­
porização, erros de formato dos bytes (por exemplo, vio­
lações nos bits de início e de fim) e erros de enquadra­
mento (número errado de bytes recebidos, byte errado de
soma de teste).
DDP_026 O IDE deteta erros de sequência, como, por exemplo,
incrementos incorretos no contador de submensagens,
em mensagens recebidas sucessivamente.
DDP_027 Se o IDE detetar um erro ou não houver resposta da VU
dentro de um período P2máx, a mensagem de pedido é
novamente enviada, num máximo de três transmissões ao
todo. Para efeitos desta deteção de erro, a acusação de
uma submensagem será considerada como um pedido à
VU.
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 341
DDP_028 O IDE aguarda pelo menos durante um período P3mín
antes de iniciar cada transmissão. O período de espera é
medido a partir da última ocorrência calculada de um bit
de fim depois de detetado o erro.
Esquema 3
Tratamento de erros por parte do IDE
2.2.6 Conteúdo da mensagem de resposta
Esta secção especifica o conteúdo dos campos de dados das várias
mensagens de resposta positiva.
Os elementos de dados são definidos no apêndice 1 (Dicionário de
dados).
Observação: Em relação aos descarregamentos da geração 2, cada ele­
mento de dados de topo é representado por uma matriz de registos,
mesmo que contenha apenas um registo. A matriz de registos começa
com um cabeçalho. Este cabeçalho contém o tipo de registo, o tamanho
do registo e o número de registos. Nos quadros a seguir, as matrizes de
registo são denominadas «... RecordArray» (com cabeçalho).
▼M3
2.2.6.1 P o s i t i v e R e s p o n s e T r a n s f e r D a t a D o w n l o a d I n t e r ­
f a c e V e r s i o n ( V e r s ã o d a i n t e r f a c e d e d e s c a r r e g a ­
m e n t o d e d a d o s d e t r a n s f e r ê n c i a d e r e s p o s t a p o s i ­
t i v a )
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:
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 342
«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 P o s i t i v e R e s p o n s e T r a n s f e r D a t a O v e r v i e w ( P a n o ­
r â m i c a d e d a d o s d e t r a n s f e r ê n c i a d e r e s p o s t a p o ­
s i t i v a )
DDP_029 O campo de dados da mensagem «Positive Response
Transfer Data Overview» fornece os seguintes dados, se­
gundo a ordem indicada, sob o SID 76 Hex e o TREP 01,
21 ou 31 Hex e com uma divisão e uma contagem ade­
quadas 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 noO­
fLocks = 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 certi­
ficados) a partir de VehicleIdentificationNumber
para baixo até ao último byte do último VuCon­
trolActivityData.
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
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 343
Elemento de dados Observação
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 ca­
beç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 ca­
beçalho da matriz com noOfRecords = 0
SignatureRecordArray Assinatura ECC de todos os dados precedentes,
com exceção dos certificados.
2.2.6.3 P o s i t i v e R e s p o n s e T r a n s f e r D a t a A c t i v i t i e s ( A t i ­
v i d a d e s d e d a d o s d e t r a n s f e r ê n c i a d e r e s p o s t a p o ­
s i t i v a )
DDP_030 O campo de dados da mensagem «Positive Response
Transfer Data Activities» fornece os seguintes dados, se­
gundo a ordem indicada, sob o SID 76 Hex e o TREP 02,
22 ou 32 Hex e com uma divisão e uma contagem ade­
quadas das submensagens:
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 344
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 (in­
serção do cartão no dia anterior) ou a 24:00 (reti­
rada do cartão no dia seguinte) deve aparecer inte­
gralmente 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 (in­
serção do cartão no dia anterior) ou a 24:00 (reti­
rada do cartão no dia seguinte) deve aparecer inte­
gralmente 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
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 345
Elemento de dados Observação
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 (in­
serção do cartão no dia anterior) ou a 24:00 (reti­
rada do cartão no dia seguinte) deve aparecer inte­
gralmente 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 descar­
regado. Se o perfil estiver vazio, é enviado um cabeça­
lho da matriz com noOfRecords = 0
SignatureRecordArray Assinatura ECC de todos os dados precedentes.
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 346
2.2.6.4 P o s i t i v e R e s p o n s e T r a n s f e r D a t a E v e n t s a n d F a u l t s
( I n c i d e n t e s e f a l h a s d e d a d o s d e t r a n s f e r ê n c i a d e
r e s p o s t a p o s i t i v a )
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 con­
tagem 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 noOfVu­
Faults = 0.
VuEventData Todos os incidentes (exceto o excesso de velocidade)
memorizados ou em curso na VU.
Se o perfil estiver vazio, é enviado apenas noOfVuE­
vents = 0.
VuOverSpeedingControlData Dados relativos ao último controlo do excesso de velo­
cidade (valor por defeito se não existirem dados).
VuOverSpeedingEventData Todos os incidentes de excesso de velocidade memori­
zados na VU.
Se o perfil estiver vazio, é enviado apenas noOfVuO­
verSpeedingEvents = 0.
VuTimeAdjustmentData Todos os incidentes de ajuste de tempo memorizados na
VU (fora do enquadramento de uma calibração com­
pleta).
Se o perfil estiver vazio, é enviado apenas noOfVuTi­
meAdjRecords = 0.
Signature Assinatura RSA de todos os dados a partir de noOfVu­
Faults 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 velo­
cidade (valor por defeito se não existirem dados).
VuOverSpeedingEventRecordArray Todos os incidentes de excesso de velocidade memori­
zados na VU.
Se o perfil estiver vazio, é enviado um cabeçalho da
matriz com noOfRecords = 0
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 347
Elemento de dados Observação
VuTimeAdjustmentRecordArray Todos os incidentes de ajuste de tempo memorizados na
VU (fora do enquadramento de uma calibração com­
pleta).
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 velo­
cidade (valor por defeito se não existirem dados).
VuOverSpeedingEventRecordArray Todos os incidentes de excesso de velocidade memori­
zados 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 com­
pleta).
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 P o s i t i v e R e s p o n s e T r a n s f e r D a t a D e t a i l e d S p e e d
( V e l o c i d a d e d e t a l h a d a d e d a d o s d e t r a n s f e r ê n c i a
d e r e s p o s t a p o s i t i v a )
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 noOfS­
peedBlocks para baixo até ao último byte do último
bloco de velocidade.
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 348
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.
2.2.6.6 P o s i t i v e R e s p o n s e T r a n s f e r D a t a T e c h n i c a l D a t a
( D a d o s t é c n i c o s d o s d a d o s d e t r a n s f e r ê n c i a d e r e s ­
p o s t a p o s i t i v a )
DDP_033 O campo de dados da mensagem «Positive Response Trans­
fer Data Technical Data» fornece os seguintes dados, se­
gundo 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 vuManu­
facturerName 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
VuSensorExternalGNSSCoupledRecordAr­
ray
Todos os acoplamentos do módulo GNSS externo me­
morizados 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.
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 349
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
VuSensorExternalGNSSCoupledRecordAr­
ray
Todos os acoplamentos do módulo GNSS externo me­
morizados 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.
▼B
2.3. Memorização de ficheiros ESM
DDP_034 Se uma sessão de descarregamento tiver incluído uma trans­
ferência de dados da VU, o IDE memoriza no espaço de um
ficheiro físico único todos os dados recebidos da VU du­
rante a sessão, dentro de mensagens Positive Response
Transfer Data. Os dados memorizados não incluem cabeça­
lhos de mensagens, contadores de submensagens, submen­
sagens vazias ou somas de teste, mas incluem o SID e o
TREP (apenas da primeira submensagem, se houver várias).
3. PROTOCOLO APLICÁVEL AO DESCARREGAMENTO DE DA­
DOS DE CARTÕES TACOGRÁFICOS
3.1. Âmbito de aplicação
A presente secção incide no descarregamento direto dos dados de um
cartão tacográfico para um IDE. Como este último não faz parte do
ambiente securizado, não se efetua qualquer autenticação entre o cartão
e o IDE.
3.2. Definições
Sessão de descarregamento: Cada operação de descarregar
dados do ICC. A sessão
abrange o processo completo
desde a reinicialização do ICC
por um IFD até à desativação
do ICC (retirada do cartão ou
reinicialização seguinte).
Ficheiro de dados assinado: Um ficheiro do ICC. O ficheiro
é transferido em texto simples
para o IFD. No ICC, o ficheiro
é dividido e assinado, com
transferência da assinatura para
o IFD.
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 350
3.3. Descarregamento do cartão
▼M3
DDP_035 O descarregamento de um cartão tacográfico inclui as se­
guintes 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 ge­
rações
— Descarregar os EF em Tachograph DF:
— Descarregar o Card_Certificate e o CA_Certifi­
cate 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 Meca­
nismos comuns de segurança, Parte A do apên­
dice 11.
— É obrigatório descarregar pelo menos a Applica­
tion_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 Tacho­
graph_G2 DF:
— Descarregar o CardSignCertificate, CA_Certifi­
cate 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.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 351
— Descarregar os outros EF de dados de aplicação
(no Tachograph_G2 DF) exceto EF Card_Down­
load. Esta informação é securizada com uma as­
sinatura digital, utilizando os Mecanismos co­
muns de segurança, Parte B do apêndice 11.
— É obrigatório descarregar pelo menos a Applica­
tion_Identification, a Application_Identifica­
tion_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_Down­
load, 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 Tacho­
graph_G2 DF.
— Ao descarregar um cartão de oficina, o EF Sen­
sor_Installation_Data no Tachograph e, quando
aplicável, nos Tachograph_G2 DF não deve ser
descarregado.
▼B
3.3.1 Sequência de inicialização
DDP_036 O IDE inicia a sequência do seguinte modo:
Cartão Direção IDE/IFD Significado/Observações
⇦ Reinicialização do hardware
ATR ⇨
É opcional utilizar PPS para passar a um número mais
elevado de bauds, desde que o ICC o aceite.
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 352
3.3.2 Sequência para ficheiros de dados não assinados
DDP_037 ►M1 A sequência de descarregamento dos EF ICC, IC,
Card_Certificate (ou CardSignCertificate para o DF Tacho­
graph_G2), CA_Certificate e Link_Certificate (apenas para
o DF Tachograph_G2) é a seguinte: ◄
Cartão Direção IDE/IFD Significado/Observações
⇦ Select File Seleção por identificadores
de ficheiro
OK ⇨
⇦ READ BINARY Se o ficheiro contiver mais
dados do que o tamanho do
tampão do leitor ou do car­
tão, tem de se repetir o co­
mando até todo o ficheiro fi­
car lido.
Dados do ficheiro
OK
⇨ Memorizar dados no ESM Segundo 3.4 Data storage
format
Nota 1: Antes de selecionar o EF Card_Certificate (ou
CardSignCertificate), deve selecionar-se a aplicação tacográ­
fica (seleção por AID).
Note 2: A seleção e leitura de um ficheiro também pode ser
realizada numa única fase mediante a utilização de um co­
mando READ BINARY com um identificador EF curto.
3.3.3 Sequência para ficheiros de dados assinados
DDP_038 Utiliza-se a seguinte sequência para cada um dos seguintes
ficheiros, que têm de ser descarregados com as respetivas
assinaturas:
▼M1
Cartão Dir IDE/IFD Significado/Observações
Select File
OK
Perform Hash of File — Calcula o valor hash so­
bre o conteúdo dos dados
do ficheiro selecionado,
utilizando o algoritmo
prescrito nos termos do
apêndice 11, parte A ou
B. Este comando não é
um ISO-Command.
Calcular Hash of File e
memorizar valor Hash
temporariamente
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 353
Cartão Dir IDE/IFD Significado/Observações
OK
Read Binary Se o ficheiro contiver mais
dados do que o tampão do
leitor ou o cartão aceitar, o
comando tem de ser repetido
até todo o ficheiro ter sido
lido.
Dados do ficheiro
OK
Memorizar no ESM dados
recebidos
de acordo com 3.4 Formato
de memorização dos dados
PSO Compute Digital Sig­
nature
Executar operação de
segurança «Compute
Digital Signature» uti­
lizando o valor Hash
temporariamente me­
morizado
Assinatura
OK
Juntar os dados aos ante­
riormente memorizados no
ESM
de acordo com 3.4 Formato
de memorização dos dados
▼B
Nota: A seleção e a leitura de um ficheiro também podem
ser realizadas numa única fase, utilizando um comando
READ BINARY com um identificador EF curto. Neste
caso, o EF pode ser selecionado e lido antes de se aplicar
o comando PERFORM HASH OF FILE.
3.3.4 Sequência para reinicializar o contador de calibração.
DDP_039 É a seguinte a sequência utilizada para reinicializar o con­
tador no EF
num cartão de oficina:
Cartão Dir IDE/IFD Significado/Observações
⇦ Select File EF Card_Do-
wnload
Seleção por identificadores
de ficheiro
OK ⇨
⇦ Update Binary
NoOfCalibrationsSinceDown­
load = «00 00»
Reinicializa o número
de descarregamento do
cartão
OK ⇨
Nota: A seleção e a atualização de um ficheiro também
podem ser realizada numa única fase, utilizando um co­
mando UPDATE BINARY com um identificador EF curto.
▼M1
02016R0799 — PT — 21.08.2023 — 003.002 — 354
3.4. Formato de memorização dos dados
3.4.1 Introdução
DDP_040 Os dados descarregados têm de ser memorizados, em con­
formidade com as seguintes condições:
— Os dados devem ser memorizados transparentes. Ou
seja, na sua transferência a partir do cartão, é mantida
a ordem dos bytes, tal como a ordem dos bits dentro de
cada byte.
— Todos os ficheiros do cartão descarregados no âmbito de
uma sessão de descarregamento são memorizados num
ficheiro no ESM.
3.4.2 Formato do ficheiro
DDP_041 O formato dos ficheiros é uma concatenação de diversos
objetos de TLV.
DDP_042 O marcador para um EF é o FID mais o apêndice «00».
DDP_043 O marcador de uma assinatura de EF é o FID do ficheiro
mais o apêndice «01».
DDP_044 O comprimento é um valor de dois bytes. O valor define o
número de bytes no campo de valor. O valor «FF FF» no
campo do comprimento é reservado para utilização
posterior.
DDP_045 Se um ficheiro não for descarregado, nada que com ele se
relacione é memorizado (marcador ou comprimento zero).
▼M1
DDP_046 Uma assinatura é memorizada como o objeto TLV imedia­
tamente a seguir ao objeto TLV que contém os dados do
ficheiro.
Definição Significado Comprimento
FID (2 Bytes) || «00» Marcador para EF (FID) no
DF ou para
informação comum do car­
tão
3 bytes
FID (2 Bytes) || «01» Marcador para assinatura do
EF (FID) no
DF
3 bytes
FID (2 Bytes) || «02» Marcador para EF (FID)
no DF
3 bytes
FID (2 Bytes) || «03» Marcador para assinatura do
EF (FID) no
DF
3 bytes
xx xx Comprimento do campo de
valor
2 bytes
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 355
Exemplo dos dados num ficheiro de descarregamento para
um ESM:
Marcador Comprimento Valor
— Dados do EF ICC
— Dados do EF Card_Certificate
— ...
Dados do EF (no
DF)
Assinatura do EF
(no DF)
Dados do EF no
DF
Assinatura do EF
no DF
▼B
4. DESCARREGAMENTO DE UM CARTÃO TACOGRÁFICO VIA
UMA UNIDADE-VEÍCULO.
DDP_047 A VU deve permitir descarregar para um IDE conectado o
conteúdo de um cartão de condutor inserido.
DDP_048 Para iniciar este modo, o IDE envia à VU uma mensagem
«Transfer Data Request Card Download» (ver 2.2.2.9).
▼M1
DDP_049 Cartões de condutor de primeira geração: Os dados devem
ser descarregados utilizando-se o protocolo de descarrega­
mento de dados de primeira geração e os dados descarrega­
dos devem possuir o mesmo formato do que aqueles que
foram descarregados a partir de uma unidade-veículo de
primeira geração.
Cartões de condutor de segunda geração: A VU descarrega
então todo o cartão, ficheiro a ficheiro, em conformidade
com o protocolo de descarregamento do cartão, definido na
secção 3, e encaminha todos os dados recebidos do cartão
para o IDE dentro do formato adequado TLV do ficheiro
(ver 3.4.2) e encapsulados dentro de uma mensagem «Posi­
tive Response Transfer Data».
▼B
DDP_050 O IDE recupera os dados da mensagem «Positive Response
Transfer Data» (excluindo todos os cabeçalhos, SID, TREP,
contadores de submensagens e somas de teste) e
memoriza-os num ficheiro físico único, em conformidade
com a secção 2.3.
DDP_051 Conforme o caso, a VU atualiza então o ficheiro
ou o ficheiro
do cartão de condutor.
▼M1
02016R0799 — PT — 21.08.2023 — 003.002 — 356
Apêndice 8
PROTOCOLO APLICÁVEL À CALIBRAÇÃO
ÍNDICE
1. INTRODUÇÃO
2. TERMOS, DEFINIÇÕES E REFERÊNCIAS
3. PANORÂMICA DOS SERVIÇOS
3.1. Serviços disponíveis
3.2. Códigos de resposta
4. SERVIÇOS DE COMUNICAÇÃO
4.1. Serviço StartCommunication
4.2. Serviço StopCommunication
4.2.1 Descrição da mensagem
4.2.2 Formato da mensagem
4.2.3 Definição de parâmetros
4.3. Serviço TesterPresent
4.3.1 Descrição da mensagem
4.3.2 Formato da mensagem
5. SERVIÇOS DE GESTÃO
5.1. Serviço StartDiagnosticSession
5.1.1 Descrição da mensagem
5.1.2 Formato da mensagem
5.1.3 Definição de parâmetros
5.2. Serviço SecurityAccess
5.2.1 Descrição da mensagem
5.2.2 Formato da mensagem — SecurityAccess — requestSeed
5.2.3 Formato da mensagem — SecurityAccess — sendKey
6. SERVIÇOS DE TRANSMISSÃO DE DADOS
6.1. Serviço ReadDataByIdentifier
6.1.1 Descrição da mensagem
6.1.2 Formato da mensagem
6.1.3 Definição de parâmetros
6.2. Serviço WriteDataByIdentifier
6.2.1 Descrição da mensagem
6.2.2 Formato da mensagem
6.2.3 Definição de parâmetros
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 357
7. CONTROLO DOS IMPULSOS DE TESTE — UNIDADE FUNCIO­
NAL DE CONTROLO DE ENTRADA/SAÍDA
7.1. Serviço InputOutputControlByIdentifier
7.1.1 Descrição da mensagem
7.1.2 Formato da mensagem
7.1.3 Definição de parâmetros
▼M3
8. SERVIÇO ROUTINECONTROL (AJUSTAMENTO DO TEMPO)
8.1. Descrição da mensagem
8.2. Formato da mensagem
9. FORMATOS DOS DATARECORDS
9.1. Gamas de parâmetros transmitidos
9.2. Formatos dos dataRecords
▼B
1. INTRODUÇÃO
O presente apêndice incide no modo como os dados são intercambiados
entre uma unidade-veículo (VU) e um dispositivo de teste através da
linha K, que faz parte da interface de calibração referida no apêndice 6.
Descreve também o controlo da linha de sinal entrada/saída no conector
de calibração.
O estabelecimento das comunicações linha K é referido na secção 4 —
«Serviços de comunicação».
O presente apêndice recorre à ideia de «sessões» de diagnóstico para
determinar o âmbito do controlo da linha K sob variadas condições. A
sessão «por defeito» é a «StandardDiagnosticSession» (sessão normal
de diagnóstico), em que qualquer dado pode ser lido de uma
unidade-veículo mas nenhum dado pode ser escrito para uma
unidade-veículo.
A seleção da sessão de diagnóstico é referida na secção 5 — «Serviços
de gestão».
O presente apêndice tem de ser considerado pertinente para ambas as
gerações de VU e cartões de oficina, em conformidade com os requi­
sitos de interoperabilidade previstos no regulamento.
CPR_001 A «ECUProgrammingSession» (sessão de programação da
ECU) permite a entrada de dados na unidade-veículo.
No caso da entrada de dados de calibração, a unidade-veí­
culo deve, ademais, encontrar-se no modo de funcionamento
CALIBRAÇÃO.
A transferência de dados através da linha K é descrita na
secção 6 — «Serviços de transmissão de dados». Os forma­
tos dos dados transferidos são descritos na secção 8 —
«Formatos dos dataRecords».
CPR_002 A «ECUAdjustmentSession» permite selecionar o modo I/O
da linha de calibração de sinal I/O através da interface
linha K. O controlo da linha de calibração de sinal I/O é
descrito na secção 7 — «Controlo dos impulsos de teste —
unidade funcional de controlo de entrada/saída».
CPR_003 Ao longo do presente documento, o endereço do dispositivo
de teste é referido como «tt». Embora possa haver endereços
preferenciais para dispositivos de teste, a VU responde cor­
retamente a qualquer endereço. O endereço físico da VU é
0xEE.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 358
2. TERMOS, DEFINIÇÕES E REFERÊNCIAS
Os protocolos, mensagens e códigos de erro baseiam-se principalmente
num projeto da norma ISO 14229-1 (Road vehicles — Diagnostic
systems — Part 1: Diagnostic services, version 6 of 22 February 2001).
Utiliza-se codificação de bytes e valores hexadecimais para os identi­
ficadores de serviço, os pedidos e respostas de serviço e os parâmetros-
-padrão.
O termo «dispositivo de teste» refere-se ao equipamento utilizado para
introduzir dados de programação/calibração na VU.
Os termos «cliente» e «servidor» referem-se, respetivamente, ao dispo­
sitivo de teste e à VU.
O termo ECU significa «unidade de controlo eletrónico» (Electronic
Control Unit) e refere-se à VU.
Referências:
▼M1
ISO 14230-2: Road Vehicles — Diagnostic Systems — Keyword Pro­
tocol 2000 — Part 2: Data Link Layer.
First edition: 1999.
▼B
3. PANORÂMICA DOS SERVIÇOS
3.1. Serviços disponíveis
O quadro que se segue fornece uma panorâmica dos serviços disponí­
veis no tacógrafo e que são definidos no presente documento.
CPR_004 O quadro indica os serviços disponíveis numa sessão de
diagnóstico ativada.
— A 1 .a coluna enuncia os serviços disponíveis.
— A 2 .a coluna indica o número da secção do presente
apêndice onde o serviço é tratado com mais detalhe.
— A 3 .a coluna indica os valores dos identificadores de
serviço para mensagens de pedido.
— A 4 .a coluna especifica os serviços da
«StandardDiagnosticSession» (SD) que devem ser exe­
cutados em cada VU.
— A 5 .a coluna especifica os serviços da
«ECUAdjustmentSession» (ECUAS) que devem ser
executados para permitir o controlo da linha de sinal
I/O no conector de calibração do painel frontal da VU.
— A 6 .a coluna especifica os serviços da
«ECUProgrammingSession» (ECUPS) que devem ser
executados para permitir a programação de parâmetros
na VU.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 359
Quadro 1
Síntese de valores dos identificadores de serviços
Sessões de diagnóstico
Nome do serviço de diagnóstico
Secção
n. o
SId Valor de
pedido
SD ECUAS ECUPS
StartCommunication 4.1 81 ■ ■ ■
StopCommunication 4.2 82 ■
TesterPresent 4.3 3E ■ ■ ■
StartDiagnosticSession 5.1 10 ■ ■ ■
SecurityAccess 5.2 27 ■ ■ ■
ReadDataByIdentifier 6.1 22 ■ ■ ■
WriteDataByIdentifier 6.2 2E ■
InputOutputControlByIdentifier 7.1 2F ■
▼M3
RoutineControl 8 31 ■ ■
▼B
■ Este símbolo indica que o serviço é obrigatório na sessão de diagnóstico.
A ausência de símbolo indica que o serviço não é permitido na sessão de diagnós­
tico.
3.2. Códigos de resposta
São definidos códigos de resposta para cada serviço.
4. SERVIÇOS DE COMUNICAÇÃO
São necessários alguns serviços para estabelecer e manter uma comu­
nicação. Não aparecem no nível de aplicação. Os serviços disponíveis
figuram no seguinte quadro:
Quadro 2
Serviços de comunicações
Nome do serviço Descrição
StartCommunication O cliente pede para começar uma ses­
são de comunicação com um ou mais
servidores.
StopCommunication O cliente pede para parar a sessão de
comunicação em curso.
TesterPresent O cliente indica ao servidor que ainda
está presente.
CPR_005 O serviço StartCommunication é utilizado para desencadear
uma comunicação. Para a execução de qualquer serviço, a
comunicação tem de ser iniciada e os seus parâmetros têm
de ser adequados ao modo pretendido.
4.1. Serviço StartCommunication
CPR_006 Ao receber uma primitiva de indicação StartCommunication,
a VU verifica se o elo de comunicação solicitado pode ser
desencadeado sob as condições vigentes. As condições apli­
cáveis à iniciação de um elo de comunicação constam da
norma ISO 14230-2.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 360
CPR_007 A VU executa então as ações necessárias para desencadear o
elo de comunicação e envia uma primitiva de resposta Start­
Communication, com os parâmetros Positive Response (res­
posta positiva) selecionados.
CPR_008 Se uma VU que já tiver sido inicializada (e tiver introduzido
uma sessão de diagnóstico) receber um novo StartCommu­
nication Request (devido, p. ex., a recuperação de erro no
dispositivo de teste), este novo pedido de início de comu­
nicação é aceite e a VU reinicializa-se.
CPR_009 Se, por alguma razão, o elo de comunicação não puder ser
iniciado, a VU continua a funcionar tal como imediatamente
antes da tentativa de iniciação da ligação.
CPR_010 A mensagem StartCommunication Request deve ser fisica­
mente endereçada.
CPR_011 A VU é inicializada para serviços mediante um método de
«inicialização rápida»:
— Há um tempo morto antes de qualquer atividade.
— O dispositivo de teste envia então um modelo de inicia­
lização.
— Toda a informação necessária ao estabelecimento da co­
municação está contida na resposta da VU.
CPR_012 Após a conclusão da inicialização:
— Todos os parâmetros de comunicação são colocados em
valores definidos no quadro 4, em conformidade com os
bytes-chave.
— A VU fica a aguardar o primeiro pedido do dispositivo
de teste.
— A VU está no modo de diagnóstico por defeito, ou seja,
StandardDiagnosticSession.
— A linha de calibração de sinal I/O está no estado por
defeito, ou seja, fora de serviço, desativada.
CPR_014 A velocidade de transmissão dos dados na linha K será de
10 400 bauds.
CPR_016 A inicialização rápida é desencadeada com o dispositivo de
teste a transmitir um «modelo de despertar» (Wup) sobre
a linha K. O modelo começa a seguir ao tempo morto na
linha K, com um tempo baixo de Tinil. O dispositivo de
teste transmite o primeiro bit do serviço StartCommunica­
tion depois de um tempo de Twup a seguir ao primeiro
flanco descendente.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 361
CPR_017 Os valores cronológicos para a inicialização rápida e as
comunicações, em geral, são indicados no quadro seguinte.
Há diferentes possibilidades para o tempo morto:
— Primeira transmissão a seguir a comutação, Tidle = 300 ms.
— Após a conclusão de um serviço StopCommunication,
Tidle = P3 min.
— Depois de parar a comunicação no tempo-limite P3 max,
Tidle = 0.
Quadro 3
Valores cronológicos para inicialização rápida
Parâmetro Valor mínimo Valor máximo
Tinil 25 ± 1 ms 24 ms 26 ms
Twup 50 ± 1 ms 49 ms 51 ms
Quadro 4
Valores cronológicos de comunicação
Parâmetro
cronológico
Descrição do parâmetro
Valores-limite
inferiores [ms]
Valores-limite
superiores [ms]
Mín. Máx.
P1 Tempo interbytes para resposta
da VU
0 20
P2 Tempo entre pedido do dispo­
sitivo de teste e resposta da
VU ou duas respostas da VU
25 250
P3 Tempo entre final das respos­
tas da VU e começo do novo
pedido do dispositivo de teste
55 5 000
P4 Tempo interbytes para pedido
do dispositivo de teste
5 20
CPR_018 O formato da mensagem de inicialização rápida é indicado
no quadro seguinte (NOTA: «hex» significa «hexadeci­
mal»):
Quadro 5
Mensagem de pedido StartCommunication
N. o do byte Nome do parâmetro Valor hex Mnemónica
#1 Byte de formato — endereça­
mento físico
81 FMT
#2 Byte de endereço-alvo EE TGT
#3 Byte de endereço-fonte tt SRC
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 362
N. o do byte Nome do parâmetro Valor hex Mnemónica
#4 Id do serviço de pedido
StartCommunication
81 SCR
#5 Soma de teste 00-FF CS
Quadro 6
Mensagem StartCommunication Positive Response
N. o do byte Nome do parâmetro Valor hex Mnemónica
#1 Byte de formato — endereça­
mento 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 StartCommunication Positive
Response Service Id
C1 SCRPR
#6 Byte-chave 1 EA KB1
#7 Byte-chave 2 8F KB2
#8 Soma de teste 00-FF CS
CPR_019 Não existe resposta negativa à mensagem de pedido Start­
Communication. Se não houver mensagem de resposta po­
sitiva a transmitir, a VU não se inicializa, mantém-se no seu
funcionamento normal e nada é transmitido.
4.2. Serviço StopCommunication
4.2.1 Descrição da mensagem
O propósito deste serviço de nível de comunicação é interromper uma
sessão de comunicação.
CPR_020 Ao receber uma primitiva de indicação StopCommunication,
a VU verifica se as condições vigentes permitem parar a
comunicação em curso. Em caso afirmativo, a VU executa
as ações necessárias para pôr termo à comunicação.
CPR_021 Se for possível pôr termo à comunicação, a VU emite uma
primitiva de resposta StopCommunication, com os parâme­
tros Positive Response selecionados, antes de a comunicação
ser interrompida.
CPR_022 Se, por alguma razão, não for possível pôr termo à comu­
nicação, a VU emite uma primitiva de resposta StopCom­
munication, com os parâmetros Negative Response (resposta
negativa) selecionados.
CPR_023 Se a VU detetar o tempo-limite P3max, é posto termo à
comunicação, sem emissão de qualquer primitiva de
resposta.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 363
4.2.2 Formato da mensagem
CPR_024 Os formatos das mensagens para as primitivas StopCommu­
nication figuram nos quadros seguintes:
Quadro 7
Mensagem de pedido StopCommunication
N. o do byte Nome do parâmetro Valor hex Mnemónica
#1 Byte de formato — endereça­
mento 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 01 LEN
#5 Id do serviço de pedido Stop­
Communication
82 SPR
#6 Soma de teste 00-FF CS
Quadro 8
Mensagem StopCommunication Positive Response
N. o do byte Nome do parâmetro Valor hex Mnemónica
#1 Byte de formato — endereça­
mento 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 01 LEN
#5 StopCommunication Positive
Response Service Id
C2 SPRPR
#6 Soma de teste 00-FF CS
Quadro 9
Mensagem StopCommunication Negative Response
N. o do byte Nome do parâmetro Valor hex Mnemónica
#1 Byte de formato — endereça­
mento 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
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 364
N. o do byte Nome do parâmetro Valor hex Mnemónica
#5 negative Response Service Id 7F NR
#6 Identificação do serviço de pe­
dido StopCommunication
82 SPR
#7 responseCode = generalReject 10 RC_GR
#8 Soma de teste 00-FF CS
4.2.3 Definição de parâmetros
Este serviço não requer definição de parâmetros.
4.3. Serviço TesterPresent
4.3.1 Descrição da mensagem
O serviço TesterPresent é utilizado pelo dispositivo de teste para in­
dicar ao servidor que está ainda presente, a fim de evitar que o servidor
regresse automaticamente ao funcionamento normal e possa interrom­
per a comunicação. Este serviço, enviado periodicamente, mantém ativa
a sessão de diagnóstico/comunicação recolocando no seu estado de
defeito o cronómetro P3 cada vez que é recebido um pedido relativo
ao serviço.
4.3.2 Formato da mensagem
CPR_079 Os formatos das mensagens para as primitivas TesterPresent
figuram nos quadros seguintes:
Quadro 10
Mensagem de pedido TesterPresent
N. o do byte Nome do parâmetro Valor hex Mnemónica
#1 Byte de formato — endereça­
mento 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 02 LEN
#5 Id do serviço de pedido Tes­
terPresent
3E TP
#6 Sub Função = respon­
seRequired =
[sim 01 RESPREQ_Y
não ] 02 RESPREQ_NO
#7 Soma de teste 00-FF CS
CPR_080 Se o parâmetro responseRequired tomar o valor «sim», o
servidor responde com a mensagem de resposta positiva que
a seguir se apresenta. Se o parâmetro responseRequired to­
mar o valor «não», o servidor não envia qualquer resposta.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 365
Quadro 11
Mensagem TesterPresent Positive Response
N. o do byte Nome do parâmetro Valor hex Mnemónica
#1 Byte de formato — endereça­
mento 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 01 LEN
#5 TesterPresent Positive Res­
ponse Service Id
7E TPPR
#6 Soma de teste 00-FF CS
CPR_081 O serviço deve aceitar os seguintes códigos de resposta
negativa:
Quadro 12
Mensagem TesterPresent Negative Response
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 negative Response Service Id 7F NR
#6 Identificação do serviço de pedido
TesterPresent
3E TP
#7 response­
Code =
[SubFunctionNotSup­
ported-InvalidFormat
12 RC_SFNS_IF
incorrectMessage­
Length ]
13 RC_IML
#8 Soma de teste 00-FF CS
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 366
5. SERVIÇOS DE GESTÃO
Os serviços disponíveis figuram no seguinte quadro:
Quadro 13
Serviços de gestão
Nome do serviço Descrição
StartDiagnosticSession O cliente pede para começar uma sessão de
diagnóstico com uma VU.
SecurityAccess O cliente pede acesso a funções restritas a
utilizadores autorizados.
5.1. Serviço StartDiagnosticSession
5.1.1 Descrição da mensagem
CPR_025 O serviço StartDiagnosticSession é utilizado para ativar di­
versas sessões de diagnóstico no servidor. Uma sessão de
diagnóstico ativa um conjunto específico de serviços, em
conformidade com o quadro 17. Uma sessão pode ativar
serviços não contemplados no presente documento e que
são específicos do fabricante de veículos. As regras de exe­
cução devem cumprir os seguintes requisitos:
— Haverá sempre exatamente uma sessão de diagnóstico
ativa na VU.
— Uma vez ligada, a VU iniciará sempre a StandardDiag­
nosticSession. Se não se iniciar outra sessão de diagnós­
tico, a StandardDiagnosticSession prosseguirá enquanto
a VU estiver ligada.
— Se uma sessão de diagnóstico em curso tiver sido pedida
pelo dispositivo de teste, a VU enviará uma mensagem
de resposta positiva.
— Sempre que o dispositivo de teste pedir uma nova sessão
de diagnóstico, a VU enviará uma mensagem de res­
posta positiva StartDiagnosticSession antes de a nova
sessão ser ativada nela. Se não puder iniciar a nova
sessão de diagnóstico pedida, a VU enviará uma res­
posta negativa StartDiagnosticSession e a sessão em
curso prosseguirá.
CPR_026 Uma sessão de diagnóstico só se inicia se tiver sido estabe­
lecida comunicação entre o cliente e a VU.
CPR_027 Os parâmetros cronológicos definidos no quadro 4 devem
ficar ativos após um começo StartDiagnosticSession bem
sucedido, com o parâmetro diagnosticSession levado ao va­
lor «StandardDiagnosticSession» na mensagem de pedido,
se outra sessão de diagnóstico tiver estado previamente
ativa.
5.1.2 Formato da mensagem
CPR_028 Os formatos das mensagens para as primitivas StartDiagnos­
ticSession figuram nos quadros seguintes:
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 367
Quadro 14
Mensagem de pedido StartDiagnosticSession
N. o do byte Nome do parâmetro Valor hex Mnemónica
#1 Byte de formato — endereça­
mento 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 02 LEN
#5 Id do serviço de pedido
StartDiagnosticSession
10 STDS
#6 diagnosticSession = [um valor
de quadro 17]
XX DS_…
#7 Soma de teste 00-FF CS
Quadro 15
Mensagem StartDiagnosticSession Positive Response
N. o do byte Nome do parâmetro Valor hex Mnemónica
#1 Byte de formato — endereça­
mento 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 02 LEN
#5 StartDiagnosticSession Posi­
tive Response Service Id
50 STDSPR
#6 diagnosticSession = [mesmo
valor que o byte #6 quadro 14 ]
XX DS_…
#7 Soma de teste 00-FF CS
Quadro 16
Mensagem StartDiagnosticSession Negative Response
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
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 368
N. o do byte Nome do parâmetro
Valor
hex
Mnemónica
#4 Byte adicional de comprimento 03 LEN
#5 Negative Response Service Id 7F NR
#6 Id do serviço de pedido StartDiag­
nosticSession
10 STDS
#7 Response­
Code =
[subFunctionNotSup­
ported ( α )
12 RC_SFNS
incorrectMessage­
Length ( β )
13 RC_IML
conditionsNotCor­
rect ( γ )
22 RC_CNC
#8 Soma de teste 00-FF CS
( α ) — O valor inserido no byte #6 da mensagem de pedido não é aceite (não consta do
quadro 17).
( β ) —Erro no comprimento da mensagem.
( γ ) — Não cumpridos os critérios no pedido StartDiagnosticSession.
5.1.3 Definição de parâmetros
CPR_029 O parâmetro diagnosticSession (DS_) é utilizado pelo ser­
viço StartDiagnosticSession para selecionar o comporta­
mento específico do(s) servidor(es). No presente documento
especificam-se as seguintes sessões de diagnóstico:
Quadro 17
Definição de valores diagnosticSession
Hex Descrição Mnemónica
81 StandardDiagnosticSession
Esta sessão de diagnóstico possibilita todos os
serviços especificados no quadro 1, coluna 4,
«SD». Estes serviços permitem a leitura de dados
de um servidor (VU). Esta sessão de diagnóstico
fica ativa uma vez concluída com êxito a
inicialização entre o cliente (dispositivo de teste)
e o servidor (VU). Esta sessão de diagnóstico
pode ser sobreposta por outras sessões de
diagnóstico especificadas na presente secção.
SD
85 ECUProgrammingSession
Esta sessão de diagnóstico possibilita todos os
serviços especificados no quadro 1, coluna 6,
«ECUPS». Estes serviços são compatíveis com a
programação da memória de um servidor (VU).
Esta sessão de diagnóstico pode ser sobreposta
por outras sessões de diagnóstico especificadas
na presente secção.
ECUPS
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 369
Hex Descrição Mnemónica
87 ECUAdjustmentSession
Esta sessão de diagnóstico possibilita todos os
serviços especificados no quadro 1, coluna 5,
«ECUAS». Estes serviços são compatíveis com
o controlo da entrada/saída de um servidor (VU).
Esta sessão de diagnóstico pode ser sobreposta
por outras sessões de diagnóstico especificadas
na presente secção.
ECUAS
5.2. Serviço SecurityAccess
Se a VU não estiver em modo CALIBRAÇÃO, não é possível escrever
dados de calibração. Para se garantir o acesso ao modo CALIBRA­
ÇÃO, é necessário introduzir na VU o PIN devido, além de um cartão
válido de oficina.
Se a VU estiver em modo CALIBRAÇÃO ou CONTROLO, o acesso à
linha de calibração de entrada/saída é também possível.
O serviço SecurityAccess fornece um meio para introduzir o PIN e
indicar ao dispositivo de teste se a VU está ou não em modo CALI­
BRAÇÃO.
São aceitáveis métodos alternativos para introduzir o PIN.
5.2.1 Descrição da mensagem
O serviço SecurityAccess consiste numa mensagem SecurityAccess
«requestSeed», seguida de uma mensagem SecurityAccess «sendKey».
O serviço SecurityAccess deve ser executado depois do serviço Start­
DiagnosticSession.
CPR_033 O dispositivo de teste utiliza a mensagem SecurityAccess
«requestSeed» para verificar se a unidade-veículo está
pronta a aceitar um PIN.
CPR_034 Se já estiver em modo CALIBRAÇÃO, a VU responde ao
pedido enviando um «seed» de 0x0000 por meio do serviço
SecurityAccess Positive Response.
CPR_035 Se estiver pronta a aceitar um PIN para verificação por um
cartão de oficina, a VU responde ao pedido enviando um
«seed» maior do que 0x0000 por meio do serviço Securi­
tyAccess Positive Response.
CPR_036 Se não estiver pronta para aceitar um PIN do dispositivo de
teste (quer porque o cartão de oficina inserido não é válido,
quer porque não foi inserido nenhum cartão de oficina, quer
ainda porque espera o PIN por outro método), a VU res­
ponde ao pedido por uma Negative Response, com um có­
digo de resposta expresso por conditionsNotCorrectOrRe­
questSequenceError.
CPR_037 O dispositivo de teste recorre então à mensagem SecurityAc­
cess «sendKey» para encaminhar o PIN para a unidade-veí­
culo. A fim de permitir que se efetue o processo de autenti­
cação do cartão, a VU utiliza o código de resposta negativa
requestCorrectlyReceived-ResponsePending para ampliar o
tempo destinado à resposta. No entanto, o tempo máximo
de resposta não deve exceder 5 minutos. Logo que o serviço
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 370
pedido esteja concluído, a VU envia uma mensagem de res­
posta positiva ou uma mensagem de resposta negativa com
um código de resposta diferente deste. O código de resposta
negativa requestCorrectlyReceived-ResponsePending pode ser
repetido pela VU até o serviço pedido estar concluído e a
mensagem de resposta final ser enviada.
CPR_038 A VU responde a este pedido utilizando o serviço Securi­
tyAccess Positive Response somente quando em modo CA­
LIBRAÇÃO.
CPR_039 Nos casos que se seguem, a VU responde a este pedido por
uma Negative Response, com os seguintes códigos de
resposta:
— subFunctionNot supported: formato não válido para o
parâmetro da subfunção (accessType)
— conditionsNotCorrectOrRequestSequenceError:
unidade-veículo não preparada para aceitar entrada de
PIN
— invalidKey: PIN não válido e número de tentativas de
verificação do PIN não excedido
— exceededNumberOfAttempts: PIN não válido e número
de tentativas de verificação do PIN excedido
— generalReject: PIN correto mas falhou autenticação mú­
tua com o cartão de oficina.
5.2.2 Formato da mensagem — SecurityAccess — requestSeed
CPR_040 Os formatos das mensagens para as primitivas SecurityAc­
cess «requestSeed» figuram nos quadros seguintes:
Quadro 18
Mensagem SecurityAccessRequest-requestSeed)
N. o do byte Nome do parâmetro Valor hex Mnemónica
#1 Byte de formato — endereça­
mento 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 02 LEN
#5 Id do serviço de pedido Secu­
rityAccess
27 SA
#6 accessType — requestSeed 7D AT_RSD
#7 Soma de teste 00-FF CS
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 371
Quadro 19
SecurityAccess — requestSeed Positive Response
N. o do byte Nome do parâmetro Valor hex Mnemónica
#1 Byte de formato — endereça­
mento 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 04 LEN
#5 SecurityAccess Positive Res­
ponse Service Id
67 SAPR
#6 accessType — requestSeed 7D AT_RSD
#7 Seed elevada 00-FF SEEDH
#8 Seed baixa 00-FF SEEDL
#9 Soma de teste 00-FF CS
Quadro 20
Mensagem SecurityAccess Negative Response
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 7F NR
#6 Id do serviço de pedido SecurityAc­
cess
27 SA
#7 response­
Code =
[conditionsNotCorrec­
tOrRequestSequen­
ceError
22 RC_CNC
incorrectMessage­
Length]
13 RC_IML
#8 Soma de teste 00-FF CS
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 372
5.2.3 Formato da mensagem — SecurityAccess — sendKey
CPR_041 Os formatos das mensagens para as primitivas SecurityAc­
cess «sendKey» figuram nos quadros seguintes:
Quadro 21
Mensagem SecurityAccess Request-sendKey)
N. o do byte Nome do parâmetro Valor hex Mnemónica
#1 Byte de formato — endereça­
mento 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 m+2 LEN
#5 Id do serviço de pedido Secu­
rityAccess
27 SA
#6 accessType — sendKey 7E AT_SK
#7 to
#m+6
Key #1 (elevado) XX KEY
… …
Chave #m (baixa: m deve ser
no mínimo 4 e no máximo 8)
XX
#m+7 Soma de teste 00-FF CS
Quadro 22
Mensagem SecurityAccess-sendKey Positive Response
N. o do byte Nome do parâmetro Valor hex Mnemónica
#1 Byte de formato — endereça­
mento 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 02 LEN
#5 SecurityAccess Positive Res­
ponse Service Id
67 SAPR
#6 accessType — sendKey 7E AT_SK
#7 Soma de teste 00-FF CS
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 373
Quadro 23
Mensagem SecurityAccess Negative Response
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 7F NR
#6 Id do serviço de pedido SecurityAc­
cess
27 SA
#7 Response­
Code =
[generalReject 10 RC_GR
subFunctionNotSup­
ported
12 RC_SFNS
incorrectMessage­
Length
13 RC_IML
conditionsNotCorrec­
tOrRequestSequen­
ceError
22 RC_CNC
invalidKey 35 RC_IK
exceededNumberO­
fAttempts
36 RC_ENA
requestCorrectlyRe­
ceived-ResponsePen­
ding]
78 RC_RCR_RP
#8 Soma de teste 00-FF CS
6. SERVIÇOS DE TRANSMISSÃO DE DADOS
Os serviços disponíveis figuram no seguinte quadro:
Quadro 24
Serviços de transmissão de dados
Nome do serviço Descrição
ReadDataByIdentifier O cliente pede a transmissão do valor atual
de um registo com acesso por recordDataI­
dentifier.
WriteDataByIdentifier O cliente pede para escrever um registo com
acesso por recordDataIdentifier.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 374
6.1. Serviço ReadDataByIdentifier
6.1.1 Descrição da mensagem
CPR_050 O serviço ReadDataByIdentifier é utilizado pelo cliente para
pedir valores de registo de dados a um servidor. Os dados
são identificados por um recordDataIdentifier. Compete ao
fabricante da VU assegurar o respeito das condições do
servidor quando da execução deste serviço.
6.1.2 Formato da mensagem
CPR_051 Os formatos das mensagens para as primitivas ReadDaTa­
ByIdentifier figuram nos quadros seguintes:
Quadro 25
Mensagem de pedido ReadDataByIdentifier
N. o do byte Nome do parâmetro Valor hex Mnemónica
#1 Byte de formato — endereça­
mento 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 03 LEN
#5 Id do serviço de pedido
ReadDataByIdentifier
22 RDBI
#6 a #7 recordDataIdentifier = [um va­
lor do quadro 28]
xxxx RDI_…
#8 Soma de teste 00-FF CS
Quadro 26
Mensagem ReadDataByIdentifier Positive Response
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 m+3 LEN
#5 ReadDataByIdentifier Positive Res­
ponse Service Id
62 RDBIPR
#6 e #7 recordDataIdentifier = [o mesmo va­
lor que bytes #6 e #7, quadro 25]
xxxx RDI_…
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 375
N. o do byte Nome do parâmetro
Valor
hex
Mnemónica
#8 a #m+7 dataRecord[] = [data#1 XX DREC_DAT­
A1
: : :
data#m] XX DREC_DA­
TAm
#m+8 Soma de teste 00-FF CS
Quadro 27
Mensagem ReadDataByIdentifier Negative Response
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 7F NR
#6 Id do serviço de pedido ReadData­
ByIdentifier
22 RDBI
#7 Response­
Code=
[requestOutO­
fRange
31 RC_ROOR
incorrectMessage­
Length
13 RC_IML
conditionsNotCor­
rect]
22 RC_CNC
#8 Soma de teste 00-FF CS
6.1.3 Definição de parâmetros
CPR_052 O parâmetro recordDataIdentifier (RDI_), na mensagem de
pedido readDataByIdentifier, identifica um registo de dados.
▼M3
CPR_053 Os valores recordDataIdentifier definidos pelo presente do­
cumento 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 ele­
mento do apêndice 1 no qual se baseia o recordDataI­
dentifier (é por vezes necessária transcodificação).
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 376
— A 3. a coluna (Descrição) especifica o nome do record­
DataIdentifier 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 HighResolutionTotalVehicleDis­
tance
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 RemoteCommunicationModuleSerial­
Number
RemoteCommunicationFacility­
SerialNumber
R RDI_RCSN
F9D2 SensorGNSSSerialNumber ExternalGNSSFacilitySerial­
Number
R RDI_GSSN
F9D3 SealDataVu SmartTachographSealsSerial­
Number
R/W RDI_SDV
F9D4 VuSerialNumber VuSerialNumber R RDI_VSN
F9D5 ByDefaultLoadType ByDefaultLoadType R/W RDI_BDLT
F9D6 TachographCardsGen1Suppression TachographCardsGen1Suppres­
sion
R/W RDI_TCG1S
F9D7 VehiclePosition VehiclePosition R RDI_VP
F9D8 LastCalibrationCountry CalibrationCountry R RDI_CC
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 377
CPR_054 O parâmetro dataRecord (DREC_) é utilizado pela mensa­
gem de resposta positiva readDataByIdentifier para fornecer
ao cliente (dispositivo de teste) o valor de registo de dado
identificado pelo recordDataIdentifier. Os formatos dos da­
dos são especificados na secção 8. Outros dataRecords op­
cionais do utilizador, incluindo dados de entrada, internos e
de saída específicos da VU, podem ser adicionalmente apli­
cados, mas não são definidos no presente documento.
6.2. Serviço WriteDataByIdentifier
6.2.1 Descrição da mensagem
CPR_056 O serviço WriteDataByIdentifier é utilizado pelo cliente para
escrever valores de registo de dados num servidor. Os dados
são identificados por um recordDataIdentifier. Compete ao
fabricante da VU assegurar o respeito das condições do
servidor quando da execução deste serviço. Para atualizar
os parâmetros constantes do quadro 28, a VU deve estar em
modo CALIBRAÇÃO.
6.2.2 Formato da mensagem
CPR_057 Os formatos das mensagens para as primitivas WriteData­
ByIdentifier figuram nos quadros seguintes:
Quadro 29
Mensagem de pedido WriteDataByIdentifier Request
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 m+3 LEN
#5 Id do serviço de pedido WriteDa­
taByIdentifier
2E WDBI
#6 a #7 recordDataIdentifier = [um valor do
quadro 28]
xxxx RDI_…
#8 a m+7 dataRecord[] = [data#1 XX DREC_DAT­
A1
: : :
data#m] XX DREC_DA­
TAm
#m+8 Soma de teste 00-FF CS
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 378
Quadro 30
Mensagem WriteDataByIdentifier Positive Response
N. o do byte Nome do parâmetro Valor hex Mnemónica
#1 Byte de formato — endereça­
mento 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 WriteDataByIdentifier Posi­
tive Response Service Id
6E WDBIPR
#6 a #7 recordDataIdentifier = [o
mesmo valor que bytes #6 e
#7, quadro 29]
xxxx RDI_…
#8 Soma de teste 00-FF CS
Quadro 31
Mensagem WriteDataByIdentifier Negative Response
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 7F NR
#6 Id do serviço de pedido WriteData­
ByIdentifier
2E WDBI
#7 Response­
Code=
[requestOutO­
fRange
31 RC_ROOR
incorrectMessage­
Length
13 RC_IML
conditionsNotCor­
rect]
22 RC_CNC
#8 Soma de teste 00-FF CS
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 379
6.2.3 Definição de parâmetros
O parâmetro recordDataIdentifier (RDI_) é definido no quadro 28.
O parâmetro dataRecord (DREC_) é utilizado pela mensagem Write­
DataByIdentifier para fornecer ao servidor (VU) os valores de registo
de dados identificados pelo recordDataIdentifier. Os formatos dos da­
dos são especificados na secção 8.
7. CONTROLO DOS IMPULSOS DE TESTE — UNIDADE FUNCIO­
NAL DE CONTROLO DE ENTRADA/SAÍDA
Os serviços disponíveis figuram no seguinte quadro:
Quadro 32
Unidade funcional de controlo de entrada/saída
Nome do serviço Descrição
InputOutputControl­
ByIdentifier
O cliente pede o controlo de uma entrada/
/saída específica do servidor.
7.1. Serviço InputOutputControlByIdentifier
7.1.1 Descrição da mensagem
Através do conector frontal, há uma ligação que permite controlar ou
acompanhar os impulsos de teste por meio de um dispositivo de teste
adequado.
CPR_058 Esta linha de calibração de sinal I/O pode ser configurada
pelo comando da linha K por intermédio do serviço Inpu­
tOutputControlByIdentifier, a fim de selecionar a função de
entrada ou de saída pretendida para a linha. Estados que a
linha pode apresentar:
— desativado,
— speedSignalInput, em que a linha de calibração de sinal
I/O é utilizada para dar entrada a um sinal de velocidade
(sinal de teste) em substituição do sinal de velocidade do
sensor de movimentos (função não disponível em modo
CONTROLO),
— realTimeSpeedSignalOutputSensor, em que a linha de
calibração de sinal I/O é utilizada para dar saída ao sinal
de velocidade do sensor de movimentos,
— RTCOutput, em que a linha de calibração de sinal I/O é
utilizada para dar saída ao sinal do relógio UTC (função
não disponível em modo CONTROLO).
CPR_059 Para configurar o estado da linha, a unidade-veículo deve ter
dado entrada a uma sessão de ajustamento e estar em modo
CALIBRAÇÃO ou CONTROLO. Se a VU estiver em modo
CALIBRAÇÃO, podem ser selecionados os quatro estados
da linha (desativado, speedSignalInput, realTimeSpeedSig­
nalOutputSensor e RTCOutput). Se a VU estiver em
modo CONTROLO, só podem ser selecionados dois estados
da linha (desativado e realTimeSpeedOutputSensor). Saindo
da sessão de ajustamento ou do modo CALIBRAÇÃO ou
CONTROLO, a VU deve assegurar que a linha de sinal I/O
regressa ao estado «desativado» (por defeito).
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 380
CPR_060 Se forem recebidos impulsos de velocidade na linha de
entrada do sinal de velocidade em tempo real da VU en­
quanto a linha de calibração de sinal I/O estiver apontada
para entrada, então a linha de sinal I/O deve ser apontada
para saída ou recolocada em estado desativado.
CPR_061 A sequência será:
— estabelecer comunicações pelo serviço StartCommunica­
tion
— introduzir uma sessão de ajustamento pelo serviço Start­
DiagnosticSession e ficar em modo de funcionamento
CALIBRAÇÃO ou CONTROLO (a ordem destas duas
operações é arbitrária)
— mudar o estado da saída pelo serviço InputOutputCon­
trolByIdentifier.
7.1.2 Formato da mensagem
CPR_062 Os formatos das mensagens para as primitivas InputOutput­
ControlByIdentifier figuram nos quadros seguintes:
Quadro 33
Mensagem de pedido InputOutputControlByIdentifier
N. o do byte Nome do parâmetro Valor hex Mnemónica
#1 Byte de formato — endereça­
mento 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 InputOutputControlByIden­
tifier Request Sid
2F IOCBI
#6 e #7 InputOutputIdentifier = [Cali­
brationInputOutput]
F960 IOI_CIO
#8 ou
#8 a #9
ControlOptionRecord = [ COR_…
inputOutputControlParameter
— um valor do quadro 36
XX IOCP_…
controlState — um valor do
quadro 37 (ver nota infra)]
XX CS_…
#9 ou #10 Soma de teste 00-FF CS
Nota: O parâmetro controlState está presente somente em
alguns casos (ver 7.1.3).
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 381
Quadro 34
Mensagem InputOutputControlByIdentifier Positive Response
N. o do byte Nome do parâmetro Valor hex Mnemónica
#1 Byte de formato — endereça­
mento 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 inputOutputControlByIdenti­
fier Positive Response SId
6F IOCBIPR
#6 e #7 inputOutputIdentifier = [Cali­
brationInputOutput]
F960 IOI_CIO
#8 ou
#8 a #9
controlStatusRecord = [ CSR_
inputOutputControlParameter
(mesmo valor que byte #8,
quadro 33)
XX IOCP_…
controlState (mesmo valor que
byte #9, quadro 33)] (se for o
caso)
XX CS_…
#9 ou #10 Soma de teste 00-FF CS
Quadro 35
Mensagem InputOutputControlByIdentifier Negative Response
N. o do byte Nome do parâmetro Valor hex Mnemónica
#1 Byte de formato — endereça­
mento 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 7F NR
#6 inputOutputControlByIdentifier
Request SId
2F IOCBI
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 382
N. o do byte Nome do parâmetro Valor hex Mnemónica
#7 responseCode=[
incorrectMessageLength 13 RC_IML
conditionsNotCorrect 22 RC_CNC
requestOutOfRange 31 RC_ROOR
deviceControlLimitsExceeded] 7A RC_DCLE
#8 Soma de teste 00-FF CS
7.1.3 Definição de parâmetros
CPR_064 O parâmetro inputOutputControlParameter (IOCP_) é de­
finido no quadro seguinte:
Quadro 36
Definição de valores inputOutputControlParameter
Hex Descrição Mnemónica
00 ReturnControlToECU
Este valor indica ao servidor (VU) que o
dispositivo de teste deixou de ter controlo sobre
a linha de calibração de sinal I/O.
RCTECU
01 ResetToDefault
Este valor indica ao servidor (VU) que lhe é
pedido recolocar no seu estado por defeito a linha
de calibração de sinal I/O.
RTD
03 ShortTermAdjustment
Este valor indica ao servidor (VU) que lhe é
pedido ajustar ao valor incluído no parâmetro
controlState a linha de calibração de sinal I/O.
STA
CPR_065 O parâmetro controlState, definido no quadro seguinte, está
presente somente quando o inputOutputControlParameter é
colocado em ShortTermAdjustment:
Quadro 37
Definição de valores de controlState
Modo Valor hex Descrição
Desativar 00 Linha I/O desativada (estado por defeito)
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 383
Modo Valor hex Descrição
Ativar 01 Ativar a linha I/O como speedSignalInput
Ativar 02 Ativar a linha I/O como realTimeSpeedSig­
nalOutputSensor
Ativar 03 Ativar a linha I/O como RTCOutput
▼M3
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 requestRou­
tineResults, com routineInfo = 0x78.
Nota: o ajustamento do tempo pode demorar algum tempo.
O dispositivo de teste diagnóstico pede o estado do ajusta­
mento do tempo utilizando a subfunção requestRoutineRe­
sults.
8.2. Formato da mensagem
CPR_065b Os formatos das mensagens para o serviço RoutineControl
(ajustamento do tempo) e respetivas primitivas são especi­
ficados 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
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 384
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
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 385
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) 7F NR
#6 inputOutputControlByIdentifier Request SId 31 RC
#7 responseCode=[
sub-functionNotSupported
incorrectMessageLengthOrInvalidFormat
conditionsNotCorrect
requestOutOfRange
]
12
13
22
31
SFNS
IMLOIF
CNC
ROOR
#8 Soma de teste 00-FF CS
Quadro 37-F:
RoutineControl, rotina (TimeAdjustment), routineInfo
routineInfo Valor hex Descrição
NormalExitWithResultAvailable 61 A rotina foi completamente executada; resultados adicio­
nais da rotina disponíveis.
RoutineExecutionOngoing 78 A rotina pedida ainda está a ser executada.
Quadro 37-G
RoutineControl, rotina (TimeAdjustment), routineStatus
Valor hex Resultado do ensaio Descrição
01 positivo Ajustamento do tempo concluído com sucesso.
02..0F RFU
10 negativo Sem receção de sinal GNSS.
11..7F RFU
80..FF Específico do fabricante
9. FORMATOS DOS DATARECORDS
A presente secção incide em:
— 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.
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 386
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 pe­
dido) 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.
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 387
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
Compri­
mento dos
dados (by­
tes)
Resolução Gama de funcionamento
TimeDate 8 Ver informações no quadro 40
HighResolutionTotalVehicleDis­
tance
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, des­
locamento de 0
0 a 64255 imp./m
LfactorTyreCircumference 2 ganho de 0,125 10 -3 m/bit, deslo­
camento de 0
0 a 8,031 m
WvehicleCharacteristicFactor 2 ganho de 0,001 imp./m/bit, des­
locamento 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, deslo­
camento 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
RemoteCommunicationModuleSe­
rialNumber
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
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 388
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 me­
ses
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 mi­
nutos
ganho de 1 min/bit, deslocamento de
-125 min
-59 a +59 min
8 Deslocamento local em ho­
ras
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 me­
ses
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.
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 389
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ên­
dice 1)
não aplicável VehicleRegistrationNumber
2 – 14 VehicleRegistrationNumber (conforme defi­
nido 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, Sen­
sorGNSSSerialNumber e RemoteCommunicationModuleSe­
rialNumber:
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 390
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, Sen­
sorGNSSSerialNumber and RemoteCommu­
nicationModuleSerialNumber:
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.
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 391
Apêndice 9 .
HOMOLOGAÇÃO DE TIPO RELAÇÃO DOS ENSAIOS MÍNIMOS
EXIGIDOS
ÍNDICE
1. INTRODUÇÃO
2. ENSAIOS DE FUNCIONALIDADE DA UNIDADE-VEÍCULO
3. ENSAIOS DE FUNCIONALIDADE DO SENSOR DE MOVIMENTOS
4. ENSAIOS DE FUNCIONALIDADE DOS CARTÕES TACOGRÁFICOS
5. ENSAIOS DO MÓDULO GNSS EXTERNO
▼M1
6. ENSAIOS DO SISTEMA DE COMUNICAÇÃO À DISTÂNCIA
▼B
7. ENSAIOS DE FUNCIONALIDADE EM PAPEL
8. ENSAIOS DE INTEROPERABILIDADE
▼M3
9. ENSAIOS DA OSNMA
▼B
1. INTRODUÇÃO
1.1. Homologação de tipo
A homologação CE de tipo para um aparelho de controlo (ou componente)
ou para um cartão tacográfico tem por base:
▼M1
— uma certificação de segurança, baseada em especificações de critérios
comuns, em relação a uma meta de segurança totalmente compatível
com o apêndice 10 do presente anexo
▼B
— uma certificação de funcionalidade, efetuada por uma autoridade do
Estado-Membro, a certificar que o elemento ensaiado cumpre o pres­
crito no presente anexo em termos de funções executadas, de rigor de
medição e de características ambientais
— uma certificação de interoperabilidade, efetuada pelo organismo
competente, a certificar que o aparelho de controlo (ou cartão taco­
gráfico) é totalmente interoperável com os modelos necessários de
cartão tacográfico (ou de aparelho de controlo) (ver capítulo 8 do
presente anexo).
O presente apêndice especifica os ensaios mínimos a efetuar pela autori­
dade nacional no âmbito dos ensaios de funcionalidade, bem como os
ensaios mínimos a efetuar pelo organismo competente no âmbito dos
ensaios de interoperabilidade. Não se dão mais pormenores sobre os pro­
cedimentos de execução nem sobre o tipo de ensaios.
O presente apêndice não aborda os aspetos relativos à certificação de
segurança. Se, durante o processo de certificação e de avaliação da segu­
rança, se executarem alguns dos ensaios requeridos para efeitos da homo­
logação de tipo, não é necessário repeti-los. Em tal eventualidade, somente
os resultados destes ensaios de segurança poderão ser inspecionados. Para
informação: os requisitos que, no âmbito da certificação de segurança,
devam ser ensaiados (ou se relacionem estreitamente com ensaios que
devam ser executados) aparecem marcados com «*» no presente apêndice.
Os requisitos numerados referem-se ao corpo do anexo, ao passo que os
restantes requisitos se referem a outros apêndices (por exemplo, PIC_001
refere-se ao requisito PIC_001 do apêndice 3 — «Pictogramas»).
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 392
O presente apêndice considera a homologação de tipo do sensor de mo­
vimentos separadamente da unidade-veículo e do módulo GNSS externo,
como componentes do aparelho de controlo. Cada componente terá o seu
próprio certificado de homologação de tipo, no qual se mencionarão os
outros componentes compatíveis. O ensaio de funcionalidade do sensor de
movimentos (ou módulo GNSS externo) é realizado em conjunto com o
da unidade-veículo e vice-versa.
Não é necessária interoperabilidade entre todos os modelos de sensor de
movimentos (ou de módulo GNSS externo) e todos os modelos de
unidade-veículo. Nesse caso, a homologação de tipo de um sensor de
movimentos (ou de um módulo GNSS externo) só pode ser concedida
em combinação com a homologação de tipo da VU pertinente e
vice-versa.
▼M3
A autoridade dos Estados-Membros encarregada dos ensaios de funciona­
lidade 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.
▼B
1.2. Referências
No presente apêndice, utilizam-se as seguintes referências:
IEC 60068-2-1: Environmental testing — Part 2-1: Tests — Test A: Cold
IEC 60068-2-2: Basic environmental testing procedures; part 2: tests; tests
B: dry heat (sinusoidal).
IEC 60068-2-6: Environmental testing — Part 2: Tests — Test Fc: Vi­
bration
IEC 60068-2-14: Environmental testing; Part 2-14: Tests; Test N: Change
of temperature
IEC 60068-2-27: Environmental testing. Part 2: Tests. Test Ea and gui­
dance: Shock
IEC 60068-2-30: Environmental testing — Part 2-30: Tests — Test Db:
Damp heat, cyclic (12 h + 12 h cycle)
IEC 60068-2-64: Environmental testing — Part 2-64: Tests — Test Fh:
Vibration, broadband random and guidance
IEC 60068-2-78 Environmental testing — Part 2-78: Tests — Test Cab:
Damp heat, steady state
ISO 16750-3 — Mechanical loads (2012-12)
ISO 16750-4 — Climatic loads (2010-04).
ISO 20653: Road vehicles — Degree of protection (IP code) — Protection
of electrical equipment against foreign objects, water and access
ISO 10605:2008 + Technical Corrigendum:2010 + AMD1:2014 Road ve­
hicles — Test methods for electrical disturbances from electrostatic dis­
charge
ISO 7637-1:2002 + AMD1: 2008 Road vehicles — Electrical disturbances
from conduction and coupling — Part 1: Definitions and general consi­
derations
ISO 7637-2 Road vehicles — Electrical disturbances from conduction and
coupling — Part 2: Electrical transient conduction along supply lines only
ISO 7637-3 Road vehicles — Electrical disturbances from conduction and
coupling — Part 3: Electrical transient transmission by capacitive and
inductive coupling via lines other than supply lines
ISO/IEC 7816-1 Identification cards — Integrated circuit(s) cards with
contacts — Part 1: Physical characteristics
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 393
ISO/IEC 7816-2 Information technology — Identification cards — Inte­
grated circuit(s) cards with contacts — Part 2: Dimensions and location of
the contacts
ISO/IEC 7816-3 Information technology — Identification cards — Inte­
grated circuit(s) cards with contacts — Part 3: Electronic signals and
transmission protocol
ISO/IEC 10373-1:2006 + AMD1:2012 Identification cards — Test met­
hods — Part 1: General characteristics
ISO/IEC 10373-3:2010 + Technical Corrigendum:2013 Identification
cards — Test methods — Part 3: Integrated circuit cards with contacts
and related interface devices
ISO 16844-3:2004, Cor 1:2006 Road vehicles — Tachograph systems —
Part 3: Motion sensor interface (with vehicle units)
ISO 16844-4 Road vehicles — Tachograph systems — Part 4: CAN
interface
ISO 16844-6 Road vehicles — Tachograph systems — Part 6: Diagnostics
ISO 16844-7 Road vehicles — Tachograph systems — Part 7: Parameters
ISO 534 Paper and board — Determination of thickness, density and
specific volume
▼M3
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)
▼B
UN ECE R10 Uniform provisions concerning the approval of vehicles
with regard to electromagnetic compatibility (United Nation Economic
Commission for Europe)
2. ENSAIOS DE FUNCIONALIDADE DA UNIDADE-VEÍCULO
▼M1
N. o Ensaio Descrição Requisitos correlatos
1. Exame administrativo
1.1 Documentação Adequação da documentação
1.2 Resultados dos ensaios
do fabricante
Resultados do ensaio efetuado pelo fabricante
durante a integração.
Demonstrações em papel.
88, 89,91
2. Inspeção visual
2.1 Conformidade com a documentação
2.2 Identificação/marcações 224 a 226
2.3 Materiais 219 a 223
2.4 Selagem 398, 401 a 405
2.5 Interfaces externas
3. Ensaios de funcionalidade
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 394
N. o Ensaio Descrição Requisitos correlatos
▼M3
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*
▼M1
02016R0799 — PT — 21.08.2023 — 003.002 — 395
N. o Ensaio Descrição Requisitos correlatos
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 136, 137, 138*, 139*, 141*,
142, 143
144, 145, 146*, 147*, 147a*,
147b*, 148*, 149, 150, 150a
3.32 Visualização 90, 134,
151 a 168,
PIC_001, DIS_001
3.33 Impressão 90, 134,
169 a 181, PIC_001, PRT_001
a PRT_014
3.34 Alerta 134, 182 a 191,
PIC_001
3.35 Descarregamento de dados para meios externos 90, 134, 192 a 196
3.36 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
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 396
N. o Ensaio Descrição Requisitos correlatos
4. Ensaios ambientais
4.1 Temperatura Verificar funcionalidade por meio de:
Ensaio de acordo com a norma ISO 16750-4,
capítulo 5.1.1.2: Low temperature operation
test (72 h a -20°C)
Este ensaio refere-se à norma IEC 60068-2-1:
Environmental testing – Part 2-1: Tests – Test
A: Cold
Ensaio de acordo com a norma ISO 16750-4:
secção 5.1.2.2: High temperature operation
test (72 h a 70 °C)
Este ensaio refere-se à norma IEC 60068-2-2:
Basic environmental testing procedures;
Ensaio de acordo com a norma ISO 16750-4:
secção 5.3.2: Rapid change of temperature
with specified transition duration (-20 °C/70
°C, 20 ciclos; duração do ensaio 2 horas a
cada temperatura)
Pode ser efetuado um conjunto reduzido de
ensaios (entre os definidos na secção 3 deste
quadro) à temperatura mais baixa, à tempera­
tura mais alta e durante os ciclos de tempera­
tura
213
4.2 Humidade Verificar se a unidade-veículo suporta varia­
ções cíclicas de humidade (ensaio térmico)
através de IEC 60068-2-30, ensaio Db, seis ci­
clos de 24 horas, variando cada temperatura de
+25 °C a + 55 °C e com humidade relativa de
97 % a + 25 °C e de 93 % a + +55 °C
214
4.3 Mecânica 1. Vibrações sinusoidais.
Verificar se a unidade-veículo suporta vi­
brações sinusoidais com as seguintes ca­
racterísticas:
deslocamento constante entre 5 e 11 Hz:
pico de 10 mm
aceleração constante entre 11 e 300 Hz:
5 g
Este requisito é verificado por meio da
norma IEC 60068-2-6, ensaio Fc, com a
duração mínima de 3 × 12 horas (12 horas
por eixo)
A norma ISO 16750-3 não exige ensaio de
vibração sinusoidal em dispositivos locali­
zados na cabina do veículo separada.
2. Vibrações aleatórias:
Ensaio de acordo com a norma ISO
16750-3: secção 4.1.2.8: Test VIII: Com­
mercial vehicle, decoupled vehicle cab
219
▼M1
02016R0799 — PT — 21.08.2023 — 003.002 — 397
N. o Ensaio Descrição Requisitos correlatos
Ensaio de vibração aleatória, 10...2000 Hz,
RMS vertical 21,3 m/s 2 , RMS longitudinal
11,8 m/s 2 , RMS lateral 13,1 m/s 2 , 3 eixos,
32 h por eixo, incluindo o ciclo de tempera­
tura -20 °C ... 70 °C.
Este ensaio refere-se à norma IEC 60068-2-
-64: Environmental testing – Part 2-64: Tests –
Test Fh: Vibration, broadband random and
guidance
3. Choques:
choque mecânico com 3 g de meio seio,
de acordo com a norma ISO 16750.
Os dois ensaios supra são executados sobre
duas amostras distintas do tipo de equipa­
mento em ensaio.
4.4 Proteção contra água e
corpos estranhos
Ensaio de acordo com a norma ISO 20653:
Road vehicles – Degree of protection (IP
code) – Protection of electrical equipment
against foreign objects, water and access
(Sem alterações nos parâmetros); valor mí­
nimo IP 40
220, 221
4.5 Proteção contra sobre­
tensão
Verificar se a unidade-veículo suporta as se­
guintes tensões de alimentação:
Versões de 24 V: 34 V a +40 °C, 1 hora
Versões de 12 V: 17 V a +40 °C, 1 hora
(ISO 16750-2)
216
4.6 Proteção contra polari­
dade inversa
Verificar se a unidade-veículo suporta uma
inversão na alimentação elétrica
(ISO 16750-2)
216
4.7 Proteção contra
curto-circuito
Verificar se os sinais de entrada-saída estão
protegidos contra curtos-circuitos na alimenta­
ção elétrica e na terra
(ISO 16750-2)
216
5. Ensaios de CEM
5.1 Emissões radiadas e
suscetibilidade
Conformidade com o Regulamento ECE R10 218
5.2 Descarga eletrostática Conformidade com a norma ISO 10605: 2008 +
Retificação técnica: 2010 +
AMD1: 2014: +/- 4 kV para contacto e +/- 8 kV
para descarga de ar
218
▼M1
02016R0799 — PT — 21.08.2023 — 003.002 — 398
N. o Ensaio Descrição Requisitos correlatos
5.3 Suscetibilidade do tran­
sitório conduzido em
relação à alimentação
elétrica
Para versões de 24 V: conformidade com a
norma ISO 7637-2 + Regulamento ECE
n. o 10 rev. 3:
impulso 1a: Vs = - 450 V Ri = 50 ohms
impulso 2 a: Vs = - 37 V Ri = 2 ohms
impulso 2b: Vs = - 20 V Ri = 0,05 ohms
impulso 3 a: Vs = - 150 V Ri = 50 ohms
impulso 3b: Vs = - 150 V Ri = 50 ohms
impulso 4: Vs = - 16 V Va = - 12 V t6 =
100 ms
impulso 5: Vs = - 120 V Ri = 2,2 ohms td =
250 ms
Para versões de 12 V: conformidade com a
norma ISO 7637-1 - Regulamento ECE n. o 10
rev. 3:
impulso 1: Vs = - 75 V Ri = 10 ohms
impulso 2 a: Vs = - 37 V Ri = 2 ohms
impulso 2b: Vs = - 10 V Ri = 0,05 ohms
impulso 3 a: Vs = - 112 V Ri = 50 ohms
impulso 3b: Vs = - 75 V Ri = 50 ohms
impulso 4: Vs = - 6 V Va = - 5 V t6 = 15 ms
impulso 5: Vs = - 65 V Ri = 3ohms td =
100 ms
O ensaio do impulso 5 só é efetuado em
unidades-veículo destinadas a veículos sem
proteção externa comum contra descarga.
Relativamente a propostas de descarga, con­
sultar a norma ISO 16750-2, 4. a edição,
capítulo 4.6.4.
218
▼B
3. ENSAIOS DE FUNCIONALIDADE DO SENSOR DE MOVIMENTOS
Não Ensaio Descrição Requisitos correlatos
1. Exame administrativo
1.1 Documentação Adequação da documentação
2. Inspeção visual
2.1. Conformidade com a documentação
2.2. Identificação/marcações 225, 226
2.3 Materiais 219 a 223
2.4. Selagem 398, 401 a 405
3. Ensaios de funcionalidade
3.1 Dados de identificação do sensor de movimentos 95 a 97*
▼M1
02016R0799 — PT — 21.08.2023 — 003.002 — 399
Não Ensaio Descrição Requisitos correlatos
3.2 Emparelhamento do sensor de movimentos com a unidade-veículo 122*, 204
3.3 Deteção de movimentos
Precisão da medição de movimentos
30 a 35
3.4 Interface da unidade-veículo 02
3.5 Verificar se o sensor de movimentos é imune ao campo magnético. Em alter­
nativa, verificar se o sensor de movimentos reage a campos magnéticos que
perturbam a deteção de movimentos do veículo de forma a que uma VU em­
parelhada possa detetar, registar e memorizar falhas do sensor
217
4. Ensaios ambientais
4.1 Temperatura de funciona­
mento
Verificar funcionalidade (cf. definição no ensaio
3.3) na amplitude térmica [–40°C; +135°C], por
meio de:
IEC 60068-2-1 ensaio Ad, com a duração de 96
horas à temperatura mais baixa To min ,
IEC 60068-2-2 ensaio Bd, com a duração de 96
horas à temperatura mais alta To max
Ensaio de acordo com a norma ISO 16750-4:
capítulo 5.1.1.2: Low temperature operation test
(24 h a –40°C)
Este ensaio refere-se à norma IEC 60068-2-1:
Environmental testing — Part 2-1: Tests — Test
A: Cold IEC 68-2-2 ensaio Ad, com a duração
de 96 horas à temperatura mais baixa de –40°C.
Ensaio de acordo com a norma ISO 16750-4:
capítulo 5.1.2.2: High temperature operation test
(96 h a 135°C)
Este ensaio refere-se à norma IEC 60068-2-2:
Basic environmental testing procedures; part 2:
tests; tests B: dry heat
213
4.2 Ciclos térmicos Ensaio de acordo com a norma ISO 16750-4:
capítulo 5.3.2: Rapid change of temperature
with specified transition duration (–40°C/135°C,
20 ciclos; duração do ensaio 30 minutos a cada
temperatura)
IEC 60068-2-14: Environmental testing; Part 2-
-14: Tests; Test N: Change of temperature
213
4.3 Ciclos de humidade Verificar funcionalidade (cf. definição no ensaio
3.3) por meio da norma IEC 60068-2-30, ensaio
Db, seis ciclos de 24 horas, variando cada tem­
peratura de +25°C a +55°C e com humidade
relativa de 97 % a +25°C e de 93 % a +55°C
214
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 400
Não Ensaio Descrição Requisitos correlatos
4.4 Vibração ISO 16750-3: capítulo 4.1.2.6: Test VI: Com­
mercial vehicle, engine, gearbox
Ensaio de vibração do modo misto que inclui:
a) Ensaio de vibração sinusoidal, 20...520 Hz,
11.4 ... 120 m/s 2 ,
b) Ensaio de vibração aleatória, 10 … 2 000 Hz,
RMS 177 m/s 2
94 horas por eixo, incluindo o ciclo térmico
–20°C ... 70°C
Este ensaio refere-se à norma IEC 60068-2-80:
Environmental testing — Part 2-80: Tests —
Test Fi: Vibration — Mixed mode
219
4.5 Choque mecânico ISO 16750-3: capítulo 4.2.3: Test VI: Test for
devices in or on the gearbox
choque semi-sinusoidal, aceleração a acordar no
intervalo 3 000...15 000 m/s 2 , duração do im­
pulso a acordar, no entanto,
choques: a acordar
Este ensaio refere-se à norma IEC 60068-2-27:
Environmental testing. Part 2: Tests. Test Ea
and guidance: Shock
219
4.6 Proteção contra água e cor­
pos estranhos
Ensaio de acordo com a norma ISO 20653:
Road vehicles — Degree of protection (IP code)
— Protection of electrical equipment against
foreign objects, water and access
(Valor-alvo IP 64)
220, 221
4.7 Proteção contra polaridade
inversa
Verificar se o sensor de movimentos suporta
uma inversão na alimentação elétrica
216
4.8 Proteção contra curto-circuito Verificar se os sinais de entrada-saída estão pro­
tegidos contra curtos-circuitos na alimentação
elétrica e na terra
216
5. Ensaios de compatibilidade eletromagnética
5.1 Emissões radiadas e susceti­
bilidade
Verificar conformidade com o Regulamento
ECE R10
218
5.2 Descarga eletrostática Conformidade com a norma ISO 10605:2008 +
Retificação técnica: 2010 + AMD1:2014: +/–
4 kV para contacto e +/– 8 kV para descarga
de ar
218
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 401
Não Ensaio Descrição Requisitos correlatos
5.3 Suscetibilidade do transitório
conduzido em relação às li­
nhas de dados)
Para versões de 24 V: conformidade com a
norma ISO 7637-2 + Regulamento ECE n. o 10
Rev. 3:
impulso 1a: Vs = –450 V Ri = 50 ohms
impulso 2a: Vs = +37 V Ri = 2 ohms
impulso 2b: Vs = +20V Ri = 0,05 ohms
impulso 3a: Vs = –150 V Ri = 50 ohms
impulso 3b: Vs = +150 V Ri = 50 ohms
impulso 4: Vs = –16 V Va = –12 V t6 = 100ms
impulso 5: Vs = +120 V Ri = 2,2 ohms td =
250ms
Para versões de 12 V: conformidade com a
norma ISO 7637-1 + Regulamento ECE n. o 10
Rev. 3:
impulso 1: Vs = –75 V Ri = 10 ohms
impulso 2a: Vs = +37 V Ri = 2 ohms
impulso 2b: Vs = +10 V Ri = 0,05 ohms
impulso 3a: Vs = –112 V Ri = 50 ohms
impulso 3b: Vs = +75 V Ri = 50 ohms
impulso 4: Vs = –6 V Va = –5 V t6 = 15ms
impulso 5: Vs = +65 V Ri = 3ohms td = 100ms
O ensaio do impulso 5 só é efetuado em
unidades-veículo destinadas a veículos sem pro­
teção externa comum contra descarga.
Relativamente a propostas de descarga, consul­
tar a norma ISO 16750-2, 4. a edição,
capítulo 4.6.4
218
4. ENSAIOS DE FUNCIONALIDADE DOS CARTÕES TACOGRÁFICOS
Os ensaios, de acordo com a presente secção 4,
n. o 5 — «Ensaios de protocolo»,
n. o 6 — «Estrutura do cartão» e
n. o 7 — «Ensaios de funcionalidade»
podem ser executados pelo avaliador ou certificador durante o processo de
certificação de segurança por critérios comuns (CC), destinado ao módulo
de pastilha.
Os ensaios números 2.3 e 4.2 são os mesmos. Trata-se dos ensaios me­
cânicos combinados do corpo do cartão e do módulo de pastilha. Se um
destes componentes (corpo do cartão, módulo de pastilha) for alterado,
estes ensaios são necessários.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 402
N. o Ensaio Descrição Requisitos correlatos
1. Exame administrativo
1.1 Documentação Adequação da documentação
2 Corpo do cartão
2.1 Projeto impresso Verificar se todos os elementos de proteção e dados visí­
veis estão conformes e corretamente impressos no cartão.
[Designador]
Anexo 1C, capítulo 4.1 «Dados visíveis», 227)
O anverso do cartão terá o seguinte conteúdo
os termos «Cartão de condutor», «Cartão de controlo»,
«Cartão de oficina» ou «Cartão de empresa», consoante
o tipo de cartão, impressos em maiúsculas na(s) língua(s)
oficial(is) do Estado-Membro emissor.
[Nome do Estado-Membro]
Anexo 1C, capítulo 4.1 «Dados visíveis», 228)
O anverso do cartão terá o seguinte conteúdo:
Nome do Estado-Membro que emite o cartão
(facultativo).
[Sinal]
Anexo 1C, capítulo 4.1 «Dados visíveis», 229)
O anverso do cartão terá o seguinte conteúdo:
Símbolo distintivo do Estado-Membro que emite o
cartão, impresso em negativo num retângulo azul e
rodeado de 12 estrelas amarelas.
[Enumeração]
Anexo 1C, capítulo 4.1 «Dados visíveis», 232)
O verso do cartão terá o seguinte conteúdo:
explicação dos elementos numerados que constam do
anverso.
[Cor]
Anexo 1C, capítulo 4.1 «Dados visíveis», 234)
Os cartões tacográficos devem ser impressos com as
seguintes colorações de fundo:
— cartão de condutor: branco
— cartão de oficina: vermelho,
— cartão de controlo: azul,
— cartão de empresa: amarelo.
227 a 229, 232, 234
a 236
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 403
N. o Ensaio Descrição Requisitos correlatos
[Segurança]
Anexo 1C, capítulo 4.1 «Dados visíveis», 235)
Os cartões tacográficos devem ter as seguintes
características de proteção contra falsificações:
— fundo de segurança em guilhoché fino e impressão
irisada
— pelo menos uma linha de microimpressão bicro-
mática.
[Marcações]
Anexo 1C, capítulo 4.1 «Dados visíveis», 236)
Os Estados-Membros podem acrescentar cores ou
marcações, como símbolos nacionais e elementos de
segurança.
[Marca de homologação]
Os cartões tacográficos devem conter uma marca de
homologação,
com a seguinte composição:
— um retângulo, no interior do qual é colocada a
letra «e», seguida de uma letra ou de um número
distintivo do país que tiver concedido a homo-
logação
— o número de homologação, correspondente ao
número do certificado de homologação de um
cartão tacográfico, colocado na proximidade do
retângulo.
2.2 Ensaios mecânicos
[Tamanho do cartão]
Os cartões tacográficos devem cumprir a norma
ISO/IEC 7810, Identification cards — Physical
characteristics,
[5] Dimension of card,
[5.1] Card size,
[5.1.1] Card dimensions and tolerances,
card type ID-1 Unused card
[Rebordos do cartão]
Os cartões tacográficos devem cumprir a norma
ISO/IEC 7810, Identification cards — Physical
characteristics,
[5] Dimension of card,
[5.1] Card size,
[5.1.2] Card edges
240, 243
ISO/IEC 7810
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 404
N. o Ensaio Descrição Requisitos correlatos
[Estrutura do cartão]
Os cartões tacográficos devem cumprir a norma
ISO/IEC 7810, Identification cards — Physical
characteristics,
[6] Card construction
[Materiais do cartão]
Os cartões tacográficos devem cumprir a norma
ISO/IEC 7810, Identification cards — Physical
characteristics,
[7] Card materials
[Rigidez à dobragem]
Os cartões tacográficos devem cumprir a norma
ISO/IEC 7810, Identification cards — Physical
characteristics,
[8] Card characteristics,
[8.1] Bending stiffness
[Toxicidade]
Os cartões tacográficos devem cumprir a norma
ISO/IEC 7810, Identification cards — Physical
characteristics,
[8] Card characteristics,
[8.3] Toxicity
[Resistência a agentes químicos]
Os cartões tacográficos devem cumprir a norma
ISO/IEC 7810, Identification cards — Physical
characteristics,
[8] Card characteristics,
[8.4] Resistance to chemicals
[Estabilidade do cartão]
Os cartões tacográficos devem cumprir a norma
ISO/IEC 7810, Identification cards — Physical
characteristics,
[8] Card characteristics,
[8.5] Card dimensional stability and warpage with
temperature and humidity
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 405
N. o Ensaio Descrição Requisitos correlatos
[Luz]
Os cartões tacográficos devem cumprir a norma
ISO/IEC 7810, Identification cards — Physical
characteristics,
[8] Card characteristics,
[8.6] Light
[Durabilidade]
Anexo 1C, capítulo 4.4 «Especificações ambientais e
elétricas», 241)
Os cartões tacográficos devem poder funcionar
corretamente durante um período de cinco anos, desde
que utilizados em conformidade com as especifica-
ções ambientais e elétricas.
[Resistência ao rasgamento]
Os cartões tacográficos devem cumprir a norma
ISO/IEC 7810, Identification cards — Physical
characteristics,
[8] Card characteristics,
[8.8] Peel strength
[Adesão ou bloqueamento]
Os cartões tacográficos devem cumprir a norma
ISO/IEC 7810, Identification cards — Physical
characteristics,
[8] Card characteristics,
[8.9] Adhesion or blocking
[Deformação]
Os cartões tacográficos devem cumprir a norma
ISO/IEC 7810, Identification cards — Physical
characteristics,
[8] Card characteristics,
[8.11] Overall card warpage
[Resistência ao calor]
Os cartões tacográficos devem cumprir a norma
ISO/IEC 7810, Identification cards — Physical
characteristics,
[8] Card characteristics,
[8.12] Resistance to heat
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 406
N. o Ensaio Descrição Requisitos correlatos
[Distorções de superfície]
Os cartões tacográficos devem cumprir a norma
ISO/IEC 7810, Identification cards — Physical
characteristics,
[8] Card characteristics,
[8.13] Surface distortions
[Contaminação]
Os cartões tacográficos devem cumprir a norma
ISO/IEC 7810, Identification cards — Physical
characteristics,
[8] Card characteristics,
[8.14] Contamination and interaction of card
components
2.3 Ensaios mecânicos
com módulo de pasti­
lha integrado
[Curvatura]
Os cartões tacográficos devem cumprir a norma
ISO/IEC 7810:2003/Amd. 1:2009, Identification
cards — Physical characteristics, Amendment 1:
Criteria for cards containing integrated circuits
[9.2] Dynamic bending stress
Número total de ciclos de curvatura: 4 000.
[Torção]
Os cartões tacográficos devem cumprir a norma
ISO/IEC 7810:2003/Amd. 1:2009, Identification cards
— Physical characteristics, Amendment 1: Criteria for
cards containing integrated circuits
[9.3] Dynamic torsional stress
Número total de ciclos de torção: 4 000.
ISO/IEC 7810
3 Módulo
3.1 Módulo O módulo é a encapsulação de pastilhas e a placa de
contacto.
[Perfil da superfície]
Os cartões tacográficos devem cumprir a norma
ISO/IEC 7816-1:2011, Identification cards — Inte­
grated circuit cards — Part 1: Cards with contacts
— Physical characteristics
[4.2] Surface profile of contacts
ISO/IEC 7816
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 407
N. o Ensaio Descrição Requisitos correlatos
[Resistência mecânica]
Os cartões tacográficos devem cumprir a norma
ISO/IEC 7816-1:2011, Identification cards — Inte­
grated circuit cards — Part 1: Cards with contacts
— Physical characteristics
[4.3] Mechanical strength (of a card and contacts)
[Resistência elétrica]
Os cartões tacográficos devem cumprir a norma
ISO/IEC 7816-1:2011, Identification cards — Inte-
grated circuit cards — Part 1: Cards with contacts —
Physical characteristics
[4.4] Electrical resistance (of contacts)
[Dimensões]
Os cartões tacográficos devem cumprir a norma
ISO/IEC 7816-2:2007, Identification cards — Inte-
grated circuit cards — Part 2: Cards with contacts —
Dimension and location of the contacts
[3] Dimension of the contacts
[Localização]
Os cartões tacográficos devem cumprir a norma
ISO/IEC 7816-2:2007, Identification cards — Inte-
grated circuit cards — Part 2: Cards with contacts —
Dimension and location of the contacts
[4] Number and location of the contacts
No caso dos módulos com seis contactos, os contactos
«C4» e «C8» não são parte integrante do presente
requisito de ensaio.
4 Pastilha
4.1 Pastilha
[Temperatura de funcionamento]
A pastilha do cartão tacográfico deve funcionar numa
amplitude térmica entre – 25 °C e + 85 °C.
241 a 244
Regulamento ECE
R10
ISO/IEC 7810
ISO/IEC 10373
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 408
N. o Ensaio Descrição Requisitos correlatos
[Temperatura e humidade]
Anexo 1C, capítulo 4.4 «Especificações ambientais e
elétricas», 241)
Os cartões tacográficos devem poder funcionar cor­
retamente nas condições climáticas normais do terri­
tório da União Europeia e pelo menos na amplitude
térmica de – 25 °C a + 70 °C, com picos ocasionais
até + 85 °C, entendendo-se por «ocasionais» ocor­
rências de duração não superior a 4 horas e em
número não superior a 100 ao longo do período de
vida útil do cartão.
Expõem-se os cartões tacográficos à sequência de
temperaturas e humidades durante o tempo determi­
nado e em etapas consecutivas. Após cada etapa,
testam-se quanto à funcionalidade elétrica.
1. Temperatura de – 20 °C, durante 2 horas.
2. Temperatura de +/– 0 °C, durante 2 horas.
3. Temperatura de + 20 °C, 50 % de HR (humidade
relativa), durante 2 horas.
4. Temperatura de + 50 °C, 50 % de HR, durante 2
horas.
5. Temperatura de + 70 °C, 50 % de HR, durante 2
horas.
A temperatura é aumentada de modo intermitente
para + 85 °C, 50 % de HR, durante 60 minutos.
6. Temperatura de + 70 °C, 85 % de HR, durante 2
horas.
A temperatura é aumentada de modo intermitente
para + 85 °C, 85 % de HR, durante 30 minutos.
[Humidade]
Anexo 1C, capítulo 4.4 «Especificações ambientais e
elétricas», 242)
Os cartões tacográficos devem poder funcionar
corretamente no intervalo de humidade entre 10 % e
90 %.
[Compatibilidade eletromagnética — EMC]
Anexo 1C, capítulo 4.4 «Especificações ambientais e
elétricas», 244)
Durante o seu funcionamento, os cartões tacográficos
devem cumprir o disposto no Regulamento ECE R10,
relativo à compatibilidade eletromagnética.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 409
N. o Ensaio Descrição Requisitos correlatos
[Eletricidade estática]
Anexo 1C, capítulo 4.4 «Especificações ambientais e
elétricas», 244)
Durante o seu funcionamento, os cartões tacográficos
devem estar protegidos contra as descargas eletrostá-
ticas.
Os cartões tacográficos devem cumprir a norma
ISO/IEC 7810:2003/Amd. 1:2009, Identification cards
— Physical characteristics, Amendment 1: Criteria for
cards containing integrated circuits
[9.4] Static electricity
[9.4.1] Contact IC cards
Tensão de ensaio: 4 000 V.
[Raios X]
Os cartões tacográficos devem cumprir a norma
ISO/IEC 7810:2003/Amd. 1:2009, Identification cards
— Physical characteristics, Amendment 1: Criteria for
cards containing integrated circuits
[9.1] X-rays
[Luz ultravioleta]
ISO/IEC 10373-1:2006, Identification cards — Test
methods — Part 1: General characteristics
[5.11] Ultraviolet light
[3-wheel]
Os cartões tacográficos devem cumprir a norma
ISO/IEC 10373-1:2006/Amd. 1:2012, Identification
cards — Test methods — Part 1: General character-
istics, Amendment 1
[5.22] ICC — Mechanical strength: 3 wheel test for
ICCs with contacts
[Acondicionamento]
Os cartões tacográficos devem cumprir a norma
MasterCard CQM V2.03:2013
[11.1.3] R-L3-14-8: Wrapping Test Robustness
[13.2.1.32] TM-422: Mechanical Reliability: Wrap-
ping Test
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 410
N. o Ensaio Descrição Requisitos correlatos
4.2 Ensaios mecânicos do
módulo de pastilha in­
tegrado no corpo do
cartão (o mesmo que
2.3)
[Dobragem]
Os cartões tacográficos devem cumprir a norma
ISO/IEC 7810:2003/Amd. 1:2009, Identification
cards — Physical characteristics, Amendment 1:
Criteria for cards containing integrated circuits
[9.2] Dynamic bending stress
Número total de ciclos de dobragem: 4 000.
[Torção]
Os cartões tacográficos devem cumprir a norma
ISO/IEC 7810:2003/Amd. 1:2009, Identification cards
— Physical characteristics, Amendment 1: Criteria for
cards containing integrated circuits
[9.3] Dynamic torsional stress
Número total de ciclos de torção: 4 000.
ISO/IEC 7810
5 Ensaios de protocolo
5.1 ATR Verificar a conformidade da ATR ISO/IEC 7816-3
TCS_14, TCS_17,
TCS_18
5.2 T=0 Verificar a conformidade do protocolo T=0 ISO/IEC 7816-3
TCS_11, TCS_12,
TCS_13, TCS_15
5.3 PTS Verificar a conformidade do comando PTS, passando
de T=0 a T=1.
ISO/IEC 7816-3
TCS_12, TCS_19,
TCS_20, TCS_21
5.4 T=1 Verificar a conformidade do protocolo T=1 ISO/IEC 7816-3
TCS_11, TCS_13,
TCS_16
6 Estrutura do cartão
6.1 Verificar a conformidade da estrutura de ficheiro do
cartão, controlando a presença dos ficheiros obrigató­
rios no cartão e as suas condições de acesso
TCS_22 a TCS_28
TCS_140 a TCS_179
7 Ensaios de funcionalidade
7.1 Processamento normal Verificar pelo menos uma vez cada uma das utiliza­
ções autorizadas de cada comando (por exemplo, en­
saiar o comando UPDATE BINARY com CLA =
«00» e CLA = «0C» e com diferentes parâmetros
P1, P2 e Lc)
Verificar se as operações foram realmente executadas
no cartão (ex: ler o ficheiro no qual o comando foi
executado)
TCS_29 a TCS_139
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 411
N. o Ensaio Descrição Requisitos correlatos
7.2 Mensagens de erro Verificar pelo menos uma vez cada uma das mensa­
gens de erro (cf. apêndice 2) para cada comando
Verificar pelo menos uma vez cada um dos erros ge­
néricos (exceto os erros de integridade «6400» con­
trolados durante a certificação de segurança)
7.3 Parâmetros de domínio normalizados e de sequência de cifras CSM_48, CSM_50
8 Personalização
8.1 Personalização ótica
Anexo 1C, capítulo 4.1 «Dados visíveis», 230)
O anverso do cartão terá o seguinte conteúdo:
elementos específicos do cartão emitido.
Anexo 1C, capítulo 4.1 «Dados visíveis», 231)
O anverso do cartão terá o seguinte conteúdo:
d a t a s , c o m o f o r m a t o « d d / m m / a a a a » o u
«dd.mm.aaaa» (dia, mês, ano).
Anexo 1C, capítulo 4.1 «Dados visíveis», 235)
Os cartões tacográficos devem ter as seguintes
características de proteção contra falsificações:
— na zona da fotografia, sobreposição do fundo de
segurança e da fotografia.
230, 231, 235
5. ENSAIOS DO MÓDULO GNSS EXTERNO
N. o Ensaio Descrição Requisitos correlatos
1. Exame administrativo
1.1 Documentação Adequação da documentação
2. Inspeção visual do módulo GNSS externo
2.1. Conformidade com a documentação
2.2. Identificação/marcações 224 a 226
2.3 Materiais 219 a 223
3. Ensaios de funcionalidade
3.1 Dados de identificação do sensor de movimentos 98, 99
3.2 Módulo GNSS externo — acoplamento da unidade-veículo 123, 205
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 412
N. o Ensaio Descrição Requisitos correlatos
3.3 Posição GNSS 36, 37
3.4 Interface da unidade-veículo quando o recetor GNSS é externo à
unidade-veículo
03
3.5 Parâmetros de domínio normalizados e de sequência de cifras CSM_48, CSM_50
4. Ensaios ambientais
4.1 Temperatura Verificar funcionalidade por meio de:
Ensaio de acordo com a norma ISO 16750-4,
capítulo 5.1.1.2: Low temperature operation test (72 h a –
20 °C)
Este ensaio refere-se à norma IEC 60068-2-1: Environmental
testing — Part 2-1: Tests — Test A: Cold
Ensaio de acordo com a norma ISO 16750-4: capítulo 5.1.2.2:
High temperature operation test (72 h, 70 °C)
Este ensaio refere-se à norma IEC 60068-2-2: Basic environ­
mental testing procedures; part 2: tests; tests B: dry heat
Ensaio de acordo com a norma ISO 16750-4: capítulo 5.3.2:
Rapid change of temperature with specified transition duration
(–20°C/70°C, 20 ciclos; duração do ensaio 1 hora a cada tem­
peratura)
Pode ser efetuado um conjunto reduzido de ensaios (entre os
definidos na secção 3 deste quadro) à temperatura mais baixa, à
temperatura mais alta e durante os ciclos de temperatura
213
4.2 Humidade Verificar se a unidade-veículo suporta variações cíclicas de
humidade (ensaio térmico) por meio da norma IEC 60068-2-
-30, ensaio Db, seis ciclos de 24 horas, variando cada tempe­
ratura de + 25 °C a + 55 °C e com humidade relativa de
97 % a + 25 °C e de 93 % a +55 °C
214
4.3 Mecânica 1. Vibrações sinusoidais:
Verificar se a unidade-veículo suporta vibrações sinusoi­
dais com as seguintes características:
deslocamento constante entre 5 e 11 Hz: pico de 10 mm
aceleração constante entre 11 e 300 Hz: 5 g
Este requisito é verificado por meio da norma IEC 60068-
-2-6, ensaio Fc, com a duração mínima de 3 × 12 horas
(12 horas por eixo)
A norma ISO 16750-3 não exige ensaio de vibração si­
nusoidal em dispositivos localizados na cabina do veículo
separada.
219
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 413
N. o Ensaio Descrição Requisitos correlatos
2. Vibrações aleatórias:
Ensaio de acordo com a norma ISO 16750-3: capítu-
lo 4.1.2.8: Test VIII: Commercial vehicle, decoupled
vehicle cab
Ensaio de vibração aleatória, 10…2 000 Hz, RMS vertical
21,3 m/s 2 , RMS longitudinal 11,8 m/s 2 , RMS lateral
13,1 m/s 2 , 3 eixos, 32 h por eixo, incluindo o ciclo de
temperatura –20 °C ... 70 °C.
Este ensaio refere-se à norma IEC 60068-2-64: Environ-
mental testing — Part 2-64: Tests — Test Fh: Vibration,
broadband random and guidance
3. Choques
Choque mecânico com 3 g de meio seio, de acordo com a
norma ISO 16750.
Os dois ensaios supra são executados sobre diferentes
amostras do tipo de equipamento em ensaio.
4.4 Proteção contra
água e corpos
estranhos
Ensaio de acordo com a norma ISO 20653: Road vehicles —
Degree of protection (IP code) — Protection of electrical
equipment against foreign objects, water and access (Sem
alterações nos parâmetros)
220, 221
4.5 Proteção contra
sobretensão
Verificar se a unidade-veículo suporta as seguintes tensões de
alimentação:
216
Versões de 24 V: 34 V a +40 °C, 1 hora
Versões de 12 V: 17 V a +40 °C, 1 hora
(ISO 16750-2, capítulo 4.3)
4.6 Proteção contra
polaridade in­
versa
Verificar se a unidade-veículo suporta uma inversão na ali­
mentação elétrica
(ISO 16750-2, capítulo 4.7)
216
4.7 Proteção contra
curto-circuito
Verificar se os sinais de entrada-saída estão protegidos contra
curtos-circuitos na alimentação elétrica e na terra
(ISO 16750-2, capítulo 4.10)
216
5 Ensaios de CEM
5.1 Emissões radia­
das e suscetibi­
lidade
Conformidade com o Regulamento ECE R10 218
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 414
N. o Ensaio Descrição Requisitos correlatos
5.2 Descarga ele­
trostática
Conformidade com a norma ISO 10605:2008 + Retificação
técnica: 2010 + AMD1:2014: +/– 4 kV para contacto e +/–
8 kV para descarga de ar
218
5.3 Suscetibilidade
do transitório
conduzido em
relação à ali­
mentação elé­
trica
Para versões de 24 V: conformidade com a norma ISO 7637-
-2 + Regulamento ECE n. o 10 Rev. 3:
impulso 1a: Vs = – 450 V Ri = 50 ohms
impulso 2a: Vs = + 37 V Ri = 2 ohms
impulso 2b: Vs = + 20 V Ri = 0,05 ohms
impulso 3a: Vs = – 150 V Ri = 50 ohms
impulso 3b: Vs = + 150 V Ri = 50 ohms
impulso 4: Vs = – 16 V Va = – 12 V t6 = 100 ms
impulso 5: Vs = + 120 V Ri = 2,2 ohms td = 250 ms
Para versões de 12 V: conformidade com a norma ISO 7637-
-1 + Regulamento ECE n. o 10 Rev. 3:
impulso 1: Vs = – 75 V Ri = 10 ohms
impulso 2a: Vs = + 37 V Ri = 2 ohms
impulso 2b: Vs = + 10 V Ri = 0,05 ohms
impulso 3a: Vs = – 112 V Ri = 50 ohms
impulso 3b: Vs = + 75 V Ri = 50 ohms
impulso 4: Vs = – 6 V Va = – 5 V t6 = 15 ms
impulso 5: Vs = + 65 V Ri = 3 ohms td = 100 ms
O ensaio do impulso 5 só é efetuado em unidades-veículo
destinadas a veículos sem proteção externa comum contra
descarga.
Relativamente a propostas de descarga, consultar a norma
ISO 16750-2, 4. a edição, capítulo 4.6.4.
218
▼M1
6. ENSAIO DO SISTEMA DE COMUNICAÇÃO À DISTÂNCIA
N. o Ensaio Descrição Requisitos correlatos
1. Exame administrativo
1.1 Documentação Adequação da docu­
mentação
2. Inspeção visual
2.1. Conformidade com a documentação
2.2. Identificação/marcações 225, 226
2,3 Materiais 219 to 223
3. Ensaios de funcionalidade
3.1 Comunicação à distância para controlos de estrada seletivos 4, 197 to 199,
3.2 Registo e memorização de dados na memória 91
3.3 Comunicação com a unidade-veículo Apêndice 14
DSC_66 a DSC_70,
DSC_71 a DSC_76
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 415
N. o Ensaio Descrição Requisitos correlatos
4. Ensaios ambientais
4.1 Temperatura Verificar funcionalidade por meio de:
Ensaio de acordo com a norma ISO 16750-4,
capítulo 5.1.1.2: Low temperature operation test (72 h
a-20 °C)
Este ensaio refere-se à norma IEC 60068-2-1: Environ­
mental testing – Part 2-1: Tests – Test A: Cold
Ensaio de acordo com a norma ISO 16750-4:
capítulo 5.1.2.2: High temperature operation test (72 h
a 70 °C)
Este ensaio refere-se à norma IEC 60068-2-2: Basic en­
vironmental testing procedures; part 2: tests;
Ensaio de acordo com a norma ISO 16750-4:
capítulo 5.3.2: Rapid change of temperature with speci­
fied transition duration (-20 °C/70 °C, 20 ciclos; duração
do ensaio 1 hora a cada temperatura)
Pode ser efetuado um conjunto reduzido de ensaios (en­
tre os definidos na secção 3 deste quadro) à temperatura
mais baixa, à temperatura mais alta e durante os ciclos
de temperatura
213
4.2 Proteção contra
água e corpos estra­
nhos
Ensaio de acordo com a norma ISO 20653: Road vehi­
cles – Degree of protection (IP code) – Protection of
electrical equipment against foreign objects, water and
access (valor visado IP40)
220, 221
5. Ensaios de CEM
5.1 Emissões radiadas e
suscetibilidade
Conformidade com o Regulamento ECE R10 218
5.2 Descarga eletrostá­
tica
Conformidade com a norma ISO 10605: 2008 + Retifi­
cação técnica: 2010 + AMD1: 2014: +/- 4 kV para con­
tacto e +/- 8 kV para descarga de ar
218
5.3 Suscetibilidade do
transitório condu­
zido em relação à
alimentação elétrica
Para versões de 24 V: conformidade com a norma ISO
7637-2 + Regulamento ECE n. o 10 rev. 3:
impulso 1a: Vs = - 450 V Ri = 50 ohms
impulso 2 a: Vs = + 37 V Ri = 2 ohms
impulso 2b: Vs = + 20 V Ri = 0,05 ohms
impulso 3 a: Vs = - 150 V Ri = 50 ohms
impulso 3b: Vs = + 150 V Ri = 50 ohms
impulso 4: Vs = - 16 V Va = -12 V t6 = 100ms
impulso 5: Vs = + 120 V Ri = 2,2 ohms td = 250ms
Para versões de 12 V: conformidade com a norma ISO
7637-1 + Regulamento ECE n. o 10 rev. 3:
impulso 1: Vs = - 75 V Ri = 10 ohms
impulso 2 a: Vs = + 37 V Ri = 2 ohms
impulso 2b: Vs = + 10 V Ri = 0,05 ohms
impulso 3 a: Vs = - 112 V Ri = 50 ohms
218
▼M1
02016R0799 — PT — 21.08.2023 — 003.002 — 416
N. o Ensaio Descrição Requisitos correlatos
impulso 3b: Vs = + 75 V Ri = 50 ohms
impulso 4: Vs = - 6 V Va = -5 V t6 = 15ms
impulso 5: Vs = + 65 V Ri = 3ohms td = 100ms
O ensaio do impulso 5 só é efetuado em
unidades-veículo destinadas a veículos sem proteção ex­
terna comum contra descarga.
Relativamente a propostas de descarga, consultar a
norma ISO 16750-2, 4. a edição, capítulo 4.6.4.
▼B
7. ENSAIOS DE FUNCIONALIDADE EM PAPEL
N. o Ensaio Descrição Requisitos correlatos
1. Exame administrativo
1.1 Documentação Adequação da documentação
2 Ensaios gerais
2.1 Número de carateres
por linha
Inspeção visual das impressões 172
2.2 Tamanho mínimo do
caráter
Inspeção visual da impressão e inspeção do caráter 173
2.3 Conjuntos de carate­
res aceites
A impressora deve aceitar os carateres indicados no
apêndice 1, capítulo 4 «Conjuntos de carateres»
174
2.4 Definição das im­
pressões
Verificação da homologação de tipo do tacógrafo e ins­
peção visual das impressões
174
2.5 Legibilidade e identi­
ficação das impres­
sões
Inspeção das impressões
Demonstrada por relatórios e protocolos de ensaio, pelo
fabricante
Todos os números de homologação de tacógrafos com
os quais pode ser utilizado o papel da impressora são
impressos no papel
175, 177, 178
2.6 Adição de notas ma­
nuscritas
Inspeção visual: Está disponível o campo para assina­
tura do condutor
Estão disponíveis campos para outras notas manuscritas
180
2.7 Pormenores adicio­
nais no rosto do pa­
pel
O rosto e o verso do papel podem apresentar pormeno­
res e informações adicionais
Estes pormenores e informações adicionais não podem
interferir na legibilidade das impressões
Inspeção visual
177, 178
▼M1
02016R0799 — PT — 21.08.2023 — 003.002 — 417
N. o Ensaio Descrição Requisitos correlatos
3 Ensaios de memorização
3.1 Calor seco Pré-condicionamento: 16 horas a +23 °C ± 2 °C/55 %
± 3 % de humidade relativa
Ambiente de ensaio: 72 horas a +70 °C ± 2 °C
Recuperação: 16 horas a + 23 °C ± 2 °C/55 % ± 3 %
de humidade relativa
176, 178
IEC 60068-2-2-Bb
2.2 Calor húmido Pré-condicionamento: 16 horas a + 23 °C ± 2 °C/55 %
± 3 % de humidade relativa
Ambiente de ensaio: 144 horas a + 55 °C ± 2 °C e
93 % ± 3 % de humidade relativa
Recuperação: 16 horas a + 23 °C ± 2 °C/55 % ± 3 %
de humidade relativa
176, 178
IEC 60068-2-78-Cab
4 Ensaios de papel contínuo
4.1 Contexto de resistên­
cia à humidade (pa­
pel não impresso)
Pré-condicionamento: 16 horas a + 23 °C ± 2 °C/55 %
± 3 % de humidade relativa
Ambiente de ensaio: 144 horas a + 55 °C ± 2 °C e
93 % ± 3 % de humidade relativa
Recuperação: 16 horas a + 23 °C ± 2 °C/55 % ± 3 %
de humidade relativa
176, 178
IEC 60068-2-78-Cab
4.2 Capacidade de im­
pressão
Pré-condicionamento: 24 horas a +40 °C ± 2 °C/93 %
±3 % de humidade relativa
Ambiente de ensaio: impressão produzida a + 23 °C
± 2 °C
Recuperação: 16 horas a + 23 °C ± 2 °C/55 % ± 3 %
de humidade relativa
176, 178
4.3 Resistência ao pó Pré-condicionamento: 16 horas a + 23 °C ± 2 °C/55 %
± 3 % de humidade relativa
Ambiente de ensaio: 2 horas a + 70 °C ± 2 °C, calor
seco
Recuperação: 16 horas a + 23 °C ± 2 °C/55 % ± 3 %
de humidade relativa
176, 178
IEC 60068-2-2-Bb
4.4 Resistência a baixas
temperaturas
Pré-condicionamento: 16 horas a + 23 °C ± 2 °C/55 %
± 3 % de humidade relativa
Ambiente de ensaio: 24 horas – 20 °C ± 3 °C, frio seco
Recuperação: 16 horas a + 23 °C ± 2 °C/55 % ± 3 %
de humidade relativa
176, 178
ISO 60068-2-1-Ab
4.5 Resistência à luz Pré-condicionamento: 16 horas a + 23 °C ± 2 °C/55 %
± 3 % de humidade relativa
Ambiente de ensaio: 100 horas sob 5 000 Lux de ilu­
minação a + 23 °C ± 2 °C/55 % ± 3 % de humidade
relativa
Recuperação: 16 horas a + 23 °C ± 2 °C/55 % ± 3 %
de humidade relativa
176, 178
Critérios de legibilidade para os ensaios 3.x e 4.x:
A legibilidade da impressão está garantida se as densidades óticas cum­
prirem os seguintes limites:
Carateres impressos: mín. 1,0
Fundo (papel não impresso): máx. 0,2
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 418
As densidades óticas das impressões obtidas devem ser medidas de acordo
com a norma DIN EN ISO 534.
As impressões não podem apresentar alterações das dimensões e devem
ser bem legíveis.
8. ENSAIOS DE INTEROPERABILIDADE
▼M1
N. o Ensaio Descrição
8.1 Ensaios de interoperabilidade entre unidades-veículo e cartões tacográficos
1 Autenticação mútua Verificar se funciona normalmente a autenticação mútua entre
a unidade-veículo e o cartão tacográfico
2 Ensaios de leitura/escrita Encenar uma atividade típica na unidade-veículo. O cenário deve
ser adaptado ao tipo de cartão em ensaio e envolver escritas em
tantos EF quantos os possíveis no cartão
Por meio de um descarregamento da unidade-veículo, verificar se
todos os registos correspondentes foram executados corretamente
Por meio de um descarregamento do cartão, verificar se todos os
registos correspondentes foram executados corretamente
Por meio de impressões diárias, verificar se todos os registos cor­
respondentes podem ser lidos corretamente
8.2 Ensaios de interoperabilidade entre unidades-veículo e sensores de movimento
1 Emparelhamento Verificar se funciona normalmente o emparelhamento entre as
unidades-veículo e os sensores de movimento
2 Ensaios de atividade Encenar uma atividade típica no sensor de movimento. O cenário
deve implicar uma atividade normal e criar tantos incidentes ou
falhas quantos os possíveis.
Por meio de um descarregamento da unidade-veículo, verificar se
todos os registos correspondentes foram executados corretamente
Por meio de um descarregamento do cartão, verificar se todos os
registos correspondentes foram executados corretamente
Por meio de uma impressão diária do cartão, verificar se todos os
registos correspondentes podem ser lidos corretamente
8.3 Ensaios de interoperabilidade entre as unidades-veículo e os módulos GNSS externos (quando aplicável)
1 Autenticação mútua Verificar se funciona normalmente a autenticação mútua (acopla­
mento) entre a unidade-veículo e o módulo GNSS externo.
2 Ensaios de atividade O cenário deve implicar uma atividade normal e criar tantos inci­
dentes ou falhas quantos os possíveis.
Por meio de um descarregamento da unidade-veículo, verificar se
todos os registos correspondentes foram executados corretamente
Por meio de um descarregamento do cartão, verificar se todos os
registos correspondentes foram executados corretamente
Por meio de uma impressão diária do cartão, verificar se todos os
registos correspondentes podem ser lidos corretamente
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 419
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 in­
dependência de qualquer outro componente do tacógrafo, os ensaios des­
critos 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 desenvolvi­
mento 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 rece­
tor 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 in­
formação da Chave Pública (P) e da
DSM-KROOT (K) (conforme definido nas
diretrizes relativas ao recetor OSNMA referi­
das 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 assi­
natura 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 se­
quê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)
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 420
SLMAC Slow MAC (MAC lento)
TESLA Timed Efficient Stream Loss-tolerant Authentication (Au­
tenticaçã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 car­
regar 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 caracte­
rí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 5 o ;
— 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 carac­
terísticas:
— Uma mensagem HKROOT com estatuto de OSNMA fixado em Ope­
racional 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).
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 421
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 sin­
cronizaçã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 con­
servadores 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 po­
siçã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 po­
siçã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 po­
siçã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 con­
figurada 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.
Apêndice 12,
GNS_3b
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 422
N. o Teste Descrição Requisitos correlatos
Antes de iniciar os testes, as efemérides e as informa­
ções KROOT devem ser apagadas da memória do re­
cetor 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 ape­
nas com MAC lento da OSNMA (ADKD = 12) e for­
nece 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.
2.4 Arranque a quente da
OSNMA com sinal re­
produzido
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 autenti­
cados, 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 in­
terrompe 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 autenti­
cada 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 OS­
NMA.
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
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 423
Apêndice 10
REQUISITOS DE SEGURANÇA
O presente apêndice especifica os requisitos de segurança de TI para os compo­
nentes do sistema tacográfico inteligente (tacógrafo da segunda geração).
SEC_001 Os componentes do sistema tacográfico inteligente a seguir indicados
devem ter certificação de segurança, de acordo com o sistema de
critérios comuns:
— unidade-veículo
— cartão tacográfico
— sensor de movimentos
— módulo GNSS externo
SEC_002 Os requisitos mínimos de segurança de TI a cumprir por cada com­
ponente que exija certificação de segurança devem ser definidos no
perfil de proteção do componente, de acordo com o sistema de crité­
rios comuns.
SEC_003 A Comissão Europeia garantirá que quatro perfis de proteção confor­
mes com o presente anexo são patrocinados, desenvolvidos, homolo­
gados pelos organismos governamentais de certificação de segurança
de TI no âmbito do Grupo de Trabalho Conjunto de
Interpretação (JIWG) que apoia o reconhecimento mútuo de certifica­
dos sob a égide do SOGIS-MRA europeu (Acordo sobre o Reconhe­
cimento Mútuo dos Certificados de Avaliação de Segurança da Tec­
nologia da Informação) e registados:
— perfil de proteção para unidade-veículo
— perfil de proteção para cartão tacográfico
— perfil de proteção para sensor de movimentos
— perfil de proteção para módulo GNSS externo
O perfil de proteção para a unidade-veículo deve abordar as situações em que a
VU é concebida para ser utilizada ou não com um módulo GNSS externo. Os
requisitos de segurança do módulo GNSS externo são fornecidos no perfil de
proteção dedicado.
SEC_004 Os fabricantes de componentes devem aperfeiçoar e completar o perfil
de proteção adequado dos componentes na medida do necessário, sem
alterarem ou eliminarem eventuais ameaças, objetivos, meios de pro­
cedimento ou especificações de funções de concretização da segu­
rança, a fim de elaborar objetivos de segurança relativamente aos quais
podem pedir a certificação de segurança do componente.
SEC_005 Durante o processo de avaliação, deve indicar-se a conformidade es­
trita dos objetivos de segurança específicos com o correspondente
perfil de proteção.
SEC_006 O nível de garantia para cada perfil de proteção é EAL4 aumentado
pelos componentes de garantia ATE_DPT.2 e AVA_VAN.5.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 424
Apêndice 11
MECANISMOS COMUNS DE SEGURANÇA
ÍNDICE
PREÂMBULO
PARTE A SISTEMA TACOGRÁFICO DA PRIMEIRA GERAÇÃO
1. INTRODUÇÃO
1.1. Referências
1.2. Notações e abreviaturas
2. SISTEMAS E ALGORITMOS CRIPTOGRÁFICOS
2.1. Sistemas criptográficos
2.2. Algoritmos criptográficos
2.2.1 Algoritmo RSA
2.2.2 Algoritmo hash
2.2.3 Algoritmo de criptagem dos dados
3. CHAVES E CERTIFICADOS
3.1. Criação e distribuição de chaves
3.1.1 Criação e distribuição de chaves RSA
3.1.2 Chaves de ensaio RSA
3.1.3 Chaves de sensor de movimentos
3.1.4 Criação e distribuição de chaves de sessão T-DES
3.2. Chaves
3.3. Certificados
3.3.1 Conteúdo dos certificados
3.3.2 Certificados emitidos
3.3.3 Verificação e revelação de certificados
4. MECANISMO DE AUTENTICAÇÃO MÚTUA
5. MECANISMOS DE CONFIDENCIALIDADE, INTEGRIDADE E
AUTENTICAÇÃO NA TRANSFERÊNCIA DE DADOS ENTRE
VU E CARTÕES
5.1. Envio seguro de mensagens
5.2. Tratamento de erros no envio seguro de mensagens
5.3. Algoritmo para calcular somas criptográficas de teste
5.4. Algoritmo para o cálculo de criptogramas para DO de confidencia­
lidade
6. MECANISMOS DE ASSINATURA DIGITAL DO DESCARRE­
GAMENTO DE DADOS
6.1. Criação da assinatura
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 425
6.2. Verificação da assinatura
PARTE B SISTEMA TACOGRÁFICO DA SEGUNDA GERAÇÃO
7. INTRODUÇÃO
7.1. Referências
7.2. Notações e abreviaturas
7.3. Definições
8. SISTEMAS E ALGORITMOS CRIPTOGRÁFICOS
8.1. Sistemas criptográficos
8.2. Algoritmos criptográficos
8.2.1 Algoritmos simétricos
8.2.2 Parâmetros de domínio normalizados e de algoritmos assimétricos
8.2.3 Algoritmos de hash
8.2.4 Sequências de cifras
9. CHAVES E CERTIFICADOS
9.1. Pares de chaves assimétricas e certificados de chave pública
9.1.1 Generalidades
9.1.2 Nível europeu
9.1.3 Nível do Estado-Membro
9.1.4 Nível do equipamento ou aparelho: unidades-veículo
9.1.5 Nível do equipamento ou aparelho: cartões tacográficos
9.1.6 Nível do equipamento ou aparelho: módulos GNSS externos
9.1.7 Panorâmica: Substituição de certificados
9.2. Chaves simétricas
9.2.1 Chaves para proteção das comunicações do sensor de movimentos
com a VU
9.2.2 Chaves para comunicações DSRC seguras
9.3. Certificados
9.3.1 Generalidades
9.3.2 Conteúdo do certificado
9.3.3 Pedido de certificados
10. AUTENTICAÇÃO MÚTUA E ENVIO SEGURO DE MENSA­
GENS ENTRE O CARTÃO E A VU
10.1. Generalidades
10.2. Verificação mútua da cadeia de certificados
10.2.1 Verificação da cadeia de certificados de cartão pela VU
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 426
10.2.2 Verificação da cadeia de certificado da VU pelo cartão
10.3. Autenticação da VU
10.4. Autenticação da pastilha e concordância de chave de sessão
10.5. Envio seguro de mensagens
10.5.1 Generalidades
10.5.2 Estrutura do envio seguro de mensagens
10.5.3 Interrupção da sessão de envio seguro de mensagens
11. ACOPLAMENTO, AUTENTICAÇÃO MÚTUA E ENVIO SE­
GURO DE MENSAGENS DO MÓDULO GNSS EXTERNO
COM A VU
11.1. Generalidades
11.2. Acoplamento da VU e do módulo GNSS externo
11.3. Verificação mútua da cadeia de certificados
11.3.1 Generalidades
11.3.2 Durante o acoplamento VU-EGF
11.3.3 Durante o funcionamento normal
11.4. Autenticação da VU, autenticação da pastilha e concordância de
chave de sessão
11.5. Envio seguro de mensagens
12. EMPARELHAMENTO E COMUNICAÇÕES DO SENSOR DE
MOVIMENTOS COM A VU
12.1. Generalidades
12.2. Emparelhamento do sensor de movimentos com a VU, utilizando
gerações de chaves diferentes
12.3. Emparelhamento e comunicações do sensor de movimentos com a
VU utilizando AES
12.4. Emparelhamento do sensor de movimentos com a VU, para dife­
rentes gerações de aparelhos
13. SEGURANÇA PARA COMUNICAÇÕES À DISTÂNCIA POR
DSRC
13.1. Generalidades
13.2. Encriptação da carga útil do tacógrafo e criação de MAC
13.3. Verificação e decifragem da carga útil do tacógrafo
14. DESCARREGAMENTOS DE DADOS DE ASSINATURA E VE­
RIFICAÇÃO DE ASSINATURAS
14.1. Generalidades
14.2. Criação da assinatura
14.3. Verificação da assinatura
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 427
PREÂMBULO
O presente apêndice especifica os mecanismos de segurança que garantem:
— autenticação mútua entre os diversos componentes do sistema tacográfico
— confidencialidade, integridade, autenticidade e/ou não-repúdio de dados trans­
feridos entre os diversos componentes do sistema tacográfico ou descarrega­
dos para meios externos de memorização.
O presente apêndice é constituído por duas partes: a parte A define os mecanis­
mos de segurança para o sistema tacográfico da primeira geração (tacógrafo
digital); a parte B define os mecanismos de segurança para o sistema tacográfico
da segunda geração (tacógrafo inteligente).
Aplicam-se os mecanismos previstos na parte A do presente apêndice se, pelo
menos, um dos componentes do sistema tacográfico envolvido numa autenticação
mútua e/ou num processo de transferência de dados for da primeira geração.
Aplicam-se os mecanismos previstos na parte B se, pelo menos, um dos com­
ponentes do sistema tacográfico envolvido na autenticação mútua e/ou no pro­
cesso de transferência de dados for da segunda geração.
O apêndice 15 fornece mais informações sobre a utilização de componentes da
primeira geração em combinação com componentes da segunda geração.
PARTE A
SISTEMA TACOGRÁFICO DA PRIMEIRA GERAÇÃO
1. INTRODUÇÃO
1.1. Referências
No presente apêndice, utilizam-se as seguintes referências:
SHA-1 National Institute of Standards and Technology (Ins­
tituto Nacional de Normas e Tecnologia, NIST). FIPS
Publication 180-1: Secure Hash Standard. Abril de
1995.
PKCS1 RSA Laboratories. PKCS # 1: RSA Encryption Stan­
dard. Versão 2.0. Outubro de 1998.
TDES National Institute of Standards and
Technology (NIST). FIPS Publication 46-3: Data En­
cryption Standard. Projeto 1999.
TDES-OP ANSI X9.52, Triple Data Encryption Algorithm Mo­
des of Operation (Modos de Funcionamento do Algo­
ritmo Triplo de Criptagem dos Dados). 1998.
ISO/IEC 7816-4 Information Technology — Identification cards — In­
tegrated circuit(s) cards with contacts — Part 4: Inte­
rindustry commands for interexchange. First edition:
1995 + Amendment 1: 1997.
ISO/IEC 7816-6 Information Technology — Identification cards — In­
tegrated circuit(s) cards with contacts — Part 6: Inte­
rindustry data elements. First edition: 1996 + Cor 1:
1998.
ISO/IEC 7816-8 Information Technology — Identification cards — In­
tegrated circuit(s) cards with contacts — Part 8: Secu­
rity related interindustry commands. First edition
1999.
ISO/IEC 9796-2 Information Technology — Security techniques —
Digital signature schemes giving message recovery
— Part 2: Mechanisms using a hash function. First
edition: 1997.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 428
ISO/IEC 9798-3 Information Technology — Security techniques —
Entity authentication mechanisms — Part 3: Entity
authentication using a public key algorithm. Second
edition 1998.
ISO 16844-3 Road vehicles — Tachograph systems — Part 3: Mo­
tion sensor interface.
1.2. Notações e abreviaturas
No presente apêndice, utilizam-se as seguintes notações e abreviaturas:
(K a , K b , K c ) feixe de chaves utilizado pelo algoritmo triplo de crip­
tagem dos dados
CA autoridade de certificação
CAR referência da autoridade de certificação
CC soma criptográfica de teste
CG criptograma
CH cabeçalho de comando
CHA autorização do titular do certificado
CHR referência do titular do certificado
D() decifragem com DES (Data Encryption Standard)
DE elemento de dados
DO objeto de dados
d chave privada/expoente privado RSA
e chave pública/expoente público RSA
E() criptagem com DES
EQT equipamento
Hash() valor Hash, saído de Hash
Hash função hash
KID identificador de chave
Km chave TDES (chave de segurança definida na norma
ISO 16844-3)
Km VU chave TDES inserida em unidades-veículo
Km WC chave TDES inserida em cartões de oficina
m representante de mensagem (número inteiro entre 0 e
n-1)
n chaves RSA, módulo
PB bytes de preenchimento
PI byte indicador de preenchimento (utilizado em cripto­
grama para DO de confidencialidade)
PV valor simples (direto)
s representante de assinatura (número inteiro entre 0 e
n-1)
SSC contador de sequências de envio
SM segurança do envio de mensagens (envio seguro de
mensagens)
TCBC modo de funcionamento do TDEA (ver TDEA) por
cifragem progressiva
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 429
TDEA algoritmo triplo de criptagem dos dados
TLV valor do comprimento de um marcador
VU unidade-veículo
X.C certificado do utilizador X, emitido por uma autori­
dade de certificação
X.CA autoridade de certificação do utilizador X
X.CA.PK o X.C operação de revelação de um certificado para extrair
uma chave pública; trata-se de um operador infixo,
cujo operando esquerdo é a chave pública de uma
autoridade de certificação e cujo operando direito é
o certificado emitido por essa autoridade de certifica­
ção; como resultado, obtém-se a chave pública do
utilizador X, cujo certificado é o operando direito
X.PK chave pública RSA de um utilizador X
X.PK[I] cifragem RSA de informações I, utilizando a chave
pública do utilizador X
X.SK chave privada RSA de um utilizador X
X.SK[I] cifragem RSA de informações I, utilizando a chave
privada do utilizador X
«xx» valor hexadecimal
|| operador de concatenação.
2. SISTEMAS E ALGORITMOS CRIPTOGRÁFICOS
2.1. Sistemas criptográficos
CSM_001 As unidades-veículo (VU) e os cartões tacográficos utilizam
um sistema criptográfico clássico de chave pública RSA para
obtenção dos seguintes mecanismos de segurança:
— autenticação mútua entre VU e cartões
— encaminhamento de chaves triplas de sessão DES entre
VU e cartões tacográficos
— assinatura digital de dados descarregados das VU ou dos
cartões tacográficos para meios de memorização externos.
CSM_002 As unidades-veículo e os cartões tacográficos utilizam um
sistema criptográfico simétrico DES triplo para obtenção de
um mecanismo de integridade dos dados durante o intercâm­
bio deles entre VU e cartões tacográficos e, se necessário,
para obtenção de confidencialidade nesse intercâmbio.
2.2. Algoritmos criptográficos
2.2.1 Algoritmo RSA
CSM_003 O algoritmo RSA é plenamente definido pelas seguintes re­
lações:
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 430
X.SK[m] = s = m d mod n
X.PK[s] = m = s e mod n
A referência PKCS1 contém uma descrição mais completa da
função RSA. No cálculo desta função, o expoente público «e»
é um inteiro entre 3 e n-1 que satisfaz a condição gcd(e,
lcm(p-1, q-1))=1.
2.2.2 Algoritmo hash
CSM_004 Os mecanismos de assinatura digital utilizam o algoritmo
Hash SHA-1 definido na referência [SHA-1].
2.2.3 Algoritmo de criptagem dos dados
CSM_005 No modo de funcionamento por cifragem progressiva
utilizam-se os algoritmos de base DES.
3. CHAVES E CERTIFICADOS
3.1. Criação e distribuição de chaves
3.1.1 Criação e distribuição de chaves RSA
CSM_006 As chaves RSA são criadas segundo três níveis hierárquicos
de funcionamento:
— nível europeu
— nível nacional (nível do Estado-Membro)
— nível do equipamento ou aparelho.
CSM_007 A nível europeu, é criado um único par de chaves
(EUR.SK e EUR.PK). Utiliza-se a chave privada europeia
para certificar as chaves públicas dos Estados-Membros. De­
vem ser mantidos registos de todas as chaves certificadas.
Estas funções são asseguradas por uma autoridade europeia
de certificação, sob a autoridade e responsabilidade da Co­
missão Europeia.
CSM_008 A nível nacional, é criado um par de chaves (MS.SK e
MS.PK) para cada Estado-Membro. A autoridade europeia
de certificação certifica as chaves públicas dos
Estados-Membros. Utiliza-se a chave privada de um
Estado-Membro para certificar as chaves públicas introduzi­
das no equipamento (VU ou cartão tacográfico). Devem ser
mantidos, juntamente com a identificação do equipamento,
registos de todas as chaves públicas certificadas que a ele
se destinem. Estas funções são asseguradas por uma autori­
dade nacional de certificação. Os Estados-Membros podem
modificar regularmente os seus pares de chaves.
CSM_009 A nível do equipamento, é criado um único par de chaves
(EQT.SK e EQT.PK), que se introduz em cada aparelho. A
autoridade nacional de certificação certifica as chaves públi­
cas do equipamento. Estas funções podem ser asseguradas por
fabricantes ou personalizadores do equipamento ou por auto­
ridades do Estado-Membro. Este par de chaves é utilizado
para autenticação, assinatura digital e serviços de cifragem.
CSM_010 Durante a criação, o eventual encaminhamento e a memori­
zação, deve manter-se a confidencialidade das chaves
privadas.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 431
O quadro seguinte sintetiza o fluxo dos dados neste processo:
3.1.2 Chaves de ensaio RSA
CSM_011 Para efeitos de ensaio do equipamento (ensaios de interope­
rabilidade incluídos), a autoridade europeia de certificação
cria um outro par único de chaves europeias de ensaio e
pelo menos dois pares de chaves nacionais de ensaio, cujas
chaves públicas são certificadas com a chave privada europeia
de ensaio. Os fabricantes devem introduzir, no equipamento
que é objeto dos ensaios de homologação de tipo, as chaves
de ensaio certificadas por uma destas chaves nacionais de
ensaio.
3.1.3 Chaves de sensor de movimentos
A confidencialidade das três chaves TDES a seguir descritas deve ser
adequadamente mantida durante a criação, o eventual encaminhamento e
a memorização.
Para que os componentes tacográficos cumpram a norma ISO 16844, as
autoridades competentes para a certificação a nível europeu e a nível de
cada Estado-Membro devem, complementarmente, assegurar o seguinte:
CSM_036 A autoridade europeia de certificação cria KmVU e KmWC,
duas chaves DES triplas independentes e únicas, e cria Km
como: Km = Km VU XOR Km WC . Mediante um procedimento
adequadamente securizado, envia seguidamente estas chaves
às autoridades de certificação de cada Estado-Membro, a seu
pedido.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 432
CSM_037 A autoridade de certificação de cada Estado-Membro:
— utiliza Km para encriptar dados dos sensores de movimen­
tos pedidos pelos seus fabricantes (esses dados são defi­
nidos na norma ISO 16844-3)
— mediante um procedimento adequadamente securizado,
envia Km VU aos fabricantes de unidades-veículo, para
inserção nestas últimas
— assegura a inserção de Km WC em todos os cartões de oficina
( no ficheiro elemen­
tar ), durante a perso­
nalização do cartão.
3.1.4 Criação e distribuição de chaves de sessão T-DES
CSM_012 No âmbito do processo de autenticação mútua, as VU e os
cartões tacográficos criam e intercambiam os dados necessá­
rios para elaborar uma chave de sessão DES tripla comum. A
confidencialidade deste intercâmbio de dados é protegida por
meio de um mecanismo de criptagem RSA.
CSM_013 Utiliza-se esta chave em todas as operações criptográficas
subsequentes, por meio do envio seguro de mensagens. A
sua validade termina no final da sessão (retirada ou reinicia­
lização do cartão) e/ou após 240 utilizações (uma utilização
da chave = um comando que utiliza o envio seguro de men­
sagens, transmitido ao cartão e seguido da correspondente
resposta).
3.2. Chaves
CSM_014 As chaves RSA (independentemente do nível) têm os seguin­
tes comprimentos: módulo n 1 024 bits, expoente público e
64 bits no máximo, expoente privado d 1 024 bits.
CSM_015 As chaves DES triplas têm a forma (K a , K b , K a ), onde K a e
K b são chaves independentes com o comprimento de 64 bits.
Não se repõem bits de deteção de erros de paridade.
3.3. Certificados
CSM_016 Os certificados de chaves públicas RSA são «non
self-descriptive» («não autodescritivos») e «card verifiable»
(«verificáveis por cartão») (Ref.: ISO/IEC 7816-8)
3.3.1 Conteúdo dos certificados
CSM_017 Os certificados de chaves públicas RSA contêm os seguintes
dados, pela ordem indicada:
Dados Formato Bytes Observações
CPI INTEIRO 1 Identificador de perfil do
certificado («01» para esta
versão)
CAR CADEIA DE
OCTETOS
8 Referência da autoridade
de certificação
CHA CADEIA DE
OCTETOS
7 Autorização do titular do
certificado
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 433
Dados Formato Bytes Observações
EOV TimeReal 4 Prazo de validade do certi­
ficado. Opcional. Preen­
chido com «FF» se não
for utilizado
CHR CADEIA DE
OCTETOS
8 Referência do titular do
certificado
n CADEIA DE
OCTETOS
128 Chave pública (módulo)
e CADEIA DE
OCTETOS
8 Chave pública (expoente
público)
164
Notas:
1. O «identificador de perfil do certificado» (CPI) indica a estrutura
exata de um certificado de autenticação. Pode ser utilizado como
identificador interno de equipamento da lista de cabeçalho que des­
creve a concatenação dos elementos informativos contidos no
certificado.
É a seguinte a lista de cabeçalho associada ao conteúdo deste
certificado:
«4D» «16» «5F
29»
«01» «42» «08» «5F
4B»
«07» «5F
24»
«04» «5F
20»
«08» «7F
49»
«05» «81» «81
80»
«82» «08»
M
ar
ca
do
r
al
ar
ga
do
d
a
li
st
a
de
c
ab
eç
al
ho

C
om
pr
im
en
to
d
a
li
st
a
de
c
ab
eç
al
ho

M
ar
ca
do
r
C
P
I
C
om
pr
im
en
to
C
P
I
M
ar
ca
do
r
C
A
R

C
om
pr
im
en
to
C
A
R

M
ar
ca
do
r
C
H
A

C
om
pr
im
en
to
C
H
A

M
ar
ca
do
r
E
O
V

C
om
pr
im
en
to
E
O
V

M
ar
ca
do
r
C
H
R

C
om
pr
im
en
to
C
H
R

M
ar
ca
do
r
de
c
ha
ve
p
úb
li
ca
(
C
on
st
ru
íd
o)

C
om
pr
im
en
to
d
e
D
O
s
ub
se
qu
en
te
s
M
ar
ca
do
r
do
m
ód
ul
o
C
om
pr
im
en
to
d
o
m
ód
ul
o
M
ar
ca
do
r
do
e
xp
oe
nt
e
pú
bl
ic
o
C
om
pr
im
en
to
d
o
ex
po
en
te
p
úb
li
co

2. A «referência da autoridade de certificação» (CAR) destina-se a iden­
tificar a autoridade de certificação (CA) emissora do certificado, de
modo que o elemento de dados possa ser utilizado ao mesmo tempo
como identificador de chave de autoridade para referenciar a chave
pública da autoridade de certificação (relativamente à codificação, ver
adiante «identificador de chave»).
3. A «autorização do titular do certificado» (CHA) destina-se a identifi­
car os direitos do titular do certificado. Consiste no ID de aplicação
do tacógrafo e no tipo de equipamento a que se refere o certificado
(consoante o elemento de dados , «00» para um
Estado-Membro).
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 434
4. A «referência do titular do certificado» (CHR) destina-se a identificar
como único o titular do certificado, de modo que o elemento de dados
possa ser utilizado ao mesmo tempo como identificador de chave de
objeto para referenciar a chave pública do titular do certificado.
5. Os identificadores de chave identificam como únicos os titulares de
certificados e as autoridades de certificação. É a seguinte a sua codi­
ficação:
5.1. Equipamento (VU ou cartão):
Dados Número
de série
do equi­
pamento
Data Tipo Fabricante
Compri­
mento
4 bytes 2 bytes 1 byte 1 byte
Valor Número
inteiro
Codificação BCD
mm aa
Específico do
fabricante
Código do fa­
bricante
Tratando-se de uma VU, o fabricante, ao requerer um certificado,
pode conhecer ou não a identificação do aparelho no qual as
chaves serão inseridas.
Se a conhecer, o fabricante transmite a identificação do aparelho,
juntamente com a chave pública, à autoridade de certificação
competente do Estado-Membro. Deste modo, o certificado con­
terá a identificação do aparelho, e o fabricante deve garantir que
as chaves e o certificado são inseridos no aparelho a que se
destinam. O identificador de chave tem a forma atrás indicada.
Se não conhecer a identificação do aparelho, o fabricante deve
identificar como único cada pedido de certificado, enviando essa
identificação, juntamente com a chave pública, à autoridade de
certificação competente do Estado-Membro. Deste modo, o cer­
tificado conterá a identificação do pedido. Após a instalação da
chave no equipamento, o fabricante deve informar o
Estado-Membro competente sobre os elementos de atribuição
de chave ao equipamento (ou seja, identificação do pedido de
certificado e identificação do aparelho). O identificador de chave
tem a seguinte forma:
Dados Número
de série
do pedido
de certifi­
cado
Data Tipo Fabricante
Compri­
mento
4 bytes 2 bytes 1 byte 1 byte
Valor Número
inteiro
Codificação BCD
mm aa
«FF» Código do fa­
bricante
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 435
5.2 Autoridade de certificação:
Dados Identificação da
autoridade
Número de
série da chave
Informações
adicionais
Identificador
Compri­
mento
4 bytes 1 byte 2 bytes 1 byte
Valor Código numérico
nacional, 1 byte
Código alfanumé­
rico nacional, 3
bytes
Número in­
teiro
Codificação
adicional
(específico da
CA)
«FF FF» se
não houver
utilização
«01»
O número de série serve para distinguir as diversas chaves de um
Estado-Membro, na eventualidade de mudança de chave.
6. Os verificadores de certificados sabem, implicitamente, que a chave
pública certificada é uma chave RSA destinada à autenticação e à
verificação e cifragem da assinatura digital, para efeitos de confiden­
cialidade (o certificado não contém qualquer identificador de objeto
que o especifique).
3.3.2 Certificados emitidos
CSM_018 O certificado emitido é uma assinatura digital com recupera­
ção parcial do conteúdo do certificado, nos termos da norma
ISO/IEC 9796-2 (com exceção do seu anexo A4), tendo
apensa a «referência da autoridade de certificação».
X.C = X.CA.SK[«6A» || C r || Hash (Cc) || «BC»] || C n || X.CAR
Com conteúdo de certificado = Cc = C r || C n
106 bytes 58 bytes
Notas:
1. Este certificado tem 194 bytes de comprimento.
2. A CAR oculta pela assinatura é também apensa a esta, de modo a que
a chave pública da autoridade de certificação possa ser selecionada
para a verificação do certificado.
3. O verificador conhece, implicitamente, o algoritmo utilizado pela au­
toridade de certificação para assinar o certificado.
4. É a seguinte a lista de cabeçalho associada a este certificado emitido:
«7F 21» «09» «5F 37» «81 80» «5F 38» «3A» «42» «08»
M
ar
ca
do
r
do
c
er
ti
fi
ca
do

C
V
(
co
ns
tr
uí
do
)
C
om
pr
im
en
to
d
e
D
O
s
ub
se
qu
en
te
s
M
ar
ca
do
r
da
a
ss
in
at
ur
a
C
om
pr
im
en
to
d
a
as
si
na
tu
ra

M
ar
ca
do
r
do
r
em
an
es
ce
nt
e
C
om
pr
im
en
to
d
o
re
m
an
es
ce
nt
e
M
ar
ca
do
r
da
C
A
R

C
om
pr
im
en
to
d
a
C
A
R

▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 436
3.3.3 Verificação e revelação de certificados
A verificação e a revelação de um certificado consistem em verificar se a
assinatura obedece à norma ISO/IEC 9796-2, extraindo o conteúdo do
certificado e a chave pública contida: X.PK = X.CA.PK o X.C, e veri­
ficando a validade do certificado.
CSM_019 Esta operação inclui os seguintes passos:
Verificação da assinatura e extração do conteúdo:
— de X.C, extrair Sign, C n «e CAR»: X.C = Sign || C n ' || CAR'
128 bytes 58 bytes 8 bytes
— a partir de CAR', selecionar a pertinente chave pública da
autoridade de certificação (se tal não tiver sido feito antes
por outros meios)
— abrir Sign com a chave pública do CA: Sr'= X.CA.PK
[Sign],
— verificar se Sr' começa por «6A» e termina por «BC»
— calcular C r ' e H' a partir de: Sr' = «6A» || C r ' || H' || «BC»
106 bytes 20 bytes
— recuperar o conteúdo do certificado C' = C r ' C n ',
— verificar Hash (C') = H'
Se todas as verificações conferirem, o certificado é genuíno e
o seu conteúdo é C'.
Verificar validade. A partir de C':
— se for o caso, verificar a data de expiração da validade.
De C', extrair e memorizar a chave pública, o identificador da
chave, a autorização do titular do certificado e a data de
expiração da validade do certificado:
— X.PK = n || e
— X.KID = CHR
— X.CHA = CHA
— X.EOV = EOV
4. MECANISMO DE AUTENTICAÇÃO MÚTUA
A autenticação mútua entre cartões e unidades-veículo baseia-se no se­
guinte princípio:
Cada parte demonstra à outra parte que possui um par válido de chaves,
no qual a chave pública foi certificada pela autoridade de certificação
competente do Estado-Membro, por sua vez certificado pela autoridade
de certificação europeia.
A demonstração é feita assinando com a chave privada um número
aleatório enviado pela outra parte, a qual recupera esse número quando
verifica esta assinatura.
O mecanismo é desencadeado pela VU logo que haja inserção de um
cartão. Inicia-se com o intercâmbio de certificados e a revelação das
chaves públicas e termina com o estabelecimento de uma chave de
sessão.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 437
CSM_020 Utiliza-se o seguinte protocolo (as setas indicam comandos e
dados intercambiados — ver apêndice 2):
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 438
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 439
5. MECANISMOS DE CONFIDENCIALIDADE, INTEGRIDADE E AU­
TENTICAÇÃO NA TRANSFERÊNCIA DE DADOS ENTRE VU E
CARTÕES
5.1. Envio seguro de mensagens
CSM_021 A integridade das transferências de dados entre as VU e os
cartões é protegida mediante o mecanismo de segurança do
envio de mensagens, em conformidade com as normas ISO/
/IEC 7816-4 e ISO/IEC 7816-8.
CSM_022 Se for necessário proteger os dados durante a transferência,
apensa-se um objeto de dados «soma criptográfica de con­
trolo», incorporado no comando ou na resposta, aos objetos
de dados enviados. A soma criptográfica de controlo é veri­
ficada pelo recetor.
CSM_023 A soma criptográfica de controlo dos dados enviados integra
o cabeçalho do comando no qual é incorporada e todos os
objetos de dados enviados (=>CLA = «0C» e todos os obje­
tos de dados devem ser encapsulados com marcadores nos
quais b1 = 1).
CSM_024 Os bytes de informação sobre a situação da resposta são
protegidos por uma soma criptográfica de controlo se a res­
posta não contiver campo de dados.
CSM_025 As somas criptográficas de controlo têm 4 bytes de
comprimento.
Se se recorrer ao envio seguro de mensagens, a estrutura dos
comandos e das respostas 'r, portanto, a seguinte:
Os DO (objetos de dados) utilizados são um subconjunto dos
DO de envio seguro de mensagens referidos na norma ISO/
/IEC 7816-4:
Marcador Mnemónica Significado
«81» T PV Valor simples não codificado em BER-TLV (a pro­
teger por CC)
«97» T LE Valor de Le no comando não seguro (a proteger por
CC)
«99» T SW Informação sobre situação (a proteger por CC)
«8E» T CC Soma criptográfica de teste
«87» T PI CG Criptograma do byte indicador de preenchimento ||
(valor simples não codificado em BER-TLV)
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 440
Dado um par de resposta a um comando não seguro:
Cabeçalho do comando Corpo do comando
CLA INS P1 P2 [Campo L c ] [Campo de dados] [Campo L e ]
quatro bytes bytes L, indicados de B 1 a B L
Corpo da resposta Indicador de fim da resposta
[Campo de dados] SW1 SW2
bytes dos dados L r dois bytes
É o seguinte o correspondente par de resposta de comando
seguro:
Comando seguro:
Cabeçalho do
comando (CH)
Corpo do comando
CLA INS P1 P2 [Novo campo L c ] [Novo campo de dados] [Novo
campo
L e ]
«OC» Comprimento do
novo campo de
dados
T PV L PV PV T LE L LE L e T CC L CC CC «00»
«81» L c Campo de
dados
«97» «01» L e «8E» «04» CC
Dados a integrar na soma de teste = CH || PB || T PV || L PV ||
PV || T LE || L LE || L e || PB
PB = Bytes de preenchimento (80 .. 00), segundo as normas
ISO/IEC 7816-4 e ISO 9797 e método 2.
Os objetos de dados PV e LE estão presentes somente se
houver dados correspondentes no comando não seguro.
Resposta segura:
1. Caso em que o campo de dados da resposta não está vazio
e não precisa de ser protegido para efeitos de
confidencialidade:
Corpo da resposta
Indicador de fim da res­
posta
[Novo campo de dados] Novo SW1 SW2
T PV L PV PV T CC L CC CC
«81» L r Campo de dados «8E» «04» CC
Dados a integrar na soma de teste = T PV || L PV || PV || PB
2. Caso em que o campo de dados da resposta não está vazio
e precisa de ser protegido para efeitos de
confidencialidade:
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 441
Corpo da resposta
Indicador de fim da res­
posta
[Novo campo de dados] Novo SW1 SW2
T PI CG L PI
CG
PI CG T CC L CC CC
«87» PI || CG «8E» «04» CC
Dados a executar por CG: dados não codificados em
BER-TLV e bytes de preenchimento.
Dados a integrar na soma de teste = T PI CG || L PI CG || PI
CG || PB
3. Caso em que o campo de dados da resposta está vazio:
Corpo da resposta
Indicador de fim da res­
posta
[Novo campo de dados] Novo SW1 SW2
T SW L SW SW T CC L CC CC
«99» «02» Novo SW1 SW2 «8E» «04» CC
Dados a integrar na soma de teste = T SW || L SW || SW ||
PB
5.2. Tratamento de erros no envio seguro de mensagens
CSM_026 Quando, ao interpretar um comando, o cartão tacográfico
reconhece um erro de SM, os bytes de situação («status by­
tes») devem ser devolvidos sem SM. Nos termos da norma
ISO/IEC 7816-4, definem-se os seguintes bytes de situação
para indicar erros de SM:
«66 88»: Falha na verificação da soma criptográfica de teste
«69 87»: Ausência de objetos de dados SM esperados
«69 88»: Incorreção dos objetos de dados SM.
CSM_027 Se o cartão tacográfico devolver bytes de situação sem DO de
SM ou com um DO de SM errado, a sessão deve ser inter­
rompida pela VU.
5.3. Algoritmo para calcular somas criptográficas de teste
CSM_028 As somas criptográficas de teste são constituídas com recurso
a um controlo de acesso ao meio (MAC) pormenorizado, nos
termos da norma ANSI X9.19 com DES:
— fase de arranque: o bloco inicial de verificação y0 é E(Ka,
SSC)
— fase sequencial: os blocos de verificação y1, .., Yn são
calculados mediante a utilização de Ka
— fase final: a soma criptográfica de teste é calculada com
base no último bloco de verificação yn, do seguinte
modo: E(Ka, D(Kb, yn)),
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 442
onde E() representa a criptagem com DES, e D() a decifragem
com DES.
Os quatro bytes mais significativos da soma criptográfica de
teste são transferidos.
CSM_029 O contador de sequências de envio (SSC) é iniciado durante o
processo de concordância de chaves:
SSC inicial: Rnd3 (4 bytes menos significativos) || Rnd1 (4
bytes menos significativos).
CSM_030 O contador de sequências de envio é acrescido de uma uni­
dade antes de cada MAC ser calculado (ou seja, o SSC para o
primeiro comando é SSC inicial + 1, o SSC para a primeira
resposta é SSC inicial + 2).
O esquema seguinte representa o cálculo do MAC
pormenorizado:
5.4. Algoritmo para o cálculo de criptogramas para DO de confidencia­
lidade
CSM_031 Os criptogramas são calculados utilizando o TDEA no modo
de funcionamento TCBC, em conformidade com as referên­
cias TDES e TDES-OP e com o vetor nulo como bloco de
valor inicial.
O esquema seguinte representa a aplicação de chaves em
TDES:
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 443
6. MECANISMOS DE ASSINATURA DIGITAL DO DESCARREGA­
MENTO DE DADOS
CSM_032 O equipamento dedicado inteligente (IDE) memoriza num
ficheiro físico os dados recebidos de um aparelho (VU ou
cartão) durante uma sessão de descarregamento. Este ficheiro
deve conter os certificados MS i .C e EQT.C. Contém as assi­
naturas digitais de blocos de dados, em conformidade com o
apêndice 7 (protocolos aplicáveis ao descarregamento de da­
dos).
CSM_033 As assinaturas digitais dos dados descarregados utilizam um
esquema de assinatura digital com apêndice, de modo a que
os dados descarregados possam, se necessário, ser lidos sem
decifragem.
6.1. Criação da assinatura
CSM_034 A criação da assinatura dos dados pelo equipamento obedece
ao esquema de assinatura digital com apêndice, definido na
referência PKCS1, com a função hash SHA-1:
Assinatura = EQT.SK[«00» || «01» || PS || «00» || DER(SHA-1(da­
dos))]
PS = Cadeia de octetos de preenchimento com valor «FF» tal
que o comprimento é 128.
DER(SHA-1(M)) é a codificação do algoritmo ID para a
função hash e o valor hash num valor ASN.1 do tipo Diges­
tInfo (regras distintas de codificação):
«30»||«21»||«30»||«09»||«06»||«05»||«2B»||«0E»|| «03»||«02»||
«1A»||«05»||«00»||«04»||«14»||valor Hash.
6.2. Verificação da assinatura
CSM_035 A verificação da assinatura relativa a dados descarregados
obedece ao esquema de assinatura com apêndice definido
na referência PKCS1, com a função hash SHA-1.
A chave pública europeia EUR.PK tem de ser conhecida (e
aprovada) independentemente pelo verificador.
O diagrama seguinte ilustra o protocolo que um IDE com
cartão de controlo pode seguir para verificar a integridade
dos dados descarregados e memorizados nos ESM (meios
externos de memorização). O cartão de controlo é utilizado
para a decifragem das assinaturas digitais. Em tal caso, esta
função pode não ser executada no IDE.
O equipamento que descarregou e assinou os dados a analisar
é designado EQT.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 444
PARTE B
SISTEMA TACOGRÁFICO DA SEGUNDA GERAÇÃO
7. INTRODUÇÃO
7.1. Referências
Nesta parte do presente apêndice, utilizam-se as seguintes referências:
AES National Institute of Standards and Technology (NIST),
FIPS PUB 197: Advanced Encryption Standard (AES),
November 26, 2001
DSS National Institute of Standards and Technology (NIST),
FIPS PUB 186-4: Digital Signature Standard (DSS), July
2013
ISO 7816-4 ISO/IEC 7816-4, Identification cards — Integrated circuit
cards — Part 4: Organization, security and commands for
interchange. Third edition 2013-04-15
ISO 7816-8 ISO/IEC 7816-8, Identification cards — Integrated circuit
cards — Part 8: Commands for security operations. Se­
cond edition 2004-06-01
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 445
ISO 8825-1 ISO/IEC 8825-1, Information technology — ASN.1 en­
coding rules: Specification of Basic Encoding
Rules (BER), Canonical Encoding Rules (CER) and Dis­
tinguished Encoding Rules (DER). Fourth edition, 2008-
-12-15
ISO 9797-1 ISO/IEC 9797-1, Information technology — Security
techniques — Message Authentication Codes (MACs)
— Part 1: Mechanisms using a block cipher. Second
edition, 2011-03-01
ISO 10116 ISO/IEC 10116, Information technology — Security tech­
niques — Modes of operation of an n-bit block cipher.
Third edition, 2006-02-01
ISO 16844-3 ISO/IEC 16844-3, Road vehicles — Tachograph systems
— Part 3: Motion sensor interface. First edition 2004,
including Technical Corrigendum 1 2006
RFC 5480 Elliptic Curve Cryptography Subject Public Key Informa­
tion, March 2009
RFC 5639 Elliptic Curve Cryptography (ECC) — Brainpool Stan­
dard Curves and Curve Generation, 2010
RFC 5869 HMAC-based Extract-and-Expand Key Derivation
Function (HKDF), May 2010
SHS National Institute of Standards and Technology (NIST),
FIPS PUB 180-4: Secure Hash Standard, March 2012
SP 800-38B National Institute of Standards and Technology (NIST),
Special Publication 800-38B: Recommendation for Block
Cipher Modes of Operation: The CMAC Mode for Aut­
hentication, 2005
TR-03111 BSI Technical Guideline TR-03111, Elliptic Curve Cryp­
tography, version 2.00, 2012-06-28
7.2. Notações e abreviaturas
No presente apêndice, utilizam-se as seguintes notações e abreviaturas:
AES norma avançada de cifragem
CA autoridade de certificação
CAR referência da autoridade de certificação
CBC modo de funcionamento por cifragem progressiva
CH cabeçalho de comando
CHA autorização do titular de um certificado
CHR referência do titular de um certificado
CV vetor constante
DER regras distintas de codificação
DO objeto de dados
DSRC comunicações dedicadas de curto alcance
ECC criptografia de curva elíptica
ECDSA algoritmo de assinatura digital de curva elíptica
ECDH curva elíptica Diffie-Hellman (algoritmo de concordância
de chaves)
EGF módulo GNSS externo
EQT equipamento
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 446
IDE equipamento dedicado inteligente
K M chave de segurança do sensor de movimentos, que permite
o emparelhamento de uma unidade-veículo com um sensor
de movimentos
K M-VU chave inserida em unidades-veículo, que permite à VU
derivar a chave de segurança do sensor de movimentos
caso esteja inserido na VU um cartão de oficina
K M-WC chave inserida em cartões de oficina, que permite à VU
derivar a chave de segurança do sensor de movimentos
caso esteja inserido na VU um cartão de oficina
MAC código de autenticação de mensagem
MoS sensor de movimentos
MSB bit mais significativo
PKI infraestrutura de chave pública
RCF sistema de comunicação à distância
SSC contador de sequências de envio
SM segurança do envio de mensagens (envio seguro de men­
sagens)
TDES norma tripla de criptagem dos dados
TLV valor do comprimento de um marcador
VU unidade-veículo
X.C certificado da chave pública do utilizador X
X.CA autoridade de certificação que emitiu o certificado do uti­
lizador X
X.CAR referência da autoridade de certificação mencionada no
certificado do utilizador X
X.CHR referência do titular do certificado mencionada no certifi­
cado do utilizador X
X.PK chave pública do utilizador X
X.SK chave privada do utilizador X
X.PK eph chave pública efémera do utilizador X
X.SK eph chave privada efémera do utilizador X
«xx» valor hexadecimal
|| operador de concatenação
7.3. Definições
As definições dos termos utilizados no presente apêndice figuram no
anexo 1C, secção I.
8. SISTEMAS E ALGORITMOS CRIPTOGRÁFICOS
8.1. Sistemas criptográficos
CSM_38 As unidades-veículo (VU) e os cartões tacográficos utili­
zam um sistema criptográfico de chave pública com re­
curso à curva elíptica para obtenção dos seguintes serviços
de segurança:
— autenticação mútua entre uma unidade-veículo e um
cartão
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 447
— concordância de chaves de sessão AES entre uma
unidade-veículo e um cartão
— garantir a autenticidade, a integridade e o não-repúdio
de dados descarregados de unidades-veículo ou cartões
tacográficos para meios externos.
CSM_39 As unidades-veículo e os módulos GNSS externos utilizam
um sistema criptográfico de chave pública com recurso à
curva elíptica para obtenção dos seguintes serviços de se­
gurança:
— acoplamento de uma unidade-veículo e de um módulo
GNSS externo
— autenticação mútua entre uma unidade-veículo e um
módulo GNSS externo
— concordância de uma chave de sessão AES entre uma
unidade-veículo e um módulo GNSS externo.
CSM_40 As unidades-veículo e os cartões tacográficos utilizam um
sistema criptográfico simétrico com recurso a AES para
obtenção dos seguintes serviços de segurança:
— garantir a autenticidade e a integridade dos dados in­
tercambiados entre uma unidade-veículo e um cartão
tacográfico
— se for caso disso, garantir a confidencialidade dos da­
dos intercambiados entre uma unidade-veículo e um
cartão tacográfico.
CSM_41 As unidades-veículo e os módulos GNSS externos utilizam
um sistema criptográfico simétrico com recurso a AES
para obtenção dos seguintes serviços de segurança:
— garantir a autenticidade e a integridade dos dados in­
tercambiados entre uma unidade-veículo e um módulo
GNSS externo.
CSM_42 As unidades-veículo e os sensores de movimento utilizam
um sistema criptográfico simétrico com recurso a AES
para obtenção dos seguintes serviços de segurança:
— emparelhamento de uma unidade-veículo com um sen­
sor de movimentos
— autenticação mútua entre uma unidade-veículo e um
sensor de movimentos
— garantir a confidencialidade dos dados intercambiados
entre uma unidade-veículo e um sensor de
movimentos.
CSM_43 As unidades-veículo e os cartões de controlo utilizam um
sistema criptográfico simétrico com recurso a AES para
obtenção dos seguintes serviços de segurança na interface
de comunicação à distância:
— garantir a confidencialidade, a autenticidade e a inte­
gridade dos dados transmitidos de uma unidade-veículo
para um cartão de controlo.
Notas:
— Em bom rigor, os dados são transmitidos a partir de uma
unidade-veículo para um interrogador à distância, sob a su­
pervisão de um agente de controlo, utilizando um sistema de
comunicação à distância que pode ser interno ou externo à
VU (ver apêndice 14). No entanto, o interrogador à distância
envia os dados recebidos para um cartão de controlo, para
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 448
decifragem e validação da autenticidade. Do ponto de vista
da segurança, o sistema de comunicação à distância e o
interrogador à distância são completamente transparentes.
— Relativamente à interface DSRC, um cartão de oficina
oferece os mesmos serviços de segurança que um car­
tão de controlo, o que permite a uma oficina validar o
funcionamento adequado da interface de comunicação
à distância da VU, incluindo a segurança. Consultar a
secção 9.2.2 para mais informações.
8.2. Algoritmos criptográficos
8.2.1 Algoritmos simétricos
CSM_44 Unidades-veículo, cartões tacográficos, sensores de movi­
mentos e módulos GNSS externos aceitam o algoritmo
AES definido em [AES], com comprimentos de chave de
128, 192 e 256 bits.
8.2.2 Parâmetros de domínio normalizados e de algoritmos assimétricos
CSM_45 Unidades-veículo, cartões tacográficos e módulos GNSS
externos aceitam criptografia de curva elíptica com um
tamanho de chave de 256, 384 e 512/521 bits.
CSM_46 Unidades-veículo, cartões tacográficos e módulos GNSS
externos aceitam o algoritmo de assinatura ECDSA, em
conformidade com DSS.
CSM_47 Unidades-veículo, cartões tacográficos e módulos GNSS
externos aceitam o algoritmo de concordância de chave
ECKA-EG, em conformidade com TR 03111.
CSM_48 Unidades-veículo, cartões tacográficos e módulos GNSS
externos aceitam todos os parâmetros de domínio norma­
lizados especificados no quadro 1, de criptografia de curva
elíptica.
Quadro 1
Parâmetros de domínio normalizados
Nome Tamanho (bits) Referência Identificador de objeto
NIST P-256 256 [DSS], [RFC 5480]
BrainpoolP256r1 256 [RFC 5639]
NIST P-384 384 [DSS], [RFC 5480]
BrainpoolP384r1 384 [RFC 5639]
BrainpoolP512r1 512 [RFC 5639]
NIST P-521 521 [DSS], [RFC 5480]
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 449
Nota: os identificadores de objeto mencionados na última
coluna do quadro 1 são especificados em RFC 5639 para
as curvas Brainpool e em RFC 5480 para as curvas NIST.
8.2.3 Algoritmos de hash
▼M1
CSM_49 Unidades-veículo, cartões tacográficos e módulos GNSS
externos aceitam os algoritmos SHA-256, SHA-384 e
SHA-512 especificados em [SHS].
▼B
8.2.4 Sequências de cifras
CSM_50 No caso de se utilizarem conjuntamente algoritmos simé­
tricos, algoritmos assimétricos e/ou algoritmos hash para
formar um protocolo de segurança, os respetivos compri­
mentos de chave e tamanhos de hash serão, aproximada­
mente, da mesma resistência. O quadro 2 apresenta as
sequências de cifras:
Quadro 2
Sequências de cifras permitidas
Id da sequência de
cifras
Tamanho da chave
ECC (bits)
Comprimento da chave
AES (bits)
Algoritmo de
hash
Comprimento do
MAC (bytes)
CS#1 256 128 SHA-256 8
CS#2 384 192 SHA-384 12
CS#3 512/521 256 SHA-512 16
Nota: Para todos os efeitos no âmbito do presente apên­
dice, os tamanhos das chaves ECC de 512 bits e de 521
bits são considerados iguais no que se refere à resistência.
9. CHAVES E CERTIFICADOS
9.1. Pares de chaves assimétricas e certificados de chave pública
9.1.1 Generalidades
Nota: utilizam-se as chaves descritas na presente secção para autentica­
ção mútua e envio seguro de mensagens entre unidades-veículo e cartões
tacográficos, bem como entre unidades-veículo e módulos GNSS exter­
nos. Estes processos estão pormenorizados nos capítulos 10 e 11 do
presente apêndice.
CSM_51 No sistema tacográfico inteligente europeu, os pares de
chaves ECC e os certificados correspondentes são criados
e geridos através de três níveis hierárquicos funcionais:
— nível europeu
— nível nacional (nível do Estado-Membro)
— nível do equipamento ou aparelho.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 450
CSM_52 Em todo o sistema tacográfico inteligente europeu, as cha­
ves públicas e privadas e os certificados são criados, geri­
dos e comunicados por métodos seguros e normalizados.
9.1.2 Nível europeu
CSM_53 A nível europeu, é criado um par de chaves ECC
original, designado EUR, que compreende uma chave pri­
vada (EUR.SK) e uma chave pública (EUR.PK). Este par
de chaves constituirá o par de chaves de raiz de toda a
infraestrutura de chave pública (PKI) tacográfica inteli­
gente europeia. Estas funções são asseguradas por uma
autoridade europeia de certificação de raiz (ERCA), sob
a autoridade e a responsabilidade da Comissão Europeia.
CSM_54 A ERCA utiliza a chave privada europeia para assinar um
certificado de raiz (autoassinado) da chave pública euro­
peia e comunica este certificado de raiz europeia a todos
os Estados-Membros.
CSM_55 Quando solicitado, a ERCA utiliza a chave privada euro­
peia para assinar os certificados das chaves públicas dos
Estados-Membros. A ERCA conserva registos de todos os
certificados assinados de chave pública dos
Estados-Membros.
CSM_56 Como mostra o esquema 1 na secção 9.1.7, a ERCA cria
um novo par de chaves de raiz europeia de 17 em 17 anos.
Nessa altura, cria um novo certificado de raiz autoassi­
nado, destinado à nova chave pública europeia. O período
de validade de um certificado de raiz europeia é de 34
anos e 3 meses.
Nota: A introdução de um novo par de chaves de raiz
significa também que a ERCA cria uma nova chave de
segurança para os sensores de movimentos e uma nova
chave de segurança DSRC (ver secções 9.2.1.2 e 9.2.2.2).
CSM_57 Antes de criar um novo par de chaves de raiz europeia, a
ERCA procede a uma análise da resistência criptográfica
necessária para o novo par de chaves, dado que deve
continuar seguro durante os próximos 34 anos. Se se re­
velar necessário, a ERCA muda para uma sequência de
cifras mais forte do que a atual, em conformidade com o
CSM_50.
▼M1
CSM_58 Sempre que cria um novo par de chaves de raiz europeia, a
ERCA cria um certificado de ligação para a nova chave
pública europeia e assina-o com a chave privada europeia
anterior. O período de validade do certificado de ligação é
de 17 anos e 3 meses. (esquema 1, na secção 9.1.7).
▼B
Nota: Dado que um certificado de ligação contém a chave
pública ERCA da geração X e é assinado com a chave
privada ERCA da geração X-1, esse certificado de ligação
disponibiliza equipamentos atribuídos ao abrigo da geração
X-1, um método de aprovação de equipamentos atribuídos
ao abrigo da geração X.
CSM_59 Assim que um novo certificado de chave de raiz se torna
válido, a ERCA não utiliza a chave privada de um par de
chaves de raiz, seja para que fins for.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 451
CSM_60 A ERCA dispõe, a qualquer momento, dos seguintes cer­
tificados e chaves criptográficas:
— o par de chaves EUR atual e o correspondente certifi­
cado
— todos os certificados EUR anteriores a utilizar na ve­
rificação dos certificados MSCA que ainda estão váli­
dos
— certificados de ligação para todas as gerações
de certificados EUR, com exceção do primeiro.
9.1.3 Nível do Estado-Membro
CSM_61 Ao nível dos Estados-Membros, todos os que são obriga­
dos a assinar certificados para cartões tacográficos criam
um ou mais pares únicos de chaves ECC, denominados
MSCA_Card. Todos os Estados-Membros obrigados a as­
sinar certificados para unidades-veículo ou módulos GNSS
externos criam um ou mais pares únicos de chaves ECC,
denominados MSCA_VU-EGF.
CSM_62 A função da criação de pares de chaves nacionais é asse­
gurada por uma autoridade de certificação do
Estado-Membro (MSCA). Sempre que uma MSCA cria
um par de chaves do Estado-Membro, envia a chave pú­
blica para a ERCA, a fim de obter um certificado corres­
pondente do Estado-Membro, assinado pela ERCA.
CSM_63 A MSCA deve escolher a resistência de um par de chaves
do Estado-Membro igual à do par de chaves de raiz euro­
peia utilizado para assinar o correspondente certificado do
Estado-Membro.
CSM_64 Se existir, o par de chaves MSCA_VU-EGF é composto
pela chave privada MSCA_VU-EGF.SK e pela chave pú­
blica MSCA_VU-EGF.PK. A MSCA utiliza a chave pri­
vada MSCA_VU-EGF.SK exclusivamente para assinar os
certificados de chave pública de unidades-veículo e módu­
los GNSS externos.
CSM_65 Um par de chaves MSCA_Card é constituído pela chave
privada MSCA_Card.SK e pela chave pública
MSCA_Card.PK. A MSCA utiliza a chave privada
MSCA_Card.SK exclusivamente para assinar os certifica­
dos de chave pública dos cartões tacográficos.
CSM_66 A MSCA conserva registos de todos os certificados assi­
nados das VU, dos módulos GNSS externos e dos cartões,
juntamente com a identificação do aparelho ao qual se
destina cada certificado.
CSM_67 O período de validade de um certificado MSCA_VU-EGF
é de 17 anos e 3 meses. O período de validade de um
certificado MSCA_Card é de 7 anos e 1 mês.
CSM_68 Como mostra o esquema 1 na secção 9.1.7, a chave pri­
vada de um par de chaves MSCA_VU-EGF e a chave
privada de um par de chaves MSCA_Card têm um período
de utilização de dois anos.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 452
CSM_69 Uma MSCA não volta a utilizar, seja para que fins for, a
chave privada do par de chaves MSCA_VU-EGF ou a
chave privada de um par de chaves MSCA_Card quando
terminam os respetivos períodos de utilização.
CSM_70 A MSCA dispõe, a qualquer momento, dos seguintes cer­
tificados e chaves criptográficas:
— o par de chaves MSCA_Card atual e o certificado
correspondente
— todos os certificados MSCA_Card anteriores a utilizar
na verificação dos certificados dos cartões tacográficos
que ainda estão válidos
— o certificado EUR atual necessário para a verificação
do certificado MSCA atual
— todos os certificados EUR anteriores a utilizar na ve­
rificação de todos os certificados MSCA que ainda
estão válidos.
CSM_71 Se uma MSCA for obrigada a assinar certificados para
unidades-veículo ou módulos GNSS externos, disporá
igualmente dos seguintes certificados e chaves:
— o par de chaves MSCA_VU-EGF atual e o correspon­
dente certificado
— todas as chaves públicas MSCA_VU-EGF anteriores a
utilizar na verificação dos certificados das VU ou dos
módulos GNSS externos que ainda estão válidos.
9.1.4 Nível do equipamento ou aparelho: unidades-veículo
▼M1
CSM_72 Para cada unidade-veículo, são criados dois pares de cha­
ves ECC originais, denominados VU_MA e VU_Sign.
Esta função é assegurada pelos fabricantes de VU. Sempre
que for criado um par de chaves de VU, a parte que cria a
chave envia a chave pública à MSCA do país de residên­
cia, a fim de obter o correspondente certificado de VU,
assinado pela MSCA. Somente a unidade-veículo utiliza a
chave privada.
▼B
CSM_73 Os certificados VU_MA e VU_Sign de uma determinada
unidade-veículo têm a mesma data de vigência do
certificado.
CSM_74 O fabricante da VU escolhe a resistência de um par de
chaves de VU igual à do par de chaves MSCA utilizado
para assinar o certificado correspondente da VU.
CSM_75 As unidades-veículo utilizam o seu par de chaves
VU_MA, que consiste na chave privada VU_MA.SK e
na chave pública VU_MA.PK, exclusivamente para efetuar
a autenticação da VU em relação aos cartões tacográficos e
módulos GNSS externos, em conformidade com as secções
10.3 e 11.4 do presente apêndice.
CSM_76 Uma unidade-veículo deve ser capaz de criar pares de
chaves ECC efémeras e utiliza um par de chaves efémero
exclusivamente para efetuar a concordância da chave de
sessão com o cartão tacográfico ou módulo GNSS externo,
em conformidade com as secções 10.4 e 11.4 do presente
apêndice.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 453
CSM_77 A unidade-veículo utiliza a chave privada VU_Sign.SK do
seu par de chaves VU_Sign exclusivamente para assinar
ficheiros de dados descarregados, em conformidade com o
capítulo 14 do presente apêndice. A chave pública
VU_Sign.PK correspondente é utilizada exclusivamente
para verificar assinaturas criadas pela unidade-veículo.
CSM_78 Como mostra o esquema 1 na secção 9.1.7, o período de
validade de um certificado VU_MA é de 15 anos e 3
meses. O período de validade de um certificado VU_Sign
é igualmente de 15 anos e 3 meses.
Notas:
— O período de validade alargado de um certificado
VU_Sign permite a uma unidade-veículo criar assina­
turas válidas em dados descarregados durante os pri­
meiros três meses após ter expirado, conforme previsto
no Regulamento (UE) n. o 581/2010.
— O período de validade alargado de um certificado
VU_MA é necessário para permitir que a VU autenti­
que um cartão de controlo ou um cartão de empresa,
durante os primeiros três meses após ter expirado, para
possibilitar um descarregamento de dados.
CSM_79 Após o termo de validade do correspondente certificado,
a unidade-veículo não utiliza a chave privada de um par de
chaves de VU, seja para que fins for.
CSM_80 Depois de a unidade-veículo ser posta em funcionamento,
os pares de chaves de VU (com exceção dos pares de
chaves efémeras) e os correspondentes certificados de
uma determinada unidade-veículo não são substituídos ou
renovados no terreno.
Notas:
— Os pares de chaves efémeras não estão incluídos neste
requisito, dado que, de cada vez que se realizar a
autenticação da pastilha e a concordância da chave
de sessão, a VU cria um novo par de chaves efémeras
(ver secção 10.4). De salientar que os pares de chaves
efémeras não têm certificados correspondentes.
— Este requisito não impede a substituição de pares de
chaves de VU estáticas durante uma renovação ou re­
paração em ambiente seguro controlado pelo fabricante
da VU.
CSM_81 Quando postas em funcionamento, as unidades-veículo
contêm os seguintes certificados e chaves criptográficas:
— a chave privada VU_MA e o correspondente certifi­
cado
— a chave privada VU_Sign e o correspondente certifi­
cado
— o certificado MSCA_VU-EGF que contém a chave
pública MSCA_VU-EGF.PK a utilizar para a verifica­
ção do certificado VU_MA e do certificado VU_Sign
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 454
— o certificado EUR que contém a chave pública
EUR.PK a utilizar para a verificação do certificado
MSCA_VU-EGF
— o certificado EUR cujo período de validade precede
diretamente o período de validade
do certificado EUR a utilizar para a verificação do
certificado MSCA_VU-EGF, se existir
— o certificado de ligação que liga estes
dois certificados EUR, se existir.
CSM_82 Além dos certificados e chaves criptográficas enumerados
em CSM_81, as unidades-veículo contêm igualmente os
certificados e chaves previstos na parte A do presente
apêndice, que permitem a uma unidade-veículo interagir
com cartões tacográficos da primeira geração.
9.1.5 Nível do equipamento ou aparelho: cartões tacográficos
▼M1
CSM_83 Para cada cartão tacográfico é criado um par de chaves
ECC original, denominado Card_MA. Para cada cartão de
condutor e de oficina é criado adicionalmente um segundo
par de chaves ECC original, denominado Card_Sign. Esta
função pode ser assegurada pelos fabricantes ou persona­
lizadores dos cartões. Sempre que for criado um par de
chaves de cartão, a parte que cria a chave envia a chave
pública à MSCA do país de residência, a fim de obter o
correspondente certificado de cartão, assinado pela MSCA.
A chave privada é utilizada somente pelo cartão tacográ­
fico.
▼B
CSM_84 Os certificados Card_MA e Card_Sign de um determinado
cartão de condutor ou cartão de oficina têm a mesma data
de vigência do certificado.
CSM_85 O fabricante ou personalizador do cartão deve escolher a
resistência de um par de chaves do cartão igual à do par de
chaves MSCA utilizado para assinar o correspondente cer­
tificado do cartão.
CSM_86 O cartão tacográfico deve utilizar o seu par de chaves
Card_MA, que consiste na chave privada Card_MA.SK e
na chave pública Card_MA.PK, exclusivamente para efe­
tuar a autenticação mútua e a concordância de chave de
sessão em relação às unidades-veículo, em conformidade
com as secções 10.3 e 10.4 do presente apêndice.
CSM_87 O cartão de condutor ou de oficina utiliza a chave privada
Card_Sign.SK do seu par de chaves Card_Sign exclusiva­
mente para assinar ficheiros de dados descarregados, em
conformidade com o capítulo 14 do presente apêndice. A
chave pública Card_Sign.PK correspondente é utilizada
exclusivamente para verificar assinaturas criadas pelo car­
tão.
▼M1
CSM_88 O período de validade de um certificado Card_MA é o
seguinte:
— Para cartões de condutor: 5 anos,
— Para cartões de empresa: 5 anos,
— Para cartões de controlo: 2 anos,
— Para cartões de oficina: 1 ano
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 455
CSM_89 O período de validade de um certificado Card_Sign é o
seguinte:
— Para cartões de condutor: 5 anos e 1 mês
— Para cartões de oficina: 1 ano e 1 mês
Nota: o período de validade alargado de um certificado
Card_Sign permite a um cartão de condutor criar assina­
turas válidas em dados descarregados durante o primeiro
mês após ter expirado. Com efeito, o Regulamento (UE)
n. o 581/2010 exige a viabilidade de um descarregamento
de dados do cartão do condutor até 28 dias após terem
sido registados os últimos dados.
CSM_90 Os correspondentes pares de chaves e certificados de um
determinado cartão tacográfico não são substituídos ou
renovados depois de ter sido emitido o cartão.
CSM_91 Quando emitidos, os cartões tacográficos contêm os se­
guintes certificados e chaves criptográficas:
— a chave privada Card_MA e o correspondente certifi­
cado
— para cartões de condutor e cartões de oficina adicio­
nais: a chave privada Card_Sign e o correspondente
certificado
— o certificado MSCA_Card que contém a chave pública
MSCA_Card.PK a utilizar para a verificação do certi­
ficado Card_MA e do certificado Card_Sign
— o certificado EUR que contém a chave pública
EUR.PK a utilizar para a verificação do certificado
MSCA_Card
— o certificado EUR cujo período de validade precede
diretamente o período de validade
do certificado EUR a utilizar para a verificação do
certificado MSCA_Card, se existir.
— o certificado de ligação que liga estes
dois certificados EUR, se existir.
▼M1
— além disso, para os cartões de controlo, os cartões de
empresa e os cartões de oficina apenas, e apenas se tais
cartões tiverem sido emitidos durante os primeiros três
meses do período de validade de um
novo certificado EUR: o certificado EUR de duas ge­
rações, se existir.
Nota respeitante ao último travessão: Por exemplo,
nos primeiros três meses do certificado ERCA(3) (ver
Figura 1), os cartões referidos devem incluir o certifi­
cado ERCA(1). Tal é necessário para assegurar que
esses cartões possam ser utilizados para descarregar
dados das VU ERCA(1), cuja duração normal de 15
anos e período de 3 meses de descarregamento de
dados expiram durante estes meses; Ver último traves­
são do requisito 13) do anexo IC.
▼B
CSM_92 Além dos certificados e chaves criptográficas enumerados
em CSM_91, os cartões tacográficos contêm igualmente os
certificados e chaves previstos na parte A do presente
apêndice, que permitem a estes cartões tacográficos inte­
ragirem com VU da primeira geração.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 456
9.1.6 Nível do equipamento ou aparelho: módulos GNSS externos
▼M1
CSM_93 Para cada módulo GNSS externo é criado um par de cha­
ves ECC original, denominado EGF_MA. Esta função é
assegurada pelos fabricantes de módulos GNSS externos.
Sempre que for criado um par de chaves EGF_MA, a parte
que cria a chave envia a chave pública à MSCA do país de
residência, a fim de obter o correspondente certificado
EGF_MA, assinado pela MSCA. A chave privada é utili­
zada somente pelo módulo GNSS externo.
▼B
CSM_94 O fabricante do EGF escolhe a resistência de um par de
chaves EGF_MA igual à do par de chaves MSCA utili­
zado para assinar o correspondente certificado EGF_MA.
▼M1
CSM_95 O módulo GNSS externo utiliza o seu par de chaves
EGF_MA, que consiste na chave privada EGF_MA.SK e
na chave pública EGF_MA.PK, exclusivamente para efe­
tuar a autenticação mútua e a concordância de chave de
sessão em relação às unidades-veículo, em conformidade
com a secção 11.4 do presente apêndice.
▼B
CSM_96 O período de validade de um certificado EGF_MA é de 15
anos.
CSM_97 Após o termo de validade do correspondente certificado, o
módulo GNSS externo não utiliza a chave privada do seu
par de chaves EGF_MA para acoplamento a uma
unidade-veículo.
Nota: tal como explicado na secção 11.3.3, um EGF pode
eventualmente utilizar a sua chave privada para autentica­
ção mútua em relação à VU a que já está acoplado, mesmo
após o termo de validade do correspondente certificado.
CSM_98 O par de chaves EGF_MA e o correspondente certificado
de um determinado módulo GNSS externo não são subs­
tituídos ou renovados no terreno depois de o EGF ter sido
posto em funcionamento.
Nota: Este requisito não impede a substituição de pares de
chaves EGF durante uma renovação ou reparação em am­
biente seguro controlado pelo fabricante do EGF.
CSM_99 Quando posto em funcionamento, o módulo GNSS externo
contém os seguintes certificados e chaves criptográficas:
— a chave privada EGF_MA e o correspondente certifi­
cado
— o certificado MSCA_VU-EGF que contém a chave
pública MSCA_VU-EGF.PK a utilizar para a verifica­
ção do certificado EGF_MA
— o certificado EUR que contém a chave pública
EUR.PK a utilizar para a verificação do certificado
MSCA_VU-EGF
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 457
— o certificado EUR cujo período de validade precede
diretamente o período de validade
do certificado EUR a utilizar para a verificação do
certificado MSCA_VU-EGF, se existir
— o certificado de ligação que liga estes
dois certificados EUR, se existir
9.1.7 Panorâmica: Substituição de certificados
O esquema 1 mostra como os certificados de raiz ERCA, os certificados
de ligação ERCA, os certificados MSCA e os certificados de equipa­
mento ou aparelho (VU e cartão) de gerações diferentes são emitidos e
utilizados ao longo do tempo:
▼M1
Esquema 1
Emissão e utilização de certificados de raiz ERCA, certificados de ligação ERCA, certificados MSCA e
certificados de equipamento ou aparelho de gerações diferentes
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 458
Notas ao esquema 1:
1. As diversas gerações do certificado de raiz são indicadas por um
número entre parênteses. Por ex.: ERCA (1) é a primeira geração
do certificado de raiz ERCA; ERCA (2) é a segunda geração, etc.
2. Outros certificados são indicados por dois números entre parênteses, o
primeiro a indicar a geração do certificado de raiz ao abrigo do qual
foram emitidos e o segundo a geração do próprio certificado. Por ex.:
MSCA_Card (1-1) é o primeiro certificado MSCA_Card emitido ao
abrigo de ERCA (1); MSCA_Card (2-1) é o primeiro certificado
MSCA_Card emitido ao abrigo de ERCA (2); MSCA_Card (2-último)
é o último certificado MSCA_Card emitido ao abrigo de ERCA (2);
Card_MA(2-1) é o primeiro certificado de cartão para autenticação
mútua emitido ao abrigo de ERCA (2), etc.
3. Os certificados MSCA_Card (2-1) e MSCA_Card (1-último) são emi­
tidos quase, mas não exatamente, na mesma data. MSCA_Card (2-1) é
o primeiro certificado MSCA_Card emitido ao abrigo de ERCA (2) e
será emitido ligeiramente mais tarde do que MSCA_Card (1-último),
o último certificado MSCA_Card ao abrigo de ERCA (1).
4. Tal como mostra o esquema, os primeiros certificados de VU e de
cartão emitidos ao abrigo de ERCA (2) surgirão quase dois anos antes
do aparecimento dos últimos certificados de VU e de cartão emitidos
ao abrigo de ERCA (1), o que se deve ao facto de os certificados de
VU e de cartão serem emitidos ao abrigo de um certificado MSCA,
não diretamente ao abrigo de um certificado ERCA. O certificado
MSCA (2-1) é emitido diretamente após ERCA (2) ficar válido,
mas o certificado MSCA (1-último) apenas é emitido ligeiramente
antes dessa data, no último momento de validade do certificado
ERCA (1). Por conseguinte, estes dois certificados MSCA têm quase
o mesmo período de validade, apesar de pertencerem a gerações
diferentes.
5. O período de validade apresentado para os cartões é o dos cartões de
condutor (5 anos).
▼M1
6. Para poupar espaço, a diferença no período de validade entre os
certificados Card_MA e Card_Sign é apresentada somente para a
primeira geração.
▼B
9.2. Chaves simétricas
9.2.1 Chaves para proteção das comunicações do sensor de movimentos com
a VU
9.2.1.1 Generalidades
Nota: presume-se que os leitores da presente secção estão familiarizados
com o conteúdo da norma ISO 16844-3, que descreve a interface entre
uma unidade-veículo e um sensor de movimentos. O processo de empa­
relhamento entre uma VU e um sensor de movimentos é descrito em
pormenor no capítulo 12 do presente apêndice.
CSM_100 São necessárias várias chaves simétricas para emparelhar
unidades-veículo e sensores de movimentos, para autentica­
ção mútua entre as unidades-veículo e os sensores de mo­
vimentos e para encriptar as comunicações entre as
unidades-veículo e os sensores de movimentos, como mostra
o quadro 3. Todas estas chaves são chaves AES, com um
comprimento de chave igual ao comprimento da chave de
segurança do sensor de movimentos, que está ligado ao
comprimento (previsto) do par de chaves de raiz europeia,
como descrito em CSM_50.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 459
Quadro 3
Chaves para proteção das comunicações do sensor de movimentos com a VU
Chave Símbolo Gerado por Método de geração Memorizado por
Chave de segurança do
sensor de movimentos
— parte da VU
K M-VU ERCA Aleatório ERCA e MSCA que participam
na emissão de certificados de
VU, fabricantes de VU,
unidades-veículo
Chave de segurança do
sensor de movimentos
— parte da oficina
K M-WC ERCA Aleatório ERCA, MSCA, fabricantes de
cartões, cartões de oficina
Chave de segurança do
sensor de movimentos
K M Não gerados inde­
pendentemente
Calculado como K M =
K M-VU XOR K M-WC
ERCA e MSCA que participam
na emissão de chaves de senso­
res de movimentos (faculta­
tivo) (*)
Chave de identificação K ID Não gerados inde­
pendentemente
Calculado do seguinte
modo: K ID = K M XOR
CV, em que CV é espe­
cificado em CSM_106
ERCA e MSCA que participam
na emissão de chaves de senso­
res de movimentos (faculta­
tivo) (*)
Chave de
emparelha-mento
K P Fabricante do sen­
sor de movimentos
Aleatório Um sensor de movimentos
Chave de sessão K S VU (durante o em­
parelhamento da
VU com o sensor
de movimentos)
Aleatório Uma VU e um sensor de mo­
vimentos
(*) Memorização de K M e K ID é opcional, uma vez que estas chaves podem ser derivadas de K M-VU , K M-WC e CV.
CSM_101 A autoridade europeia de certificação de raiz cria K M-VU e
K M-WC , duas chaves AES aleatórias e originais a partir das
quais a chave de segurança do sensor de movimentos K M
pode ser calculada como K M-VU XOR K M-WC . A ERCA
transmite as chaves K M, K M-VU e K M-WC às autoridades
de certificação do Estado-Membro, a seu pedido.
CSM_102 A ERCA atribui a cada chave de segurança do sensor de
movimentos K M um número de versão único, igualmente
aplicável às chaves constituintes K M-VU e K M-WC e à chave
de identificação relativa K ID. A ERCA informa as MSCA
sobre o número de versão ao enviar-lhes as chaves K M-VU e
K M-WC.
Nota: O número de versão é utilizado para distinguir dife­
rentes gerações dessas chaves, conforme explicado em por­
menor na secção 9.2.1.2.
CSM_103 Uma autoridade europeia de certificação do Estado-Membro
transmite aos fabricantes de unidades-veículo, a seu pedido,
a chave K M-VU , juntamente com o seu número de versão. Os
fabricantes de VU inserem a chave K M-VU e o seu número
de versão em todas as VU produzidas.
CSM_104 A autoridade de certificação do Estado-Membro assegura
que a chave K M-WC , juntamente com o respetivo número
de versão, são inseridos em todos os cartões de oficina
emitidos sob a sua responsabilidade.
Notas:
— Ver a descrição do tipo de dados
no apêndice 2.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 460
— Conforme explicado na secção 9.2.1.2, na realidade, po­
dem ter de ser inseridas várias gerações de chaves K M-
-WC num único cartão de oficina.
CSM_105 Além da chave AES especificada no CSM_104, uma MSCA
assegura que a chave TDES Km WC , especificada no requi­
sito CSM_037 (constante da parte A do presente apêndice),
é inserida em todos os cartões de oficina emitidos sob a sua
responsabilidade.
Notas:
— Tal permite a utilização de um cartão de oficina da
segunda geração para acoplamento com uma VU da
primeira geração.
— Um cartão de oficina da segunda geração terá duas apli­
cações diferentes, uma em conformidade com a parte B
e a outra que obedece à parte A do presente apêndice.
Esta última tem a chave TDES Km WC .
CSM_106 Uma MSCA envolvida na emissão de sensores de movimen­
tos deriva a chave de identificação da chave de segurança do
sensor de movimentos através de XORing com um vetor CV
constante. O valor de CV é o seguinte:
▼M1
— Para chaves de segurança do sensor de movimentos de
128 bits: CV = ‘B6 44 2C 45 0E F8 D3 62 0B 7A 8A
97 91 E4 5D 83’
▼B
— Para chaves de segurança do sensor de movimentos de
192 bits: CV = «72 AD EA FA 00 BB F4 EE F4 99 15
70 5B 7E EE BB 1C 54 ED 46 8B 0E F8 25»
— Para chaves de segurança do sensor de movimentos de
256 bits: CV = «1D 74 DB F0 34 C7 37 2F 65 55 DE
D5 DC D1 9A C3 23 D6 A6 25 64 CD BE 2D 42 0D
85 D2 32 63 AD 60»
Nota: os vetores constantes foram criados da seguinte forma:
Pi_10 = primeiros 10 bytes da parte decimal da constante
matemática π = «24 3F 6A 88 85 A3 08 D3 13 19»
CV_128-bits = primeiros 16 bytes de SHA-256(Pi_10)
CV_192-bits = primeiros 24 bytes de SHA-384(Pi_10)
CV_256-bits = primeiros 32 bytes de SHA-512(Pi_10)
CSM_107 ►M1 Cada fabricante de sensores de movimentos cria uma
chave de emparelhamento K P aleatória e original para cada
sensor de movimentos e envia cada chave de emparelha­
mento à respetiva autoridade de certificação do
Estado-Membro. A MSCA encripta cada chave de empare­
lhamento individualmente com a chave de segurança do
sensor de movimentos K M e devolve a chave encriptada
ao fabricante do sensor de movimentos. Relativamente a
cada chave encriptada, a MSCA comunica ao fabricante
do sensor de movimentos o número de versão da chave
K M associada. ◄
Nota: tal como explicado na secção 9.2.1.2, na realidade, o
fabricante de sensores de movimentos pode ter de criar
múltiplas chaves de emparelhamento originais para um
único sensor de movimentos.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 461
CSM_108 Cada fabricante de sensores de movimentos cria um número
de série único para cada sensor de movimentos e envia
todos os números de série à respetiva autoridade de certifi­
cação do Estado-Membro. A MSCA encripta cada número
de série individualmente com a chave de identificação K ID e
devolve o número de série encriptado ao fabricante do sen­
sor de movimentos. Relativamente a cada número de série
encriptado, a MSCA comunica ao fabricante do sensor de
movimentos o número de versão da chave K ID associada.
▼B
CSM_109 Relativamente aos requisitos CSM_107 e CSM_108, a
MSCA utiliza o algoritmo AES no modo de funcionamento
por cifragem progressiva, conforme definido na norma ISO
10116, com um parâmetro intercalar m = 1 e um vetor de
inicialização SV = «00» {16}, ou seja, dezasseis bytes com
valor binário 0. Quando necessário, a MSCA utiliza o mé­
todo de preenchimento 2 definido na norma ISO 9797-1.
CSM_110 O fabricante de sensores de movimentos memoriza a chave
de emparelhamento encriptada e o número de série encrip­
tado no sensor de movimentos a que se destina, juntamente
com os valores de texto simples e o número de versão das
chaves K M e K ID utilizadas para encriptação.
Nota: tal como explicado na secção 9.2.1.2, na realidade, o
fabricante de sensores de movimentos pode ter de inserir
múltiplas chaves de emparelhamento encriptadas e múltiplos
números de série encriptados num único sensor de
movimentos.
CSM_111 Além do material criptográfico com recurso a AES especi­
ficado no CSM_110, um fabricante de sensores de movi­
mentos também pode memorizar em cada sensor de movi­
mentos o material criptográfico com recurso a TDES espe­
cificado no requisito CSM_037 (parte A do presente apên­
dice).
Nota: este procedimento permite que um sensor de movi­
mentos da segunda geração seja acoplado a uma VU da
primeira geração.
CSM_112 O comprimento da chave de sessão K S criada por uma VU
durante o emparelhamento com um sensor de movimentos
está ligado ao comprimento da respetiva chave K M-VU , con­
forme descrito em CSM_50.
9.2.1.2 Substituição da chave de segurança do sensor de movimentos em apare­
lhos da segunda geração
CSM_113 Cada chave de segurança do sensor de movimentos e todas
as chaves relacionadas (ver quadro 3) estão associadas a
uma determinada geração do par de chaves de raiz ERCA.
Essas chaves são, por conseguinte, substituídas de 17 em 17
anos. O período de validade de cada geração da chave de
segurança do sensor de movimentos tem início um ano antes
do início de validade do par de chaves de raiz ERCA asso­
ciado e termina quando expirar a validade do par de chaves
de raiz ERCA associado. Tal é descrito no esquema 2.
▼M1
02016R0799 — PT — 21.08.2023 — 003.002 — 462
Esquema 2
Emissão e utilização de diferentes gerações da chave de segurança de sensores de movimentos em
unidades-veículo, sensores de movimentos e cartões de oficina
CSM_114 Pelo menos um ano antes de criar um novo par de chaves de
raiz europeia, conforme indicado no requisito CSM_56, a
ERCA cria uma nova chave de segurança do sensor de
movimentos K M através de novas chaves K M-VU e K M-WC .
O comprimento da chave de segurança do sensor de movi­
mentos está ligado à resistência prevista do novo par de
chaves de raiz europeia, de acordo com CSM_50. A
ERCA comunica as novas chaves K M , K M-VU e K M-WC às
MSCA, a seu pedido, juntamente com o respetivo número
de versão.
CSM_115 Uma MSCA deve assegurar que todas as gerações válidas de
K M-WC são memorizadas nos cartões de oficina emitidos sob
a sua autoridade, juntamente com os respetivos números de
versão, como mostra o esquema 2.
Nota: Tal implica que, no último ano do período de validade
de um certificado ERCA, os cartões de oficina sejam emitidos
com três gerações diferentes de chaves K M-WC , como mostra o
esquema 2.
CSM_116 No que se refere ao processo descrito em CSM_107 e
CSM_108: Uma MSCA encripta cada chave de emparelha­
mento K P que recebe de um fabricante de sensores de mo­
vimentos, separadamente com cada geração válida da chave
de segurança do sensor de movimentos K M . Encripta ainda
cada número de série que recebe de um fabricante de sen­
sores de movimentos, separadamente com cada geração vá­
lida da chave de identificação K ID . Um fabricante de senso­
res de movimentos memoriza todas as encriptações da chave
de emparelhamento e todas as encriptações do número de
série no sensor de movimentos a que se destina, juntamente
com os valores de texto simples e o número de versão das
chaves K M e K ID utilizadas para encriptação.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 463
Nota: Tal implica que, no último ano do período de validade
de um certificado ERCA, os sensores de movimentos sejam
emitidos com dados encriptados baseados em três gerações
diferentes de chaves K M, como mostra o esquema 2.
CSM_117 No que se refere ao processo descrito em CSM_107: Dado
que o comprimento da chave de emparelhamento K P está
ligado ao comprimento da chave K M (ver CSM_100), o
fabricante do sensor de movimentos pode ter de criar até
três chaves de emparelhamento diferentes (de comprimentos
diferentes) para um sensor de movimentos, se as gerações
subsequentes de K M tiverem comprimentos diferentes. Nesse
caso, o fabricante envia todas as chaves de emparelhamento
à MSCA. A MSCA garante que todas as chaves de empare­
lhamento estão encriptadas com a geração correta da chave
de segurança do sensor de movimentos, ou seja, aquela que
tem o mesmo comprimento.
Nota: Se o fabricante do sensor de movimentos escolher a
criação de uma chave de emparelhamento com recurso a
TDES para um sensor de movimentos da segunda geração
(ver CSM_111), deve indicar à MSCA que a chave de se­
gurança do sensor de movimentos com recurso a TDES tem
de ser utilizada para encriptar essa chave de emparelha­
mento. Tal ocorre devido ao facto de o comprimento de
uma chave TDES ser igual ao de uma chave AES; logo, a
MSCA não pode considerar isoladamente o comprimento da
chave.
CSM_118 Os fabricantes de unidades-veículo inserem apenas uma ge­
ração de K M-VU em cada unidade-veículo, juntamente com o
respetivo número de versão. Esta geração de K M-VU está
ligada ao certificado ERCA sobre o qual se baseiam os
certificados das VU.
Notas:
— Uma unidade-veículo baseada no certificado ERCA da
geração X contém unicamente a chave K M-VU da geração
X, mesmo que seja emitida após o início do período de
validade do certificado ERCA da geração X+1 (ver es­
quema 2).
— Uma VU da geração X não pode ser emparelhada com
um sensor de movimentos da geração X-1.
— Dado que o período de validade dos cartões de oficina é
de um ano, resulta dos requisitos CSM_113 a CSM_118
que todos os cartões de oficina terão a nova chave K M-
-WC no momento da emissão da primeira VU que contém
a nova chave K M-VU . Por conseguinte, a VU conseguirá
calcular sempre a nova chave K M . Além disso, por essa
altura, também os novos sensores de movimentos pos­
suirão, na sua maioria, dados encriptados baseados na
nova chave K M .
9.2.2 Chaves para comunicações DSRC seguras
9.2.2.1 Generalidades
CSM_119 A autenticidade e a confidencialidade dos dados comunica­
dos a uma autoridade de controlo a partir de uma
unidade-veículo, através de um canal de comunicações à
distância DSRC, são asseguradas por meio de um conjunto
de chaves AES específicas da VU, derivadas de uma chave
de segurança DSRC única, a KM DSRC .
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 464
CSM_120 A chave de segurança DSRC KM DSRC é uma chave AES
criada, memorizada e distribuída de forma segura pela
ERCA. O seu comprimento pode ser de 128, 192 ou 256
bits e está associado ao comprimento do par de chaves de
raiz europeia, conforme se refere no requisito CSM_50.
CSM_121 A ERCA comunica, de forma segura, a chave de segurança
DSRC às autoridades de certificação do Estado-Membro, a
seu pedido, para que possam derivar chaves DSRC especí­
ficas da VU e para garantir que a chave de segurança DSRC
é inserida em todos os cartões de controlo e de oficina
emitidos sob a sua responsabilidade.
CSM_122 A ERCA atribui a cada chave de segurança DSRC um
número de versão único e informa as MSCA sobre o nú­
mero de versão ao enviar-lhes a chave de segurança DSRC.
Nota: O número de versão é utilizado para distinguir dife­
rentes gerações da chave de segurança DSRC, conforme se
explica em pormenor na secção 9.2.2.2.
▼M1
CSM_123 Relativamente a todas as unidades-veículo: O fabricante de
unidades-veículo cria um número de série de VU único e
envia-o à autoridade de certificação do respetivo
Estado-Membro, num pedido de obtenção de um conjunto
de duas chaves DSRC específicas da VU. O número de série
da VU tem o tipo de dados
Nota:
— O referido número de série da VU deve ser idêntico ao
elemento vuSerialNumber da VuIdentification, ver apên­
dice 1 e à referência do titular do certificado nos certi­
ficados da VU.
— O número de série da VU pode não ser conhecido no
momento em que um fabricante de unidades-veículo so­
licite as chaves DSRC específicas da VU. Nesse caso, o
fabricante de VU envia, em vez disso, o ID de pedido de
certificado único que utilizou quando solicitou os certi­
ficados da VU; Ver CSM_153. Esse ID de pedido de
certificado deve, por conseguinte, ser igual à referência
do titular do certificado nos certificados da VU.
▼B
CSM_124 Ao receber um pedido de chaves DSRC específicas da VU,
a MSCA deriva para a unidade-veículo duas chaves AES,
denominadas K_VU DSRC _ENC e K_VU DSRC _MAC. Estas
chaves específicas da VU têm o mesmo comprimento da
chave de segurança DSRC. A MSCA utiliza a função de
derivação de chave definida em [RFC 5869]. A função hash
necessária para instanciar a função HMAC-Hash é ligada ao
comprimento da chave de segurança DSRC, conforme refere
o requisito CSM_50. A função de derivação de chave em
[RFC 5869] é utilizada do seguinte modo:
Passo 1 (Extrair):
— PRK = HMAC-Hash (salt, IKM) onde salt é uma cadeia
vazia e IKM é KM DSRC .
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 465
Passo 2 (Expandir):
— OKM = T(1), onde
T(1) = HMAC-Hash (PRK, T(0) || info || «01») com
— T(0) = uma cadeia vazia («»)
— ►M1 info = número de série da VU, conforme
especificado no CSM_123 ◄
— K_VU DSRC _ENC = primeiros octetos L de OKM e
K_VU DSRC _MAC = últimos octetos L de OKM
onde L é o comprimento necessário de K_VU DSRC _ENC
e K_VU DSRC _MAC em octetos.
CSM_125 A MSCA distribui ao fabricante da VU, de forma segura, as
chaves K_VU DSRC _ENC e K_VU DSRC _MAC, para inserção
na unidade-veículo a que se destinam.
CSM_126 Uma vez emitida, uma unidade-veículo terá memorizado as
chaves K_VU DSRC _ENC e K_VU DSRC _MAC na respetiva
memória segura, a fim de poder garantir a integridade, a
autenticidade e a confidencialidade dos dados enviados atra­
vés do canal de comunicação à distância. Uma
unidade-veículo memoriza ainda o número de versão da
chave de segurança DSRC utilizada para derivar essas cha­
ves específicas da VU.
CSM_127 Uma vez emitidos, os cartões de controlo e de oficina terão
memorizado KM DSRC na respetiva memória segura, a fim de
poderem verificar a integridade e a autenticidade dos dados
enviados por uma VU através do canal de comunicação à
distância e decifrar os dados. Os cartões de controlo e de
oficina memorizam também o número de versão da chave de
segurança DSRC.
Nota: Conforme se explica na secção 9.2.2.2, podem, na
realidade, ter de ser inseridas várias gerações de chaves
KM DSRC num único cartão de controlo ou de oficina.
▼M1
CSM_128 A MSCA mantém registos de todas as chaves DSRC espe­
cíficas da VU que criou, os respetivos números de versão e
o número de série da VU ou ID de pedido de certificado
utilizado para os obter.
▼B
9.2.2.2 Substituição da chave de segurança DSRC
CSM_129 Cada chave de segurança DSRC está associada a uma de­
terminada geração do par de chaves de raiz ERCA. Por
conseguinte, a ERCA substitui a chave de segurança
DSRC de 17 em 17 anos. O período de validade de cada
geração da chave de segurança DSRC tem início dois anos
antes do início de validade do par de chaves de raiz ERCA
associado e termina quando expira a validade do par de
chaves de raiz ERCA associado (ver esquema 3).
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 466
Esquema 3
Emissão e utilização de diferentes gerações da chave de segurança DSRC em unidades-veículo, cartões de oficina
e cartões de controlo
CSM_130 Pelo menos dois anos antes da criação de um novo par de
chaves de raiz europeia (descrição em CSM_56), a ERCA
cria uma nova chave de segurança DSRC. O comprimento
da chave DSRC é ligado à resistência prevista do novo par
de chaves de raiz europeia, de acordo com CSM_50. A
ERCA comunica a nova chave de segurança DSRC às
MSCA, a seu pedido, juntamente com o respetivo número
de versão.
CSM_131 Uma MSCA deve assegurar que todas as gerações válidas de
KM DSRC são memorizadas nos cartões de controlo emitidos
sob a sua autoridade, juntamente com os respetivos números
de versão, como mostra o esquema 3.
Nota: Tal implica que, nos últimos dois anos do período de
validade de um certificado ERCA, os cartões de controlo
serão emitidos com três gerações diferentes de chaves
KM DSRC , como mostra o esquema 3.
CSM_132 Uma MSCA assegura que todas as gerações de KM DSRC que
tenham estado válidas durante, pelo menos, um ano e con­
tinuam válidas, são memorizadas em todos os cartões de
oficina emitidos sob a sua autoridade, juntamente com os
respetivos números de versão, como mostra o esquema 3.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 467
Nota: Tal implica que, no último ano do período de validade
de um certificado ERCA, os cartões de oficina serão emiti­
dos com três gerações diferentes de chaves KM DSRC , como
mostra o esquema 3.
CSM_133 Os fabricantes de unidades-veículo inserem apenas um con­
junto de chaves DSRC específicas da VU em cada
unidade-veículo, juntamente com o respetivo número de ver­
são. Este conjunto de chaves é derivado da geração
KM DSRC , ligado ao certificado ERCA no qual se baseiam
os certificados das VU.
Notas:
— Tal implica que uma unidade-veículo baseada no certi­
ficado ERCA da geração X contenha unicamente as cha­
ves K_VU DSRC _ENC e K_VU DSRC _MAC da geração X,
mesmo que a VU seja emitida após o início do período
de validade do certificado ERCA da geração X+1 (ver
esquema 3).
— Dado que o período de validade dos cartões de oficina é
de um ano e o dos cartões de controlo é de dois anos,
resulta dos requisitos CSM_131 — CSM_133 que todos
os cartões de oficina e de controlo terão a nova chave de
segurança DSRC no momento da emissão da primeira
VU que contém chaves específicas da VU baseadas
nessa chave de segurança.
9.3. Certificados
9.3.1 Generalidades
CSM_134 No sistema tacográfico inteligente europeu, todos os certifi­
cados serão certificados autodescritivos e verificáveis do
cartão (CV), em conformidade com as normas ISO 7816-4
e ISO 7816-8.
CSM_135 ►M1 De acordo com a norma ISO 8825-1, utilizar-se-ão as
regras distintas de codificação para codificar os objetos de
dados dentro dos certificados. O quadro 4 mostra a codifi­
cação de todo o certificado, incluindo marcadores e com­
primento (bytes). ◄
Nota: Esta codificação resulta numa estrutura Marcador-
-Comprimento-Valor (TLV), da seguinte forma:
Marcador: O marcador está codificado em um ou dois
octetos e indica o conteúdo.
Comprimento: O comprimento é codificado como número
inteiro não assinado, em um, dois ou três
octetos, que resultam num comprimento má­
ximo de 65 535 octetos. Deve utiliza-se o
número mínimo de octetos.
Valor: O valor é codificado em zero ou mais octe­
tos
9.3.2 Conteúdo do certificado
CSM_136 Todos os certificados têm a estrutura de perfil do certificado
apresentada no quadro 4.
Quadro 4
Perfil do certificado, versão 1
Campo ID do campo Marcador Compri-mento (bytes)
Tipo de dados ASN.1
(ver apêndice 1)
Certificado ECC C «7F 21» var
Corpo do certificado
ECC
B «7F 4E» var
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 468
Campo ID do campo Marcador Compri-mento (bytes)
Tipo de dados ASN.1
(ver apêndice 1)
Identificador de perfil
do certificado
CPI «5F 29» «01»
Referência da autori­
dade de certificação
CAR «42» «08»
Autorização do titular
do certificado
CHA «5F 4C» «07»
Chave pública PK «7F 49» var
Parâmetros de domí­
nio
DP «06» var
Ponto público PP «86» var
Referência do titular
do certificado
CHR «5F 20» «08»
Data de vigência do
certificado
CEfD «5F 25» «04»
Data de validade do
certificado
CExD «5F 24» «04»
Assinatura do certifi­
cado ECC
S «5F 37» var
Nota: O ID do campo será utilizado em secções posteriores
do presente apêndice para indicar campos individuais de um
certificado; por exemplo, X.CAR é a referência da autori­
dade de certificação referida no certificado do utilizador X.
9.3.2.1 Identificador de perfil do certificado
CSM_137 Os certificados utilizam um identificador de perfil do certi­
ficado para indicar o perfil do certificado utilizado. A ver­
são 1, em conformidade com o quadro 4, é identificada por
um valor de «00».
9.3.2.2 Referência da autoridade de certificação
CSM_138 Utiliza-se a referência da autoridade de certificação para
identificar a chave pública a utilizar para verificar a assina­
tura do certificado. A referência da autoridade de certifica­
ção será, por conseguinte, igual à referência do titular do
certificado, constante do certificado da correspondente auto­
ridade de certificação.
CSM_139 Um certificado de raiz ERCA deve ser autoassinado, ou
seja: no certificado, a referência da autoridade de certifica­
ção e a referência do titular do certificado são iguais.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 469
CSM_140 Relativamente a um certificado de ligação ERCA, a referên­
cia do titular do certificado é igual à CHR do novo certifi­
cado de raiz ERCA. A referência da autoridade de certifica­
ção para um certificado de ligação é igual à CHR do ante­
rior certificado de raiz ERCA.
9.3.2.3 Autorização do titular do certificado
▼M1
CSM_141 Utiliza-se a autorização do titular do certificado para identi­
ficar o tipo de certificado. Consiste nos seis bytes mais
significativos do ID da aplicação tacográfica, concatenados
com o tipo de aparelho, que indica o tipo de aparelho ao
qual se destina o certificado. No caso de um certificado de
VU, um certificado de cartão de condutor ou um certificado
de cartão de oficina, o tipo de aparelho também é utilizado
para destrinçar um certificado de autenticação mútua de um
certificado para criação de assinaturas digitais (ver secção
9.1 e apêndice 1, tipo de dados EquipmentType).
▼B
9.3.2.4 Chave pública
A chave pública agrupa dois elementos de dados: os parâmetros de
domínio normalizados, a utilizar com a chave pública no certificado, e
o valor do ponto público.
CSM_142 Os parâmetros de domínio do elemento de dados contêm um
dos identificadores de objeto especificados no quadro 1 para
fazer referência a um conjunto de parâmetros de domínio
normalizados.
CSM_143 O ponto público do elemento de dados contém o
ponto público. Os pontos públicos da curva elíptica devem
ser convertidos em cadeias de octetos, em conformidade
com a Orientação Técnica TR-03111. Deve utilizar-se o
formato de codificação não compactado. Ao recuperar um
ponto de curva elíptica do seu formato codificado, devem
efetuar-se sempre as validações descritas na Orientação Téc­
nica TR-03111.
9.3.2.5 Referência do titular do certificado
CSM_144 A referência do titular do certificado é um identificador da
chave pública fornecida no certificado. Utiliza-se para fazer
referência a esta chave pública em outros certificados.
CSM_145 Relativamente a certificados de cartões e certificados de
módulos GNSS externos, a referência do titular do certifi­
cado tem o tipo de dados ,
especificado no apêndice 1.
CSM_146 No que se refere às unidades-veículo: sempre que pedir um
certificado, o fabricante pode não conhecer o número de
série específico do fabricante da VU para o qual se destina
o certificado e a chave privada associada. Se o conhecer, a
referência do titular do certificado tem o tipo de dados
, especificado no apêndice 1.
Se não o conhecer, a referência do titular do certificado tem
o tipo de dados , especificado
no apêndice 1.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 470
Nota: Para um certificado do cartão, o valor do CHR deve
ser igual ao valor do cardExtendedSerialNumber no
EF_ICC; ver apêndice 2. Para um certificado EGF, o valor
do CHR deve ser igual ao valor do sensorGNSSSerialNum­
ber no EF_ICC; ver apêndice 14. Para um certificado de
VU, o valor do CHR deve ser igual ao elemento vuSerial­
Number da VuIdentification, ver apêndice 1, exceto se o
fabricante não conhecer o número de série específico do
fabricante no momento em que o certificado é pedido.
▼B
CSM_147 Em relação aos certificados ERCA e MSCA, a referência do
titular do certificado tem o tipo de dados
, especificado no apên­
dice 1.
9.3.2.6 Data de vigência do certificado
▼M1
CSM_148 A data de vigência do certificado indica a data e a hora de
início do período de validade do certificado.
▼B
9.3.2.7 Data de validade do certificado
CSM_149 A data de vigência do certificado indica a data e a hora de
termo do período de validade do certificado.
9.3.2.8 Assinatura do certificado
CSM_150 A assinatura no certificado é criada sobre o corpo do certi­
ficado codificado, que inclui o marcador e o comprimento
do corpo do certificado. O algoritmo de assinatura é
ECDSA, conforme especificado em DSS, mediante utiliza­
ção do algoritmo de hash ligado ao tamanho da chave da
autoridade de assinatura, em conformidade com o CSM_50.
O formato de assinatura deve ser simples, em conformidade
com a Orientação Técnica TR-03111.
9.3.3 Pedido de certificados
CSM_151 ►M1 Ao pedir um certificado, a MSCA deve enviar à
ERCA os seguintes dados: ◄
— identificador de perfil do certificado pedido
— referência da autoridade de certificação a utilizar para a
assinatura do certificado.
— chave pública a assinar
CSM_152 Num pedido de certificado à ERCA, para permitir que esta
crie a referência do titular do novo certificado MSCA, a
MSCA deve enviar os dados a seguir indicados, além dos
que figuram no requisito CSM_151:
— código numérico da autoridade de certificação nacional (tipo
de dados , definido no apêndice 1)
— código alfanumérico da autoridade de certificação nacio­
nal (tipo de dados , definido no apên­
dice 1)
— número de série de 1 byte que distingue as diferentes
chaves da autoridade de certificação, caso sejam altera­
das
— campo de dois bytes que contém informações adicionais
específicas da autoridade de certificação
▼M1
02016R0799 — PT — 21.08.2023 — 003.002 — 471
CSM_153 Num pedido de certificado a uma MSCA, para permitir que
esta crie a referência do titular do novo certificado do equi­
pamento, o fabricante do equipamento ou aparelho deve
enviar os dados a seguir indicados:
— Se for conhecido (ver CSM_154), número de série do
equipamento, único para o fabricante, para o tipo do
equipamento e para o mês de fabrico; caso contrário,
um identificador de pedido de certificado único.
— Mês e ano de fabrico do equipamento ou de pedido do
certificado.
O fabricante assegura que estes dados estão corretos e que o certificado
devolvido pela MSCA é inserido no equipamento a que se destina.
▼B
CSM_154 No caso de uma VU, o fabricante, quando pede um certifi­
cado, pode não conhecer o número de série específico do
fabricante da VU ao qual se destinam o certificado e a chave
privada associada. Se o conhecer, o fabricante da VU envia
o número de série à MSCA. Se não o conhecer, o fabricante
identifica cada pedido de certificado de forma única e envia
o número de série do pedido de certificado à MSCA. O
certificado obtido contém o número de série do pedido de
certificado. Após a inserção do certificado numa VU espe­
cífica, o fabricante comunica à MSCA a conexão entre o
número de série do pedido de certificado e a identificação da
VU.
10. AUTENTICAÇÃO MÚTUA E ENVIO SEGURO DE MENSAGENS
ENTRE O CARTÃO E A VU
10.1. Generalidades
CSM_155 A um nível superior, a comunicação segura entre uma
unidade-veículo e um cartão tacográfico baseia-se nos se­
guintes passos:
— Em primeiro lugar, cada parte demonstra à outra que
possui um certificado de chave pública válido, assinado
por uma autoridade de certificação do Estado-Membro.
Por sua vez, o certificado de chave pública MSCA é
assinado pela autoridade europeia de certificação de raiz.
Este passo denomina-se «verificação da cadeia de certi­
ficados» e é pormenorizado na secção 10.2.
— Em segundo lugar, a unidade-veículo demonstra ao car­
tão que está de posse da chave privada correspondente à
chave pública constante do certificado apresentado. Tal é
feito através da assinatura de um número aleatório en­
viado pelo cartão. O cartão verifica a assinatura no nú­
mero aleatório. Se esta verificação tiver êxito, a VU é
autenticada. Este passo denomina-se «autenticação da
VU» e é pormenorizado na secção 10.3.
▼M1
02016R0799 — PT — 21.08.2023 — 003.002 — 472
— Em terceiro lugar, ambas as partes calculam, de modo
independente, duas chaves de sessão AES que utilizam
um algoritmo de concordância de chave assimétrica. Ao
utilizar uma dessas chaves de sessão, o cartão cria um
código de autenticação de mensagem (MAC) em alguns
dados enviados pela VU. A VU verifica o MAC. Se esta
verificação tiver êxito, o cartão é autenticado. Este passo
denomina-se «autenticação do cartão» e é pormenorizado
na secção 10.4.
— Em quarto lugar, a VU e o cartão utilizam as chaves de
sessão acordadas para garantir a confidencialidade, a
integridade e a autenticidade de todas as mensagens in­
tercambiadas. Este passo denomina-se «envio seguro de
mensagens» e é pormenorizado na secção 10.5.
CSM_156 O mecanismo descrito no requisito CSM_155 é acionado
pela unidade-veículo sempre que o cartão for inserido
numa das suas ranhuras para cartões.
10.2. Verificação mútua da cadeia de certificados
10.2.1 Verificação da cadeia de certificados de cartão pela VU
CSM_157 ►M1 As unidades-veículo utilizam o protocolo descrito no
esquema 4 para verificarem a cadeia de certificados dos
cartões tacográficos. Para cada certificado lido a partir do
cartão, a VU verifica se o campo relativo à autorização do
titular do certificado (CHA) está correto:
— O campo CHA do certificado do cartão deve indicar um
certificado de cartão de autenticação mútua (ver apên­
dice 1, tipo de dados EquipmentType).
— O CHA do certificado Card.CA deve indicar uma
MSCA.
— O CHA do certificado Card.Link deve indicar uma
ERCA. ◄
Notas do esquema 4:
— Os certificados de cartão e as chaves públicas mencio­
nados no esquema são os destinados à autenticação mú­
tua. A secção 9.1.5 indica-os como Card_MA.
— Os certificados Card.CA e as chaves públicas menciona­
dos no esquema são os destinados à assinatura dos cer­
tificados de cartão e estão indicados na CAR do certifi­
cado do cartão. A secção 9.1.3 indica-os como
MSCA_Card.
— O certificado Card.CA.EUR mencionado no esquema é o
certificado de raiz europeia indicado na CAR do certifi­
cado Card.CA.
— O certificado Card.Link mencionado no esquema é o
certificado de ligação do cartão, caso exista. Em confor­
midade com a secção 9.1.2, trata-se de um certificado de
ligação para um novo par de chaves de raiz europeia
criado pela ERCA e assinado pela chave privada euro­
peia anterior.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 473
— O certificado Card.Link.EUR é o certificado de raiz eu­
ropeia indicado na CAR do certificado Card.Link.
CSM_158 Conforme descrito no esquema 4, a verificação da cadeia de
certificados dos cartões tem início com a inserção do cartão.
A unidade-veículo lê a referência do titular do cartão (­
) a partir de EF ICC.
Verifica se conhece o cartão, ou seja, se teve êxito na veri­
ficação da cadeia de certificados dos cartões no passado e a
memorizou para referência futura. Em caso afirmativo e se o
certificado do cartão ainda for válido, o processo continua,
com a verificação da cadeia de certificados da VU. Caso
contrário, a VU lê consecutivamente a partir do cartão o
certificado MSCA_Card a utilizar para verificação do certi­
ficado do cartão, o certificado Card.CA.EUR a utilizar para
verificação do certificado MSCA_Card e, possivelmente, o
certificado de ligação, até localizar um certificado que co­
nheça ou possa verificar. A VU utiliza então o certificado
que conhece para verificar os certificados de cartão subja­
centes que tenha lido a partir do cartão. Em caso de êxito, o
processo continua com a verificação da cadeia de certifica­
dos da VU. Se não tiver êxito, a VU ignora o cartão.
Nota: Há três maneiras pelas quais a VU pode conhecer o
certificado Card.CA.EUR:
— o certificado Card.CA.EUR é o mesmo que
o certificado EUR da VU;
— o certificado Card.CA.EUR precede o certificado EUR
da VU, e a VU continha este certificado já no momento
da emissão (ver CSM_81);
— o certificado Card.CA.EUR sucede ao certificado EUR
da VU, e a VU recebeu no passado, de outro cartão
tacográfico, um certificado de ligação, que verificou e
memorizou para referência futura.
CSM_159 Conforme indica o esquema 4, assim que a VU tiver veri­
ficado a autenticidade e a validade de um certificado ante­
riormente desconhecido, pode memorizá-lo para referência
futura, de tal forma que não precisa de verificar novamente
a autenticidade se o certificado voltar a ser apresentado à
VU. Em vez de memorizar todo o certificado, a VU pode
optar por memorizar apenas o conteúdo do corpo, em con­
formidade com a secção 9.3.2. ►M1 Enquanto a memori­
zação de todos os outros tipos de certificado é facultativa, a
VU deve obrigatoriamente memorizar um novo certificado
de ligação apresentado por um cartão. ◄
CSM_160 A VU verifica a validade temporal de todos os certificados
lidos a partir do cartão ou memorizados na sua memória e
rejeita os certificados expirados. Para verificar a validade
temporal de um certificado apresentado pelo cartão, a VU
utiliza o seu relógio interno.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 474
Esquema 4
Protocolo para a verificação da cadeia de certificado do cartão pela VU
10.2.2 Verificação da cadeia de certificado da VU pelo cartão
CSM_161 ►M1 Os cartões tacográficos utilizam o protocolo descrito
no esquema 5 para a verificação da cadeia de certificados da
VU. Para cada certificado apresentado pela VU, o cartão
verifica se o campo relativo à autorização do titular do
certificado (CHA) está correto:
— O CHA do certificado VU.Link deve indicar uma
ERCA.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 475
— O CHA do certificado VU.CA deve indicar uma MSCA.
— O campo CHA do certificado da VU deve indicar um
certificado da VU de autenticação mútua (ver apêndice
1, tipo de dados EquipmentType). ◄
Esquema 5
Protocolo para a verificação da cadeia de certificado da VU pelo cartão
Notas do esquema 5:
— Os certificados de VU e as chaves públicas mencionados no esquema
são os destinados à autenticação mútua. A secção 9.1.4 indica-os
como VU_MA.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 476
— Os certificados VU.CA e as chaves públicas mencionados no es­
quema são os destinados à assinatura dos certificados da VU e do
módulo GNSS externo. A secção 9.1.3 indica-os como MSCA_VU-
-EGF.
— O certificado VU.CA.EUR mencionado no esquema é o certificado
de raiz europeia indicado na CAR do certificado VU.CA.
— O certificado VU.Link mencionado no esquema é o certificado de
ligação da VU, caso exista. Em conformidade com a secção 9.1.2,
trata-se de um certificado de ligação para um novo par de chaves de
raiz europeia criado pela ERCA e assinado pela chave privada euro­
peia anterior.
— O certificado VU.Link.EUR é o certificado de raiz europeia indicado
na CAR do certificado VU.Link.
CSM_162 Conforme descrito no esquema 5, a verificação da cadeia de
certificado da unidade-veículo tem início com a tentativa da
unidade-veículo de definir a sua própria chave pública para
utilização no cartão tacográfico. Se tal acontecer, significa
que, no passado, o cartão verificou com êxito a cadeia de
certificados da VU e memorizou o certificado da VU para
referência futura. Neste caso, o certificado da VU é definido
para utilização, e o processo continua, com a autenticação
da VU. Se o cartão não conhecer o certificado da VU, esta
deve apresentar consecutivamente o certificado VU.CA a
utilizar para verificação do seu certificado de VU, o certi­
ficado VU.CA.EUR a utilizar para verificação do certificado
VU.CA e, possivelmente, o certificado de ligação, a fim de
localizar um certificado conhecido ou verificável pelo car­
tão. Se localizar um certificado, o cartão utiliza-o para ve­
rificar os certificados de VU subjacentes apresentados à VU.
Em caso de êxito, a VU define finalmente a sua chave
pública para utilização no cartão tacográfico. Se não tiver
êxito, a VU ignora o cartão.
Nota: Há três maneiras pelas quais o cartão pode conhecer
o certificado VU.CA.EUR:
— o certificado VU.CA.EUR é o mesmo que
o certificado EUR do cartão
— o certificado VU.CA.EUR precede o certificado EUR do
cartão, e o cartão continha este certificado já no mo­
mento da emissão (ver CSM_91)
— o certificado VU.CA.EUR sucede ao certificado EUR
do cartão, e o cartão recebeu no passado, de outra
unidade-veículo, um certificado de ligação, verificou-o
e memorizou-o para referência futura.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 477
CSM_163 A VU utiliza o comando MSE: Set AT para definir a sua
chave pública para utilização no cartão tacográfico. Em
conformidade com o apêndice 2, o comando contém uma
indicação do mecanismo criptográfico que será utilizado
com a chave definida. Este mecanismo é a autenticação
da VU que utiliza o algoritmo ECDSA, em combinação
com o algoritmo de hash ligado ao tamanho da chave do
par de chaves VU_MA da VU, em conformidade com o
requisito CSM_50.
CSM_164 O comando MSE: Set AT contém igualmente uma indica­
ção do par de chaves efémeras que a VU utilizará durante a
concordância de chave de sessão (ver secção 10.4). Por
conseguinte, antes de enviar o comando MSE: Set AT, a
VU cria um par de chaves ECC efémeras, para o que utiliza
os parâmetros de domínio normalizados indicados no certi­
ficado do cartão. O par de chaves efémeras é indicado como
(VU.SK eph , VU.PK eph , Card.DP). A VU recebe como iden­
tificação da chave da coordenada X do ponto público efé­
mero ECDH. Trata-se da «representação compactada da
chave pública» indicada como Comp(VU.PK eph ).
▼M1
CSM_165 Se o comando MSE: Set AT tiver êxito, o cartão define o
VU.PK indicado, para utilização posterior durante a auten­
ticação do veículo, e memoriza temporariamente
Comp(VU.PKeph). Caso dois ou mais comandos MSE:
Set AT com êxito sejam enviados antes de ser efetuada a
concordância de chave de sessão, o cartão memoriza apenas
o último Comp(VU.PKeph) recebido. O cartão reinicializa
Comp(VU.PKeph) após um comando GENERAL AUT­
HENTICATE bem-sucedido.
▼B
CSM_166 O cartão verifica a validade temporal de todos os certifica­
dos apresentados pela VU ou referenciados pela VU, en­
quanto são memorizados na memória do cartão, e rejeita os
certificados expirados.
CSM_167 Para verificar a validade temporal do certificado apresentado
pela VU, cada cartão tacográfico memoriza internamente
alguns dados que representam a hora atual. Estes dados
não são diretamente atualizáveis por uma VU. Na emissão,
a hora atual de um cartão deve ser igual à data de vigência
do certificado Card_MA do cartão. Um cartão atualiza a sua
hora se a data de vigência de um certificado «fonte de
tempo válida» autêntico apresentado por uma VU for mais
recente do que a hora atual do cartão. Nesse caso, o cartão
define a sua hora atual para a data de vigência desse certi­
ficado. Como fonte de tempo válida, o cartão aceita apenas
os seguintes certificados:
— Certificados de ligação ERCA da segunda geração
— Certificados MSCA da segunda geração
— Certificados de VU da segunda geração emitidos pelo
mesmo país do próprio certificado dos cartões.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 478
Nota: O último requisito implica que um cartão seja capaz
de reconhecer a CAR do certificado de VU, ou seja, o
certificado MSCA_VU-EGF. Este não será o mesmo que
a CAR do seu próprio certificado, que é o certificado
MSCA_Card.
CSM_168 Conforme indica o esquema 5, assim que o cartão tiver
verificado a autenticidade e a validade de um certificado
anteriormente desconhecido, pode memorizá-lo para referên­
cia futura, de tal modo que não precisa de verificar nova­
mente a autenticidade do certificado se este voltar a ser-lhe
apresentado. Em vez de memorizar todo o certificado, o
cartão pode optar por memorizar apenas o conteúdo do
corpo, em conformidade com a secção 9.3.2.
10.3. Autenticação da VU
CSM_169 As unidades-veículo e os cartões utilizam o protocolo de
autenticação da VU descrito no esquema 6 para autenticar a
VU em relação ao cartão. A autenticação da VU permite
que o cartão tacográfico verifique explicitamente se a VU é
autêntica. Para isso, a VU utiliza a sua chave privada para
assinar um desafio criado pelo cartão.
CSM_170 ►M1 Ao lado do desafio do cartão, a VU inclui na assi­
natura a referência do titular do certificado retirada do cer­
tificado do cartão. ◄
Nota: Garante-se assim que o cartão no qual a VU se au­
tentica é o mesmo cuja cadeia de certificados a VU verifi­
cou anteriormente.
CSM_171 A VU inclui igualmente na assinatura o identificador da
chave pública efémera Comp(VU.PK eph ) que a VU utiliza
para configurar o envio seguro de mensagens durante o
processo de autenticação de pastilha especificado na sec­
ção 10.4.
Nota: Garante-se assim que a VU com a qual o cartão
comunica durante uma sessão de envio seguro de mensa­
gens é a mesma que foi autenticada pelo cartão.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 479
Esquema 6
Protocolo de autenticação da VU
▼B
CSM_172 Se, durante a sua autenticação, a VU enviar vários coman­
dos GET CHALLENGE, o cartão devolve um novo desafio
aleatório de 8 bytes, de cada vez, mas memoriza apenas o
último desafio.
CSM_173 O algoritmo de assinatura utilizado pela VU para autentica­
ção é ECDSA, em conformidade com DSS, que utiliza o
algoritmo de hash ligado ao tamanho da chave do par de
chaves VU_MA da VU, em conformidade com o requisito
CSM_50. O formato de assinatura será simples, em confor­
midade com a Orientação Técnica TR-03111. A VU envia
ao cartão a assinatura obtida.
▼M1
CSM_174 Ao receber a assinatura da VU no comando EXTERNAL
AUTHENTICATE, o cartão
— Calcula o testemunho de autenticação mediante a con­
catenação Card.CHR, o desafio do cartão rcard e o
identificador da chave pública efémera da VU
Comp(VU.PKeph),
— Verifica a assinatura da VU utilizando o algoritmo
ECDSA, que utiliza o algoritmo de hash ligado ao ta­
manho da chave do par de chaves VU_MA da VU, em
conformidade com o requisito CSM_50, em combinação
com o VU.PK e o testemunho de autenticação
calculado.
▼M1
02016R0799 — PT — 21.08.2023 — 003.002 — 480
10.4. Autenticação da pastilha e concordância de chave de sessão
CSM_175 As unidades-veículo e os cartões utilizam o protocolo de
autenticação da pastilha descrito no esquema 7 para auten­
ticar o cartão em relação à VU. A autenticação da pastilha
permite que a unidade-veículo verifique explicitamente se o
cartão é autêntico.
Esquema 7
Autenticação da pastilha e acordo de chave de sessão
CSM_176 A VU e o cartão tomam as seguintes medidas:
1. A unidade-veículo inicia o processo de autenticação da
pastilha enviando o comando MSE: Set AT que indica
«autenticação da pastilha utilizando o algoritmo ECDH
que obtém um comprimento de chave de sessão AES
ligado ao tamanho da chave do par de chaves Card_MA
do cartão, em conformidade com o requisito CSM_50».
A VU determina o tamanho da chave do par de chaves
do cartão do certificado de cartão.
▼M1
2. A VU envia para o cartão o ponto público VU.PK eph do
seu par de chaves efémeras. O ponto público deve ser
convertido numa cadeia de octetos, em conformidade
com a Orientação Técnica TR-03111. Deve utilizar-se
o formato de codificação não compactado. Tal como
explicado em CSM_164, a VU criou esse par de chaves
efémeras antes da verificação da cadeia de certificado da
VU. A VU enviou o identificador da chave pública efé­
mera Comp(VU.PK eph ) para o cartão, que o memorizou.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 481
3. O cartão calcula Comp(VU.PK eph ) e compara o resultado
com o valor memorizado de Comp(VU.PK eph ).
4. O cartão calcula um k secreto, utilizando o algoritmo
ECDH em combinação com a chave privada estática
do cartão e a chave pública efémera da VU.
5. O cartão escolhe um valor de 8 bytes aleatórios N PICC e
utiliza-o para derivar duas chaves de sessão AES K MAC
e K ENC de K (ver CSM_179).
▼M1
6. Utilizando K MAC , o cartão calcula um testemunho de
autenticação sobre o identificador de ponto público efé­
mero da VU: T PICC = CMAC(K MAC , VU.PK eph ). O
ponto público deve revestir o formato utilizado pela
VU (ver ponto 2 supra). O cartão envia N PICC e T PICC
para a unidade-veículo.
▼B
7. À semelhança do que o cartão fez no passo 4, a VU
calcula um k secreto, utilizando o algoritmo ECDH em
combinação com a chave pública estática do cartão e a
chave privada efémera da VU.
8. A VU deriva chaves de sessão K MAC e K ENC de K e
N PICC (ver CSM_179).
9. A VU verifica o testemunho de autenticação T PICC .
CSM_177 No passo 3, o cartão calcula Comp(VU.PKeph) como ab­
cissa do ponto público em VU.PKeph.
CSM_178 Nos passos 4 e 7, o cartão e a unidade-veículo utilizam o
algoritmo ECKA-EG definido na Orientação Técnica
TR-03111.
CSM_179 Nos passos 5 e 8, o cartão e a unidade-veículo utilizam a
função de derivação da chave para as chaves de sessão AES
definidas na Orientação Técnica TR-03111, com as seguin­
tes precisões e alterações:
— O valor do contador é «00 00 00 01» para K ENC e «00
00 00 02» para K MAC.
— O valor aleatório opcional r é utilizado e igual a N PICC.
— Para derivar chaves AES de 128 bits, o algoritmo de
hash a utilizar é SHA-256.
— Para derivar chaves AES de 192 bits, o algoritmo de
hash a utilizar é SHA-384.
— Para derivar chaves AES de 256 bits, o algoritmo de
hash a utilizar é SHA-512.
O comprimento das chaves de sessão (ou seja, o compri­
mento a que o hash é truncado) é ligado ao tamanho do par
de chaves Card_MA, em conformidade com o requisito
CSM_50.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 482
CSM_180 Nos passos 6 e 9, o cartão e a unidade-veículo utilizam o
algoritmo AES no modo CMAC, em conformidade com SP
800-38B. O comprimento de T PICC está ligado ao compri­
mento das chaves de sessão AES, em conformidade com o
requisito CSM_50.
10.5. Envio seguro de mensagens
10.5.1 Generalidades
CSM_181 Todos os comandos e respostas intercambiados entre uma
unidade-veículo e um cartão tacográfico, após uma autenti­
cação da pastilha com êxito e até ao fim da sessão, estão
protegidos pelo envio seguro de mensagens.
CSM_182 Exceto quando da leitura de um ficheiro com condição de
acesso SM-R-ENC-MAC-G2 (ver apêndice 2, secção 4), o
envio seguro de mensagens é utilizado no modo «apenas
autenticação», no qual é adicionada uma soma criptográfica
de teste (a.k.a. MAC) a todos os comandos e respostas para
garantir a autenticidade e a integridade das mensagens.
CSM_183 Ao ler dados de um ficheiro com condição de acesso SM-R-
-ENC-MAC-G2, o envio seguro de mensagens é utilizado no
modo «encriptar depois autenticar», ou seja, os dados de
resposta são encriptados primeiro para garantir a confiden­
cialidade da mensagem, e em seguida é calculado um MAC
sobre os dados encriptados formatados, para garantir a au­
tenticidade e a integridade.
CSM_184 O envio seguro de mensagens utiliza AES, definido em
AES, com as chaves de sessão K MAC e K ENC acordadas
durante a autenticação da pastilha.
CSM_185 De modo a evitar ataques de reprodução, utiliza-se um nú­
mero inteiro não assinado como o contador de sequências
de envio (SSC). O tamanho do SSC é igual ao tamanho do
bloco AES, ou seja, 128 bits. O SSC está no formato de
primeiro MSB. O contador de sequências de envio é inicia­
lizado a zero (ou seja, «00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00») quando se iniciar o envio seguro de
mensagens. O SSC aumenta sempre antes de ser criado
um comando ou resposta APDU; ou seja, uma vez que o
valor de início do SSC numa sessão SM é 0, no primeiro
comando o valor do SSC será 1. O valor do SSC para a
primeira resposta será 2.
CSM_186 No que se refere a encriptação de mensagens, utiliza-se
K ENC com AES no modo de funcionamento por cifragem
progressiva (CBC), definido na norma ISO 10116, com um
parâmetro intercalar m = 1 e um vetor de inicialização SV =
E (K ENC , SSC), ou seja, o valor atual do contador de se­
quências de envio encriptado com K ENC .
CSM_187 Relativamente à autenticação de mensagens, utiliza-se
K MAC com AES no modo CMAC, em conformidade com
SP 800-38B. O comprimento do MAC está ligado ao com­
primento das chaves de sessão AES, em conformidade com
o requisito CSM_50. O contador de sequências de envio
estará incluído no MAC, prefixando-o antes da autenticação
do datagrama.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 483
10.5.2 Estrutura do envio seguro de mensagens
CSM_188 O envio seguro de mensagens faz uso apenas dos objetos de
dados do envio seguro de mensagens (ver norma ISO 7816-
-4) enumerados no quadro 5. Estes objetos de dados serão
utilizados em todas as mensagens, segundo a ordem espe­
cificada neste quadro.
Quadro 5
Objetos de dados do envio seguro de mensagens
Nome do objeto de dados Marcador
Presença (O)brigatória, (C)­
ondicional ou (P)roibida:
Comandos Respostas
Valor simples não codificado em
BER-TLV
«81» C C
Valor simples codificado em
BER-TLV, mas que não inclui SM DO
«B3» C C
Indicador de conteúdo de preenchi­
mento seguido por criptograma, valor
simples não codificado em BER-TLV
«87» C C
Le protegido «97» C F
Estado de processamento «99» F M
Soma criptográfica de teste «8E» M M
Nota: Em conformidade com o apêndice 2, os cartões taco­
gráficos podem aceitar os comandos READ BINARY e
UPDATE BINARY com um byte INS ímpar (respetiva­
mente, «B1» e «D7»). Estas variantes de comando são ne­
cessárias para ler e atualizar os ficheiros com 32 768 bytes
ou mais. Caso se recorra a tal variante, utiliza-se um objeto
de dados com o marcador «B3» em vez de um objeto com
marcador «81» (ver apêndice 2 para mais informações).
CSM_189 Todos os objetos de dados SM são codificados em DER
TLV, em conformidade com a norma ISO 8825-1. Esta
codificação resulta numa estrutura Marcador-Comprimento-
-Valor (TLV), nos seguintes termos:
Marcador: O marcador está codificado em um ou dois
octetos e indica o conteúdo.
Comprimento: O comprimento é codificado como número
inteiro não assinado, em um, dois ou três
octetos, que resultam num comprimento má­
ximo de 65 535 octetos. Utiliza-se o número
mínimo de octetos.
Valor: O valor é codificado em zero ou mais
octetos.
CSM_190 As APDU protegidas pelo envio seguro de mensagens são
criadas do seguinte modo:
— O cabeçalho de comando é incluído no cálculo do
MAC; por conseguinte, utiliza-se o valor «0C» para o
CLA do byte de classe.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 484
— Em conformidade com o apêndice 2, todos os bytes INS
são pares, com a possível exceção de bytes INS ímpares
para os comandos READ BINARY e UPDATE BI­
NARY.
— O valor real de Lc é modificado para Lc após a aplica­
ção do envio seguro de mensagens.
— O campo de dados é composto por objetos de dados
SM.
— Na APDU de comando protegido, o novo byte Le é
colocado no valor «00». Se necessário, inclui-se um
objeto de dados «97» no campo de dados, a fim de
transmitir o valor original de Le.
▼M1
CSM_191 Qualquer objeto de dados a encriptar é preenchido de
acordo com a norma ISO 7816-4, mediante a utilização
do indicador de conteúdo de preenchimento «01». Relativa­
mente ao cálculo do MAC, os objetos de dados na APDU
são preenchidos de acordo com a norma ISO 7816-4.
Nota: O preenchimento para envio seguro de mensagens é
efetuado sempre pelo nível de envio seguro de mensagens e
não pelos algoritmos CMAC ou CBC.
Síntese e exemplos
Uma APDU de comando com envio seguro de mensagens aplicado terá a
estrutura seguinte, consoante a caixa do comando não seguro correspon­
dente (DO é objeto de dados):
Caixa 1: CLA INS P1 P2 || Lc' || DO ‘8E’ || Le
Caixa 2: CLA INS P1 P2 || Lc' || DO ‘97’ || DO ‘8E’
|| Le
Caixa 3 (byte INS par): CLA INS P1 P2 || Lc' || DO ‘81’ || DO ‘8E’
|| Le
Caixa 3 (byte INS ímpar): CLA INS P1 P2 || Lc' || DO ‘B3’ || DO ‘8E’
|| Le
Caixa 4 (byte INS par): CLA INS P1 P2 || Lc' || DO ‘81’ || DO ‘97’
|| DO ‘8E’ || Le
Caixa 4 (byte INS ímpar): CLA INS P1 P2 || Lc' || DO ‘B3’ || DO ‘97’
|| DO ‘8E’ || Le
onde Le = ‘00’ ou ‘00 00’, consoante se utilizem campos de comprimento
curto ou campos de comprimento alargado; ver norma ISO 7816-4.
Uma APDU de resposta, com envio seguro de mensagens aplicado, tem a
seguinte estrutura, consoante a caixa do comando não seguro correspon­
dente (DO é objeto de dados):
Caixa 1 ou 3: DO ‘99’ || DO ‘8E’ ||
SW1SW2
Caixa 2 ou 4 (byte INS par) sem
encriptação: DO ‘81’ || DO ‘99’ || DO
‘8E’ || SW1SW2
Caixa 2 ou 4 (byte INS par)
com encriptação: DO ‘87’ || DO ‘99’ || DO
‘8E’ || SW1SW2
Caixa 2 ou 4 (byte INS ímpar) sem
encriptação:
DO ‘B3’ || DO ‘99’ || DO
‘8E’ || SW1SW2
Nota: A caixa 2 ou 4 (byte INS ímpar) com encriptação nunca é utilizada
na comunicação entre uma VU e um cartão.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 485
Seguem-se três exemplos de transformações da APDU para comandos
com código INS par. O esquema 8 apresenta uma APDU de comando da
caixa 4 autenticada, o esquema 9 apresenta uma APDU de resposta da
caixa 1/caixa 3 autenticada e o esquema 10 apresenta uma APDU de
resposta da caixa 2/caixa 4 encriptada e autenticada.
Esquema 8
Transformação de uma APDU de comando da caixa 4 autenticada
Esquema 9
Transformação de uma APDU de resposta da caixa 1/caixa 3 autenticada
▼M1
02016R0799 — PT — 21.08.2023 — 003.002 — 486
Esquema 10
Transformação de uma APDU de resposta da caixa 2/caixa 4
▼B
10.5.3 Interrupção da sessão de envio seguro de mensagens
CSM_192 A unidade-veículo interrompe uma sessão de envio seguro de
mensagens contínua se e só se ocorrer uma das seguintes
condições:
— recebe uma APDU de resposta simples
— deteta um erro de envio seguro de mensagens numa
APDU de resposta:
— está ausente um (esperado) objeto de dados do envio
seguro de mensagens, está incorreta a ordem dos ob­
jetos de dados ou está incluído um objeto de dados
desconhecido
— está incorreto um objeto de dados do envio seguro de
mensagens: por exemplo, o valor MAC está incorreto,
a estrutura TLV está incorreta ou o indicador de
preenchimento no marcador «87» não é igual a «01»
— o cartão envia um tipo de estado a indicar que detetou um
erro SM (ver CSM_194)
— é atingido o limite para o número de comandos e respos­
tas associados na sessão atual. Em relação a uma deter­
minada VU, esse limite é definido pelo fabricante, tendo
em conta os requisitos de segurança do equipamento in­
formático utilizado, com um valor máximo de 240 coman­
dos SM e respostas associadas por sessão.
▼M1
02016R0799 — PT — 21.08.2023 — 003.002 — 487
CSM_193 O cartão tacográfico interrompe uma sessão de envio seguro
de mensagens contínua se e só se ocorrer uma das seguintes
condições:
— recebe uma APDU de comando simples,
— deteta um erro de envio seguro de mensagens numa
APDU de comando:
— está ausente um (esperado) objeto de dados do envio
seguro de mensagens, está incorreta a ordem dos ob­
jetos de dados ou está incluído um objeto de dados
desconhecido,
— está incorreto um objeto de dados do envio seguro de
mensagens: por exemplo, o valor MAC está incorreto
ou a estrutura TLV está incorreta,
— é desligado da energia elétrica ou reinicializado,
— a VU inicia o processo da sua autenticação,
— é atingido o limite para o número de comandos e respos­
tas associados na sessão atual. Em relação a um determi­
nado cartão, esse limite é definido pelo fabricante, tendo
em conta os requisitos de segurança do equipamento in­
formático utilizado, com um valor máximo de 240 coman­
dos SM e respostas associadas por sessão.
▼B
CSM_194 Em relação ao tratamento de erros SM por um cartão taco­
gráfico:
— o cartão tacográfico responde com os bytes de estatuto
«69 87» se estiverem ausentes alguns objetos de dados
de envio seguro de mensagens numa APDU de comando,
se estiver incorreta a ordem dos objetos de dados ou se
estiverem incluídos objetos de dados desconhecidos
— o cartão tacográfico responde com bytes de estatuto «69
88» se um objeto de dados de envio seguro de mensagens
estiver incorreto numa APDU de comando.
Em tal caso, os bytes de estatuto são devolvidos sem utilizar
SM.
CSM_195 Se uma sessão de envio seguro de mensagens entre uma VU
e um cartão tacográfico for interrompida, a VU e o cartão
tacográfico:
— destroem as chaves de sessão memorizadas com segu­
rança
— estabelecem imediatamente uma nova sessão de envio
seguro de mensagens, conforme referido nas secções
10.2 a 10.5.
CSM_196 Se, por qualquer motivo, a VU decidir reiniciar a autenticação
mútua em relação a um cartão inserido, o processo reinicia-se
com a verificação da cadeia de certificado do cartão, con­
forme referido na secção 10.2, continuando como referido
nas secções 10.2 a 10.5.
▼M1
02016R0799 — PT — 21.08.2023 — 003.002 — 488
11. ACOPLAMENTO, AUTENTICAÇÃO MÚTUA E ENVIO SEGURO
DE MENSAGENS DO MÓDULO GNSS EXTERNO COM A VU
11.1. Generalidades
CSM_197 O módulo GNSS utilizado por uma VU para determinar a sua
posição pode ser interno (ou seja, incorporado na caixa da
VU e não desmontável) ou externo. No primeiro caso, não há
necessidade de uniformizar as comunicações internas entre o
módulo GNSS e a VU, não se aplicando os requisitos do
presente capítulo. No segundo caso, as comunicações entre
a VU e o módulo GNSS externo são uniformizadas e prote­
gidas, conforme descrito no presente capítulo.
CSM_198 A comunicação segura entre uma unidade-veículo e um mó­
dulo GNSS externo deve ter lugar do mesmo modo que a
comunicação segura entre uma unidade-veículo e um cartão
tacográfico, assumindo o módulo GNSS externo (EGF) o
papel do cartão. Todos os requisitos do capítulo 10, relativos
aos cartões tacográficos, são cumpridos por um EGF, tendo
em conta os desvios, os esclarecimentos e os aditamentos do
presente capítulo. Nomeadamente, a verificação mútua da ca­
deia de certificados, a autenticação da VU e a autenticação da
pastilha são efetuadas conforme descrito nas secções 11.3 e
11.4.
CSM_199 A comunicação entre uma unidade-veículo e um EGF difere
da comunicação entre uma unidade-veículo e um cartão, na
medida em que, antes de poderem intercambiar dados com
recurso a GNSS durante o funcionamento normal, uma VU e
um EGF têm primeiro de ser acoplados numa oficina. O
processo de acoplamento é descrito na secção 11.2.
CSM_200 Para a comunicação entre uma VU e um EGF, utilizam-se os
comandos e respostas APDU baseados nas normas ISO 7816-
-4 e ISO 7816-8. A estrutura exata destas APDU é definida no
apêndice 2 do presente anexo.
11.2. Acoplamento da VU e do módulo GNSS externo
CSM_201 O acoplamento da unidade-veículo com o EGF num veículo é
efetuado por uma oficina. Apenas uma unidade-veículo e um
EGF acoplados estão capacitados para comunicar durante o
funcionamento normal.
CSM_202 O acoplamento de uma unidade-veículo e de um EGF só é
possível se a unidade-veículo estiver em modo de calibração.
O acoplamento deve ser iniciado pela unidade-veículo.
CSM_203 Uma oficina pode, a qualquer momento, reacoplar uma
unidade-veículo a outro EGF ou ao mesmo EGF. Durante o
reacoplamento, a VU destrói, de modo seguro, o certificado
EGF_MA existente na sua memória e memoriza o certificado
EGF_MA do EGF ao qual está a ser acoplada.
CSM_204 Uma oficina pode, a qualquer momento, reacoplar um módulo
GNSS externo a outra VU ou à mesma VU. Durante o reaco­
plamento, o EGF destrói, de modo seguro, o certificado
VU_MA existente na sua memória e memoriza o certificado
VU_MA da VU à qual está a ser acoplado.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 489
11.3. Verificação mútua da cadeia de certificados
11.3.1 Generalidades
CSM_205 A verificação mútua da cadeia de certificados entre uma VU e
um EGF é efetuada por uma oficina e apenas durante o
acoplamento da VU ao EGF. Durante o funcionamento nor­
mal de uma VU e um EGF acoplados, não se verificam
certificados. Em vez disso, a VU e o FEG aprovam os cer­
tificados que memorizaram durante o acoplamento, após ve­
rificação da validade temporal desses certificados. Durante o
funcionamento normal, a VU e o EGF não aprovam quaisquer
outros certificados, de modo a proteger as comunicações entre
a VU e o EGF.
11.3.2 Durante o acoplamento VU-EGF
CSM_206 Durante o acoplamento a um EGF, a unidade-veículo utiliza o
protocolo descrito no esquema 4 (secção 10.2.1) para verifi­
cação da cadeia de certificados do módulo GNSS externo.
Notas do esquema 4 neste contexto:
— O controlo das comunicações está fora do âmbito do pre­
sente apêndice. No entanto, um EGF não é um cartão
inteligente, pelo que, provavelmente, a VU não envia
uma reinicialização para iniciar a comunicação nem re­
cebe um ATR.
— Os certificados de cartão e as chaves públicas menciona­
dos no esquema são interpretados como os certificados e
chaves públicas do EGF para autenticação mútua. A sec­
ção 9.1.6 indica-os como EGF_MA.
— Os certificados Card.CA e as chaves públicas menciona­
dos no esquema são interpretados como os certificados e
chaves públicas de MSCA para assinatura de certificados
EGF. A secção 9.1.3 indica-os como MSCA_VU-EGF.
— O certificado Card.CA.EUR mencionado no esquema é
interpretado como o certificado de raiz europeia indicado
na CAR do certificado MSCA_VU-EGF.
— O certificado Card.Link mencionado no esquema é inter­
pretado como o certificado de ligação do EGF, caso
exista. Em conformidade com a secção 9.1.2, trata-se de
um certificado de ligação para um novo par de chaves de
raiz europeia criado pela ERCA e assinado pela chave
privada europeia anterior.
— O certificado Card.Link.EUR é o certificado de raiz eu­
ropeia indicado na CAR do certificado Card.Link.
— Em vez de , a VU lê
de EF ICC.
— Em vez de selecionar o AID do tacógrafo, a VU seleciona
o AID EGF.
— «Ignorar cartão» deve ser interpretado como «Ignorar
EGF».
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 490
CSM_207 Após verificar o certificado EGF_MA, a VU memoriza-o para
utilização durante o funcionamento normal (ver secção
11.3.3).
CSM_208 Durante o acoplamento a uma VU, o módulo GNSS externo
utiliza o protocolo descrito no esquema 5 (secção 10.2.2) para
verificação da cadeia de certificados da VU.
Notas do esquema 5 neste contexto:
— A VU cria um novo par de chaves efémeras com recurso
aos parâmetros de domínio no certificado EGF.
— Os certificados de VU e as chaves públicas mencionados
no esquema são os destinados à autenticação mútua. A
secção 9.1.4 indica-os como VU_MA.
— Os certificados VU.CA e as chaves públicas mencionados
no esquema são os destinados à assinatura dos certificados
da VU e do módulo GNSS externo. A secção 9.1.3
indica-os como MSCA_VU-EGF.
— O certificado VU.CA.EUR mencionado no esquema é o
certificado de raiz europeia indicado na CAR do certifi­
cado VU.CA.
— O certificado VU.Link mencionado no esquema é o cer­
tificado de ligação da VU, caso exista. Em conformidade
com a secção 9.1.2, trata-se de um certificado de ligação
para um novo par de chaves de raiz europeia criado pela
ERCA e assinado pela chave privada europeia anterior.
— O certificado VU.Link.EUR é o certificado de raiz euro­
peia indicado na CAR do certificado VU.Link.
CSM_209 Em desvio do requisito CSM_167, um EGF utiliza a hora
GNSS para verificação da validade temporal dos certificados
apresentados.
CSM_210 Após verificar o certificado VU_MA, o módulo GNSS ex­
terno memoriza-o para utilização durante o funcionamento
normal (ver secção 11.3.3).
11.3.3 Durante o funcionamento normal
CSM_211 ►M1 Durante o funcionamento normal, uma unidade-veículo
e um EGF utilizam o protocolo descrito no esquema 11 para
verificar a validade temporal do certificado EGF_MA memori­
zado e para definir a chave pública VU_MA para autenticação
subsequente da VU. Durante o funcionamento normal, não têm
lugar verificações mútuas adicionais do certificado. ◄
Importa lembrar que o esquema 11 consiste essencialmente
nos primeiros passos apresentados no esquema 4 e no es­
quema 5. Importa lembrar ainda que, como um EGF não é
um cartão inteligente, a VU provavelmente não envia uma
reinicialização para iniciar a comunicação nem recebe um
ATR. De qualquer modo, o controlo das comunicações está
fora do âmbito do presente apêndice.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 491
Esquema 11
Verificação mútua da validade temporal do certificado durante o funcionamento normal da VU com o EGF
CSM_212 Como mostra o esquema 11, se o certificado EGF_MA já não
for válido, a unidade-veículo regista um erro. No entanto, a
autenticação mútua, a concordância de chave e as comunica­
ções subsequentes através do envio seguro de mensagens
continuam normalmente.
11.4. Autenticação da VU, autenticação da pastilha e concordância de
chave de sessão
CSM_213 A autenticação da VU, a autenticação da pastilha e a concor­
dância de chave de sessão entre uma VU e um EGF ocorrem
durante o acoplamento ou sempre que, durante o funciona­
mento normal, seja restabelecida uma sessão de envio seguro
de mensagens. A VU e o EGF executam os processos des­
critos nas secções 10.3 e 10.4. Aplicam-se todos os requisitos
constantes das presentes secções.
11.5. Envio seguro de mensagens
CSM_214 Todos os comandos e respostas intercambiados entre uma
unidade-veículo e um módulo GNSS externo, após uma au­
tenticação da pastilha com êxito e até ao fim da sessão, estão
protegidos pelo envio seguro de mensagens no modo «apenas
autenticação». Aplicam-se todos os requisitos da secção 10.5.
CSM_215 Se uma sessão de envio seguro de mensagens entre a VU e o
EGF for interrompida, a VU estabelece imediatamente uma
nova sessão de envio seguro de mensagens, conforme se des­
creve nas secções 11.3.3 e 11.4.
12. Emparelhamento e comunicações do sensor de movimentos com a VU
12.1. Generalidades
CSM_216 Durante o emparelhamento e o funcionamento normal,
a unidade-veículo e o sensor de movimentos comunicam uti­
lizando o protocolo de interface especificado na norma
ISO 16844-3, com as alterações descritas no presente capítu­
lo e na secção 9.2.1.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 492
Nota: presume-se que os leitores deste capítulo estão familia­
rizados
com o conteúdo da norma ISO 16844-3.
12.2. Emparelhamento do sensor de movimentos com a VU, utilizando
gerações de chaves diferentes
Conforme explicado na secção 9.2.1, a chave de segurança do sensor de
movimentos e todas as chaves associadas são substituídas periodica­
mente, o que pode conduzir a que, nos cartões de oficina, haja três
chaves AES relativas ao sensor de movimentos K M-WC (de gerações de
chaves consecutivas). De modo semelhante, pode haver nos sensores de
movimentos até três encriptações de dados diferentes com recurso a AES
(baseadas em gerações consecutivas da chave de segurança do sensor de
movimentos K M ). Uma unidade-veículo contém apenas uma chave rela­
tiva ao sensor de movimentos K M-VU.
CSM_217 A VU da segunda geração e o sensor de movimentos da
segunda geração estão emparelhados do seguinte modo (com­
parar quadro 6 da norma ISO 16844-3):
1. O cartão de oficina da segunda geração é inserido na VU e
a VU está ligada ao sensor de movimentos.
2. A VU lê todas as chaves K M-WC disponíveis do cartão de
oficina, inspeciona os respetivos números de versão de
chave e escolhe a que corresponde ao número de versão
de chave da VU K VU-M . Se no cartão de oficina não existir
a correspondente chave K M-WC , a VU interrompe o pro­
cesso de emparelhamento e apresenta uma mensagem de
erro apropriada ao titular do cartão de oficina.
3. A VU calcula a chave de segurança do sensor de movi­
mentos K M de K M-VU e K M-WC , bem como a chave de
identificação K ID de K M , em conformidade com a secção
9.2.1.
4. A VU envia a instrução para iniciar o processo de empa­
relhamento em relação ao sensor de movimentos, con­
forme consta da norma ISO 16844-3, e encripta o número
de série que recebe do sensor de movimentos com a chave
de identificação K ID . A VU envia ao sensor de movimen­
tos o número de série encriptado.
5. O sensor de movimentos faz corresponder o número de
série encriptado consecutivamente com cada uma das en­
criptações do número de série que possui internamente. Se
encontrar correspondência, a VU é autenticada. O sensor
de movimentos regista a geração de K ID utilizado pela VU
e devolve a correspondente versão encriptada da sua chave
de emparelhamento, ou seja, a encriptação criada com
utilização da mesma geração de K M .
6. A VU decifra a chave de emparelhamento utilizando K M ,
cria uma chave de sessão K S , encripta-a com a chave de
emparelhamento e envia o resultado para o sensor de mo­
vimentos. O sensor de movimentos decifra K S .
7. A VU reúne as informações de emparelhamento, conforme
a norma ISO 16844-3 define, encripta as informações com
a chave de emparelhamento e envia o resultado para o
sensor de movimentos. O sensor de movimentos decifra
as informações de emparelhamento.
8. O sensor de movimentos encripta as informações de em­
parelhamento recebidas com o K S recebido e devolve-o à
VU. A VU verifica se as informações de emparelhamento
são as mesmas informações que enviou para o sensor de
movimentos no passo anterior. Em caso afirmativo,
prova-se que o sensor de movimentos utilizou
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 493
o mesmo K S que a VU e, portanto, no passo 5 enviou a
sua chave de emparelhamento encriptada com a geração
correta de K M . Assim, o sensor de movimentos é
autenticado.
De salientar que os passos 2 e 5 são diferentes dos do pro­
cesso uniformizado constante da norma ISO 16844-3. Os
outros passos estão uniformizados.
Exemplo: Suponhamos que um emparelhamento ocorre no
primeiro ano de validade do certificado ERCA (3) (ver es­
quema 2 na secção 9.2.1.2). Além disso,
— Suponhamos que o sensor de movimentos foi emitido no
último ano de validade do certificado ERCA (1). Por
conseguinte, conterá os seguintes dados e chaves:
— N s [1]: número de série encriptado com a geração 1 de
K ID
— N s [2]: número de série encriptado com a geração 2 de
K ID
— N s [3]: número de série encriptado com a geração 3 de
K ID
— K P [1]: chave de emparelhamento da geração 1 ( 1 ), en­
criptada com a geração 1 de K M
— K P [2]: chave de emparelhamento da geração 2, encrip­
tada com a geração 2 de K M
— K P [3]: chave de emparelhamento da geração 3, encrip­
tada com a geração 3 de K M .
— Suponhamos que o cartão de oficina foi emitido no primeiro
ano de validade do certificado ERCA (3). Por conseguinte,
conterá a geração 2 e a geração 3 da chave K M-WC .
— Suponhamos que a VU é uma VU da geração 2, que
contém a geração 2 de K M-VU .
Neste caso, acontecerá o seguinte nos passos 2 a 5:
— Passo 2: a VU lê a geração 2 e a geração 3 de K M-WC do
cartão de oficina e inspeciona os respetivos números de
versão.
— Passo 3: a VU combina a geração 2 de K M-WC com o seu
K VU-M para calcular K M e K ID .
— Passo 4: a VU encripta o número de série que recebe do
sensor de movimentos com K ID .
— Passo 5: o sensor de movimentos compara os dados re­
cebidos com N s [1] e não encontra correspondências. Em
seguida, compara os dados com N s [2] e encontra uma
correspondência. Conclui que a VU é uma VU da gera­
ção 2 e, por conseguinte, devolve K P [2].
▼B
( 1 ) De salientar que as chaves de emparelhamento da geração 1, da geração 2 e da geração 3
podem, na realidade, ser a mesma chave. Ou pode haver três chaves diferentes com
comprimentos diferentes, conforme se explica no requisito CSM_117.
02016R0799 — PT — 21.08.2023 — 003.002 — 494
12.3. Emparelhamento e comunicações do sensor de movimentos com a
VU utilizando AES
CSM_218 Em conformidade com o quadro 3 na secção 9.2.1, todas as
chaves envolvidas no emparelhamento de uma
unidade-veículo (da segunda geração) com um sensor de mo­
vimentos e nas comunicações subsequentes devem ser chaves
AES, em vez de chaves de comprimento duplo TDES, nos
termos da norma ISO 16844-3. Estas chaves AES podem ter
um comprimento de 128, 192 ou 256 bits. Como o tamanho
do bloco AES é de 16 bytes, o comprimento de uma mensa­
gem encriptada é um múltiplo de 16 bytes, em comparação
com 8 bytes para TDES. Além disso, algumas destas mensa­
gens são utilizadas para transmitir chaves AES, cujo compri­
mento pode ser de 128, 192 ou 256 bits. Por conseguinte, o
número de bytes de dados por instrução, constantes do qua­
dro 5 da norma ISO 16844-3, é alterado como mostra o
quadro 6:
▼M1
Quadro 6
Número de bytes de dados de texto simples e encriptados por instrução definida na norma ISO 16844-3
Instruções
Pedido / res­
posta
Descrição dos dados
N. o de bytes de da­
dos de texto simples,
de acordo com
a norma ISO
16844-3
N. o de bytes de da­
dos de texto simples
que utilizam chaves
AES
N. o de bytes de dados encrip­
tados ao utilizar chaves AES
com comprimento em bits
128 192 256
10 Pedido Dados de autentica­
ção + número de fi­
cheiro
8 8 16 16 16
11 Resposta Dados de autentica­
ção + conteúdo do fi­
cheiro
16 ou 32, con­
soante o ficheiro
16 or32 consoante
o ficheiro
32 / 48 32 / 48 32 / 48
41 Pedido Número de série MoS 8 8 16 16 16
41 Resposta Chave de emparelha­
mento
16 16 / 24 / 32 16 32 32
42 Pedido Chave de sessão 16 16 / 24 / 32 16 32 32
43 Pedido Informações do em­
parelhamento
24 24 32 32 32
50 Resposta Informações do em­
parelhamento
24 24 32 32 32
70 Pedido Dados de autentica­
ção
8 8 16 16 16
80 Resposta Valor do contador
MoS + dados autenti­
cados
8 8 16 16 16
▼B
CSM_219 As informações de emparelhamento enviadas nas instruções
43 (pedido da VU) e 50 (resposta MoS) são reunidas em
conformidade com a secção 7.6.10 da norma ISO 16844-3,
com exceção do algoritmo AES, que é utilizado em vez do
algoritmo TDES no esquema de encriptação de dados de
emparelhamento, resultando assim em duas encriptações
AES e na adoção do preenchimento especificado no requisito
CSM_220 para se adaptar ao tamanho do bloco AES. A
chave K' p para esta encriptação é criada da seguinte forma:
— Se a chave de emparelhamento K P tiver 16 bytes de com­
primento: K' p = K P XOR (N s ||N s )
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 495
— Se a chave de emparelhamento K P tiver 24 bytes de com­
primento: K' p = K P XOR (N s ||N s ||N s )
— Se a chave de emparelhamento K P tiver 32 bytes de com­
primento: K' p = K P XOR (N s ||N s ||N s ||N s )
onde N s é o número de série do sensor de movimentos de 8
bytes.
CSM_220 Se o comprimento de dados de texto simples (que utiliza
chaves AES) não for múltiplo de 16 bytes, utiliza-se o mé­
todo de preenchimento 2, definido na norma ISO 9797-1.
Nota: Na norma ISO 16844-3, o número de bytes de dados
de texto simples é sempre um múltiplo de 8, de tal modo que
esse preenchimento não é necessário quando utiliza TDES. A
definição de dados e mensagens constante da norma
ISO 16844-3 não sofre alterações nesta parte do presente
apêndice, exigindo, portanto, a aplicação de preenchimento.
CSM_221 Relativamente à instrução 11 e no caso de mais de um bloco
de dados ter de ser encriptado, utiliza-se o modo de funcio­
namento por cifragem progressiva definido na norma
ISO 10116, com um parâmetro intercalar m = 1. É a seguinte
a IV a utilizar:
— Em relação à instrução 11: o bloco de autenticação de 8
bytes especificado na secção 7.6.3.3 da norma ISO 16844-
-3, com o método de preenchimento 2 definido na norma
ISO 9797-1 (ver também secções 7.6.5 e 7.6.6 da norma
ISO 16844-3).
— Em relação a todas as outras instruções nas quais são
transferidos mais de 16 bytes, em conformidade com o
quadro 6: «00» {16}, ou seja, 16 bytes com valor biná­
rio 0.
Nota: Como mostram as secções 7.6.5 e 7.6.6 da norma
ISO 16844-3, quando o MoS encripta ficheiros de dados
para inclusão na instrução 11, o bloco de autenticação é:
— utilizado como vetor de inicialização para a encriptação
do modo CBC dos ficheiros de dados
— encriptado e incluído como primeiro bloco nos dados en­
viados à VU.
12.4. Emparelhamento do sensor de movimentos com a VU, para diferen­
tes gerações de aparelhos
CSM_222 Conforme se explica na secção 9.2.1, o sensor de movimentos
da segunda geração pode conter a encriptação dos dados de
emparelhamento com recurso a TDES (definição na parte A
do presente apêndice), que permite ao sensor de movimentos
ser emparelhado com uma VU da primeira geração. Se for
este o caso, a VU da primeira geração e o sensor de movi­
mentos da segunda geração são emparelhados conforme des­
crito na parte A do presente apêndice e na norma ISO 16844-
-3. Relativamente ao processo de emparelhamento, pode
utilizar-se um cartão de oficina tanto da primeira geração
como da segunda.
Notas:
— Não é possível emparelhar uma VU da segunda geração
com um sensor de movimentos da primeira geração.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 496
— Não é possível utilizar um cartão de oficina da primeira
geração para o acoplamento de uma VU da segunda ge­
ração a um sensor de movimentos.
13. SEGURANÇA PARA COMUNICAÇÕES À DISTÂNCIA POR DSRC
13.1. Generalidades
Em conformidade com o apêndice 14, uma VU cria regularmente dados
relativos à monitorização tacográfica à distância (RTM) e envia-os ao
sistema (interno ou externo) de comunicação à distância (RCF). O sis­
tema de comunicação à distância tem a responsabilidade de enviar estes
dados pela interface DSRC descrita no apêndice 14 ao interrogador à
distância. O apêndice 1 prevê que os dados RTM são a concatenação de:
Carga útil encriptada do tacógrafo a encriptação em texto simples da
carga útil do tacógrafo
Dados de segurança DSRC descrição adiante
O formato de dados em texto simples da carga útil do tacógrafo é
especificado no apêndice 1 e descrito em pormenor no apêndice 14. A
presente secção descreve a estrutura dos dados de segurança DSRC. A
especificação formal é apresentada no apêndice 1.
CSM_223 Os dados de texto simples transmiti­
dos pela VU a um sistema de comunicação à distância (se o
RCF for externo à VU) ou da VU a um interrogador à dis­
tância pela interface DSRC (se o RCF for interno à VU) são
protegidos no modo «encriptar depois autenticar», ou seja, os
dados de carga útil do tacógrafo são encriptados primeiro para
garantir a confidencialidade da mensagem e, posteriormente, é
calculado um MAC para garantir a autenticidade e a integri­
dade dos dados.
CSM_224 Os dados de segurança DSRC são constituídos pela concate­
nação dos seguintes elementos de dados, pela ordem indicada
(ver também esquema 12):
Data e hora atuais data e hora atuais da VU (tipo de dados
)
Contador um contador de 3 bytes, ver CSM_225
▼M1
Número de série da VU número de série da VU ou ID de pedido de
certificado (tipo de dados VuSerialNumber ou
CertificateRequestID) – ver CSM_123
▼B
Número de versão da chave de segurança DSRC o número de versão de 1 byte da chave de
segurança DSRC da qual derivaram as chaves
DSRC específicas da VU (ver secção 9.2.2).
MAC o MAC calculado sobre todos os bytes ante­
riores nos dados RTM.
CSM_225 O contador de 3 bytes nos dados de segurança DSRC está no
formato de primeiro MSB. A primeira vez que uma VU
calcula um conjunto de dados RTM após entrar em produção,
fixa o valor do contador a 0. Sempre antes de calcular o
próximo conjunto de dados RTM, a VU aumenta de 1 valor
os dados do contador.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 497
13.2. Encriptação da carga útil do tacógrafo e criação de MAC
CSM_226 Dado um elemento de dados de texto simples com tipo de
dados , conforme descrição no
apêndice 14, uma VU encripta esses dados do modo ilustrado
no esquema 12: a chave DSRC da VU para encriptação
K_VU DSRC _ENC (ver secção 9.2.2) é utilizada com AES
no modo de funcionamento por cifragem
progressiva (CBC), definido na norma ISO 10116, com um
parâmetro intercalar m = 1. O vetor de inicialização é igual ao
IV = data e hora atual || «00 00 00 00 00 00 00 00 00» ||
contador, onde data e hora atual e contador são especifica­
dos no requisito CSM_224. Os dados a encriptar são preen­
chidos utilizando o método 2 definido na norma ISO 9797-1.
CSM_227 A VU calcula o MAC nos dados de segurança DSRC como
ilustra o esquema 12: o MAC é calculado sobre todos os
bytes precedentes nos dados RTM, até o número de versão
de chave de segurança DSRC, inclusive, e incluindo os mar­
cadores e comprimentos dos objetos de dados. A VU utiliza a
sua chave DSRC para autenticidade K_VU DSRC _MAC (ver
secção 9.2.2) com o algoritmo AES no modo CMAC, em
conformidade com SP 800-38B. O comprimento do MAC
está ligado ao comprimento das chaves DSRC específicas
da VU, em conformidade com o requisito CSM_50.
Esquema 12
Encriptação da carga útil do tacógrafo e criação do MAC
13.3. Verificação e decifragem da carga útil do tacógrafo
CSM_228 Quando um interrogador à distância recebe dados RTM de
uma VU, envia-os todos para um cartão de controlo no
campo de dados de um comando PROCESS DSRC MES­
SAGE, conforme descrito no apêndice 2. Logo:
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 498
1. O cartão de controlo inspeciona o número de versão da
chave de segurança nos dados de segurança DSRC. Se o
cartão de controlo não conhecer a chave de segurança
DSRC indicada, devolve um erro especificado no apên­
dice 2 e interrompe o processo.
▼M1
2. O cartão de controlo utiliza a chave de segurança DSRC
indicada em combinação com o número de série da VU ou
com o ID de pedido de certificado nos dados de segurança
DSRC, para derivar as chaves DSRC específicas da VU
K_VU DSRC _ENC e K_VU DSRC _MAC, em conformidade
com o requisito CSM_124.
▼B
3. O cartão de controlo utiliza K_VU DSRC _MAC para verifi­
car o MAC nos dados de segurança DSRC, em conformi­
dade com o requisito CSM_227. Se o MAC estiver incor­
reto, o cartão de controlo devolve um erro especificado no
apêndice 2 e interrompe o processo.
4. O cartão de controlo utiliza K_VU DSRC _ENC para decifrar
a carga útil encriptada do tacógrafo, em conformidade com
o requisito CSM_226. O cartão de controlo retira o preen­
chimento e devolve ao interrogador à distância os dados de
carga útil decifrados do tacógrafo.
CSM_229 A fim de evitar ataques de reprodução, o interrogador à dis­
tância verifica a atualização dos dados RTM, verificando se
as data e hora atuais nos dados de segurança DSRC não se
desviam muito da hora atual do interrogador à distância.
Notas:
— Esta verificação exige que o interrogador à distância tenha
uma fonte cronológica precisa e fiável.
— Como o apêndice 14 estabelece que a VU calcula um novo
conjunto de dados RTM a cada 60 segundos e o relógio da
VU pode desviar-se 1 minuto da hora real, o limite inferior
para a atualização dos dados RTM é de 2 minutos. A
atualização real a exigir depende igualmente da precisão
do relógio do interrogador à distância.
CSM_230 Quando uma oficina verifica o funcionamento correto da fun­
cionalidade DSRC de uma VU, envia todos os dados RTM
recebidos da VU para um cartão de oficina no campo de
dados de um comando PROCESS DSRC MESSAGE, con­
forme descrição no apêndice 2. O cartão de oficina realiza
todas as verificações e ações especificadas no requisito
CSM_228.
14. DESCARREGAMENTOS DE DADOS DE ASSINATURA E VERIFI­
CAÇÃO DE ASSINATURAS
14.1. Generalidades
CSM_231 O equipamento dedicado inteligente (IDE) memoriza num
ficheiro físico os dados recebidos de uma VU ou de um
cartão durante uma sessão de descarregamento. Os dados
podem ser memorizados num ESM (meio externo de memo­
rização). Este ficheiro contém as assinaturas digitais em blo­
cos de dados, em conformidade com o apêndice 7 e também
os seguintes certificados (consultar secção 9.1):
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 499
— No caso de descarregamento de dados da VU:
— o certificado VU_Sign
— o certificado MSCA_VU-EGF que contém a chave
pública a utilizar para a verificação do certificado
VU-Sign
— No caso de descarregamento de dados do cartão:
— o certificado Card_Sign
— o certificado MSCA_Card que contém a chave pública
a utilizar para a verificação do certificado Card-Sign
CSM_232 O IDE dispõe igualmente de:
— certificado de ligação que liga o último certificado EUR
ao certificado EUR cujo período de validade o precede
diretamente (se existir), no caso de utilizar um cartão de
controlo para verificar a assinatura, como mostra o es­
quema 13;
— todos os certificados de raiz europeus válidos, no caso de
verificar a própria assinatura.
Nota: o presente apêndice não especifica o método que o IDE
utiliza para recuperar esses certificados.
14.2. Criação da assinatura
CSM_233 O algoritmo de assinatura para criação de assinaturas digitais
em dados descarregados é ECDSA, em conformidade com
DSS, que utiliza o algoritmo de hash ligado ao tamanho da
chave da VU ou do cartão, em conformidade com o requisito
CSM_50. O formato de assinatura é simples, em conformi­
dade com a Orientação Técnica TR-03111.
14.3. Verificação da assinatura
CSM_234 ►M1 Um IDE pode executar a verificação de uma assinatura
em dados descarregados por si próprio ou utilizar um cartão
de controlo para esse efeito. Caso utilize um cartão de con­
trolo, a verificação da assinatura ocorre como mostra o es­
quema 13. Para verificar a validade temporal de um certifi­
cado apresentado pelo IDE, o cartão de controlo utiliza o seu
relógio interno, em conformidade com o requisito CSM_167.
O cartão de controlo atualiza a sua hora se a data de vigência
de um certificado «fonte de tempo válida» autêntico for mais
recente do que a hora atual do cartão. Como fonte de tempo
válida, o cartão aceita apenas os seguintes certificados:
— Certificados de ligação ERCA da segunda geração
— Certificados MSCA da segunda geração
— Certificados VU_Sign ou Card_Sign da segunda geração
emitidos pelo mesmo país do próprio certificado dos car­
tões do cartão de controlo.
Caso realize a verificação da própria assinatura, o IDE veri­
fica a autenticidade e a validade de todos os certificados, na
cadeia de certificado no ficheiro de dados e verifica a assi­
natura na sequência de dados do esquema de assinatura defi­
nido em DSS. Em ambos os casos, para cada certificado lido
a partir do ficheiro de dados, é necessário verificar se o
campo da autorização do titular do certificado (CHA) está
correto:
— O campo CHA do certificado de EQT deve indicar um
certificado da VU ou de cartão (consoante o que for apli­
cável) para assinatura (ver apêndice 1, tipo de dados
EquipmentType).
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 500
— O CHA do certificado EQT.CA deve indicar uma MSCA.
— O CHA do certificado EQT.Link deve indicar uma
ERCA. ◄
Notas do esquema 13:
— O equipamento que assinou os dados a analisar é desig­
nado EQT.
— Os certificados EQT e as chaves públicas mencionados no
esquema são os destinados à assinatura, ou seja, VU_Sign
ou Card_Sign.
— Os certificados EQT.CA e as chaves públicas menciona­
dos no esquema são os destinados à assinatura dos certi­
ficados a VU ou de cartão, consoante o caso.
— O certificado EQT.CA.EUR mencionado no esquema é o
certificado de raiz europeia indicado na CAR do certifi­
cado EQT.CA.
— O certificado EQT.Link mencionado no esquema é o cer­
tificado de ligação de EQT, caso exista. Em conformidade
com a secção 9.1.2, trata-se de um certificado de ligação
para um novo par de chaves de raiz europeia criado pela
ERCA e assinado com a chave privada europeia anterior.
— O certificado EQT.Link.EUR é o certificado de raiz eu­
ropeia indicado na CAR do certificado EQT.Link.
CSM_235 Para calcular o hash M enviado para o cartão de controlo no
comando PSO:Hash, o IDE utiliza o algoritmo de hash ligado
ao tamanho da chave da VU ou do cartão a partir do qual os
dados são descarregados, em conformidade com o CSM_50.
CSM_236 Para verificar a assinatura EQT, o cartão de controlo segue o
esquema de assinatura definido em DSS.
Nota: O presente documento não especifica qualquer ação a
empreender se uma assinatura num ficheiro de dados descar­
regados não puder ser verificada ou se a verificação não tiver
êxito.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 501
Esquema 13
Protocolo de verificação da assinatura num ficheiro de dados descarregados
▼M1
02016R0799 — PT — 21.08.2023 — 003.002 — 502
Apêndice 12
POSICIONAMENTO BASEADO NO SISTEMA GLOBAL DE
NAVEGAÇÃO POR SATÉLITE (GNSS)
ÍNDICE
1. INTRODUÇÃO
1.1. Âmbito de aplicação
▼M3
1.1.1 Referências
▼B
1.2. Acrónimos e notações
▼M3
2. CARACTERÍSTICAS BÁSICAS DO RECETOR GNSS
3. FRASES INDICADAS PELO RECETOR GNSS
▼B
4. UNIDADE-VEÍCULO COM MÓDULO GNSS EXTERNO
4.1. Configuração
4.1.1 Principais componentes e interfaces
4.1.2 Estado do módulo GNSS externo no final da produção
4.2. Comunicação entre o módulo GNSS externo e a unidade-veículo
4.2.1 Protocolo de comunicação
4.2.2 Transferência segura de dados GNSS
4.2.3 Estrutura do comando Read Record
▼M3
4.2.4 Estrutura do comando WriteRecord
4.2.5 Outros comandos
▼B
4.3. Acoplamento, autenticação mútua e concordância de chave de sessão do
módulo GNSS externo com a unidade-veículo
4.4. Tratamento de erros
4.4.1 Erro de comunicação com o módulo GNSS externo
4.4.2 Violação da integridade física do módulo GNSS externo
4.4.3 Ausência de informação sobre a posição do recetor GNSS
4.4.4 Expiração do certificado do módulo GNSS externo
5. UNIDADE-VEÍCULO SEM MÓDULO GNSS EXTERNO
5.1. Configuração
▼M3
5.2. Transferência de informações do recetor GNSS para a VU
__________
5.3. Transferência de informações da VU para o recetor GNSS
5.4. Tratamento de erros
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 503
5.4.1. Ausência de informações sobre a posição do recetor GNSS
6. TRATAMENTO E REGISTO DE DADOS DE POSIÇÃO PELA VU
7. CONFLITO DE TEMPO GNSS
8. CONFLITO RELATIVO AO MOVIMENTO DO VEÍCULO
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:
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
▼B
Figura 1
Diversas configurações do recetor GNSS
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 504
1.2. Acrónimos e notações
No presente apêndice, utilizam-se os seguintes acrónimos:
DOP Diluição de precisão
EGF Ficheiro elementar do módulo GNSS
EGNOS Serviço Europeu Complementar de Navegação Geoestacioná­
ria
GNSS Sistema global de navegação por satélite
GSA GPS DOP e satélites ativos
HDOP Diluição de precisão horizontal
ICD Documento de controlo da interface
NMEA Associação Nacional de Eletrónica para Aplicações Marítimas
▼M3
OSNMA Autenticação de mensagens de navegação do serviço aberto
Galileo
▼B
PDOP Diluição de precisão de posição
RMC Específico mínimo recomendado
▼M3
RTC Relógio de tempo real
▼B
SIS Sinal no espaço
HDOP Diluição de precisão vertical
VU Unidade-veículo
▼M3
2. CARACTERÍSTICAS BÁSICAS DO RECETOR GNSS
▼B
Independentemente da configuração do tacógrafo inteligente, com ou sem
módulo GNSS externo, o fornecimento de informações de posiciona­
mento precisas e fiáveis é um elemento essencial do bom funcionamento
do tacógrafo inteligente. Por conseguinte, convém exigir que este sistema
seja compatível com os serviços prestados pelo Programa Galileo e pelo
Serviço Europeu Complementar de Navegação Geoestacionária (EG­
NOS), conforme prevê o Regulamento (UE) n. o 1285/2013 do Parla­
mento Europeu e do Conselho ( 1 ). O sistema criado pelo Programa Ga­
lileo é um sistema autónomo mundial de navegação por satélite e o
sistema criado pelo Programa EGNOS é um sistema regional de nave­
gação por satélite que melhora a qualidade dos sinais do sistema de
posicionamento global.
GNS_2 Os construtores devem assegurar que os recetores GNSS a
bordo dos tacógrafos inteligentes são compatíveis com os ser­
viços de posicionamento prestados pelos sistemas Galileo e
EGNOS. Complementarmente, podem também optar por um
sistema compatível com outros sistemas de navegação por sa­
télite.
▼B
( 1 ) Regulamento (UE) n. o 1285/2013 do Parlamento Europeu e do Conselho, de , relativo à
im11 de dezembro de 2013 plantação e à exploração dos sistemas europeus de navega­
ção por satélite e que revoga o Regulamento (CE) n. o 876/2002 do Conselho e o
Regulamento (CE) n. o 683/2008 do Parlamento Europeu e do Conselho (JO L 347 de
20.12.2013, p. 1).
02016R0799 — PT — 21.08.2023 — 003.002 — 505
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).
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 inconsis­
tentes com a posição estimada,
— verificações de posição e velocidade, incluindo soluções de
posição e velocidade anormais, saltos abruptos e comporta­
mento inconsistente com a dinâmica do veículo,
— consistência de tempo e frequência, incluindo saltos e de­
rivas do relógio que não são consistentes com as caracte­
rí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 OS­
NMA transmitida no sinal Galileo.
— Diretrizes relativas ao recetor OSNMA, indicando os requi­
sitos e processos nos recetores para garantir uma implemen­
tação segura da OSNMA, bem como recomendações para
melhorar o desempenho da OSNMA.
Os recetores GNSS instalados em tacógrafos, internos ou ex­
ternos, 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, denomi­
nadas 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 nave­
gaçã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.
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 506
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, junta­
mente com a hora RTC da VU.
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):
Figura 2
Estrutura da frase RMC
$–RMC,hhmmss.ss,A,llll.ll,a,yyyyy.yy,a,x.x,x .x,xxxx,x.x,a,a,a*hh
1) Time (UTC)
2) Status, A= Valid position, V= Warning
3) Latitude
4) N or S
5) Longitude
6) E or W
7) Speed over ground in knots
8) Track made good, degrees true
9) Date, ddmmyy
10) Magnetic Variation, degrees
11) E or W
12) FAA Mode Indicator
13) Navigational status
14) Checksum
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 507
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 minu­
tos, 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):
Figura 3
Estrutura da frase AMC
$–AMC,hhmmss.ss,A,llll.ll,a,yyyyy.yy,a,x.x,x.x,xxxx,x.x,a,a,a*hh
1) Hora (UTC):
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 veri­
ficações de consistência implementadas de acordo com GNS_3a), F = au­
tenticaçã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
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 508
O estatuto de navegação é facultativo e pode não estar pre­
sente na frase AMC.
O estatuto indica se uma posição GNSS autenticada está dis­
ponível, se foi detetado um ataque aos sinais do GNSS, se a
autenticação das mensagens de navegação falhou ou se a po­
sição do GNSS é nula. Enquanto o valor do estatuto não
estiver fixado em A, os dados recebidos (por exemplo, relati­
vos à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» (autenti­
caçã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 infor­
maçõ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 especial­
mente 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)
$–ASA,a,a,x,x,x,x,x,x,x,x,x,x,x,x,x.x,x.x,x.x,a*h h
1) Modo de seleção
2) Modo
3) 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.
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 509
De igual modo, a VU pode utilizar o comando de satélites
ativos autenticados (ASA) da frase do tipo NMEA para de­
terminar 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)
$–ASA,a,a,x,x,x,x,x,x,x,x,x,x,x,x,x.x,x.x,x.x,a*h h
1) Modo de seleção
2) Modo
3) 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)
▼B
4. UNIDADE-VEÍCULO COM MÓDULO GNSS EXTERNO
4.1. Configuração
4.1.1 Principais componentes e interfaces
Nesta configuração, o recetor GNSS faz parte do módulo GNSS
externo.
GNS_8 O módulo GNSS externo deve ser alimentado por uma
interface de veículo específica.
▼M3
GNS_9 O módulo GNSS externo tem os seguintes componentes
(ver figura 6):
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 510
a) Um recetor GNSS comercial para fornecer os dados de
posição, através da interface de dados GNSS. Por exem­
plo, 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.
▼B
b) Um emissor-recetor (emissor-recetor seguro GNSS) com
capacidade para servir a norma ISO/IEC 7816-4:2013
(ver 4.2.1), para comunicar com a unidade-veículo e
servir a interface de dados GNSS para o recetor GNSS.
A unidade é disponibilizada com uma memória desti­
nada a memorizar os dados de identificação do recetor
GNSS e do módulo GNSS externo.
▼M3
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 se­
gurança exigidas no perfil de proteção dos tacógrafos
inteligentes
▼B
d) Uma antena GNSS instalada no veículo e ligada ao
recetor GNSS por meio do sistema de invólucro.
GNS_10 O módulo GNSS externo tem, pelo menos, as seguintes
interfaces externas:
a) a interface para a antena GNSS instalada no camião,
caso se utilize uma antena externa.
b) a interface para a unidade-veículo.
GNS_11 Na VU, o emissor-recetor seguro da VU é a outra extremi­
dade das comunicações seguras com o emissor-recetor se­
guro GNSS e tem de obedecer à norma ISO/IEC 7816-
-4:2013 no que se refere à conexão com o módulo GNSS
externo.
GNS_12 Para a camada física da comunicação com o módulo GNSS
externo, a unidade-veículo deve obedecer à norma ISO/IEC
7816-12:2005 ou a outra norma compatível com a ISO/IEC
7816-4:2013 (ver 4.2.1).
4.1.2 Estado do módulo GNSS externo no final da produção
GNS_13 O módulo GNSS externo deve memorizar os seguintes va­
lores, na memória não volátil do emissor-recetor seguro
GNSS, quando este sai de fábrica:
— o par de chaves EGF_MA e o certificado correspon­
dente
— o certificado MSCA_VU-EGF que contém a chave pú­
blica MSCA_VU-EGF.PK a utilizar para a verificação
do certificado EGF_MA
— o certificado EUR que contém a chave pública EUR.PK
a utilizar para a verificação do certificado MSCA_VU-
-EGF
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 511
— o certificado EUR cujo período de validade precede
diretamente o período de validade do certificado EUR
a utilizar para a verificação do certificado MSCA_VU-
-EGF, se existir
— o certificado de ligação que liga estes
dois certificados EUR, se existir
— o número de série alargado do módulo GNSS externo
— o identificador do sistema operativo do módulo GNSS
— o número de homologação de tipo do módulo GNSS
externo
— o identificador do componente de segurança do módulo
GNSS externo.
4.2. Comunicação entre o módulo GNSS externo e a unidade-veículo
4.2.1 Protocolo de comunicação
▼M3
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 verda­
deira e a hora RTC da VU.
▼B
GNS_15 O protocolo de comunicação deve basear-se na norma ISO/
/IEC 7816-4:2013 em que o emissor-recetor seguro da VU
desempenha o papel principal e o emissor-recetor seguro
GNSS desempenha o papel secundário. A conexão física
entre o módulo GNSS externo e a unidade-veículo tem
por base a norma ISO/IEC 7816-12:2005 ou outra norma
compatível com a ISO/IEC 7816-4:2013.
GNS_16 O protocolo de comunicação não aceita os campos de com­
primento alargado.
GNS_17 O protocolo de comunicação estabelecido pela norma ISO
7816 (*-4:2013 e *-12:2005) entre o módulo GNSS externo
e a VU deve ser definido como T=1.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 512
GNS_18 Em relação às funções 1 — «recolha e distribuição de
dados GNSS», 2 — «recolha dos dados de configuração
do módulo GNSS externo» e 3 — «protocolo de gestão»,
o emissor-recetor seguro GNSS deve simular um cartão
inteligente com uma arquitetura de sistema de ficheiros
composta por um ficheiro principal (MF), um ficheiro
dedicado (DF) com o identificador de aplicação especifi­
cado no apêndice 1, secção 6.2 (‘FF 44 54 45 47 4D’) e
com três EF que possuem certificados e um ficheiro ele­
mentar único (EF.EGF) com identificador de ficheiro igual
a ‘2F2F’, conforme consta do quadro 1.
▼M3
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.
▼B
GNS_19 O emissor-recetor seguro GNSS deve memorizar os dados
provenientes do recetor GNSS e a configuração no EF.EGF.
Trata-se de um ficheiro de registo linear de comprimento
variável com um identificador igual a «2F2F» em formato
hexadecimal.
▼M3
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 identifica­
dor igual a «2F30» em formato hexadecimal.
GNS_20 O emissor-recetor seguro GNSS utiliza uma memória para
memorizar os dados e poder executar tantos ciclos de lei­
tura/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.
▼M1
O mapeamento de números e dados de registo consta do
quadro 1. De referir que há cinco frases GSA para o sis­
tema de aumento com recurso a satélites (SBAS) GNSS.
▼B
GNS_21 A estrutura do ficheiro é dada no quadro 1. Relativamente
às condições de acesso (ALW, NEV, SM-MAC), ver apên­
dice 2, capítulo 3.5.
▼M3
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
▼M1
02016R0799 — PT — 21.08.2023 — 003.002 — 513
Condições de acesso
Ficheiro File ID Read Atualizar Encriptado
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
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 514
Ficheiro/elemento de dados n. o de registo Tamanho (bytes)
Valores por
defeito
Identificador do sistema operativo do
emissor-recetor seguro GNSS definido
no apêndice 1 como SensorOSIdenti­
fier.
'08' 2 2
Número de homologação de tipo do
módulo GNSS externo definido no
apêndice 1 como SensorExternalGNS­
SApprovalNumber.
'09' 16 16
Identificador do componente de segu­
rança do módulo GNSS externo defi­
nido no apêndice 1 como SensorExter­
nalGNSSSCIdentifier.
'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}
▼B
4.2.2 Transferência segura de dados GNSS
▼M3
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:
▼B
1. O processo de acoplamento foi concluído, conforme des­
creve o apêndice 11 ( Mecanismos comuns de segu­
rança).
2. A autenticação mútua periódica e a concordância de
chave de sessão entre a VU e o módulo GNSS externo,
também descritas no apêndice 11 (Mecanismos comuns
de segurança), foram executadas na frequência indicada.
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 515
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 RE­
CORD(S) (Ler registo[(s)] (norma ISO/IEC 7816-
-4:2013) no modo apenas de autenticação do envio se­
guro de mensagens descrito na secção 11.5 do apên­
dice 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 me­
morizados no EF com o identificador «2F2F» e os re­
gistos 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 ex­
traindo 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).
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 516
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 neces­
sá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 men­
sagens 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.
▼B
4.2.3 Estrutura do comando Read Record
▼C2
A presente secção descreve em pormenor a estrutura do comando Read
Record (ler registo). O envio seguro de mensagens (modo «apenas
autenticação») é adicionado conforme descrito no apêndice 11 (Meca­
nismos comuns de segurança).
▼B
GNS_24 O comando deve aceitar o modo apenas de autenticação do
envio seguro de mensagens (ver apêndice 11).
GNS_25 Mensagem de comando
▼C2
Byte
Compri­
mento
Valor Descrição
CLA 1 «0Ch» Pedido envio seguro de mensagens
INS 1 «B2h» Ler registo (Read Record)
P1 1 «XXh» Número de registo («00» refere-se ao re­
gisto atual)
P2 1 «04h» Ler registo com o número indicado em
P1
Le 1 «XXh» Comprimento dos dados esperados. Nú­
mero de bytes a ler
▼B
GNS_26 O registo referenciado em P1 torna-se o registo atual.
Byte
Compri­
mento
Valor Descrição
#1-#X X «XX..XXh» Dados lidos
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).
▼M3
— Se o registo não for encontrado, o emissor-recetor se­
guro GNSS devolve «6A 83».
— Se o módulo GNSS externo tiver detetado adulteração,
deve devolver as palavras de estatuto «6690»
__________
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 517
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 (Meca­
nismos 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
Compri­
mento
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
Compri­
mento
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 se­
guro 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 au­
tenticar)
Apêndice 2, capítulo 3.5.9
General Authenticate (Geral autenti­
car)
Apêndice 2, capítulo 3.5.10
MSE:SET Apêndice 2, capítulo 3.5.11
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 518
4.3. Acoplamento, autenticação mútua e concordância de chave de ses­
são do módulo GNSS externo com a unidade-veículo
O acoplamento, a autenticação mútua e a concordância de chave de
sessão do módulo GNSS externo com a unidade-veículo são descritos
no apêndice 11 (Mecanismos comuns de segurança), capítulo 11.
4.4. Tratamento de erros
Esta secção descreve como são abordadas e registadas na VU as
condições de erro potenciais do módulo GNSS externo.
4.4.1 Erro de comunicação com o módulo GNSS externo
▼M3
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 (EventFault­
Type). Neste contexto, desencadeia-se um erro de comuni­
caçã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.
▼B
4.4.2 Violação da integridade física do módulo GNSS externo
▼M3
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 in­
cidente 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'
▼B
4.4.3 Ausência de informação sobre a posição do recetor GNSS
▼M3
GNS_30 Se não receber dados do recetor GNSS, o emissor-recetor
seguro GNSS cria uma mensagem de resposta para o co­
mando READ RECORD com número RECORD igual a
«01», com um campo de dados de 12 bytes, todos defini­
dos 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).
▼B
4.4.4 Expiração do certificado do módulo GNSS externo
▼M3
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.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 519
Figura 6
Esquema do módulo GNSS externo
▼B
5. UNIDADE-VEÍCULO SEM MÓDULO GNSS EXTERNO
5.1. Configuração
Na presente configuração, o recetor GNSS está no interior da
unidade-veículo, conforme consta da figura 1.
▼M3
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.
▼B
GNS_33 A antena GNSS externa instalada no veículo ou a antena
GNSS interna devem estar ligadas à VU.
▼M3
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 autenti­
cada for válida, o processador da VU extrai também os
valores HDOP das frases ASA.
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 520
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 (EventFault­
Type).
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áli­
das e consistentes, a posição padrão e a respetiva preci­
sã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áli­
das, 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 res­
petiva precisão, e o indicador deve ser fixado em «não
autenticada».
As posições autenticadas e padrão são consideradas consis­
tentes, 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.
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 521
— 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 in­
cidente 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 pro­
veniente dos sinais GNSS, deve gerar e registar um inci­
dente de conflito de tempo, conforme definido no requisito
86 do anexo IC e no apêndice 1 (EventFaultType).
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 in­
formaçõ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 estabele­
cido 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 con­
dições de acionamento:
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 522
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 po­
siçã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 elimina­
rem 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 últi­
mos 5 minutos para atenuar o risco de medições discrepan­
tes 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 > [OdometerDifference×OdometerTolerance­
Factor+Minimum (SlipDistanceUpperlimit; (OdometerDif­
ference×SlipFactor))+GnssTolerance+FerryTrainDistance]
na qual:
— GnssDistance é a distância entre a posição atual do
veículo e a anterior, ambas obtidas a partir de mensa­
gens 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 cor­
respondente à mensagem de posição autenticada válida
anterior,
— OdometerToleranceFactor é igual a 1.1 (fator de tole­
rância mais pessimista para todas as tolerâncias de me­
dição do conta-quilómetros do veículo),
— GnssTolerance é igual a 1 km (tolerância do GNSS
mais pessimista),
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 523
— Minimum (SlipDistanceUpperLimit; (OdometerDiffe­
rence * 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 Slip­
Factor é igual a 0,2 (influência máxima dos efeitos
de escorregamento durante a travagem),
— FerryTrainDistance é calculado como: FerryTrainDis­
tance = 200km/h * tFerryTrain, em que tFerryTrain é
a soma das durações em horas das travessias de bate­
lão/comboio no intervalo de tempo considerado. A du­
raçã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 indepen­
dente 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 estabeleci­
dos pelo fabricante da unidade-veículo, embora a discre­
pância deva detetada, no máximo, dentro de três horas.
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 524
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 Regula­
mento (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.
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 525
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 Na­
vegação por Satélite)
ITS Intelligent Transport System (Sistema de Transporte Inteli­
gente)
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 con­
tradição, prevalecem as cláusulas do presente apêndice.
As normas referidas no presente apêndice são as seguintes:
— Bluetooth® — Versão principal 5.0
— ISO 16844-7: Veículos rodoviários — Sistemas tacográficos —
7. a parte: Parâmetros
— 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 qual­
quer 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.
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 526
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 dispo­
nibilizar 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.
Figura 1
partição da comunicação através da interface ITS de acordo com as camadas do modelo OSI
ITS_10 Quando a interface de descarregamento é utilizada através do co­
nector 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 des­
carregamento 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, con­
forme especificado no quadro 1.
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 527
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
R
an
hu
ra
d
o
aj
ud
an
te

Ausência de car­
tão
Não disponível Disponível Disponível Disponível Disponível
Cartão de con­
dutor
Disponível Disponível Disponível Disponível Disponível
Cartão de con­
trolo
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 em­
presa
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
Atribuição da ligação ITS
Bluetooth®
Ranhura do condutor
Ausência de cartão Cartão de condutor Cartão de controlo Cartão de oficina Cartão de empresa
R
an
hu
ra
d
o
aj
ud
an
te

Ausência de car­
tão
Não disponível Cartão de con­
dutor
Cartão de con­
trolo
Cartão de ofi­
cina
Cartão de em­
presa
Cartão de con­
dutor
Cartão de con­
dutor
Cartão de con­
dutor (**)
Cartão de con­
trolo
Cartão de ofi­
cina
Cartão de em­
presa
Cartão de con­
trolo
Cartão de con­
trolo
Cartão de con­
trolo
Cartão de con­
trolo (*)
Não disponível Não disponível
Cartão de oficina Cartão de ofi­
cina
Cartão de ofi­
cina
Não disponível Cartão de ofi­
cina (*)
Não disponível
Cartão de em­
presa
Cartão de em­
presa
Cartão de em­
presa
Não disponível Não disponível Cartão de em­
presa (*)
(*) A ligação ITS Bluetooth® deve ser atribuída ao cartão tacográfico na ranhura do condutor da VU.
(**) 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).
ITS_15 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.
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 528
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 re­
feridos 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 aces­
síveis mediante consentimento do condutor, aceitando-se, por con­
seguinte, que os dados pessoais possam sair da rede do veículo,
exceto no caso previsto no requisito ITS_25, para o qual o con­
sentimento 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 con­
sentimento 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 conduto­
res, 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 da­
dos
Fonte
Classificação recomendada (pessoais/
/não pessoais) Consentimento quanto
à disponibilidade dos
dados
Disponibili­
dade
condutor ajudante
VehicleIdentification­
Number
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
TachographVehicleS­
peed
ISO 16844-7 VU pessoais N/A consentimento do
condutor
obrigatória
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 529
Nome dos dados
Formato dos da­
dos
Fonte
Classificação recomendada (pessoais/
/não pessoais) Consentimento quanto
à disponibilidade dos
dados
Disponibili­
dade
condutor ajudante
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
Driver1TimeRelatedS­
tates
ISO 16844-7 VU pessoais N/A consentimento do
condutor
obrigatória
Driver2TimeRelatedS­
tates
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
HighResolutionTotal­
VehicleDistance
ISO 16844-7 VU não pessoais não pessoais não é necessário o
consentimento
obrigatória
HighResolutionTrip­
Distance
ISO 16844-7 VU não pessoais não pessoais não é necessário o
consentimento
obrigatória
ServiceComponentI­
dentification
ISO 16844-7 VU não pessoais não pessoais não é necessário o
consentimento
obrigatória
ServiceDelayCalendar­
TimeBased
ISO 16844-7 VU não pessoais não pessoais não é necessário o
consentimento
obrigatória
Driver1Identification ISO 16844-7 Car­
tão
de
con­
dutor
pessoais N/A consentimento do
condutor
obrigatória
Driver2Identification ISO 16844-7 Car­
tão
de
con­
dutor
N/A pessoais consentimento do
ajudante
obrigatória
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 530
Nome dos dados
Formato dos da­
dos
Fonte
Classificação recomendada (pessoais/
/não pessoais) Consentimento quanto
à disponibilidade dos
dados
Disponibili­
dade
condutor ajudante
NextCalibrationDate Apêndice 8 VU não pessoais não pessoais não é necessário o
consentimento
obrigatória
Driver1ContinuousDri­
vingTime
ISO 16844-7 VU pessoais N/A consentimento do
condutor
obrigatória
Driver2ContinuousDri­
vingTime
ISO 16844-7 VU N/A pessoais consentimento do
ajudante
obrigatória
Driver1Cumulative­
BreakTime
ISO 16844-7 VU pessoais N/A consentimento do
condutor
obrigatória
Driver2Cumulative­
BreakTime
ISO 16844-7 VU N/A pessoais consentimento do
ajudante
obrigatória
Driver1CurrentDuratio­
nOfSelectedActivity
ISO 16844-7 VU pessoais N/A consentimento do
condutor
obrigatória
Driver2CurrentDuratio­
nOfSelectedActivity
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 Car­
tão
de
con­
dutor
pessoais N/A consentimento do
condutor
obrigatória
Driver2Name ISO 16844-7 Car­
tão
de
con­
dutor
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
Driver1CumulatedDri­
vingTimePreviousAnd­
CurrentWeek
ISO 16844-7 VU pessoais N/A consentimento do
condutor
obrigatória
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 531
Nome dos dados
Formato dos da­
dos
Fonte
Classificação recomendada (pessoais/
/não pessoais) Consentimento quanto
à disponibilidade dos
dados
Disponibili­
dade
condutor ajudante
Driver2CumulatedDri­
vingTimePreviousAnd­
CurrentWeek
ISO 16844-7 VU N/A pessoais consentimento do
ajudante
obrigatória
EngineSpeed ISO 16844-7 VU pessoais N/A consentimento do
condutor
facultativa
RegisteringMemberS­
tate
Apêndice 8 VU não pessoais não pessoais não é necessário o
consentimento
obrigatória
VehicleRegistration­
Number
Apêndice 8 VU não pessoais não pessoais não é necessário o
consentimento
obrigatória
Driver1EndOfLastDai­
lyRestPeriod
ISO 16844-7 VU pessoais N/A consentimento do
condutor
facultativa
Driver2EndOfLastDai­
lyRestPeriod
ISO 16844-7 VU N/A pessoais consentimento do
ajudante
facultativa
Driver1EndOfLas­
tWeeklyRestPeriod
ISO 16844-7 VU pessoais N/A consentimento do
condutor
facultativa
Driver2EndOfLas­
tWeeklyRestPeriod
ISO 16844-7 VU N/A pessoais consentimento do
ajudante
facultativa
Driver1EndOfSecon­
dLastWeeklyRestPe­
riod
ISO 16844-7 VU pessoais N/A consentimento do
condutor
facultativa
Driver2EndOfSecon­
dLastWeeklyRestPe­
riod
ISO 16844-7 VU N/A Pessoais consentimento do
ajudante
facultativa
Driver1TimeLastLoa­
dUnloadOperation
ISO 16844-7 VU pessoais N/A consentimento do
condutor
facultativa
Driver2TimeLastLoa­
dUnloadOperation
ISO 16844-7 VU N/A pessoais consentimento do
ajudante
facultativa
Driver1CurrentDaily­
DrivingTime
ISO 16844-7 VU pessoais N/A consentimento do
condutor
facultativa
Driver2CurrentDaily­
DrivingTime
ISO 16844-7 VU N/A pessoais consentimento do
ajudante
facultativa
Driver1CurrentWeekly­
DrivingTime
ISO 16844-7 VU pessoais N/A consentimento do
condutor
facultativa
Driver2CurrentWeekly­
DrivingTime
ISO 16844-7 VU N/A pessoais consentimento do
ajudante
facultativa
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 532
Nome dos dados
Formato dos da­
dos
Fonte
Classificação recomendada (pessoais/
/não pessoais) Consentimento quanto
à disponibilidade dos
dados
Disponibili­
dade
condutor ajudante
Driver1TimeLeftUntil­
NewDailyRestPeriod
ISO 16844-7 VU pessoais N/A consentimento do
condutor
facultativa
Driver2TimeLeftUntil­
NewDailyRestPeriod
ISO 16844-7 VU N/A pessoais consentimento do
ajudante
facultativa
Driver1CardExpiry­
Date
ISO 16844-7 Car­
tão
de
con­
dutor
pessoais N/A consentimento do
condutor
facultativa
Driver2CardExpiry­
Date
ISO 16844-7 Car­
tão
de
con­
dutor
N/A pessoais consentimento do
ajudante
facultativa
Driver1CardNextMan­
datoryDownloadDate
ISO 16844-7 VU pessoais N/A consentimento do
condutor
facultativa
Driver2CardNextMan­
datoryDownloadDate
ISO 16844-7 VU N/A pessoais consentimento do
ajudante
facultativa
TachographNextMan­
datoryDownloadDate
ISO 16844-7 VU não pessoais não pessoais não é necessário o
consentimento
facultativa
Driver1TimeLeftUntil­
NewWeeklyRestPeriod
ISO 16844-7 VU pessoais N/A consentimento do
condutor
facultativa
Driver2TimeLeftUntil­
NewWeeklyRestPeriod
ISO 16844-7 VU N/A pessoais consentimento do
ajudante
facultativa
Driver1NumberOfTi­
mes9hDailyDrivingTi­
mesExceeded
ISO 16844-7 VU pessoais N/A consentimento do
condutor
facultativa
Driver2NumberOfTi­
mes9hDailyDrivingTi­
mesExceeded
ISO 16844-7 VU N/A pessoais consentimento do
ajudante
facultativa
Driver1Cumulative­
UninterruptedRestTime
ISO 16844-7 VU pessoais N/A consentimento do
condutor
facultativa
Driver2Cumulative­
UninterruptedRestTime
ISO 16844-7 VU N/A pessoais consentimento do
ajudante
facultativa
Driver1MinimumDai­
lyRest
ISO 16844-7 VU pessoais N/A consentimento do
condutor
facultativa
Driver2MinimumDai­
lyRest
ISO 16844-7 VU N/A pessoais consentimento do
ajudante
facultativa
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 533
Nome dos dados
Formato dos da­
dos
Fonte
Classificação recomendada (pessoais/
/não pessoais) Consentimento quanto
à disponibilidade dos
dados
Disponibili­
dade
condutor ajudante
Driver1Minimum­
WeeklyRest
ISO 16844-7 VU pessoais N/A consentimento do
condutor
facultativa
Driver2Minimum­
WeeklyRest
ISO 16844-7 VU N/A pessoais consentimento do
ajudante
facultativa
Driver1MaximumDai­
lyPeriod
ISO 16844-7 VU pessoais N/A consentimento do
condutor
facultativa
Driver2MaximumDai­
lyPeriod
ISO 16844-7 VU N/A pessoais consentimento do
ajudante
facultativa
Driver1MaximumDai­
lyDrivingTime
ISO 16844-7 VU pessoais N/A consentimento do
condutor
facultativa
Driver2MaximumDai­
lyDrivingTime
ISO 16844-7 VU N/A pessoais consentimento do
ajudante
facultativa
Driver1NumberOfUse­
dReducedDailyRestPe­
riods
ISO 16844-7 VU pessoais N/A consentimento do
condutor
facultativa
Driver2NumberOfUse­
dReducedDailyRestPe­
riods
ISO 16844-7 VU N/A pessoais consentimento do
ajudante
facultativa
Driver1RemainingCur­
rentDrivingTime
ISO 16844-7 VU pessoais N/A consentimento do
condutor
facultativa
Driver2RemainingCur­
rentDrivingTime
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
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 534
Apêndice 14.
FUNÇÃO DE COMUNICAÇÃO À DISTÂNCIA
ÍNDICE
1 INTRODUÇÃO
2 ÂMBITO DE APLICAÇÃO
3 ACRÓNIMOS, DEFINIÇÕES E NOTAÇÕES
4 CENÁRIOS OPERACIONAIS
4.1 Panorâmica
4.1.1 Condições prévias para a transferência de dados através da interface
DSRC 5,8 GHz
4.1.2 Perfil 1a: através de um leitor de comunicações de deteção rápida à
distância apontado manualmente ou montado e apontado temporaria­
mente à estrada
4.1.3 Perfil 1b: através de um leitor de comunicações de deteção rápida à
distância (REDCR) montado num veículo e direcionado
4.2 Segurança/integridade
5 CONCEÇÃO E PROTOCOLOS DA COMUNICAÇÃO À DISTÂN­
CIA
5.1 Conceção
5.2 Fluxo de trabalho
5.2.1 Operações
5.2.2 Interpretação dos dados recebidos através da comunicação DSRC
5.3 Parâmetros da interface física DSRC para comunicação à distância
5.3.1 Restrições de localização
5.3.2 Parâmetros de ligação descendente e ascendente
5.3.3 Conceção das antenas
5.4 Requisitos de protocolo DSRC para RTM
5.4.1 Panorâmica
5.4.2 Comandos
5.4.3 Sequência de comandos de interrogação
5.4.4 Estruturas de dados
5.4.5 Elementos de RtmData, ações realizadas e definições
5.4.6 Mecanismo de transferência de dados
5.4.7 Descrição pormenorizada de transação DSRC
5.4.8 Descrição de transação de ensaio DSRC
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 535
5.5 Reservado para utilização futura
▼B
5.6 Transferência de dados entre a DSRC-VU e a VU
5.6.1 Conexão física e interfaces
5.6.2 Protocolo de aplicação
5.7 Tratamento de erros
5.7.1 Memorização e comunicação dos dados na DSRC-VU
5.7.2 Erros de comunicações sem fios
6 ENSAIOS DE COLOCAÇÃO EM SERVIÇO E DE INSPEÇÃO PE­
RIÓDICA PARA A FUNÇÃO DE COMUNICAÇÃO À DISTÂNCIA
6.1 Geral
6.2 ECHO
6.3 Ensaios para validar o conteúdo de dados seguro
1 INTRODUÇÃO
Este apêndice especifica a conceção e os procedimentos a seguir a fim
de implementar a função de comunicação à distância («a comunicação»),
conforme estipula o artigo 9. o do Regulamento (UE) n. o 165/2014 («o
Regulamento»).
DSC_1 O Regulamento (UE) n. o 165/2014 determina que o tacógrafo
deve estar equipado com uma função de comunicação à dis­
tância que permita aos agentes das autoridades de controlo
lerem informações dos tacógrafos de veículos em circulação,
mediante equipamentos de interrogação à distância (leitor de
comunicações de deteção rápida à distância [REDCR]), espe­
cialmente equipamentos de interrogação de conexão sem fios
que utilizam interfaces de comunicações dedicadas de curto
alcance (DSRC) CEN 5,8 GHz.
Importa compreender que esta função se destina a servir ape­
nas como um pré-filtro, de modo a selecionar veículos para
uma inspeção aprofundada, e não substitui o processo de ins­
peção formal, determinado pelo Regulamento (UE)
n. o 165/2014 (cf. considerando 9 deste regulamento, nos ter­
mos do qual a comunicação à distância entre o tacógrafo e as
autoridades responsáveis pelo controlo rodoviário facilita con­
trolos de estrada seletivos).
DSC_2 Os dados são intercambiados por meio da comunicação, que
será uma ligação com recurso a comunicações sem fios DSRC
de 5,8 GHz compatíveis com o presente apêndice, ensaiada em
relação aos parâmetros pertinentes da norma EN 300 674-1
{Electromagnetic compatibility and Radio spectrum Matters
(ERM); Road Transport and Traffic Telematics (RTTT); De­
dicated Short Range Communication (DSRC) transmission
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 536
equipment (500 kbit/s / 250 kbit/s) operating in the 5,8 GHz
Industrial, Scientific and Medical (ISM) band; Part 1: General
characteristics and test methods for Road Side Units (RSU)
and On -Board Units (OBU)}.
DSC_3 A comunicação deve ser estabelecida com o equipamento de
comunicação apenas quando tal for solicitado pelo equipa­
mento da autoridade de controlo competente, mediante a uti­
lização de meios de radiocomunicação compatíveis (leitor de
comunicações de deteção rápida à distância [REDCR]).
DSC_4 Os dados devem estar protegidos, para garantir a integridade.
DSC_5 «Só as autoridades responsáveis pelo controlo autorizadas a
controlar as infrações ao Regulamento (CE) n. o 561/2006 e
ao Regulamento (UE) n. o 165/2014 e as oficinas terão acesso
aos dados comunicados, na medida em que for necessário para
verificar o correto funcionamento do tacógrafo».
DSC_6 Durante a comunicação, são intercambiados apenas os dados
estritamente necessários para a realização de controlos de es­
trada seletivos a veículos com tacógrafos eventualmente mani­
pulados ou indevidamente utilizados.
DSC_7 A integridade e a segurança dos dados obtêm-se protegendo os
dados na unidade-veículo (VU) e passando pelo meio de co­
municação à distância sem fios DSRC de 5,8 GHz apenas os
dados de carga útil segura e os dados relacionados com a
segurança (ver 5.4.4), o que significa que somente os agentes
autorizados das autoridades de controlo competentes dispõem
dos meios para compreender os dados transmitidos pela comu­
nicação e para verificar a sua autenticidade (ver apêndice 11
— Mecanismos comuns de segurança).
DSC_8 Os dados contêm um período de tempo para o momento da
sua última atualização.
DSC_9 O conteúdo dos dados de segurança deve ser conhecido apenas
e sob o controlo das autoridades de controlo competentes e
pelas partes com as quais essas autoridades partilham esta
informação. O referido conteúdo está fora do âmbito das dis­
posições da comunicação que é objeto do presente apêndice,
com a ressalva de que a comunicação prevê a transferência de
um pacote de dados de segurança com cada pacote de dados
de carga útil.
DSC_10 A mesma arquitetura e os mesmos equipamentos devem poder
ser utilizados para adquirir outros conceitos de dados (como a
pesagem a bordo) utilizando a arquitetura aqui especificada.
DSC_11 Para esclarecimento, em conformidade com o disposto no
Regulamento (UE) n. o 165/2014 (artigo 7. o ), os dados relativos
à identidade do condutor não devem ser divulgados através da
comunicação.
2 ÂMBITO DE APLICAÇÃO
O presente apêndice destina-se a especificar de que modo os agentes das auto­
ridades de controlo competentes utilizam uma comunicação sem fios DSRC
5,8 GHz específica para obter à distância dados (os dados) provenientes de um
veículo visado, a qual identifica a eventual violação do Regulamento (UE)
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 537
n. o 165/2014 por este veículo e assinala a necessidade de o mandar parar, com
vista a uma investigação mais aprofundada.
Segundo o Regulamento (UE) n. o 165/2014, os dados recolhidos devem
limitar-se (ou ser relativos) aos dados que identificam uma potencial
infração, na aceção do seu artigo 9. o .
▼M1
Neste cenário, o tempo disponível para a comunicação é limitado, por­
que a comunicação é orientada e com uma conceção de curto alcance.
Além disso, os mesmos meios de comunicação destinados à monitori­
zação tacográfica à distância (RTM) podem ser igualmente utilizados
pelas autoridades de controlo para outras aplicações (como os pesos e
as dimensões máximos dos veículos pesados de mercadorias, definidos
na Diretiva (UE) 2015/719) e essas operações podem ser distintas ou
sequenciais, ao critério das autoridades de controlo competentes.
▼B
O presente apêndice especifica:
— O equipamento de comunicações, procedimentos e protocolos a uti­
lizar para a comunicação
— As normas e regulamentos a que o equipamento de rádio deve
obedecer
— A apresentação dos dados no equipamento de comunicação
— Os procedimentos de descarregamento e pedido e a sequência das
operações
— Os dados a transferir
— A potencial interpretação dos dados transferidos através da comuni­
cação
— As disposições destinadas aos dados de segurança relativos à comu­
nicação
— A disponibilidade dos dados para as autoridades de controlo com­
petentes
— O modo como o leitor de comunicações de deteção rápida à dis­
tância pode pedir diferentes conceitos de dados sobre a carga e a
frota
Para esclarecimento, o presente apêndice não especifica:
— O funcionamento e a gestão da recolha dos dados na VU (que serão
uma função da conceção do produto, salvo se especificadas noutras
partes do Regulamento (UE) n. o 165/2014)
— A forma de apresentação dos dados recolhidos para o agente das
autoridades de controlo, nem os critérios a utilizar por essas autori­
dades para decidirem quais os veículos a mandar parar (que serão
uma função da conceção do produto, salvo se especificados noutras
partes do Regulamento (UE) n. o 165/2014 ou uma decisão política
das autoridades de controlo competentes). Para esclarecimento: a
comunicação disponibiliza os dados apenas às autoridades de con­
trolo competentes, para que estas possam tomar decisões informadas
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 538
— Disposições de segurança dos dados (como a encriptação) relativa­
mente ao conteúdo dos dados (especificadas no apêndice 11 —
Mecanismos comuns de segurança)
— Pormenores de conceitos de dados diferentes de RTM que podem ser
obtidos utilizando a mesma arquitetura e o mesmo equipamento
— Pormenor do comportamento e da gestão entre VU e a DSRC-VU,
nem o comportamento na DSRC-VU (exceto para fornecer os dados,
quando um REDCR os pedir).
3 ACRÓNIMOS, DEFINIÇÕES E NOTAÇÕES
No presente apêndice utilizam-se os seguintes acrónimos e definições,
que lhe são específicos:
antena Dispositivo elétrico que converte
energia elétrica em ondas de rádio
e vice-versa, utilizado em combina­
ção com um transmissor ou um re­
cetor de rádio. Em funcionamento,
um transmissor de rádio fornece
uma corrente elétrica oscilante com
uma frequência de rádio aos termi­
nais da antena, e a antena irradia a
energia da corrente sob a forma de
ondas eletromagnéticas (ondas de rá­
dio). Na receção, uma antena inter­
ceta alguma da energia de uma onda
eletromagnética, a fim de produzir
uma pequena tensão nos seus termi­
nais, que é aplicada a um recetor
para ser amplificada
comunicação Intercâmbio de informações/dados
entre uma DSRC-REDCR e uma
DSRC-VU, de acordo com a sec­
ção 5, numa relação de
principal-secundário, para obter os
dados
dados Dados seguros de formato definido
(ver 5.4.4), pedidos pela DSRC-
-REDCR e fornecidos à DSRC-
-REDCR pela DSRC-VU através de
uma ligação DSRC 5,8 GHz, defi­
nida em 5
Regulamento (UE) n. o 165/2014 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, que revoga
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 539
o Regulamento (CEE) n. o 3821/85
do Conselho relativo à introdução
de um aparelho de controlo no do­
mínio dos transportes rodoviários e
que altera o Regulamento (CE)
n. o 561/2006 do Parlamento Euro­
peu e do Conselho relativo à harmo­
nização de determinadas disposições
em matéria social no domínio dos
transportes rodoviários
AID Identificador de uma aplicação
BLE Baixo consumo energético do Blue­
tooth
BST Quadro de serviço de baliza
CIWD Inserção de cartão durante a condu­
ção
CRC Controlo de redundâncias cíclicas
DSC (n) Identificador de um pedido de apên­
dice DSRC específico
DSRC Comunicações dedicadas de curto
alcance
DSRC-REDCR DSRC–Leitor de comunicações de
deteção rápida à distância
DSRC-VU DSRC–Unidade-veículo (módulo de
«comunicação de deteção rápida à
distância», definido no anexo 1C)
DWVC Condução sem cartão válido
EID Identificador de elemento
LLC Controlo de ligação lógica
LPDU LLC Unidade de dados de protocolo
OWS Sistema de pesagem a bordo
PDU Unidade de dados de protocolo
REDCR Leitor de comunicação de deteção
rápida à distância (equipamento de­
finido no anexo 1C)
RTM Monitorização tacográfica à distân­
cia
SM-REDCR Módulo de segurança do leitor de
comunicação de deteção rápida à
distância
TARV Aplicações telemáticas para veículos
regulamentados (série das normas
ISO 15638)
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 540
VU Unidade-veículo
VUPM Memória de carga útil da
unidade-veículo
VUSM Módulo de segurança da
unidade-veículo
VST Quadro de serviço do veículo
WIM Peso em movimento
WOB Peso a bordo
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. Em caso de contradição sem que
esteja claramente determinada qualquer especificação no presente apên­
dice, prevalece a aplicação da Recomendação ERC 70-03 (com ensaio
em função dos parâmetros adequados da norma EN 300 674-1),
seguindo-se, por ordem decrescente de preferência, as normas EN 12795,
EN 12253, EN 12834 e EN 13372, n. os 6.2, 6.3, 6.4 e 7.1.
Regulamentos e normas de referência no presente apêndice:
[1] Regulamento (UE) n. o 165/2014 do Parlamento Europeu e do Con­
selho, de 4 de fevereiro de 2014, relativo à utilização de tacógrafos
nos transportes rodoviários, que revoga o Regulamento (CEE)
n. o 3821/85 do Conselho relativo à introdução de um aparelho
de controlo no domínio dos transportes rodoviários e que altera o
Regulamento (CE) n. o 561/2006 do Parlamento Europeu e do Con­
selho relativo à harmonização de determinadas disposições em ma­
téria social no domínio dos transportes rodoviários.
[2] Regulamento (CE) n. o 561/2006 do Parlamento Europeu e do Con­
selho, de 15 de março de 2006, relativo à harmonização de deter­
minadas disposições em matéria social no domínio dos transportes
rodoviários, que altera os Regulamentos (CEE) n. o 3821/85 e (CE)
n. o 2135/98 do Conselho e revoga o Regulamento (CEE)
n. o 3820/85 do Conselho.
[3] ERC 70-03 CEPT: ECC Recommendation 70-03: Relating to the
Use of Short Range Devices (SRD)
[4] ISO 15638-9 Intelligent transport systems — Framework for coo­
perative telematics applications for regulated commercial freight
vehicles (TARV).
[5] EN 300 674-1: Electromagnetic compatibility and Radio spectrum
Matters (ERM); Road Transport and Traffic Telematics (RTTT);
Dedicated Short Range Communication (DSRC) transmission
equipment (500 kbit/s / 250 kbit/s) operating in the 5,8 GHz Indus­
trial, Scientific and Medical (ISM) band; Part 1: General characte­
ristics and test methods for Road Side Units (RSU) and On-Board
Units (OBU).
[6] EN 12253: Road transport and traffic telematics — Dedicated
short-range communication — Physical layer using microwave at
5,8 GHz.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 541
[7] EN 12795: Road transport and traffic telematics — Dedicated
short-range communication — Data link layer: medium access
and logical link control.
[8] EN 12834: Road transport and traffic telematics — Dedicated
short-range communication — Application layer.
[9] EN 13372: Road transport and traffic telematics — Dedicated
short-range communication — Profiles for RTTT applications
[10] ISO 14906: Electronic fee collection — Application interface de­
finition for dedicated short- range communication
4 CENÁRIOS OPERACIONAIS
4.1 Panorâmica
O Regulamento (UE) n. o 165/2014 apresenta cenários específicos e con­
trolados nos quais deve ser utilizada a comunicação.
Cenários compatíveis:
«Communication Profile 1: Roadside inspection using a short range
wireless communication Remote Early Detection Communication Reader
instigating a physical roadside inspection (master-:-slave)
Reader Profile 1a: via a hand aimed or temporary roadside mounted
and aimed Remote Early Detection Communication
Reader Profile 1b: via a vehicle mounted and directed Remote Early
Detection Communication Reader».
4.1.1 Condições prévias para a transferência de dados através da interface
DSRC 5,8 GHz
NOTA: A fim de compreender o contexto das condições prévias o leitor
é mencionado no esquema 14.3 infra.
4.1.1.1 Dados detidos pela VU
DSC_12 A VU tem a responsabilidade de manter atualizados de 60 em
60 segundos e de guardar os dados a memorizar na VU, sem
qualquer envolvimento da função de comunicação DSRC. O
meio pelo qual se consegue este procedimento é interno à VU,
está especificado no Regulamento (UE) n. o 165/2014 e no
anexo 1C, secção 3.19 («Comunicação à distância para con­
trolos de estrada seletivos») e não é especificado no presente
apêndice.
4.1.1.2 Dados fornecidos ao módulo DSRC-VU
DSC_13 A VU tem a responsabilidade de atualizar os dados (os dados)
tacográficos DSRC sempre que os dados memorizados na VU
sejam atualizados em intervalos determinados em 4.1.1.1
(DSC_12), sem qualquer envolvimento da função de comuni­
cação DSRC.
DSC_14 Os dados da VU são utilizados como base para preencher e
atualizar os dados, estando os meios pelos quais tal é conse­
guido especificados no anexo 1C, secção 3.19 («Comunicação
à distância para controlos de estrada seletivos») ou, se não
existir essa especificação, trata-se de uma função de conceção
do produto, que o presente apêndice não especifica. Relativa­
mente à conceção da conexão entre o módulo DSRC-VU e a
VU, consultar a secção 5.6.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 542
4.1.1.3 Conteúdo dos dados
DSC_15 O conteúdo e o formato dos dados devem ser tais que, uma
vez decifrados, são estruturados e disponibilizados na forma e
no formato especificados na secção 5.4.4 do presente apêndice
(estruturas de dados).
4.1.1.4 Apresentação dos dados
DSC_16 Os dados, tendo sido mantidos atualizados com frequência, de
acordo com os procedimentos previstos em 4.1.1.1, devem ser
protegidos antes da apresentação à DSRC-VU e apresentados
como valor de conceito de dados seguros, para memorização
temporária na DSRC-VU como a versão atual dos dados. Estes
dados são transferidos do VUSM para o VUPM da função
DSRC. O VUSM e VUPM são funções e não necessariamente
entidades físicas. A forma de instanciação física para executar
essas funções será uma questão de conceção do produto, salvo
especificação noutras partes do Regulamento (UE)
n. o 165/2014.
4.1.1.5 Dados de segurança
▼M3
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ên­
dice 11 «Mecanismos comuns de segurança», para memoriza­
ção temporária na DSRC-VU como a versão atual de DSRCSe­
curityData, na forma definida na secção 5.4.4. do presente
apêndice.
▼B
4.1.1.6 Dados VUPM disponíveis para transferência através da interface DSRC
DSC_18 O conceito dos dados que devem estar sempre disponíveis na
VUPM de função DSRC para transferência imediata, a pedido
do REDCR, é definido na secção 5.4.5 relativamente a espe­
cificações completas do módulo ASN.1.
Panorâmica geral do perfil de comunicação 1
Este perfil abrange o caso em que um agente das autoridades de controlo
competentes utiliza um leitor de comunicações de deteção rápida à dis­
tância (interfaces DSRC de 5,8 GHz em aplicação da Recomendação
ERC 70-03 e ensaiadas em relação aos parâmetros pertinentes da norma
EN 300 674-1, conforme refere a secção 5) (o REDCR) para identificar à
distância um veículo que está em possível violação do disposto no
Regulamento (UE) n. o 165/2014. Uma vez identificado, o agente das
autoridades de controlo competentes que está a controlar a interrogação
decide se o veículo deve ser parado.
4.1.2 Perfil 1a: através de um leitor de comunicações de deteção rápida à
distância apontado manualmente ou montado e apontado temporaria­
mente à estrada
Neste caso de utilização, o agente das autoridades de controlo compe­
tentes está postado na berma da estrada e segura um REDCR manual de
mira, montado no tripé ou outro equipamento portátil semelhante, a
partir da berma da estrada, na direção do centro do para-brisas do
veículo visado. A interrogação é feita com recurso a interfaces DSRC
de 5,8 GHz, em aplicação da Recomendação ERC 70-03, e ensaiada em
relação aos parâmetros pertinentes da norma EN 300 674-1, conforme
refere a secção 5 (ver esquema 14.1 — Caso de utilização 1).
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 543
Esquema 14.1
Caso de utilização 1: interrogação de estrada com recurso a DSRC de
5,8 GHz
4.1.3 Perfil 1b: através de um leitor de comunicações de deteção rápida à
distância (REDCR) montado num veículo e direcionado
Neste caso de utilização, o agente das autoridades de controlo compe­
tentes está postado dentro de um veículo em movimento e segura um
REDCR manual de mira, portátil a partir do veículo, em direção ao
centro do para-brisas do veículo visado, ou o REDCR está montado
no interior ou no veículo de modo a apontar em direção ao centro do
para-brisas do veículo visado quando o veículo do leitor de comunica­
ções de deteção rápida à distância está numa posição particular per­
tinente para o veículo visado (por exemplo, diretamente em frente
num fluxo de tráfego). A interrogação é feita com recurso a interfaces
DSRC de 5,8 GHz em aplicação da Recomendação ERC 70-03 e en­
saiada em relação aos parâmetros pertinentes da norma EN 300 674-1,
conforme refere a secção 5 (ver esquema 14.2 — Caso de utilização 2).
Esquema 14.2
Caso de utilização 2: interrogação com base em veículo, com
recurso a DSRC de 5,8 GHz
4.2 Segurança/integridade
Para tornar possível verificar a autenticidade e a integridade dos dados
descarregados através da comunicação à distância, os dados seguros são
verificados e decifrados em conformidade com o apêndice 11 (Mecanis­
mos comuns de segurança).
5 CONCEÇÃO E PROTOCOLOS DA COMUNICAÇÃO À DISTÂNCIA
5.1 Conceção
A conceção da função de comunicação à distância no tacógrafo inteli­
gente é apresentada e descrita no esquema 14.3.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 544
Esquema 14.3
Conceção da função de comunicação à distância
DSC_19 As funções que se seguem localizam-se na VU:
— Módulo de Segurança (VUSM). Esta função, presente na
VU, é responsável pela proteção dos dados que se trans­
mitem da DSRC-VU ao agente das autoridades de controlo
competentes, através da comunicação à distância.
— Os dados protegidos são memorizados na memória VUSM.
Em intervalos determinados em 4.1.1.1 (DSC_12), a VU
encripta e reabastece o conceito RTMdata (que com­
preende dados de carga útil e valores de conceito de dados
de segurança determinados no presente apêndice), detido
na memória de DSRC-VU. O funcionamento do módulo
de segurança está definido no apêndice 11 (Mecanismos
comuns de segurança) e fora do âmbito de aplicação do
presente apêndice, com a ressalva de que é necessário
fornecer atualizações ao módulo de comunicação da VU
sempre que os dados VUSM mudarem.
— A comunicação entre a VU e a DSRC-VU pode ser uma
comunicação por cabo ou uma comunicação de baixo con­
sumo energético do Bluetooth (BLE), e a localização física
da DSRC-VU pode estar integrada na antena (no
para-brisas do veículo), pode ser interna à VU ou
localizar-se algures entre os dois.
— A DSRC-VU deve ter uma fonte fiável de energia per­
manentemente disponível. O meio pelo qual a energia
lhe é fornecida é uma decisão de conceção.
— A memória da DSRC-VU deve ser não-volátil, para que os
dados sejam mantidos mesmo quando a ignição do veículo
está desligada.
— Se a comunicação entre a VU e a DSRC-VU for efetuada
através de BLE e a fonte de energia for uma bateria não
recarregável, a fonte de energia da DSRC-VU deve ser
substituída a cada inspeção periódica e o fabricante do
equipamento DSRC-VU deve ser responsável por
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 545
garantir que a alimentação elétrica é adequada para durar
de uma inspeção periódica à seguinte, mantendo o acesso
normal aos dados por um REDCR durante todo o período,
sem falhas nem interrupções.
— Módulo de «memória de carga útil» VU RTM (VUPM).
Esta função, presente na VU, é responsável por fornecer e
atualizar os dados. O conteúdo dos dados («Tachograph­
Payload») está definido em 5.4.4/5.4.5 e é atualizado no
intervalo determinado em 4.1.1.1 (DSC_12).
— DSRC-VU. Esta é a função, no interior ou ligada à antena
e em comunicação com a VU através de uma ligação com
fios ou sem fios (BLE), que mantém os dados atuais
(VUPM-dados) e gere a resposta a uma interrogação no
meio de comunicação DSRC de 5,8 GHz. A desconexão
do módulo DSCR ou interferências durante o funciona­
mento normal do veículo com o funcionamento do módulo
DSRC devem ser interpretadas como violação do
Regulamento (UE) n. o 165/2014.
— Módulo de segurança (REDCR) (SM-REDCR) é a função
utilizada para decifrar e verificar a integridade dos dados
provenientes da VU. O meio pelo qual tal é conseguido
está determinado no apêndice 11 (Mecanismos comuns de
segurança) e não está definido no presente apêndice.
— A função do módulo DSRC (REDCR) (DSRC-REDCR)
compreende um emissor-recetor de 5,8 GHz e software
associado (permanente e não-permanente) que gere a co­
municação com a DSRC-VU em conformidade com o pre­
sente apêndice.
— A DSRC-REDCR interroga a DSRC-VU do veículo visado
e obtém os dados (VUPM-dados atuais do veículo visado),
através da ligação DSRC e processa e memoriza os dados
recebidos na sua SM-REDCR.
▼M1
— A antena DSRC-VU deve ser posicionada num local onde
otimize a comunicação DSRC entre o veículo e a antena
do lado da estrada, estando esta instalada a 15 m de dis­
tância à frente do veículo e a 2 m de altura, para apontar
ao centro horizontal e vertical do para-brisas. Nos veículos
ligeiros, é adequada a parte superior do para-brisas. Em
todos os demais veículos, a antena DSRC deve ser ins­
talada quer perto da parte inferior quer superior do
para-brisas.
▼B
DSC_20 A antena e a comunicação devem funcionar nos termos da
ERC 70-03, ensaiadas em relação aos parâmetros pertinentes
da norma EN 300 674-1, conforme refere a secção 5. A antena
e a comunicação podem pôr em prática técnicas de atenuação
do risco de interferência sem fios descritas no relatório
ECC 228, utilizando, por exemplo, filtros na comunicação
CEN DSRC 5,8 GHz.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 546
DSC_21 A antena DSRC deve estar ligada ao módulo DSRC-VU dire­
tamente no módulo montado ou junto ao para-brisas ou através
de um cabo dedicado construído de maneira a dificultar des­
conexão ilegal. Desconexão ou interferências com o funciona­
mento da antena constituem violações do Regulamento (UE)
n. o 165/2014. Ocultação deliberada ou outra forma de impacto
negativo no desempenho operacional da antena deve ser inter­
pretada como violação do Regulamento (UE) n. o 165/2014.
DSC_22 ►M1 O fator forma da antena não está definido e deve ser
uma decisão comercial, desde que a DSRC-VU montada sa­
tisfaça os requisitos de conformidade definidos na secção 5. A
antena é posicionada conforme determinado em DSC_19 e
aceita eficientemente os casos de utilização descritos em 4.1.2
e 4.1.3. ◄
Esquema 14.4
Exemplo de posicionamento da antena DSRC de 5,8 GHz no
para-brisas dos veículos regulamentados
O fator forma do REDCR e da respetiva antena pode variar de acordo
com as circunstâncias do leitor (montado em tripé, porte manual, mon­
tado no veículo, etc.) e com o modus operandi aplicado pelo agente das
autoridades de controlo.
A função de exibição e/ou notificação é utilizada para apresentar ao
agente das autoridades de controlo os resultados da função de comuni­
cação à distância. A exibição pode ser fornecida num ecrã, como resul­
tado impresso, sinal de áudio ou combinação das notificações. A forma
dessa exibição e/ou notificação depende dos agentes das autoridades de
controlo e da conceção do equipamento, não estando especificada no
presente apêndice.
DSC_23 O fator de conceção e forma do REDCR deve ser uma função
de conceção comercial, em aplicação da Recomendação
ERC 70-03 e das especificações de conceção e desempenho
definidas no presente apêndice (secção 5.3.2), proporcionando
assim a máxima flexibilidade de mercado para conceber e
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 547
fornecer equipamentos e cobrir os cenários específicos de in­
terrogação de qualquer autoridade de controlo competente.
DSC_24 O fator conceção e forma da DSRC-VU e o seu posiciona­
mento dentro ou fora da VU deve ser uma função de conceção
comercial, em aplicação da Recomendação ERC 70-03 e das
especificações de conceção e desempenho definidas no pre­
sente apêndice (secção 5.3.2) e nesta cláusula (5.1)
DSC_25 No entanto, a DSRC-VU deve ser razoavelmente capaz de
aceitar valores de conceito de dados de outro equipamento
inteligente de veículos por meio de uma conexão-padrão da
indústria aberta e protocolos (por exemplo, de equipamento de
pesagem a bordo), desde que os conceitos de dados sejam
identificados por identificadores de aplicação/nomes de fichei­
ros conhecidos e únicos. Por outro lado, as instruções de fun­
cionamento desses protocolos devem ser disponibilizadas à
Comissão Europeia e disponibilizadas, sem custos, aos fabri­
cantes dos equipamentos relevantes.
5.2 Fluxo de trabalho
5.2.1 Operações
O fluxo de trabalho das operações está representado no esquema 14.5.
Esquema 14.5
Fluxo de trabalho para a função de comunicação à distância
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 548
Descrevem-se seguidamente as fases:
a. Com o veículo em funcionamento (ignição ligada), o tacógrafo for­
nece dados à função da VU. A função da VU prepara os dados para
a função de comunicação à distância (encriptada) e atualiza o VUPM
guardado na memória da DSRC-VU (conforme definição em 4.1.1.1-
-4.1.1.2). Os dados recolhidos devem ser formatados conforme deter­
minado em 5.4.4-5.4.5.
b. Sempre que os dados são atualizados, o período de tempo definido
no conceito de dados de segurança é atualizado.
c. A função VUSM protege os dados em conformidade com os proce­
dimentos previstos no apêndice 11.
d. Sempre que são atualizados (ver 4.1.1.1-4.1.1.2), os dados são trans­
feridos para a DSRC-VU, onde substituem todos os dados anteriores,
para que esses dados atualizados (os dados) estejam sempre dispo­
níveis, no caso de uma interrogação por um REDCR. Se forem
fornecidos pela VU à DSRC-VU, os dados devem ser identificáveis
pelo nome de ficheiro RTMData ou pelos identificadores Applicatio­
nID e Attribute.
e. Se um agente de controlo quiser designar um veículo e recolher os
correspondentes dados, deve, em primeiro lugar, inserir o seu cartão
inteligente no REDCR para permitir a comunicação e para permitir
que o SM-REDCR verifique a sua autenticidade e decifre os dados.
f. O agente da autoridade de controlo competente designa um veículo e
pede os dados através da comunicação à distância. O REDCR abre
uma sessão da interface DSRC de 5,8 GHz com a DSRC-VU do
veículo visado e pede os dados. Os dados são transferidos para o
REDCR através do sistema de comunicações sem fios como um
DSRC Attribute utilizando o serviço de Application GET definido
em 5.4. O Attribute contém os valores encriptados de dados de carga
útil e os dados de segurança DSRC.
g. Os dados são analisados pelo equipamento REDCR e fornecidos ao
agente da autoridade de controlo competente.
h. O agente da autoridade de controlo competente utiliza os dados para
o auxiliar a decidir se deve ou não parar o veículo para uma inspeção
pormenorizada, ou pedir a outro agente da autoridade de controlo
competente para parar o veículo.
5.2.2 Interpretação dos dados recebidos através da comunicação DSRC
DSC_26 Os dados recebidos através da interface de 5,8 GHz devem
transportar o significado e a importação definidos nas secções
5.4.4 e 5.4.5 e apenas esse significado e essa importação, e
devem estar compreendidos nos objetivos neles definidos. Em
conformidade com o Regulamento (UE) n. o 165/2014, os
dados apenas devem ser utilizados para fornecer informações
pertinentes à autoridade de controlo competente com vista a
auxiliar os agentes na determinação de qual o veículo que
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 549
deve ser parado para inspeção física, sendo posteriormente
destruídos, conforme estipula o artigo 9. o do Regula­
mento (UE) n. o 165/2014.
5.3 Parâmetros da interface física DSRC para comunicação à distância
5.3.1 Restrições de localização
DSC_27 A interrogação à distância de veículos com recurso à interface
SRC de 5,8 GHz não deve ser utilizada a menos de 200
metros de um pórtico operacional DSRC de 5,8 GHz.
5.3.2 Parâmetros de ligação descendente e ascendente
DSC_28 O equipamento utilizado na monitorização tacográfica à dis­
tância deve estar conforme e em aplicação da Recomendação
ERC 70-03 e dos parâmetros definidos nos quadros 14.1 e
14.2 abaixo.
DSC_29 Além disso, para garantir a compatibilidade com os parâme­
tros operacionais dos outros sistemas DSRC de 5,8 GHz nor­
malizados, o equipamento utilizado na monitorização tacográ­
fica à distância deve estar em conformidade com os parâme­
tros das normas EN 12253 e EN 13372.
A saber:
Quadro 14.1
▼C2
Parâmetros de ligação descendente
Ponto Parâmetro Valor(es) Observação
D1 Frequências de ligação
descendente
O REDCR pode utilizar
quatro alternativas:
5,7975 GHz
5,8025 GHz
5,8075 GHz
5,8125 GHz
No limite de ERC 70-03.
As frequências de ligação podem
ser selecionadas pelo responsável
do sistema de controlo rodoviário
e não têm de ser conhecidas a nível
de DSRC-VU
(conforme EN 12253 e EN 13372)
D1a (*) Tolerância das frequências
de ligação
No limite de ± 5 ppm (conforme EN 12253)
D2 (*) Máscara espetral de emissão
da RSU (REDCR)
No limite de ERC 70-03.
O REDCR deve correspon­
der à classe B,C definida na
norma EN 12253.
Não há mais requisitos es­
pecíficos no presente anexo.
Parâmetro utilizado para controlar
interferências entre interrogadores
nas proximidades (cf. definição
nas normas EN 12253 e EN 13372)
D3 OBU (DSRC-VU) Gama
mínima de frequências
Entre 5,795 e 5,815 GHz (conforme EN 12253)
D4 (*) P.I.R.E. máxima No limite de ERC 70-03
(sem autorizações) e da re­
gulamentação nacional
Máximo + 33 dBm
(conforme EN 12253)
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 550
Ponto Parâmetro Valor(es) Observação
D4a Máscara angular P.I.R.E. Conforme especificação de­
clarada e publicada do pro­
jetista do interrogador
(conforme EN 12253)
D5 Polarização Circular no sentido retró­
grado
(conforme EN 12253)
D5a Polarização cruzada XPD:
No eixo de visão: (REDCR)
RSU t ≥ 15 dB
(DSRC-VU) OBU r
≥ 10 dB
Na zona – 3 dB: (REDCR)
RSU t ≥ 10 dB
(DSRC-VU) OBU r ≥ 6 dB
(conforme EN 12253)
D6 (*) Modulação Modulação de amplitude a
dois níveis
(conforme EN 12253)
D6a (*) Índice de modulação 0,5 … 0,9 (conforme EN 12253)
D6b Padrão do olho ≥ 90 % (tempo)/≥ 85 %
(amplitude)
D7 (*) Codificação de dados FM0
O bit «1» só tem transições
no início e no fim do inter­
valo. Em comparação com
o bit «1», o bit «0» tem
uma transição suplementar
no meio do intervalo.
(conforme EN 12253)
D8 (*) Débito de bits 500 kBit/s (conforme EN 12253)
D8a Tolerância do relógio de
bits
Melhor do que ± 100 ppm (conforme EN 12253)
D9 (*) Taxa de erro de bits
(B.E.R.) para a comunica­
ção
≤ 10 – 6 se a potência inci­
dente na OBU (DSRC-VU)
se situar na gama dada por
[D11a — D11b].
(conforme EN 12253)
D10 Sinal que aciona a OBU
(DSRC-VU)
A OBU (DSRC-VU) é acio­
nada ao receber uma cadeia
com 11 ou mais octetos (in­
cluindo preâmbulo)
Não é necessária nenhuma estrutura
especial de acionamento.
A DSRC-VU pode ser acionada ao
receber uma cadeia com menos de
11 octetos (conforme EN 12253)
D10a Tempo máximo de arranque ≤ 5 ms (conforme EN 12253)
D11 Zona de comunicação Espaço dentro do qual se
atinge um B.E.R. corres­
pondente a D9a
(conforme EN 12253)
D11a (*) Limite de potência para co­
municação (superior)
– 24dBm (conforme EN 12253)
▼C2
02016R0799 — PT — 21.08.2023 — 003.002 — 551
Ponto Parâmetro Valor(es) Observação
D11b (*) Limite de potência para co­
municação (inferior)
Potência incidente:
– 43 dBm (eixo de visão)
– 41 dBm [entre – 45° e +
45°, corresponde ao plano
paralelo à superfície da es­
trada quando a DSRC-VU é
instalada posteriormente no
veículo (Azimuth)]
(conforme EN 12253)
Requisito alargado a ângulos hori­
zontais até ± 45°, atendendo aos
casos de utilização definidos no
presente anexo
D12 (*) Nível da potência de corte
da DSRC-VU
– 60 dBm (conforme EN 12253)
D13 Preâmbulo O preâmbulo é obrigatório (conforme EN 12253)
D13a Comprimento e estrutura do
preâmbulo
16 bits ± 1 bit «1» codifi­
cado em FM0
(conforme EN 12253)
D13b Forma de onda do preâm­
bulo
Sequência alternante de ní­
vel baixo e nível elevado,
com 2 μs de duração de im­
pulso
Tolerância dada por D8a
(conforme EN 12253)
D13c Bits residuais A RSU (REDCR) é autori­
zada a emitir um máximo
de 8 bits depois do sinal
de fim. A OBU (DSRC-
-VU) não é obrigada a ter
em conta estes bits
suplementares.
(conforme EN 12253)
▼B
(*) — Parâmetros de ligação descendente sujeitos a ensaios de conformidade segundo a norma EN 300 674-1
Quadro 14.2
▼C2
Parâmetros de ligação ascendente
Item Parâmetro Valor(es) Observação
U1 (*) Frequências de subligação A OBU (DSRC-VU) deve
comportar 1,5 MHz e 2,0
MHz
A RSU (REDCR) deve
comportar 1,5 MHz ou 2,0
MHz ou ambos. U1-0: 1,5
MHz U1-1: 2,0 MHz
A seleção da frequência de subliga­
ção (1,5 MHz ou 2,0 MHz) de­
pende do perfil EN 13372
selecionado.
U1a (*) Tolerância das frequências
de subligação
No intervalo ± 0,1 % (conforme EN 12253)
U1b Utilização de bandas late­
rais
Mesmos dados em ambos
os lados
(conforme EN 12253)
U2 (*) Máscara espetral de emissão
da OBU (DSRC-VU)
Conforme EN12253
1) Potência extrabanda:
ver ETSI EN 300674-1
(conforme EN 12253)
▼C2
02016R0799 — PT — 21.08.2023 — 003.002 — 552
Item Parâmetro Valor(es) Observação
2) Potência intrabanda:
[U4a] dBm a 500 kHz
3) Emissão noutro qualquer
canal ascendente:
U2(3)-1 = – 35 dBm a
500 kHz
U4a (*) P.I.R.E. máxima — banda
lateral única (eixo de visão)
Duas opções:
U4a-0: – 14 dBm
U4a-1: – 21 dBm
Conforme especificação declarada e
publicada do projetista do equipa­
mento
U4b (*) P.I.R.E. máxima — banda
lateral única (35°)
Duas opções:
— Não aplicável
— – 17dBm
Conforme especificação declarada e
publicada do projetista do equipa­
mento
U5 Polarização Circular no sentido retró­
grado
(conforme EN 12253)
U5a Polarização cruzada XPD:
Eixo de visão: (REDCR)
RSU r ≥ 15 dB
(DSRC-VU) OBU
t ≥ 10 dB
Na zona – 3 dB: (REDCR)
RSU r ≥ 10 dB
(DSRC-VU) OBU t ≥ 6 dB
(conforme EN 12253)
U6 Modulação de subligação 2-PSK
Dados codificados sincroni­
zados com a subligação:
Transições de dados codifi­
cados coincidem com tran­
sições de subligação
(conforme EN 12253)
U6b Ciclo de funcionamento Ciclo de funcionamento:
50 % ± α, α ≤ 5 %
(conforme EN 12253)
U6c Modulação em ligação Multiplicação da subligação
modulada pela ligação
(conforme EN 12253)
U7 (*) Codificação de dados NRZI (sem transição no iní­
cio do bit «1», com transi­
ção no início do bit «0»,
sem transição no interior
do bit)
(conforme EN 12253)
U8 (*) Débito de bits 250 kbit/s (conforme EN 12253)
U8a Tolerância do relógio de
bits
No intervalo ± 1 000 ppm (conforme EN 12253)
U9 Taxa de erro de bits
(B.E.R.) para a comunica­
ção
≤ 10 – 6 (conforme EN 12253)
▼C2
02016R0799 — PT — 21.08.2023 — 003.002 — 553
Item Parâmetro Valor(es) Observação
U11 Zona de comunicação Espaço dentro do qual está
situada a DSRC-VU, de
modo tal que as suas emis­
sões são recebidas pelo
REDCR com uma B.E.R.
inferior à dada por U9a
(conforme EN 12253)
U12a (*) Ganho de conversão (limite
inferior)
1 dB para cada banda late­
ral
Abertura angular: circular­
mente simétrica entre o
eixo de visão e ± 35° [entre
– 45° e + 45°, corresponde
ao plano paralelo à superfí­
cie da estrada quando
a DSRC-VU é instalada
posteriormente no veículo
(Azimuth)]
No caso de ângulos horizontais
até ± 45°, a abertura é maior do
que a especificada, atendendo aos
casos de utilização definidos no
presente anexo
U12b (*) Ganho de conversão (limite
superior)
10 dB para cada banda late­
ral
Para cada banda lateral dentro de
um cone circular em torno de um
eixo de visão com um ângulo
de ± 45°, a abertura é menor do
que a especificada
U13 Preâmbulo O preâmbulo é obrigatório (conforme EN 12253)
U13a Comprimento e estrutura do
preâmbulo
32 a 36 μs, modulado com
subligação apenas; depois,
8 bits «0» codificados em
NRZI
(conforme EN 12253)
U13b Bits residuais A DSRC-VU é autorizada a
emitir um máximo de 8 bits
depois do sinal de fim. A
RSU (REDCR) não é obri­
gada a ter em conta estes
bits suplementares.
(conforme EN 12253)
▼B
(*) — Parâmetros de ligação ascendente sujeitos a ensaios de conformidade segundo a norma EN 300 674-1
5.3.3 Conceção das antenas
5.3.3.1 Antena REDCR
DSC_30 A conceção da antena REDCR deve ser uma função de con­
ceção comercial, a operar dentro dos limites definidos na
secção 5.3.2, adaptados para otimizar o desempenho de leitura
do DSRC-REDCR com a finalidade específica e as circuns­
tâncias de leitura nas quais o REDCR foi concebido para
funcionar.
5.3.3.2 Antena da VU
DSC_31 A conceção da antena DSRC-VU deve ser uma função de
conceção comercial, a operar dentro dos limites definidos
na secção 5.3.2, adaptados para otimizar o desempenho de
leitura do DSRC-REDCR com a finalidade específica e as
circunstâncias de leitura nas quais o REDCR foi concebido
para funcionar.
▼C2
02016R0799 — PT — 21.08.2023 — 003.002 — 554
DSC_32 A antena da VU deve ser fixada ou aproximada ao para-brisas
dianteiro do veículo, conforme especificado na secção 5.1.
DSC_33 No ambiente de ensaio de uma oficina (ver secção 6.3), uma
antena da DSRC-VU, colocada conforme descrito em 5.1,
deve ligar-se com êxito a uma comunicação de
ensaio-padrão e proporcionar uma transação RTM
bem-sucedida, conforme definido no presente apêndice, a
uma distância de 2 a 10 metros, melhor do que 99 % das
vezes, com uma média superior a 1 000 interrogações de
leitura.
5.4 Requisitos de protocolo DSRC para RTM
5.4.1 Panorâmica
DSC_34 O protocolo de transação para descarregamento dos dados
através da ligação da interface DSRC de 5,8 GHz deve cum­
prir as etapas que se seguem (esta secção descreve um fluxo
de transação em condições ideais, sem retransmissões nem
interrupções de comunicação).
NOTA: A finalidade da fase de inicialização (etapa 1) é es­
tabelecer a comunicação entre o REDCR e as DSRC-VU que
entraram na área de transação da DSRC de 5,8 GHz (princi­
pal-secundário) mas ainda não estabeleceram comunicação
com o REDCR, e notificar os processos da aplicação.
— Etapa 1— Inicialização. O REDCR envia uma estrutura
que contém um «quadro de serviço de baliza» (BST), que
inclui os identificadores de aplicação (AID) na lista de
serviço que aceita. Na aplicação RTM será simplesmente
o serviço com o valor AID = 2 (carga e frota). A DSRC-
-VU avalia o BST recebido e responde (ver adiante) com a
lista das aplicações aceites no domínio carga e frota, ou
não responde se nenhum for aceite. Se o REDCR não
oferecer AID=2, a DSRC-VU não responde ao REDCR.
— Etapa 2— A DSRC-VU envia uma estrutura que contém
um pedido de atribuição de janela privada.
— Etapa 3— O REDCR envia uma estrutura que contém
um pedido de atribuição de janela privada.
— Etapa 4— A DSRC-VU utiliza a janela privada atribuída
para enviar uma estrutura que contém o seu quadro de
serviço do veículo (VST). Este VST inclui uma lista de
todas as instanciações de aplicação diferentes que esta
DSRC-VU aceita no âmbito de AID=2. As diferentes ins­
tanciações devem ser identificadas por meio de EID de
geração exclusiva, cada um associado a um valor do
parâmetro Application Context Mark que indica a aplica­
ção e a norma aceites.
— Etapa 5— Em seguida, o REDCR analisa o VST ofere­
cido e termina a ligação (RELEASE), uma vez que não
está interessado em nada do que o VST tem para oferecer
(ou seja, está a receber um VST de uma DSRC-VU que
não aceita a transação RTM) ou, se receber um VST
adequado, inicia uma instanciação da aplicação.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 555
— Etapa 6— Para que tal aconteça, o REDCR deve enviar
uma estrutura que contém um comando de recuperação
dos dados RTM, identificando a instanciação da aplicação
RTM por meio da especificação do identificador corres­
pondente à instanciação da aplicação RTM (conforme
especificado pela DSRC-VU no VST) e atribui uma janela
privada.
— Etapa 7— A DSRC-VU utiliza a janela privada atribuída
recentemente para enviar uma estrutura que contém o
identificador tratado correspondente à instanciação da
aplicação RTM conforme previsto no VST, seguido
pelo atributo RtmData (elemento de carga útil + elemento
de segurança).
— Etapa 8— Se houver vários serviços pedidos, o valor
«n» é alterado para o número de referência de serviço
seguinte e o processo é repetido.
— Etapa 9— O REDCR confirma a receção dos dados,
enviando uma estrutura que contém um comando RE­
LEASE para a DSRC-VU terminar a sessão OU, se não
tiver conseguido validar uma receção bem sucedida do
LDPU, volta à etapa 6.
Ver no esquema 14.6 uma imagem do protocolo de transação.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 556
Esquema 14.6
RTM acima do fluxo de processo DSRC de 5,8 GHz
5.4.2 Comandos
DSC_35 Os comandos que se seguem são as únicas funções utilizadas
numa fase de transação RTM:
— INITIALISATION.request: comando emitido a partir do
REDCR sob a forma de uma transmissão com a definição
de aplicações que o REDCR aceita.
— INITIALISATION.response: resposta da DSRC-VU que
confirma a conexão e contém uma lista de instâncias de
aplicações aceites com características e informações sobre
como tratá-las (EID).
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 557
— GET.request: comando emitido do REDCR para a
DSRC-VU, que especifica a instanciação da aplicação a
tratar por meio de um EID definido, recebido no VST,
instruindo a DSRC-VU para enviar o atributo selecionado
com os dados. O objetivo do comando GET é que o
REDCR obtenha os dados da DSRC-VU.
— GET.response: resposta da DSRC-VU que contém os
dados pedidos.
— ACTION.request ECHO: comando que instrui a DSRC-
-VU para devolver os dados da DSRC-VU para o REDCR.
O objetivo do comando ECHO é autorizar as oficinas ou
unidades de ensaio de homologações de tipo a testar se a
ligação DSRC funciona sem necessidade de acesso a cre­
denciais de segurança.
— ACTION.response ECHO: resposta da DSRC VU no
comando ECHO.
— EVENT_REPORT.request RELEASE: comando que
dá instrução à DSRC-VU de que a transação está finali­
zada. O objetivo do comando RELEASE é terminar a
sessão com a DSRC-VU. Ao receber o comando RE­
LEASE, a DSRC-VU não responde a mais nenhumas in­
terrogações no âmbito da conexão atual. De salientar que,
segundo a norma EN 12834, uma DSRC-VU não se li­
gará duas vezes ao mesmo interrogador, a menos que
tenha estado fora da área de comunicação durante 255
segundos ou se a ID da baliza do interrogador for
alterada.
5.4.3 Sequência de comandos de interrogação
DSC_36 Do ponto de vista da sequência de comando e resposta, a
transação é descrita da seguinte forma:
▼C2
Sequência Emissor Recetor Descrição Ação
1 REDCR > DSRC-VU Inicialização da ligação de
comunicação — Pedido
REDCR difunde BST
2 DSRC-VU > REDCR Inicialização da ligação de
comunicação — Resposta
Se BST comportar AID = 2,
DSRC-VU pede atribuição de
janela privada
3 REDCR > DSRC-VU Atribui janela privada Envia estrutura que contém
atribuição de janela privada
4 DSRC-VU > REDCR Envia VST Envia estrutura que inclui
VST
5 REDCR > DSRC-VU Envia GET.request relativo
a dados contidos no atri­
buto para EID específico
6 DSRC-VU > REDCR Envia GET.response com o
atributo pedido para o EID
específico
Envia atributo (RTMData,
OWSData…) com os dados
para o EID específico
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 558
Sequência Emissor Recetor Descrição Ação
7 REDCR > DSRC-VU Envia GET.request relativo
a dados de outro atributo
(se pertinente)
8 DSRC-VU > REDCR Envia GET.response com o
atributo pedido
Envia atributo com os dados
para o EID específico
9 REDCR > DSRC-VU Acusa receção dos dados Envia comando RELEASE
que encerra a transação
10 DSRC-VU Encerra transação
▼B
Nas cláusulas 5.4.7 e 5.4.8 é definido um exemplo de sequên­
cia e conteúdos de transação das estruturas intercambiadas.
5.4.4 Estruturas de dados
DSC_37 A estrutura semântica dos dados, quando passados através da
interface DSRC de 5,8 GHz, deve ser compatível com o des­
crito no presente apêndice. O modo como esses dados estão
estruturados é especificado na presente cláusula.
DSC_38 A carga útil (dados RTM) é composta pela concatenação de:
1. Dados EncryptedTachographPayload: trata-se da encripta­
ção da TachographPayload definida em ASN.1, na secção
5.4.5. O método de encriptação é descrito no apêndice 11;
2. DSRCSecurityData, especificado no apêndice 11.
DSC_39 Os dados RTM são tratados como RTM Attribute = 1 e são
transferidos no RTM container =10.
DSC_40 A marca de contexto RTM identificador da parte normalizada
aceite na série das normas TARV (RTM corresponde à parte 9).
A definição do módulo ASN.1 para os dados DSRC na apli­
cação RTM é definida como se segue:
▼C2
02016R0799 — PT — 21.08.2023 — 003.002 — 559
► (2) (3) M1
► (1) M3
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 560
5.4.5 Elementos de RtmData, ações realizadas e definições
DSC_41 Os valores de dados a calcular pela VU e utilizados para
atualizar os dados seguros na DSRC-VU devem ser calcula­
dos de acordo com as regras definidas no quadro 14.3:
▼M3
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 ele­
mento de dados RTM1
tp15638VehicleRegistration­
Plate a partir do valor regis­
tado do tipo de dados
VehicleRegistrationIdentifica­
tion como definido no apên­
dice 1 VehicleRegistrationI­
dentification
Placa de matrícula do
veículo expressa numa
sequência de carateres
tp15638VehicleRegistration­
Plate LPN, –Placa de matrí­
cula
do veículo utilizando a estru­
tura 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 de­
terminante 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 tp15638Speedin­
gEvent é calculado pela VU a
partir dos incidentes de ex­
cesso de velocidade regista­
dos na VU nos últimos 10
dias, conforme definido no
anexo IC.
1 (TRUE): se o incidente
de excesso de velocidade
mais recente tiver termi­
nado nos últimos 10 dias
ou continuar a verificar-
-se;
0 (FALSE): em qualquer
outro caso.
tp15638SpeedingEvent BOO­
LEAN,
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 561
(1)
Elemento de dados RTM
(2)
Ação realizada pela VU
(3)
Definição de dados ASN.1
RTM3
Condução sem
cartão válido
A VU gera um valor
booleano para o elemento de
dados RTM3
tp15638DrivingWithoutVa­
lidCard.
A VU atribui um valor
TRUE à variável
tp15638DrivingWithoutVa­
lidCard 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 re­
cente sem um cartão
apropriado tiver termi­
nado nos últimos 10 dias
ou continuar a verificar-
-se;
0 (FALSE): em qualquer
outro caso.
tp15638DrivingWithoutValid­
Card
BOOLEAN,
RTM4
Cartão de condutor vá­
lido
A VU gera um valor boo­
leano 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 ra­
nhura do condutor da
VU;
tp15638DriverCard BOO­
LEAN,
RTM5
Inserção do cartão du­
rante
a condução
A VU gera um valor boo­
leano para o elemento de
dados RTM5 tp15638Car­
dInsertion.
A VU atribui um valor
TRUE à variável
tp15638CardInsertion se pelo
menos um incidente de in­
serçã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 con­
dução tiver ocorrido nos
últimos 10 dias;
0 (FALSE): em qualquer
outro caso.
tp15638CardInsertion BOO­
LEAN,
RTM6
Erro nos dados de mo­
vimento
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 regis­
tado na VU nos últimos 10
dias, conforme definido no
anexo IC.
1 (TRUE): se o incidente
mais recente de erro nos
dados de movimento ti­
ver terminado nos últi­
mos 10 dias ou continuar
a verificar-se;
0 (FALSE): em qualquer
outro caso.
tp15638MotionDataError
BOOLEAN,
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 562
(1)
Elemento de dados RTM
(2)
Ação realizada pela VU
(3)
Definição de dados ASN.1
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
tp15638VehicleMotionCon­
flict se pelo menos um inci­
dente 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 termi­
nado 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 esti­
ver presente na VU
2 (FALSE): se não esti­
ver presente na VU ne­
nhum cartão de ajudante
válido.
tp156382ndDriverCard BOO­
LEAN,
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 qual­
quer uma atividade diferente
de «DRIVING», conforme
definido no anexo IC, a VU
fixa a variável em TRUE.
1 (TRUE): outra ativi­
dade
selecionada;
0 (FALSE): condução
selecionada
tp15638CurrentActivityDri­
ving
BOOLEAN
RTM10
Última sessão encerrada
A VU gera um valor boo­
leano 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 incorreta­
mente»;
0 (FALSE): nenhum dos
cartões inseridos acionou
um incidente «última
sessão do cartão encer­
rada incorretamente».
tp15638LastSessionClosed
BOOLEAN
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 563
(1)
Elemento de dados RTM
(2)
Ação realizada pela VU
(3)
Definição de dados ASN.1
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 tp15638PowerSup­
plyInterruption igual ao nú­
mero de incidentes de inter­
rupção da alimentação ener­
gética memorizados na VU
nos últimos 10 dias, con­
forme definido no anexo IC.
Se não tiver sido registado
nenhum incidente de inter­
rupção da alimentação ener­
gé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.
tp15638PowerSupplyInterrup­
tion
INTEGER (0..127),
RTM12
Falha do sensor
A VU gera um valor inteiro
para o elemento de dados
RTM12.
A VU atribui à variável sen­
sorFault 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 tive­
rem terminado durante os
últimos 10 dias ou con­
tinuarem a verificar-se.
— 5 Se a falha do sensor e
o erro de comunicação
com o incidente do mó­
dulo GNSS externo tive­
rem terminado durante os
últimos 10 dias ou con­
tinuarem a verificar-se.
- falha do sensor um
octeto de acordo com o
dicionário de dados
tp15638SensorFault INTEGER
(0..255),
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 564
(1)
Elemento de dados RTM
(2)
Ação realizada pela VU
(3)
Definição de dados ASN.1
— 6 Se a falha do recetor
GNSS e o erro de co­
municação com o inci­
dente do módulo GNSS
externo tiverem termi­
nado 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 fi­
xar o valor de RTM12 em 0.
RTM13
Ajustamento do tempo
A VU gera um valor inteiro
(timeReal do apêndice 1)
para o elemento de dados
RTM13 com base na pre­
sença de dados de ajusta­
mento 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, con­
forme 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 pre­
sença de dados de ajusta­
mento do tempo, conforme
definido no anexo IC.
A VU define o valor da hora
da tentativa mais recente de
violação da segurança regis­
tada pela VU.
Se nenhum incidente de ten­
tativa de violação da segu­
ranç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 inci­
dente mais recente de
tentativa de violação da
segurança.
tp15638LatestBreachAttempt
INTEGER(0..4294967295),
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 565
(1)
Elemento de dados RTM
(2)
Ação realizada pela VU
(3)
Definição de dados ASN.1
RTM15
Última calibração
A VU gera um valor inteiro
(timeReal do apêndice 1)
para o elemento de dados
RTM15 com base na pre­
sença de dados de ajusta­
mento do tempo, conforme
definido no anexo IC.
A VU fixa o valor de
RTM15 no oldTimeValue do
mais recente registo da cali­
bração.
Se não tiver havido calibra­
ção, a VU fixa o valor de
RTM15 em 0.
oldTimeValue do mais
recente registo da cali­
braçã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 à úl­
tima 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 cali­
bração da VU no veículo
atual.
tp15638DateTachoConnected
INTEGER(0..4294967295),
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 566
(1)
Elemento de dados RTM
(2)
Ação realizada pela VU
(3)
Definição de dados ASN.1
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 INTE­
GER (0..255),
RTM19
Selo temporal
A VU gera um valor inteiro
para o elemento de dados
RTM19 (timeReal do apên­
dice 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 re­
cente posição autenti­
cada 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 autenti­
cada do veículo ficou dispo­
nível a partir do recetor
GNSS.
Se nunca tiver estado dispo­
nível uma posição autenti­
cada do veículo a partir do
recetor GNSS, a VU fixa o
valor de RTM20 em 0.
Selo temporal da mais
recente posição autenti­
cada do veículo
tp15638LatestAuthenticatedPo­
sition
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 va­
lor 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 condu­
tor é 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á dis­
ponível.
tp15638ContinuousDriving­
Time INTEGER(0..255),
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 567
(1)
Elemento de dados RTM
(2)
Ação realizada pela VU
(3)
Definição de dados ASN.1
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 con­
dução do condutor, que é o
turno RTM em curso ou o
anterior.
Tempo diário de condu­
ção do condutor, codifi­
cado como um valor in­
teiro.
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á dis­
poní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, codifi­
cado como um valor in­
teiro.
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á dis­
ponível.
tp15638DailyDrivingTime­
Week INTEGER(0..255),
RTM24
Tempo semanal de con­
duçã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 con­
dução do condutor, co­
dificado 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á dis­
ponível.
tp15638WeeklyDrivingTime
INTEGER(0..255),
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 568
(1)
Elemento de dados RTM
(2)
Ação realizada pela VU
(3)
Definição de dados ASN.1
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 va­
lor 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á dis­
ponível.
tp15638FortnightlyDriving­
Time INTEGER(0..255),
Nota: RTM22, RTM23, RTM24 e RTM25 são calculados de acordo com a
adenda ao presente apêndice
▼B
5.4.6 Mecanismo de transferência de dados
DSC_42 Os dados de carga útil definidos anteriormente são pedidos
pelo REDCR após a fase de inicialização e, consequente­
mente, transmitidos pela DSRC-VU na janela atribuída. O
comando GET é utilizado pelo REDCR para recuperar dados.
▼M1
DSC_43 Relativamente a todos os intercâmbios DSRC, os dados
devem ser codificados utilizando PER (regras de codificação
compactadas) NÃO ALINHADAS, exceto
e , que são codi­
ficados utilizando OER (regras de codificação de octetos)
definidas na norma ISO/IEC 8825-7, Rec. ITU-T X.696.
▼B
5.4.7 Descrição pormenorizada de transação DSRC
DSC_44 A inicialização é realizada de acordo com DSC_44 a DSC_48
e quadros 14.4-14.9. Na fase de inicialização, o REDCR co­
meça a enviar uma estrutura que contém um BST (quadro de
serviço de baliza) nos termos das normas EN 12834 e
EN 13372, 6.2, 6.3, 6.4 e 7.1, com as configurações especi­
ficadas no quadro 14.4:
Quadro 14.4
▼C2
Inicialização — Configurações da estrutura BST
Campo Configurações
Link Identifier Endereço de difusão
BeaconId Conforme EN 12834
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 569
Time Conforme EN 12834
Profile Sem extensão — utilizar 0
ou 1
MandApplications Sem extensão, EID não pre­
sente, parâmetro não pre­
sente, AID = 2
Freight&Fleet
NonMandApplications Não presente
ProfileList Sem extensão, número de
perfis na lista = 0
Fragmentation header Sem fragmentação
Layer 2 settings PDU de comando, comando
UI
▼B
No quadro 14.5 que se segue é apresentado um exemplo
prático das configurações especificadas no quadro 14.4, com
uma indicação de codificações de bits.
Quadro 14.5
▼C2
Inicialização — Exemplo do conteúdo da estrutura BST
N
.o
d
o
oc
te
to

Atributo/campo Bits no octeto Descrição
1 FLAG Sinal (bandeira) de início
2 Broadcast ID Endereço de difusão
3 MAC Control Field PDU de comando
4 LLC Control field Comando UI
5 Fragmentation header Sem fragmentação
6 BST Pedido de inicialização
SEQUENCE {
OPTION indicator
BeaconID SEQUENCE {
ManufacturerId INTEGER (0..65535)
Aplicações NonMand não
presentes
Identificador do fabricante
7
8
IndividualID INTEGER (0..134217727) ID de 27 bits disponível
para o fabricante
9
10
11 }
▼C2
02016R0799 — PT — 21.08.2023 — 003.002 — 570
N
.o
d
o
oc
te
to

Atributo/campo Bits no octeto Descrição
12 Time INTEGER (0..4294967295) Tempo real UNIX de
32 bits
13
14
15
16 Profile INTEGER (0..127,…) Sem extensão. Perfil de
exemplo 0
17 MandApplications SEQUENCE
(SIZE(0..127, …))
OF {
Sem extensão, número de
mandApplications = 1
18 SEQUENCE {
OPTION indicator EID não presente
OPTION indicator Parâmetro não presente
AID DSRCApplicationEntityID}} Sem extensão. AID = 2
Freight&Fleet
19 ProfileList SEQUENCE (0..127,…) OF
Profile}
Sem extensão, número de
perfis na lista = 0
20 FCS Sequência de verificação
da estrutura
21
22 Flag Sinal (bandeira) de termi­
nação
▼B
DSC_45 Ao receber um BST, a DSRC-VU necessita da atribuição de
uma janela privada, especificada pelas normas EN 12795 e
EN 13372, cláusula 7.1.1, sem configurações RTM específi­
cas. O quadro 14.6 apresenta um exemplo de codificação de
bits:
Quadro 14.6
▼C2
Inicialização — Conteúdos da estrutura de pedido de atribuição de janela privada
N
.o
d
o
oc
te
to

Atributo/campo Bits no octeto Descrição
1 FLAG Sinal (bandeira) de início
2 Private LID Endereço de ligação da
DSRC-VU específica
3
4
5
6 MAC Control field Pedido de atribuição de
janela privada
7 FCS Sequência de verificação
da estrutura
8
9 Flag Sinal (bandeira) de termi­
nação
▼C2
02016R0799 — PT — 21.08.2023 — 003.002 — 571
DSC_46 O REDCR responde mediante a atribuição de uma janela
privada, conforme especificado pelas normas EN 12795 e
EN 13372, cláusula 7.1.1, sem configurações RTM específi­
cas.
O quadro 14.7 apresenta um exemplo de codificação de bits.
Quadro 14.7
▼C2
Inicialização — Conteúdos da estrutura de atribuição de janela privada
N
.o
d
o
oc
te
to

Atributo/campo Bits no octeto Descrição
1 FLAG Sinal (bandeira) de início
2 Private LID Endereço de ligação da
DSRC-VU específica
3
4
5
6 MAC Control field Atribuição de janela pri­
vada
7 FCS Sequência de verificação
da estrutura
8
9 Flag Sinal (bandeira) de termi­
nação
▼B
DSC_47 Ao receber a atribuição de janela privada, a DSRC-VU envia
o seu VST (quadro de serviço de veículo), conforme definido
nas normas EN 12834 e EN 13372, 6.2, 6.3, 6.4 e 7.1, com
as configurações especificadas no quadro 14.8, utilizando a
janela de transmissão atribuída.
Quadro 14.8
▼C2
Inicialização — Configurações da estrutura VST
Campo Configurações
Private LID Conforme EN 12834
VST parameters Fill = 0. Em seguida, por cada apli­
cação compatível: EID presente, parâ­
metro presente, AID = 2, EID tal
como gerado pela OBU
Parameter Sem extensão. Contém a marca de
contexto RTM
ObeConfiguration O campo opcional ObeStatus pode es­
tar presente, mas não deve ser utili­
zado pelo REDCR
Fragmentation header Sem fragmentação
Layer 2 settings PDU de comando, comando UI
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 572
DSC_48 A DSRC-VU aceita a aplicação «Carga e Frota», identificada
pelo identificador de aplicação «2». Podem ser aceites outros
identificadores de aplicação, mas não estão presentes neste
VST, dado que o BST exige apenas AID = 2. O campo
«aplicações» contém uma lista das instâncias de aplicação
aceites na DSRC-VU. Para cada instanciação de aplicação é
atribuída a referência à norma adequada, constituída por uma
marca Rtm Context, que é composta por um IDENTIFICA­
DOR DE OBJETO que representa a norma a que se refere, a
sua parte (9 para RTM) e, eventualmente, a sua versão, além
de um EID que é criado pela DSRC-VU e associado a essa
instância de aplicação.
No quadro 14.9 que se segue é apresentado um exemplo
prático das configurações especificadas no quadro 14.8, com
uma indicação de codificações de bits.
▼M3
Quadro 14.9
Inicialização — exemplo de conteúdos da estrutura VST
n.
o
d
e
oc
te
to
s
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 iden­
tificando a instância de
aplicação.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 573
n.
o
d
e
oc
te
to
s
Atributo/campo Bits no octeto Descrição
14 Parameter Container { 0000 0010 Sem extensão, Escolha de
contentor = 02,
Cadeia de octetos
15 0000 0110 Sem extensão, Compri­
mento da marca de con­
texto 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 se­
guida (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 fabri­
cante 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
▼B
DCS_49 O REDCR lê os dados emitindo um comando GET, em con­
formidade com o comando GET definido nas normas
EN 13372, 6.2, 6.3, 6.4, e EN 12834, com as configurações
especificadas no quadro 14.10.
Quadro 14.10
▼C2
Apresentação — Configurações da estrutura de pedido GET
Campo Configurações
Invoker Identifier (IID) Não presente
Link Identifier (LID) Endereço de ligação da DSRC-VU es­
pecífica
Chaining Não
Element Identifier (EID) Conforme especificação na VST. Sem
extensão
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 574
Campo Configurações
Access Credentials Não
AttributeIdList Sem extensão, 1 atributo, Attribu­
teID = 1 (RtmData)
Fragmentation Não
Layer2 settings PDU de comando, comando ACn so­
licitado
▼B
O quadro 14.11 mostra um exemplo da leitura dos dados
RTM.
Quadro 14.11
▼C2
Apresentação — Exemplo de estrutura de pedido Get
N
.o
d
o
oc
te
to

Atributo/campo Bits no octeto Descrição
1 FLAG Sinal (bandeira) de início
2 Private LID Endereço de ligação da
DSRC-VU específica
3
4
5
6 MAC Control field PDU de comando
7 LLC Control field Comando ACn solicitado,
bit n
8 Fragmentation header Sem fragmentação
9 Get.request
SEQUENCE {
Pedido Get
OPTION indicator Credenciais de acesso não
presentes
OPTION indicator IID não presente
OPTION indicator AttributeIdList presente
Fill BIT STRING(SIZE (1)) Fixado em 0
10 EID INTEGER(0..127,…) O EID da instância de
aplicação RTM, conforme
especificação na VST.
Sem extensão
11 AttributeIdList SEQUENCE OF {
AttributeId}}
Sem extensão, número de
atributos = 1
12 AttributeId = 1, RtmData.
Sem extensão
13 FCS Sequência de verificação
da estrutura
14
15 Flag Sinal (bandeira) de termi­
nação
▼C2
02016R0799 — PT — 21.08.2023 — 003.002 — 575
DSC_50 Ao receber o comando Get Request, a DSRC-VU, envia uma
resposta Get com os dados pedidos, em conformidade com o
Get response definido nas normas EN 13372, 6.2, 6.3, 6.4, e
EN 12834, com configurações conforme especificado no qua­
dro 14.12.
Quadro 14.12
▼C2
Apresentação — Configurações da estrutura de resposta
Get
Campo Configurações
Invoker Identifier (IID) Não presente
Link Identifier (LID) Conforme EN 12834
Chaining Não
Element Identifier (EID) Conforme especificação na
VST
Access Credentials Não
Fragmentation Não
Layer2 settings PDU de resposta. Resposta
disponível e comando aceite.
Comando ACn
▼B
O quadro 14.13 mostra um exemplo da leitura dos dados
RTM.
Quadro 14.13
▼C2
Apresentação — Exemplo de conteúdos da estrutura de resposta
N
.o
d
o
oc
te
to

Atributo/campo Bits no octeto Descrição
1 FLAG Sinal (bandeira) de início
2 Private LID Endereço de ligação da
DSRC-VU específica
3
4
5
6 MAC Control field PDU de resposta
7 LLC Control field Resposta disponível, co­
mando ACn bit n
8 LLC Status field Resposta disponível e co­
mando aceite
9 Fragmentation header Sem fragmentação
10 Get.response
SEQUENCE {
Obter resposta
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 576
N
.o
d
o
oc
te
to

Atributo/campo Bits no octeto Descrição
OPTION indicator IID não presente
OPTION indicator Lista de atributos presente
OPTION indicator Estatuto de devolução não
presente
Fill BIT STRING(SIZE(1)) Não utilizado
11 EID INTEGER(0..127,…) A responder da aplicação
RTM Instance. Sem ex­
tensão,
12 AttributeList SEQUENCE OF { Sem extensão, número de
atributos = 1
13 Attributes SEQUENCE {
AttributeId
Sem extensão, Attribu­
teId = 1 (RtmData)
14 AttributeValue CONTAINER { Sem extensão, escolha de
contentor
= 10 10
15 RtmData
16
17
… …
n }}}}
n+1 FCS Sequência de verificação
da estrutura
n+2
n+3 Flag Sinal (bandeira) de termi­
nação
▼B
DSC_51 O REDCR encerra a conexão mediante a emissão de um
comando EVENT_REPORT, RELEASE conforme às normas
EN 13372, 6.2, 6.3, 6.4, e EN 12834, 7.3.8, sem configura­
ções RTM específicas. O quadro 14.14 mostra um exemplo
de codificação de bits do comando RELEASE.
Quadro 14.14
▼C2
Terminação — Conteúdo da estrutura de terminação da ligação EVENT_REPORT
N
.o
d
o
oc
te
to

Atributo/campo Bits no octeto Descrição
1 FLAG Sinal (bandeira) de início
2 Private LID Endereço de ligação da
DSRC-VU específica
3
4
▼C2
02016R0799 — PT — 21.08.2023 — 003.002 — 577
N
.o
d
o
oc
te
to

Atributo/campo Bits no octeto Descrição
5
6 MAC Control field A estrutura contém um
comando LPDU
7 LLC Control field Comando UI
8 Fragmentation header Sem fragmentação
9 EVENT_REPORT.request
SEQUENCE {
EVENT_REPORT (Re­
lease)
OPTION indicator Credenciais de acesso não
presentes
OPTION indicator Parâmetro de incidente:
não presente
OPTION indicator IID não presente
Mode BOOLEAN Não se espera resposta
10 EID INTEGER (0..127,…) Sem extensão, EID = 0
(System)
11 EventType INTEGER (0..127,…)} Tipo de incidente: 0 =
Release
12 FCS Sequência de verificação
da estrutura
13
14 Flag Sinal (bandeira) de termi­
nação
▼B
DSC_52 Não se prevê que a DSRC-VU responda ao comando Release.
A comunicação é, pois, encerrada.
5.4.8 Descrição de transação de ensaio DSRC
DSC_53 Conforme definido no apêndice 11 (Mecanismos comuns de
segurança), é necessário realizar ensaios completos que in­
cluam a proteção dos dados, por pessoas autorizadas com
acesso a procedimentos de segurança, utilizando o comando
GET normal atrás definido.
DSC_54 Devem ser realizados ensaios de colocação em serviço e ins­
peção periódica que exijam conteúdo de dados decifrados,
conforme especificado no apêndice 11 (Mecanismos comuns
de segurança) e no apêndice 9 (Relação dos ensaios mínimos
exigidos para homologação de tipo).
No entanto, a comunicação DSRC básica pode ser ensaiada
pelo comando ECHO. Esses ensaios podem ser necessários
aquando da colocação em serviço, numa inspeção periódica,
ou de qualquer outra forma por exigência da autoridade de
controlo competente ou do Regulamento (UE) n. o 165/2014
(ver secção 6).
▼C2
02016R0799 — PT — 21.08.2023 — 003.002 — 578
DSC_55 De modo a efetuar este ensaio de comunicação básico, o
comando ECHO é emitido pelo REDCR durante uma sessão,
ou seja, depois de uma fase de inicialização ter sido concluída
com êxito. A sequência de interações é, desta forma, seme­
lhante à de uma interrogação:
— Etapa 1— O REDCR envia um «quadro de serviço de
baliza» (BST), que inclui os identificadores de
aplicação (AID) na lista de serviço que aceita. Nas apli­
cações RTM será simplesmente o serviço com o valor
AID = 2.
A DSRC-VU avalia o BST recebido e sempre que iden­
tificar que o BST está a pedir Freight&Fleet (AID = 2), a
DSRC-VU responde. Se o REDCR não oferecer AID=2, a
DSRC-VU desliga a sua transação com o REDCR.
— Etapa 2— A DSRC-VU envia um pedido de atribuição de
janela privada.
— Etapa 3— O REDCR envia uma atribuição de janela
privada.
— Etapa 4— A DSRC-VU utiliza a janela privada atribuída
para enviar o seu quadro de serviço do veículo (VST).
Este VST inclui uma lista de todas as instanciações de
aplicação diferentes que esta DSRC-VU aceita no âmbito
de AID=2. As diferentes instanciações devem ser identi­
ficadas por meio de EID exclusivos, cada um associado a
um valor do parâmetro que indica a instância da aplicação
que é aceite.
— Etapa 5— Em seguida, o REDCR analisa o VST ofere­
cido, e termina a ligação (RELEASE), uma vez que não
está interessado em nada do que o VST tem para oferecer
(ou seja, está a receber um VST de uma DSRC-VU que
não é uma RTM VU) ou, se receber um VST adequado,
inicia uma instanciação da aplicação.
— Etapa 6— O REDCR emite um comando (ECHO) à
DSRC-VU específica e atribui uma janela privada.
— Etapa 7— A DSRC-VU utiliza a janela privada atribuída
recentemente para enviar uma estrutura de resposta
ECHO.
Os quadros que se seguem apresentam um exemplo prático de uma
sessão de intercâmbio ECHO.
DSC_56 A inicialização é realizada de acordo com a secção 5.4.7
(DSC_44 — DSC_48) e com os quadros 14.4 a 14.9.
DSC_57 O REDCR emite um comando ACTION, ECHO conforme
com a norma ISO 14906, contendo 100 octetos de dados e
sem configurações específicas de RTM. O quadro 14.15 mos­
tra o conteúdo da estrutura enviada pelo REDCR.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 579
Quadro 14.15
▼C2
Exemplo de estrutura de pedido de ação ECHO
N
.o
d
o
oc
te
to

Atributo/campo Bits no octeto Descrição
1 FLAG Sinal (bandeira) de início
2 Private LID Endereço de ligação da
DSRC-VU específica
3
4
5
6 MAC Control field PDU de comando
7 LLC Control field Comando ACn solicitado,
bit n
8 Fragmentation header Sem fragmentação
9 ACTION.request
SEQUENCE {
Pedido de ação (ECHO)
OPTION indicator Credenciais de acesso não
presentes
OPTION indicator Parâmetro de ação pre­
sente
OPTION indicator IID não presente
Mode BOOLEAN Espera-se resposta
10 EID INTEGER (0..127,…) Sem extensão, EID = 0
(System)
11 ActionType INTEGER (0..127,…) Sem extensão. Tipo de
ação: pedido ECHO
12 ActionParameter CONTAINER { Sem extensão, escolha de
contentor = 2
13 Sem extensão. Compri­
mento da cadeia = 100 oc­
tetos
14 Dados a reenviar
… …
113 }}
114 FCS Sequência de verificação
da estrutura
115
116 Flag Sinal (bandeira) de termi­
nação
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 580
DSC_58 Ao receber o pedido ECHO, a DSRC-VU envia uma resposta
ECHO de 100 octetos de dados, refletindo o comando rece­
bido, de acordo com a norma ISO 14906, sem configurações
específicas de RTM. O quadro 14.16 mostra um exemplo de
codificação do nível de bit.
Quadro 14.16
▼C2
Inicialização — Exemplo de estrutura de resposta de ação ECHO
N
.o
d
o
oc
te
to

Atributo/campo Bits no octeto Descrição
1 FLAG Sinal (bandeira) de início
2 Private LID Endereço de ligação da
DSRC-VU específica
3
4
5
6 MAC Control field PDU de resposta
7 LLC Control field Comando ACn, bit n
8 LLC status field Resposta disponível
9 Fragmentation header Sem fragmentação
10 ACTION.response
SEQUENCE {
Resposta de ACTION
(ECHO)
OPTION indicator IID não presente
OPTION indicator Parâmetro de resposta pre­
sente
OPTION indicator Estatuto de devolução não
presente
Fill BIT STRING (SIZE (1)) Não utilizado
11 EID INTEGER (0..127,…) Sem extensão, EID = 0
(System)
12 ResponseParameter CONTAINER { Sem extensão, escolha de
contentor = 2
13 Sem extensão. Compri­
mento da cadeia = 100 oc­
tetos
14 Dados reenviados
… …
113 }}
114 FCS Sequência de verificação
da estrutura
115
116 Flag Sinal (bandeira) de termi­
nação
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 581
5.5 Reservado para utilização futura
▼M2
__________
▼B
5.6 Transferência de dados entre a DSRC-VU e a VU
5.6.1 Conexão física e interfaces
DSC_66 A conexão entre a VU e a DSRC-VU pode ser por cabo físico
ou por comunicação sem fios de curto alcance com base em
Bluetooth v4.0 BLE.
DSC_67 Independentemente da escolha da conexão física e interface,
devem ser satisfeitos os seguintes requisitos:
DSC_68 ►M1 a) A fim de que possam ser contratados fornecedores
diferentes para o fornecimento de VU e DSRC-VU
e, na verdade, diferentes lotes de DSRC-VU, a
conexão entre a VU e a DSRC-VU não interna à
VU deve ser uma conexão-padrão aberta. A VU
deve conectar-se à DSRC-VU ◄
i) utilizando um cabo fixo de pelo menos 2 m ou
um conector H11 Straight DIN 41612 — co­
nector macho homologado de 11 pinos — da
DSRC-VU para corresponder a um conector
fêmea homologado DIN/ISO semelhante do
dispositivo da VU,
ii) utilizando baixo consumo energético do
Bluetooth (BLE),
iii) utilizando uma conexão homologada pelas nor­
mas ISO 11898 ou SAE J1939;
DSC_69 b) A definição das interfaces e da conexão entre a VU e
DSRC-VU tem de aceitar (isto é, tem de ser compatível
com) os comandos do protocolo de aplicação definidos na
secção 5.6.2 e
DSC_70 c) A VU e a DSRC-VU têm de aceitar (isto é, têm de ser
compatíveis com) a operação de transferência de dados
através da conexão, no que respeita ao desempenho e à
alimentação energética.
5.6.2 Protocolo de aplicação
DSC_71 O protocolo de aplicação entre o módulo de comunicação à
distância da VU e a DSRC-VU é responsável por transferir
periodicamente os dados de comunicação à distância da VU
para a DSRC.
DSC_72 Identificam-se a seguir os principais comandos:
1. Inicialização da ligação de comunicação — pedido
2. Inicialização da ligação de comunicação — resposta
3. Envio de dados com identificador da aplicação RTM e
carga útil definida pelos dados RTM
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 582
4. Reconhecimento dos dados
5. Terminação da ligação de comunicação — pedido
6. Terminação da ligação de comunicação — resposta
DSC_73 Em ASN1.0, os comandos anteriores podem ser definidos
como:
DSC_74 A descrição dos comandos e parâmetros é a seguinte:
— :
utilizado para inicializar a ligação de comunicação. O
comando é enviado pela VU à DSRC-VU. O LinkIdenti­
fier é definido pela VU e comunicado à DSRC-VU para
rastrear uma ligação de comunicação específica
(Nota: destina-se a aceitar ligações futuras e outros mó­
dulos/aplicações, como a pesagem a bordo).
— :
utilizado pela DSRC-VU para fornecer a resposta do pe­
dido de inicialização da ligação de comunicação. O co­
mando é enviado pela DSRC-VU à VU. O comando for­
nece o resultado da inicialização como resposta = 1
(êxito) ou = 0 (falha).
DSC_75 A inicialização da ligação de comunicação deve ser efetuada
apenas após a instalação e a calibração e após estar ligado o
arranque do motor/VU.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 583
— : utilizado para, através da VU, en­
viar o RCDTData assinado (ou seja, os dados de comu­
nicação à distância) à DSRC-VU. Os dados são enviados
de 60 em 60 segundos. O parâmetro DataTransactionId
identifica a transmissão específica de dados. O LinkIden­
tifier é igualmente utilizado para garantir que a ligação
adequada está correta.
— : enviado pela
DSRC-VU para fornecer o retorno à VU sobre a receção
dos dados de um comando identifi­
identificado pelo parâmetro DataTransactionId. O parâme­
tro de resposta é = 1 (êxito) ou = 0 (falha). Se uma VU
receber mais do que três respostas iguais a 0 ou não
receber RCDT Data Acknowledgment para um RCDT-
Send Data específico enviado anteriormente com um Da­
taTransactionId específico, cria e regista um incidente.
— é enviado
pela VU à DSRC-VU para encerrar uma ligação para
um LinkIdentifier específico.
DSC_76 Ao reiniciar a DSRC-VU ou uma VU, todas as ligações de
comunicação existentes devem ser removidas, dado poderem
existir ligações «penduradas» devido ao desligamento repen­
tino de uma VU.
— : enviado
pela DSRC-VU à VU para confirmar o pedido de termi­
nação da ligação pela VU para o LinkIdentifier específico.
5.7 Tratamento de erros
5.7.1 Memorização e comunicação dos dados na DSRC-VU
▼M3
DSC_77 Os dados devem ser fornecidos, já protegidos, pela função
VUSM à DSRC-VU. O VUSM verifica se os dados regista­
dos 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 Event­
FaultType e o valor de enumeração definido como falha de
comunicação «0C»H com o incidente do módulo de comuni­
caçã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.
▼B
DSC_79 Se o VUPM tentar obter dados da VU do módulo de segu­
rança (para passar ao VU-DSRC), mas não o fizer, regista a
falha com o tipo EventFaultType e o valor de enumeração
definido como falha de comunicação «62»H módulo de co­
municação à distância, juntamente com o período de
tempo. O fracasso da comunicação é detetado quando
uma mensagem não
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 584
é recebida para o correspondente (ou seja, com o mesmo
DataTransactionId nas mensagens )
durante mais de três vezes
consecutivas.
5.7.2 Erros de comunicações sem fios
DSC_80 O tratamento de erros de comunicação deve ser coerente com
o disposto nas normas DSRC correspondentes, nomeadamente
EN 300 674-1, EN 12253, EN 12795 e EN 12834 e os
parâmetros adequados da norma EN 13372.
5.7.2.1 Erros de encriptação e assinatura
DSC_81 Os erros de assinatura e de encriptação devem ser tratados
conforme definido no apêndice 11 (Mecanismos comuns de
segurança) e não estão presentes nas mensagens de erro as­
sociadas à transferência de dados DSRC.
5.7.2.2 Registo de erros
O meio DSRC é uma comunicação sem fios dinâmica num ambiente de
condições atmosféricas e de interferência incertas, particularmente nas
combinações «REDCR portátil» e «veículo em movimento» presentes
nesta aplicação. É, por conseguinte, necessário verificar a diferença entre
uma «falha de leitura» e uma situação de «erro». Numa transação atra­
vés de uma interface sem fios, é comum a falha de leitura e, normal­
mente, a consequência é voltar a tentar, ou seja, voltar a transmitir o
BST e tentar novamente a sequência, que, na maioria das circunstâncias,
leva a uma conexão de comunicação e transferência de dados com êxito,
exceto se o veículo visado se mover para fora do alcance durante o
tempo necessário para retransmitir (uma instância de «leitura» «com
êxito» pode ter envolvido várias tentativas e repetições).
A falha de leitura pode ter múltiplas causas: as antenas não estão devi­
damente emparelhadas (falha de «pontaria»); uma das antenas está blin­
dada (pode ser deliberado, mas pode igualmente dever-se à presença
física de outro veículo); há interferência do rádio, especialmente de cerca
de 5,8 GHz Wi-Fi ou outras comunicações sem fios de acesso público;
há interferência do radar ou condições atmosféricas adversas (por exem­
plo, durante um temporal); ou simples movimento para fora do alcance
da comunicação DSRC. Pela sua natureza, as instâncias individuais de
falhas de leitura não podem ser registadas, simplesmente porque a co­
municação não aconteceu.
No entanto, se o agente da autoridade de controlo competente tiver
como alvo um veículo e tentar interrogar a sua DSRC-VU, mas sem
obter êxito na transferência de dados, esta falha pode ter ocorrido devido
a adulteração deliberada e, por conseguinte, o agente precisa de um meio
para registar a falha e avisar os seus colegas a jusante de que pode haver
uma violação. Os colegas podem, desta forma, parar o veículo e realizar
uma inspeção física. No entanto, como não ocorreu nenhuma comuni­
cação com êxito, o DSRC-VU não pode fornecer dados sobre a falha.
Essa comunicação deve, por conseguinte, ser uma função de conceção
de equipamento REDCR.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 585
Tecnicamente, «falha de leitura» é diferente de «erro». Neste contexto,
um «erro» é a aquisição de um valor errado.
Os dados transferidos para a DSRC-VU são fornecidos já protegidos,
pelo que devem ser verificados pelo fornecedor dos dados (ver 5.4).
Os dados transferidos posteriormente através da interface aérea são ve­
rificados através de controlos de redundância cíclica ao nível das comu­
nicações. Se o CRC validar, os dados estão corretos. Se o CRC não
validar, os dados são retransmitidos. A probabilidade de os dados po­
derem passar com êxito por um CRC, de modo incorreto, é estatistica­
mente muito improvável, pelo que pode ser descartada.
Se o CRC não validar e não houver tempo para retransmitir e receber os
dados corretos, o resultado não será um erro, mas uma instanciação de
um tipo específico de falha de leitura.
O único dado de «falha» significativo que pode ser registado é o número
de iniciações com êxito, das transações que ocorrem, que não resultam
numa transferência bem sucedida de dados para o REDCR.
DSC_82 Por conseguinte, o REDCR regista, com período de tempo, o
número de ocasiões em que a fase de «inicialização» de uma
interrogação DSRC for bem sucedida, mas a transação ter­
mina antes de os dados terem sido recuperados com êxito
pelo REDCR. Estes dados estarão disponíveis para o agente
da autoridade de controlo competente e serão memorizados na
memória do equipamento REDCR. Os meios pelos quais tal é
obtido terão a ver com a conceção do produto ou a especifi­
cação de uma autoridade de controlo competente.
O único dado de «erro» significativo que pode ser registado é
o número de ocasiões em que o REDCR não decifra os dados
recebidos. No entanto, deve referir-se que tal é relativo apenas
à eficiência do software REDCR. Tecnicamente, os dados
podem ser decifrados, mas não fazem sentido semântico.
DSC_83 Por conseguinte, o REDCR regista, com período de tempo, o
número de ocasiões em que a decifragem dos dados recebidos
através da interface DSRC foi tentada mas falhou.
6 ENSAIOS DE COLOCAÇÃO EM SERVIÇO E DE INSPEÇÃO PE­
RIÓDICA PARA A FUNÇÃO DE COMUNICAÇÃO À DISTÂNCIA
6.1 Geral
DSC_84 Estão previstos dois tipos de ensaios para a função de comu­
nicação à distância:
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 586
1) Ensaio ECHO para validar o DSRC-REDCR >>-:-
-VU sem fios canal de comunicação.
2) Ensaio de segurança integral para garantir que um cartão
de oficina é capaz de aceder a conteúdo de dados assinado
e encriptado criado pela VU e transmitido através do canal
de comunicação sem fios.
6.2 ECHO
A presente cláusula contém disposições especificamente para testar ape­
nas se o DSRC-REDCR >>-:-
O objetivo do comando ECHO é autorizar as oficinas ou unidades de
ensaio de homologações de tipo a testar se a ligação DSRC funciona
sem necessidade de acesso a credenciais de segurança. Por conseguinte,
o equipamento do dispositivo de teste só tem de ser capaz de inicializar
uma comunicação DSRC (envio de um BST com AID = 2) e enviar o
comando ECHO; presumindo que o DSRC está a trabalhar, receberá a
resposta ECHO (ver 5.4.8 para mais informações). Presumindo que
recebe corretamente esta resposta, a ligação DSRC (DSRC-REDCR
>>-:-
6.3 Ensaios para validar o conteúdo de dados seguro
DSC_85 Este ensaio é executado para validar o fluxo de dados de
segurança integral. Este ensaio requer um leitor de ensaio
DSRC. O leitor de ensaio DSRC executa a mesma função e
é aplicado com as mesmas especificações do leitor utilizado
pelas forças da lei (autoridade de controlo competente), com a
diferença de que, para autenticar o utilizador do leitor de
ensaio DSRC, deve ser utilizado um cartão de oficina, e
não um cartão de controlo. O ensaio pode ser executado
após a ativação inicial de um tacógrafo inteligente ou no final
do procedimento de calibração. Após a ativação, a unidade-
-veículo deve criar e comunicar ao DSRC-VU os dados de
deteção rápida protegidos.
DSC_86 O pessoal da oficina tem de posicionar o leitor de ensaio
DSRC a uma distância entre 2 e 10 metros à frente do veí­
culo.
DSC_87 De seguida, o pessoal da oficina insere um cartão de oficina
no leitor de ensaio DSRC para pedir a interrogação dos dados
de deteção rápida à unidade-veículo. Após uma interrogação
com êxito, o pessoal da oficina acede aos dados recebidos
para garantir que foi validada com êxito, em termos de in­
tegridade, e decifrada.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 587
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 con­
dução e o tempo quinzenal de condução utilizando dados relevantes memo­
rizados num cartão de condutor (ou de oficina) inserido na ranhura do con­
dutor (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 «TRABA­
LHO»
— 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 des­
canso 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;
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 588
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 in­
terrompido 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 acumu­
lado 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.
Figura 1.
Exemplo de período de repouso diário interrompido devido a travessia de batelão/comboio
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 divi­
dido 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 inter­
rompida uma ou duas vezes, ou
— a segunda parte do período de repouso diário dividido pode ser inter­
rompida uma ou duas vezes, ou
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 589
— a primeira parte do período de repouso diário dividido pode ser inter­
rompida 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 interrom­
pido 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 interrom­
pido por TRAVESSIA DE BATELÃO/COMBOIO.
Figura 2.
Exemplo de período de repouso diário dividido interrompido devido a 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 acu­
mulado 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 pri­
meira parte de um período de repouso diário dividido devido a traves­
sia 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 pri­
meira parte de um período de repouso diário dividido devido a traves­
sia 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.
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 590
Se, pelo menos, uma das condições acima for satisfeita, a VU deve in­
terromper 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 pri­
meira parte de um período de repouso diário dividido também interrom­
pido por travessia de batelão/comboio. Caso contrário, a VU deve prosse­
guir 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 acumu­
lado 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 pe­
rí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 con­
diçã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.
Figura 3.
Tratamento dos tempos de repouso pela VU, a fim de determinar se um período de repouso interrompido
deve ser calculado como um período de repouso diário regular ou como a primeira parte de um período de
repouso diário dividido
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 591
Figura 4.
Tratamento dos tempos de repouso pela VU, a fim de determinar se um período de repouso interrompido
deve ser calculado como a segunda parte de um período de repouso diário dividido
Figura 5.
Exemplo de um período de repouso diário interrompido mais de duas vezes, levando a que o período de
repouso H não seja incluído no cálculo
Figura 6.
Exemplo de um período de repouso diário em que o período de cálculo da travessia de batelão/comboio tem
início do final do período de trabalho
Figura 7.
Exemplo de um período de repouso diário interrompido mais de duas vezes, levando a que o período de
repouso B não seja incluído no cálculo
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 592
Figura 8.
Exemplo de um período de repouso diário dividido interrompido uma vez durante o primeiro período de
repouso e uma vez durante o segundo período de repouso
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/com­
boio 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 adi­
cionados 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.
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 593
Apêndice 15
MIGRAÇÃO: GESTÃO DA COEXISTÊNCIA DE GERAÇÕES E
VERSÕES DE APARELHOS
▼B
ÍNDICE
1. DEFINIÇÕES
2. DISPOSIÇÕES GERAIS
2.1. Síntese da transição
▼M3
2.2. Interoperabilidade entre VU e cartões
▼B
2.3. Interoperabilidade entre VU e MS
2.4. Interoperabilidade entre unidades-veículo, cartões tacográficos e equipa­
mento de descarregamento de dados
2.4.1 Descarregamento direto do cartão pelo IDE
2.4.2 Descarregamento do cartão através de uma unidade-veículo
2.4.3 Descarregamento da unidade-veículo
2.5. Interoperabilidade entre VU e aparelhos de calibração
3. PRINCIPAIS ETAPAS DURANTE O PERÍODO ANTERIOR À DATA
DE PRODUÇÃO
4. DISPOSIÇÕES PARA O PERÍODO APÓS A DATA DE PRODUÇÃO
▼M3
5. REGISTO DE TRAVESSIAS DE FRONTEIRAS NOS TACÓGRAFOS
DA PRIMEIRA GERAÇÃO E DA PRIMEIRA VERSÃO DA SE­
GUNDA GERAÇÃO
▼B
1. DEFINIÇÕES
Para efeitos do presente apêndice, entende-se por:
Sistema tacográfico inteligente: conforme definição no presente
anexo (capítulo 1: definição bbb);
Sistema tacográfico da primeira geração: conforme definição no pre­
sente regulamento (artigo 2. o : definição 1);
Sistema tacográfico da segunda geração: conforme definição no pre­
sente regulamento (artigo 2. o : definição 7);
Data de produção: conforme definição no presente anexo (capítulo 1:
definição ccc);
Equipamento dedicado inteligente (IDE): equipamento utilizado para
executar a descarga de dados, conforme definição no apêndice 7 do pre­
sente anexo.
▼M3
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áfi­
cos da segunda geração.
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 594
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 ge­
raçã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 interope­
rá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 car­
tõ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 con­
dutor, 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 taco­
grá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 utili­
zar 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 ge­
raçã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 pri­
meira 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 in­
teroperá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 qual­
quer 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 movi­
mentos da primeira geração.
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 595
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 equi­
pamento de descarregamento de dados
MIG_009 O equipamento de descarregamento de dados pode ser com­
patí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 proto­
colo 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 Tacho­
graph) solicitados pelo protocolo de descarregamento do
cartão da primeira geração. Esta informação deve ser pro­
tegida com uma assinatura digital, de acordo com os me­
canismos 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 pri­
meira geração que utiliza o protocolo de descarregamento
de dados da primeira geração. O cartão responde aos coman­
dos 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 se­
gunda 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.
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 596
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 mecanis­
mos de segurança da segunda geração e o protocolo de des­
carregamento 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 des­
carregar dados de qualquer versão das unidades-veículo da
segunda geração utilizando mecanismos de segurança da pri­
meira 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 car­
tõ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 ta­
cográficos da segunda geração.
MIG_023 Os fabricantes de unidades-veículo ou de sensores de movi­
mentos poderão produzir unidades-veículo ou sensores de mo­
vimentos da primeira geração enquanto este equipamento for
utilizado no terreno, de modo a que os componentes com
defeito possam ser substituídos.
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 597
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 se­
gunda geração podem devem ser substituídos pela versão 2
das unidades-veículo ou dos módulos GNSS da segunda ge­
ração.
MIG_024 Os fabricantes de unidades-veículo ou de sensores de movi­
mentos poderão solicitar e obter a manutenção da homologa­
ção de tipos já homologados de unidades-veículo ou de sen­
sores de movimentos da primeira geração ou da versão 1 das
unidades-veículo da segunda geração
5. REGISTO DE TRAVESSIAS DE FRONTEIRAS NOS TACÓGRAFOS
DA PRIMEIRA GERAÇÃO E DA PRIMEIRA VERSÃO DA SE­
GUNDA GERAÇÃO
MIG_025 O símbolo do país e, se aplicável, da região em que o con­
dutor entra depois de atravessar a fronteira de um
Estado-Membro em aplicação do artigo 34. o , n. o 7, do Regu­
lamento (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
▼M3
02016R0799 — PT — 21.08.2023 — 003.002 — 598
Apêndice 16.
ADAPTADOR PARA VEÍCULOS DAS CATEGORIAS M1 E N1
ÍNDICE
1. ABREVIATURAS E REFERÊNCIAS
1.1. Abreviaturas
1.2. Normas de referência
2. CARACTERÍSTICAS GERAIS E FUNÇÕES DO ADAPTADOR
2.1. Descrição geral do adaptador
2.2. Funções
2.3. Segurança
3. REQUISITOS APLICÁVEIS AO APARELHO DE CONTROLO
QUANDO ESTÁ INSTALADO UM ADAPTADOR
4. REQUISITOS DE CONSTRUÇÃO E FUNCIONAMENTO DO ADAP­
TADOR
4.1. Estabelecer uma interface com os impulsos de entrada de velocidade e
adaptá-los
4.2. Induzir os impulsos de entrada no sensor de movimentos incorporado
4.3. Sensor de movimentos incorporado
4.4. Requisitos de segurança
4.5. Características de desempenho
4.6. Materiais
4.7. Marcações
5. INSTALAÇÃO DO APARELHO DE CONTROLO QUANDO É UTILI­
ZADO UM ADAPTADOR
5.1. Instalação
5.2. Selagem
6. VERIFICAÇÕES, INSPEÇÕES E REPARAÇÕES
6.1. Controlos periódicos
7. HOMOLOGAÇÃO DE TIPO DO APARELHO DE CONTROLO
QUANDO É UTILIZADO UM ADAPTADOR
7.1. Aspetos gerais
7.2. Certificado de funcionalidade
1. ABREVIATURAS E REFERÊNCIAS
1.1. Abreviaturas
A DEFINIR a definir
VU unidade-veículo
1.2. Normas de referência
ISO 16844-3 Road vehicles — Tachograph systems — Part 3: Motion
sensor interface
2. CARACTERÍSTICAS GERAIS E FUNÇÕES DO ADAPTADOR
2.1. Descrição geral do adaptador
ADA_001 O adaptador deve fornecer permanentemente a uma VU a ele
ligada dados securizados representativos da velocidade de cir­
culação do veículo e da distância por ele percorrida.
O adaptador destina-se unicamente aos veículos que têm de ser
equipados com aparelhos de controlo na aceção do presente
regulamento.
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 599
O adaptador deve ser instalado e utilizado apenas nos veículos
correspondentes à definição yy («adaptador») do anexo IC,
onde não seja mecanicamente possível instalar outro tipo de
sensor de movimentos que, por outro lado, cumpre o disposto
no presente anexo e nos seus apêndices 1 a 16.
O adaptador não pode ter uma interface mecânica com partes
móveis do veículo; deve, sim, ser ligado aos impulsos veloci­
dade/distância gerados por sensores integrados ou interfaces
alternativas.
ADA_002 Deve colocar-se um sensor de movimentos de tipo homologado
(em conformidade com o disposto no anexo IC, ponto 8, «Ho­
mologação de tipo dos aparelhos de controlo e dos cartões
tacográficos») na caixa do adaptador, que incluirá também
um dispositivo conversor para induzir os impulsos de entrada
no sensor de movimentos incorporado. Por sua vez, o sensor
de movimentos incorporado deve ser ligado à VU, para que a
interface entre a VU e o adaptador cumpra os requisitos da
norma ISO 16844-3.
2.2. Funções
ADA_003 Funções do adaptador:
— estabelecer uma interface com os impulsos de entrada de
velocidade e adaptá-los
— induzir os impulsos de entrada no sensor de movimentos
incorporado
— todas as funções do sensor de movimentos incorporado,
fornecendo à VU dados de movimento securizados
2.3. Segurança
ADA_004 Ao adaptador não pode ser concedida a certificação de segu­
rança correspondente ao objetivo genérico de segurança do
sensor de movimentos, definido no apêndice 10 do presente
anexo. Em vez disso, aplicam-se-lhe os requisitos de segurança
especificados no ponto 4.4 do presente apêndice.
3. REQUISITOS APLICÁVEIS AO APARELHO DE CONTROLO
QUANDO ESTÁ INSTALADO UM ADAPTADOR
Neste capítulo e nos seguintes, explicam-se os requisitos do presente
anexo quando é utilizado um adaptador. Os números dos requisitos do
anexo IC figuram entre parêntesis retos.
ADA_005 O aparelho de controlo de um veículo equipado com adaptador
deve cumprir integralmente o disposto no presente anexo, salvo
indicação em contrário neste apêndice.
ADA_006 Quando é instalado um adaptador, o aparelho de controlo inclui
os cabos, o adaptador (incluindo um sensor de movimentos) e
uma VU [01].
ADA_007 A função de deteção de incidentes e/ou falhas do aparelho de
controlo é alterada nos seguintes termos:
— O incidente «interrupção da alimentação energética» é de­
sencadeado pela VU, fora do modo de calibração, no caso
de uma interrupção superior a 200 milésimos de segundo
na alimentação elétrica do sensor de movimentos incorpo­
rado [79]
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 600
— O incidente «erro nos dados de movimento» é desenca­
deado pela VU em caso de interrupção no fluxo normal
de dados entre o sensor de movimentos incorporado e a
VU e/ou em caso de erro na integridade ou na autenticação
de dados durante o intercâmbio destes entre o sensor de
movimentos incorporado e a VU [83]
— O incidente «tentativa de violação da segurança» é desen­
cadeado pela VU na eventualidade de qualquer outro inci­
dente que afete a segurança do sensor de movimentos in­
corporado, fora do modo de calibração [85]
— A «falha do aparelho de controlo» é desencadeada pela
VU, fora do modo de calibração, na eventualidade de qual­
quer falha do sensor de movimentos incorporado [88].
ADA_008 As falhas do adaptador detetáveis pelo aparelho de controlo são
as relacionadas com o sensor de movimentos incorporado [88].
ADA_009 A função de calibração da VU deve permitir emparelhar auto­
maticamente o sensor de movimentos incorporado e a VU
[202, 204].
4. REQUISITOS DE CONSTRUÇÃO E FUNCIONAMENTO DO ADAP­
TADOR
4.1. Estabelecer uma interface com os impulsos de entrada de velocidade e
adaptá-los
ADA_011 A interface do adaptador para entrada de dados deve aceitar
impulsos de frequência representativos da velocidade de circu­
lação do veículo e da distância por ele percorrida. Caracterís­
ticas elétricas dos impulsos de entrada: A definir pelo fabri­
cante. A interface correta dos dados do adaptador para o veí­
culo, se for caso disso, será viabilizada por ajustamentos aces­
síveis apenas ao fabricante do adaptador e à oficina homolo­
gada que o instala.
▼M3
ADA_012 Se for caso disso, a interface dos dados do adaptador deve
poder multiplicar ou dividir os impulsos de frequência de en­
trada 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.
▼B
4.2. Induzir os impulsos de entrada no sensor de movimentos incorporado
ADA_013 Os impulsos de entrada, eventualmente adaptados conforme
atrás se especificou, são induzidos no sensor de movimentos
incorporado, de modo a que cada impulso de entrada seja
detetado pelo sensor.
4.3. Sensor de movimentos incorporado
ADA_014 O sensor de movimentos incorporado deve ser estimulado pe­
los impulsos induzidos, podendo assim gerar dados que repre­
sentam com precisão o movimento do veículo, como se tivesse
uma interface mecânica com uma parte móvel do veículo.
ADA_015 Para identificar o adaptador, a VU deve utilizar os dados de
identificação do sensor de movimentos incorporado [95].
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 601
ADA_016 Os dados da instalação armazenados no sensor de movimentos
incorporado devem ser considerados como representando os
dados da instalação do adaptador [122].
4.4. Requisitos de segurança
ADA_017 A caixa do adaptador deve ser projetada de modo a impossi­
bilitar a sua abertura. Deve ser selada, de modo a permitir
detetar facilmente tentativas de fraude física (por exemplo,
através de inspeção visual — ver ADA_035). Os selos devem
cumprir os mesmos requisitos dos selos dos sensores de mo­
vimentos [398 a 406].
ADA_018 Deve ser impossível remover do adaptador o sensor de movi­
mentos incorporado sem quebrar o(s) selo(s) da caixa do adap­
tador ou o selo entre o sensor e a caixa do adaptador (ver
ADA_034).
ADA_019 O adaptador deve assegurar que os dados de movimento só
possam ser processados e derivados a partir dos dados de
entrada do adaptador.
4.5. Características de desempenho
ADA_020 O adaptador deve ser plenamente funcional no intervalo de
temperatura definido pelo fabricante.
ADA_021 O adaptador deve ser plenamente funcional no intervalo de
humidade de 10 % a 90 % [214].
ADA_022 O adaptador deve ser protegido contra sobretensão elétrica,
inversão da polaridade da sua fonte de alimentação e
curtos-circuitos [216].
ADA_023 O adaptador deve ainda:
— reagir a um campo magnético que perturbe a deteção do
movimento do veículo; nessas circunstâncias, a unidade-
-veículo regista e memoriza falhas do sensor [88]
— ou dispor de um elemento de deteção que esteja protegido
contra campos magnéticos ou lhes seja imune [217].
ADA_024 O adaptador deve cumprir o disposto na regulamentação inter­
nacional ONU ECE R10, relativa à compatibilidade eletromag­
nética, e deve ser protegido contra descargas eletrostáticas e
contra transitórios [218].
4.6. Materiais
ADA_025 O adaptador deve atingir o grau de proteção (a determinar pelo
fabricante, dependendo da posição da instalação) [220, 221].
ADA_026 A caixa do adaptador deve ser de cor amarela.
4.7. Marcações
ADA_027 Ao adaptador deve ser afixada uma placa descritiva, com os
seguintes elementos:
— nome e endereço do fabricante do adaptador
— número dado pelo fabricante e ano de fabrico do adaptador
— marca de homologação do tipo do adaptador ou do tipo do
aparelho de controlo, incluindo o adaptador
— data de instalação do adaptador
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 602
— número de identificação do veículo no qual foi instalado o
adaptador.
ADA_028 A placa descritiva deve também indicar os seguintes elementos
(se não forem legíveis do exterior no sensor de movimentos
incorporado):
— nome do fabricante do sensor de movimentos incorporado
— número dado pelo fabricante e ano de fabrico do sensor de
movimentos incorporado
— marca de homologação do sensor de movimentos
incorporado.
5. INSTALAÇÃO DO APARELHO DE CONTROLO QUANDO É UTILI­
ZADO UM ADAPTADOR
5.1. Instalação
ADA_029 Os adaptadores só podem ser instalados por fabricantes de
veículos ou por oficinas homologadas, autorizadas a instalar,
ativar e calibrar tacógrafos digitais e tacógrafos inteligentes.
ADA_030 A oficina homologada que instala o adaptador ajusta a interface
de entrada de dados e seleciona o fator de divisão do sinal de
entrada (se for caso disso).
ADA_031 A oficina homologada que instala o adaptador sela a caixa do
adaptador.
ADA_032 O adaptador deve ser colocado o mais próximo possível da
parte do veículo que fornece os impulsos de entrada.
ADA_033 Os cabos que fornecem energia elétrica ao adaptador devem ser
de cor vermelha (polo positivo) e negra (terra).
5.2. Selagem
ADA_034 Requisitos aplicáveis à selagem:
— a caixa do adaptador deve ser selada (ver ADA_017)
— a caixa do sensor incorporado deve ser selada à caixa do
adaptador, a menos que seja impossível remover o sensor
sem quebrar o(s) selo(s) da caixa do adaptador (ver
ADA_018)
— a caixa do adaptador deve ser selada ao veículo
— a ligação entre o adaptador e o equipamento que fornece os
seus impulsos de entrada deve ser selada em ambos os
extremos (na medida do razoavelmente possível).
6. VERIFICAÇÕES, INSPEÇÕES E REPARAÇÕES
6.1. Controlos periódicos
ADA_035 Quando se utiliza um adaptador, cada inspeção periódica do
aparelho de controlo (entendendo-se por inspeções periódicas
as que cumprem os requisitos [409] a [413] do anexo 1C) deve
incluir as seguintes verificações:
— se o adaptador exibe a devida marca de homologação de
tipo
— se estão intactos os selos colocados no adaptador e nas suas
ligações
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 603
— se o adaptador foi instalado conforme indica a placa de
instalação
— se o adaptador foi instalado conforme a especificação do
técnico responsável e/ou do fabricante do veículo
— se é autorizada a montagem de um adaptador no veículo
inspecionado.
ADA_036 Estas inspeções devem incluir a calibração e a substituição de
todos os selos, qualquer que seja o seu estado.
7. HOMOLOGAÇÃO DE TIPO DO APARELHO DE CONTROLO
QUANDO É UTILIZADO UM ADAPTADOR
7.1. Aspetos gerais
ADA_037 Quando for sujeito à homologação de tipo, o aparelho de con­
trolo deve estar completo, com o adaptador [425].
ADA_038 Qualquer adaptador pode ser sujeito a homologação de tipo
autonomamente ou como componente de um aparelho de
controlo.
ADA_039 Esta homologação de tipo deve incluir ensaios de funcionali­
dade que envolvam o adaptador. Os resultados positivos de
cada um destes ensaios devem ser declarados por certificados
correspondentes [426].
7.2. Certificado de funcionalidade
ADA_040 Ao fabricante só será passado o certificado de funcionalidade
do adaptador ou do aparelho de controlo que inclui adaptador
se tiverem êxito os seguintes ensaios de funcionalidade míni­
mos:
N. o Ensaio Descrição Requisitos correlatos
1. Exame administrativo
1.1 Documentação Adequação da docu­
mentação do adapta­
dor
2. Inspeção visual
2.1. Conformidade do adaptador com a documentação
2.2. Identificação/marcações do adaptador ADA_027,
ADA_028
2.3 Materiais do adaptador [219] a [223]
ADA_026
2.4. Selagem ADA_017,
ADA_018,
ADA_034
3. Ensaios de funcionalidade
3.1 Indução dos impulsos de velocidade no sensor de
movimentos incorporado
ADA_013
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 604
N. o Ensaio Descrição Requisitos correlatos
3.2 Estabelecer uma interface com os impulsos de
entrada de velocidade e adaptá-los
ADA_011,
ADA_012
3.3 Precisão da medição de movimentos [30] a [35], [217]
4. Ensaios ambientais
4.1 Resultados dos ensaios do
fabricante
Resultados dos en­
saios ambientais do
fabricante
ADA_020,
ADA_021,
ADA_022,
ADA_024
5. Ensaios de compatibilidade eletromagnética
5.1 Emissões radiadas e sus­
cetibilidade
Verificação da con­
formidade com a
Diretiva 2006/28/
/CE
ADA_024
5.2 Resultados dos ensaios do
fabricante
Resultados dos en­
saios ambientais do
fabricante
ADA_024
▼B
02016R0799 — PT — 21.08.2023 — 003.002 — 605
Apêndice 17
DISPOSIÇÕES TRANSITÓRIAS RELATIVAS À UTILIZAÇÃO DA
OSNMA PARA OS TACÓGRAFOS
1. DEFINIÇÕES E ACRONIMOS
1.1. Definições
Declaração de serviço da autenticação de mensagens de navegação do
serviço aberto Galileo (Service Declaration of Galileo Open Service
Navigation Message Authentication - OSNMA) significa a declaração da
Comissão Europeia de que a OSNMA do Galileo entra na sua fase
operacional.
Unidade-veículo de transição: unidade-veículo que cumpre as disposi­
ções do presente apêndice.
As unidades-veículo de transição são construídas em conformidade com o
documento de controlo de interface do sinal no espaço (SIS ICD) e as
orientações do recetor OSNMA aplicáveis à fase de ensaio público da
OSNMA. Contêm um recetor GNSS capaz de utilizar a OSNMA dispo­
nível durante a sua fase de ensaio público.
No entanto, as unidades-veículo de transição não podem autenticar as
mensagens de navegação disponíveis após a declaração de serviço da
OSNMA, em virtude da atualização necessária do material criptográfico
na unidade-veículo. É necessário proceder a uma atualização adequada do
software, para que a OSNMA possa começar a ser utilizada, além de
cumprir todos os requisitos do anexo IC e dos seus apêndices 1 a 16.
Antes de serem atualizadas, as unidades-veículo de transição implementam
as funcionalidades relacionadas com a OSNMA, conforme especificado no
presente apêndice. As funcionalidades não relacionadas com a OSNMA
permanecem inalteradas.
Se se proceder a uma atualização de software adequada, as
unidades-veículo de transição devem aplicar o SIS ICD e as orientações
do recetor OSNMA aplicáveis à fase operacional da OSNMA e cumprir
todos os requisitos do anexo IC e dos seus apêndices 1 a 16, utilizando a
OSNMA disponível durante a fase operacional.
Tacógrafo de transição: tacógrafo que inclui uma unidade-veículo de
transição.
1.2. Acrónimos
ICD Documento de controlo da interface
OSNMA Autenticação de mensagens de navegação do ser­
viço aberto Galileo
SIS Sinal no espaço
VU Unidade-veículo
▼M4
02016R0799 — PT — 21.08.2023 — 003.002 — 606
2. CONSIDERAÇÕES GERAIS RELACIONADAS COM A OSNMA
A fim de permitir que os veículos matriculados pela primeira vez sejam
equipados com a versão 2 dos tacógrafos de segunda geração, a partir da
data de introdução solicitada, tal como definida no anexo I C, secção 1,
alínea ccc), do Regulamento de Execução (UE) 2016/799, é necessário
homologar, produzir e comercializar unidades-veículo antes da declaração
de serviço da OSNMA. Para estas unidades-veículo, referidas como
unidades-veículo de transição, os requisitos relativos à OSNMA, incluídos
no anexo IC e nos respetivos apêndices 1 a 16, necessitam de ser adap­
tados, de modo a poderem ser homologados e utilizados no terreno.
As disposições do presente apêndice definem os requisitos específicos
aplicáveis às unidades-veículo de transição. Aplicam-se apenas às
unidades-veículo com um recetor GNSS interno.
3. REQUISITOS APLICAVEIS AO RECETOR GNSS DOS TACOGRA­
FOS DE TRANSIÇÃO
TRA_001 As unidades-veículo de transição devem incluir um recetor
GNSS capaz de utilizar a OSNMA disponível durante a sua fase de ensaio
público.
TRA_002 Os requisitos do apêndice 12 aplicam-se ao recetor GNSS
incluído nas unidades-veículo de transição, com as seguintes interpreta­
ções:
— As referidas orientações para o recetor SIS ICD e OSNMA correspon­
dem aos documentos disponíveis para a fase de teste público:
— Utilizador ICD da autenticação de mensagens de navegação do
serviço aberto Galileo (OSNMA) para a fase de teste, edição
1.0, novembro de 2021,
— Diretrizes relativas ao recetor da autenticação de mensagens de
navegação do serviço aberto Galileo (OSNMA) para a fase de
ensaio, edição 1.0, novembro de 2021,
— A OSNMA é o serviço disponível durante a fase de teste público,
— O SIS é o sinal no espaço disponível durante a fase de teste público.
TRA_003 O recetor GNSS incluído nas unidades-veículo de transição
deve ser concebido de modo que, após uma atualização do seu software,
aplicada através de uma atualização do software da unidade-veículo, cum­
pra plenamente os requisitos do anexo 12, utilizando a OSNMA disponí­
vel durante a sua fase operacional.
4. REQUISITOS APLICAVEIS AS UNIDADES-VEICULO DE TRANSI­
ÇÃO
As unidades-veículo de transição podem processar o sinal OSNMA dis­
ponível durante a sua fase de ensaio público, mas não podem comunicar o
estado de autenticação das mensagens de navegação a partir do SIS dis­
ponível durante a fase operacional da OSNMA, até que seja aplicada uma
atualização adequada do software. Por conseguinte, presume-se que as
posições padrão fornecidas pelo recetor GNSS são sempre autenticadas.
Aplicam-se os requisitos do anexo IC e dos seus apêndices 1 a 16, com as
seguintes interpretações.
▼M4
02016R0799 — PT — 21.08.2023 — 003.002 — 607
TRA_004 Anexo IC, ponto 3.9.15 Incidente “conflito de tempo”, requi­
sito 86, deve ser entendido como:
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 padrão autenti­
cadas transmitidas pelo recetor GNSS ou pelo módulo GNSS externo. É
detetada uma “discrepância de tempo” se a diferença de tempo exce­
der ± 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.
TRA_005 Anexo IC, ponto 3.9.18 Incidente “anomalia do GNSS”, requi­
sito 88-A, deve ser entendido como:
Este incidente produz-se, fora do modo de calibração, quando o recetor
GNSS deteta um ataque , 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.
TRA_006 Anexo IC, ponto 3.12.5 Registo e memorização de dados na
memória, Locais e posições de início e/ou final dos períodos de trabalho
diário, e/ou em que são atingidas 3 horas de tempo de condução acumu­
lado, requisito 110, deve ser entendido como:
Juntamente com cada local ou 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 introdução de dados,
— o tipo de introdução (início, final ou 3 horas de tempo de condução
acumulado),
— a precisão, data e hora do GNSS relacionadas, se aplicável,
— o valor do conta-quilómetros do veículo,
— um indicador que denota que a posição foi considerada autenticada.
TRA_007 Anexo IC, ponto 3.12.17 Registo e memorização de dados na
memória, Travessia das fronteiras, requisito 133-B, deve ser entendido
como:
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 que a posição foi considerada autenticada,
— o valor do conta-quilómetros do veículo no momento da deteção da
travessia da fronteira.
▼M4
02016R0799 — PT — 21.08.2023 — 003.002 — 608
TRA_008 Anexo IC, ponto 3.12.18, Registo e memorização de dados na
memória, Operações de carga/descarga, requisito 133-G, deve ser enten­
dido como:
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 que a posição foi considerada autenticada,
— o valor do conta-quilómetros do veículo.
TRA_009 Anexo IC, ponto 3.23 Ajustamento da hora, requisito 211,
deve ser entendido como:
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 padrão válida, 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 re­
ló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 padrão , conforme estipu­
lado no apêndice 12. A referência temporal para o ajustamento automá­
tico da hora do relógio interno da VU deve ser fornecida na mensagem
de posição padrão.
TRA_010 Anexo IC, ponto 3.23 Ajustamento da hora, requisito 212,
deve ser entendido como:
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 WriteDa­
taByIdentifier, 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 padrão auten­
ticadas. Neste último caso, deve ser utilizado o serviço RoutineCon­
trol, em conformidade com a secção 8 do apêndice 8.
▼M4
02016R0799 — PT — 21.08.2023 — 003.002 — 609
TRA_011 Apêndice 4, ponto 2: Especificações relativas aos blocos de
dados, primeiro parágrafo, sétimo travessão, deve ser entendida como:
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 picto­
grama indica que esta posição foi considerada autenticada,
TRA_012 Apêndice 8, ponto 8.1 Serviço RoutineControl (ajustamento do
tempo), Descrição da mensagem, requisito CPR_065a, deve ser entendido
como:
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 padrão do recetor GNSS.
Desde que o ajustamento do tempo esteja em curso, a VU responde ao
pedido RoutineControl, subfunção requestRoutineResults, com routi­
neInfo = 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.
TRA_013 No apêndice 12, ponto 3, Frases indicadas pelo recetor GNSS,
requisito GNS_4a:
Os dados contidos nas frases AMC fornecidas pelo recetor GNSS, caso
existam, não devem ser utilizados pela unidade-veículo, exceto para os
seguintes valores do estatuto:
“J”=interferência ou O = outro ataque ao GNSS (através de controlos de
coerência aplicados de acordo com o GNS_3a),
V = nulo (a posição autenticada não está disponível por qualquer outro
motivo).
TRA_014 No apêndice 12, ponto 3, Frases indicadas pelo recetor GNSS,
requisito GNS_5:
Os dados contidos nas frases ASA fornecidas pelo recetor GNSS, caso
existam, não devem ser utilizados pela unidade-veículo.
TRA_015 No apêndice 12, ponto 5.2 Unidade-veículo sem módulo
GNSS externo, Transferência de informações do recetor GNSS para a
VU, requisitos GNS_34 e 36:
O processador da VU não pode utilizar informações extraídas da frase
AMC, exceto para os seguintes valores do estatuto:
“J”=interferência ou O = outro ataque ao GNSS (através de controlos de
coerência aplicados de acordo com o GNS_3a),
V = nulo (a posição autenticada não está disponível por qualquer outro
motivo).
O processador da VU não pode utilizar as informações extraídas da frase
ASA.
▼M4
02016R0799 — PT — 21.08.2023 — 003.002 — 610
TRA_016 Apêndice 12, ponto 6 Tratamento e registo de dados de posi­
ção pela VU, requisito GNS_39, deve ser entendido como:
Os dados de posição são memorizados na VU, juntamente com um in­
dicador que denota que a posição foi considerada autenticada. Quando
os dados de posição precisam de ser registados na VU, aplica-se a regra
seguinte:
a) Se a posição autenticada for válida, a posição padrão e a respetiva
precisão são registadas na VU e o indicador deve ser fixado em
“autenticada”.
TRA_017 Apêndice 12, ponto 6 Tratamento e registo de dados de posi­
ção pela VU, requisito GNS_40, deve ser entendido como:
Quando o valor do estatuto numa frase AMC recebida for fixado em “J”
ou “O” em conformidade com o requisito GNS_4a, a VU deve gerar e
registar um incidente de anomalia GNSS, tal como 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”.
TRA_018 Apêndice 12, ponto 8 Conflito relativo ao movimento do veí­
culo, requisito GNS_42, condição Trigger 2, o primeiro e o segundo
travessões a seguir à fórmula devem ser entendidos como:
— GnssDistance é a distância entre a posição atual do veículo e a
anterior, ambas obtidas a partir de mensagens de posição padrão
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 padrão válida anterior.
TRA_019 Apêndice 14, ponto 5.4.5 Requisitos do protocolo DSRC para
RTMElements de RtmData, ações executadas e definições, requisito
DSC_41, quadro 14.3, segunda célula da linha RTM20, deve ser enten­
dido como:
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
padrão do veículo ficou disponível a partir do recetor GNSS.
Se nunca tiver estado disponível uma posição padrão do veículo a partir
do recetor GNSS, a VU fixa o valor de RTM20 em 0.
TRA_020 O fabricante de uma unidade-veículo de transição homologada
deve informar a Comissão das suas versões de software. A Comissão
publica essas versões de software num sítio Web acessível ao público.
▼M4
02016R0799 — PT — 21.08.2023 — 003.002 — 611
5. DISPOSIÇÕES ESPECIFICAS PARA A HOMOLOGAÇÃO E UTILI­
ZAÇÃO DE TACOGRAFOS DE TRANSIÇÃO
TRA_021 As unidades-veículo de transição devem ser homologadas de
acordo com os requisitos do anexo IC e dos seus anexos 1 a 16, com­
plementados pelas disposições do presente apêndice.
TRA_022 Os certificados de homologação das unidades-veículo de tran­
sição e dos tacógrafos de transição só podem ser solicitados até 31 de de­
zembro de 2023 ou até à data da declaração de serviço da OSNMA,
consoante a data que for posterior.
TRA_023 As unidades-veículo de transição só podem ser instaladas em
veículos matriculados pela primeira vez até 31 de maio de 2024 ou 5
meses após a data da declaração de serviço da OSNMA, consoante a data
que for posterior.
▼M4
02016R0799 — PT — 21.08.2023 — 003.002 — 612
ANEXO II
MARCA E CERTIFICADO DE HOMOLOGAÇÃO
I. MARCA DE HOMOLOGAÇÃO
1. Composição da marca de homologação:
a) um retângulo, no interior do qual se coloca a letra «e», seguida de uma
letra ou de um número distintivo do país que tenha concedido a homolo­
gação, segundo as seguintes convenções:
Bélgica 6
Bulgária 34
República Checa 8
Dinamarca 18
Alemanha 1
Estónia 29
Irlanda 24
Grécia 23
Espanha 9
França 2
Croácia 25
Itália 3
Chipre CY
Letónia 32
Lituânia 36
Luxemburgo 13
Hungria 7
Malta MT
Países Baixos 4
Áustria 12
Polónia 20
Portugal 21
Roménia 19
Eslovénia 26
Eslováquia 27
Finlândia 17
Suécia 5
Reino Unido 11
e
▼M1
b) o número de homologação, correspondente ao número do certificado de
homologação atribuído ao protótipo do aparelho de controlo ou à folha de
registo ou cartão tacográfico, colocado na proximidade daquele retângulo.
▼C1
02016R0799 — PT — 21.08.2023 — 003.002 — 613
2. A marca de homologação é aposta na chapa sinalética de cada aparelho, em
cada folha de registo e em cada cartão tacográfico. Deve ser indelével e
conservar-se sempre bem legível.
3. As dimensões da marca de homologação, a seguir representada grafica­
mente ( 1 ), são expressas em milímetros. Trata-se de dimensões mínimas. A
relação de proporcionalidade entre as dimensões deve ser respeitada.
▼C1
( 1 ) Valores meramente a título de orientação.
02016R0799 — PT — 21.08.2023 — 003.002 — 614
II. CERTIFICADO DE HOMOLOGAÇÃO PARA TACÓGRAFOS
ANALÓGICOS
O Estado-Membro que tiver procedido a uma homologação deve conceder ao
requerente um certificado de homologação, conforme o modelo a seguir indicado.
Para informar outros Estados-Membros das homologações concedidas ou even­
tualmente revogadas, os Estados-Membros devem utilizar cópias do certificado.
CERTIFICADO DE HOMOLOGAÇÃO
Nome da autoridade
Comunicação referente a ( 1 ):
— homologação de um modelo de aparelho de controlo
— revogação da homologação de um modelo de aparelho de controlo
— homologação de um modelo de folha de registo
— revogação da homologação de um modelo de folha de registo
N. o de homologação:
...................................
1. Marca de fabrico ou comercial
2. Denominação do modelo
3. Nome do fabricante
4. Endereço do fabricante
5. Data da apresentação para homologação
6. Laboratório de ensaios
7. Data e número de ensaios
8. Data da homologação
9. Data da revogação da homologação
10. Modelo(s) de aparelho(s) de controlo no(s) qual(is) a folha se destina a ser
utilizada
11. Lugar
12. Data
13. Documentos descritivos em anexo
14. Observações (incluindo a posição dos selos, se for caso disso)
(assinatura)
▼C1
( 1 ) Riscar o que não interessa.
02016R0799 — PT — 21.08.2023 — 003.002 — 615
III. CERTIFICADO DE HOMOLOGAÇÃO PARA TACÓGRAFOS DIGITAIS
O Estado-Membro que tiver procedido a uma homologação deve conceder ao
requerente um certificado de homologação, conforme o modelo a seguir indicado.
Para informar outros Estados-Membros das homologações concedidas ou even­
tualmente revogadas, os Estados-Membros devem utilizar cópias do certificado.
CERTIFICADO DE HOMOLOGAÇÃO PARA TACÓGRAFOS DIGITAIS
Nome da autoridade
Comunicação referente a ( 1 ):
□ homologação de: □ revogação da homologação de:
□ modelo de aparelho de controlo
□ componente de aparelho de controlo ( 2 )
□ cartão de condutor
□ cartão de oficina
□ cartão de empresa
□ cartão de controlador
N. o de homologação:
1. Marca de fabrico ou marca comercial
2. Nome do modelo
3. Nome do fabricante
4. Endereço do fabricante
▼M1
5. Data da apresentação para homologação
▼C1
6. Laboratório(s)
7. Data e número do relatório de ensaio
9. Data da revogação da homologação
10. Modelo de aparelho(s) de controlo no(s) qual(is) o componente se destina a
ser utilizado
11. Lugar
12. Data
13. Documentos descritivos em anexo
14. Observações (incluindo a posição dos selos, se for caso disso)
(assinatura)
▼C1
( 1 ) Assinalar os quadrados pertinentes.
( 2 ) Especificar o componente a que se refere a comunicação.
02016R0799 — PT — 21.08.2023 — 003.002 — 616
IV. CERTIFICADO DE HOMOLOGAÇÃO PARA TACÓGRAFOS
INTELIGENTES
O Estado-Membro que tiver procedido a uma homologação deve conceder ao
requerente um certificado de homologação, conforme o modelo a seguir indicado.
Para informar outros Estados-Membros das homologações concedidas ou even­
tualmente revogadas, os Estados-Membros devem utilizar cópias do certificado.
CERTIFICADO DE HOMOLOGAÇÃO PARA TACÓGRAFOS
INTELIGENTES
Nome da autoridade
Comunicação referente a ( 1 ):
□ homologação de: □ revogação da homologação de:
□ modelo de aparelho de controlo
□ componente de aparelho de controlo ( 2 )
□ cartão de condutor
□ cartão de oficina
□ cartão de empresa
□ cartão de controlador
N. o de homologação:
1. Marca de fabrico ou marca comercial
2. Nome do modelo
3. Nome do fabricante
4. Endereço do fabricante
▼M1
5. Data da apresentação para homologação
▼C1
6. a) Laboratório de ensaio para certificação de funcionalidade
b) Laboratório de ensaio para certificação de segurança
c) Laboratório de ensaio para certificação de interoperabilidade
7. a) Data e número do certificado de funcionalidade
b) Data e número de certificado de segurança …
8. Data da homologação
9. Data da revogação da homologação
10. Modelo de aparelho(s) de controlo no(s) qual(is) o componente se destina a
ser utilizado
11. Lugar
12. Data
13. Documentos descritivos em anexo
14. Observações (incluindo a posição dos selos, se for caso disso)
(assinatura)
▼C1
( 1 ) Assinalar os quadrados pertinentes.
( 2 ) Especificar o componente a que se refere a comunicação.


Full & Egal Universal Law Academy