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  2 0  6.2.2020  
►M3 Regulamento de Execução (UE) 2021/1228 da Comissão de 16 de ju lho 
de 2021  L 273  1  30.7.2021  
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.001 — 1
02016R0799 — PT — 21.08.2023 — 003.001 — 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óg rafos:  
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 in devido 
de tacógrafos inteligentes;  
c) interface com sistemas de transporte inteligentes;  
d) os requisitos administrativos e técnicos para os procediment os 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 funciona mento 
e a reparação de tacógrafos inteligentes e dos respetivos compo nentes 
devem cumprir os requisitos técnicos constantes do anexo IC do pre­
sente regulamento.  
3. No que respeita à construção, ao ensaio, à instalação, à ins peçã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 pesag em 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 1 6 de abril 
de 2014, relativa à harmonização da legislação dos Estados-Memb ros 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.001 — 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ónic o 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 e le­
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 part es 
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 rodo viá­
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 element os: 
unidade-veículo, sensor de movimentos, cartão tacográfico, folh a 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-Membr o 
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, s e 
for caso disso, a revogação dos certificados de homologação, ag ir 
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 prescr ito 
no presente regulamento ;  
▼M1 
10) «unidade-veículo»: o tacógrafo, excluindo o sensor de movim entos 
e os cabos que o ligam.  
A unidade pode ser única ou consistir em diversas unidades dist ribuí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.001 — 4  
e instrumentos para a introdução de dados do utilizador, um rec etor 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íd as 
pelo veículo, o corpo principal da unidade-veículo é constituíd o 
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 homol o­
gação para esse efeito designadas por cada Estado-Membro. O ped ido 
compreende um dossier de fabrico que contém as informações rela tivas 
a cada um dos componentes em questão, incluindo, se for caso di sso, 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éc nicos 
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 adici o­
nais ao fabricante (ou ao seu mandatário).  ▼M1
 02016R0799 — PT — 21.08.2023 — 003.001 — 5  
4. O fabricante (ou o seu mandatário) deve disponibilizar às au tori­
dades de homologação, bem como às entidades responsáveis pela e mis­
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 procedimen to de 
homologação.  
5. Sempre que o fabricante (ou o seu mandatário) visar a homolo ga­
ção de determinados componentes ou grupos de componentes de um 
tacógrafo, deve fornecer às autoridades de homologação os outro s com­
ponentes já homologados, bem como outras peças necessárias à co ns­
trução integral do tacógrafo, a fim de que as autoridades de ho mologa­
ção realizem os ensaios necessários.  
Artigo 5.  o 
Alterações às homologações  
1. O fabricante (ou o seu mandatário) deve comunicar imediatame nte 
às autoridades de homologação que concederam a homologação orig inal 
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 a lte­
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 utili za­
dos no fabrico são pequenas, deve proceder a uma «revisão». Nes ses 
casos, deve emitir os documentos revistos do dossier de homolog ação, 
indicando a natureza das alterações efetuadas e a data da sua h omolo­
gação. Para cumprimento do presente requisito, será suficiente a versão 
atualizada do dossier de homologação em forma consolidada, acom pa­
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 utili za­
dos no fabrico são substanciais, deve proceder a uma «prorrogaç ão». 
Nesses casos, pode solicitar novos ensaios e informar o fabrica nte (ou o 
seu mandatário) em conformidade. Se os novos ensaios forem sati sfa­
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 ma is 
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 par a 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.001 — 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 20 16. 
▼M1 
No entanto, o anexo IC é aplicável a partir de 15 de junho de 2 019, 
com exceção do apêndice 16, que é aplicável a partir de 2 de ma rç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.001 — 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 consent imento 
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 incorretamen te» 
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 re cetor 
GNSS»  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 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 co ndutor 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íod os 
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.001 — 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 seletivo s 
▼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 segun da gera­ 
ção) 
4.5.2.3 Informações ATR (condicionadas, presentes somente nos c artões 
tacográficos da segunda geração)  
4.5.2.4 Informação do aumento do comprimento (condicionado, pre sente 
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 da s 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.001 — 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 cond ução acumula­ 
das 
▼M3 
4.5.3.2.17 Estatuto de autenticação de posições relacionadas co m locais de 
início e/ou final dos períodos de trabalho diário (não acessíve l 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 atin gidas 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 d as 
unidades-veículo da segunda geração)  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 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 da s 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 temp o 
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 temp o 
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.001 — 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 cond uçã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 co m locais de 
início e/ou final dos períodos de trabalho diário (não acessíve l 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 atin gidas 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 d as 
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ív eis 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 da s 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íc ulo 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.001 — 13  
4.5.6.1 Aplicação tacográfica (acessível às unidades-veículo da s 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íc ulo 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íc ulos 
▼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 interope rabili­ 
dade para aparelhos de controlo e cartões tacográficos da segun da 
geração  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 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 conce bidos para serem 
também utilizados nas unidades-veículo da primeira geração cons truídas de 
acordo com o anexo IB do Regulamento (CEE) n.  o 3821/85.  
Reciprocamente, os cartões tacográficos da primeira geração pod em ser utilizados 
nas unidades-veículo da segunda geração. No entanto, as unidade s-veículo da 
segunda geração só podem ser calibradas utilizando cartões de o ficina da segunda 
geração.  
Os requisitos respeitantes à interoperabilidade entre os sistem as tacográficos da 
primeira e da segunda geração encontram-se especificados no pre sente anexo. 
Neste sentido, o apêndice 15 contém informações adicionais sobr e a gestão da 
coexistência entre ambas as gerações.  
Além disso, graças à implementação de novas funções, como a uti lização da 
Autenticação de Mensagens de Navegação de Sinal Aberto do Galil eo, 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 cond utor para 56 dias 
de atividade de condução, o presente regulamento introduz os re quisitos técnicos 
para a segunda versão dos aparelhos de controlo e dos cartões t acográ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.001 — 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 relevante s 
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.001 — 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 co ndução contínua. Não 
prejudica a interpretação jurídica desses intervalos. Podem uti lizar-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 atualiz açõ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.001 — 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 co ndução contínua. Não 
prejudica a interpretação jurídica desses intervalos. Podem uti lizar-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 atualiz açõ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.001 — 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 Parlame nto Europeu e do 
Conselho (JO L 353 de 21.12.2012, p. 31), na sua última redação .
 02016R0799 — PT — 21.08.2023 — 003.001 — 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, re lativa à instalação e 
utilização de dispositivos de limitação de velocidade para cert as categorias de veículos 
a motor na Comunidade (JO L 57 de 2.3.1992, p. 27).
 02016R0799 — PT — 21.08.2023 — 003.001 — 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.001 — 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, relat iva 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, r elativa à aproximação 
das legislações dos Estados-Membros respeitantes às chapas e in scrições regulamentares, 
bem como à sua localização e modo de fixação no que respeita ao s 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 desti nados 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.001 — 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.001 — 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, exib ir, 
imprimir e transmitir os dados relativos às atividades do condu tor. 
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 c on­
trolo. Estas funções podem ser incluídas no aparelho de control o. 
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.001 — 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áfico s. 
▼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.001 — 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
 Ranhura do ajudante 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.001 — 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 movime n­
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 autent icidade 
dos dados intercambiados através da comunicação de deteção rápi da 
à distância para efeitos de controlo e verificar a integridade e a 
autenticidade dos dados descarregados.  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 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.001 — 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.001 — 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.001 — 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ív el 
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.001 — 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.001 — 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 d o 
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.001 — 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.001 — 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.001 — 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 d e 
o veículo abandonar o local onde a operação de carga/des­
carga é realizada.  ▼M3
 02016R0799 — PT — 21.08.2023 — 003.001 — 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 falha s: 
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.001 — 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
 Ranhura do ajudante 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
 Ranhura do ajudante 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.001 — 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.001 — 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.001 — 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 ciclo s 
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.001 — 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.001 — 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.001 — 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.001 — 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íod os diários 
de trabalho e/ou em que são alcançados os períodos de três hora s 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 d o 
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.001 — 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 t em 
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.001 — 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.001 — 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.001 — 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 control o 
deve procurar registar e memorizar na sua memória, se­
gundo as regras indicadas, os seguintes dados:  ▼B
02016R0799 — PT — 21.08.2023 — 003.001 — 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.001 — 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.001 — 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.001 — 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 aparelh o 
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.001 — 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 qu e 
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.001 — 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.001 — 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.001 — 56  
141) A atualização dos dados de cartões tacográficos deve ser d e 
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 a os 
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.001 — 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 d e 
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.001 — 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.001 — 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.001 — 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, d a 
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.001 — 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.001 — 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 equipado s 
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.001 — 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.001 — 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.001 — 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.001 — 66  
3.22 Controlo de calibração de estrada  
207) A função de controlo de calibração de estrada deve permiti r 
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.001 — 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 interna s 
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.001 — 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 o s 
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 frontei ra 
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 pos i­
çã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.001 — 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  N L  Países Baixos  
D 
EST Alemanha 
Estónia  A 
PL Áustria 
Polónia  ▼M3
 02016R0799 — PT — 21.08.2023 — 003.001 — 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  U K  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 e feitos 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.001 — 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íst i­
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.001 — 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 autentic idade 
dos dados que circulam entre os cartões e o aparelho de control o 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 falsi fica­
çã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.001 — 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, cons tam 
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áfic o 
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.001 — 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.001 — 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 memorizado s 
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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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 memorizado s 
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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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 cond uçã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 co m locais de 
início e/ou final dos períodos de trabalho diário (não acessíve l 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.001 — 86  
4.5.3.2.18 Estatuto de autenticação de posições em que são atin gidas 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 d as 
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.001 — 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.001 — 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 temp o 
313) O cartão de oficina deve poder guardar os registos relativ os 
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.001 — 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.001 — 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 temp o 
336) O cartão de oficina deve poder guardar os registos relativ os 
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.001 — 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.001 — 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 cond uçã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 co m locais de 
início e/ou final dos períodos de trabalho diário (não acessíve l na 
versão 1 das unidades-veículo da segunda geração)  
356-A) O cartão de oficina deve poder memorizar dados adicionai s 
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.001 — 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 atin gidas 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 des te 
tipo. 
4.5.4.2.18 Travessia de fronteiras (não acessível na versão 1 d as 
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 dest e 
tipo. 
4.5.4.2.21 Dados adicionais relativos à calibração (não acessív eis 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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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 regista r 
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.001 — 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.001 — 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 transporte s rodoviários (JO L 21 
de 24.1.2009, p. 3).
 02016R0799 — PT — 21.08.2023 — 003.001 — 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 d e 
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.001 — 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 dev em 
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 r isco 
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.001 — 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.001 — 104  
411) Caso se verifique, desde a última inspeção, a ocorrência d e 
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.001 — 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 altera r 
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.001 — 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 qua l­
quer componente do aparelho de controlo, desde que estes esteja m 
em conformidade com os requisitos do presente anexo. Em alterna ­
tiva, os fabricantes podem também solicitar a homologação de ti po 
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íve l do 
conjunto de componentes. Independentemente do conjunto de com­
ponentes da unidade-veículo, a antena externa e (quando aplicáv el) 
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 tip o 
para o aparelho de controlo devem publicitar uma lista de anten as 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.001 — 107  
429) Os procedimentos de atualização  in situ  d o 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.001 — 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.001 — 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.001 — 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 d e 
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 pel o 
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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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 e struturas 
dos dados a utilizar no aparelho de controlo e nos cartões taco gráficos.  
1.1. Metodologia na definição dos tipos de dados  
O presente apêndice utiliza a Abstract Syntax Notation One («no tação de 
sintaxe abstrata um» ou ASN.1) para definir os tipos de dados, per­
mitindo que dados simples e estruturados sejam definidos sem si ntaxe 
específica de transferência (regra de codificação) dependente d a 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 m arcar 
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, co m 
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, algu ns tipos 
ASN.1 que constam do presente apêndice são restringidos por ide ntifi­
cadores de intervalos (ou gamas) de valores. Na secção 3 e no a pê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.001 — 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 Notatio n 
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 defe ito 
relativo a um conteúdo «desconhecido» ou «não aplicável» consis te 
em preencher o elemento de dados com bytes «FF»Hex, salvo indic ação 
em contrário.  
Nas aplicações de geração 1 e geração 2 utilizam-se todos os ti pos 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 ge ração 1 e 
de geração 2, a dimensão especificada no presente apêndice refe re-se à 
aplicação de geração 2. Supõe-se que a dimensão referente à apl icação 
de geração 1 já seja conhecida pelo leitor. Os números dos requ isitos do 
anexo IC referentes a tais tipos de dados abrangem tanto as apl icaçõ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 ge raçã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 p ara 
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.001 — 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 0 0h00 
e/ou alterações na atividade e/ou alterações na situação da con dução e/ou 
alterações na situação do cartão, quer para o condutor quer par a 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 (o u 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.001 — 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 é retira do 
— «c» deve ser fixado em 0  
— «p» deve ser fixado em 1  
— «aa» deve codificar a atividade em curso, selecionada no mome nto. 
Em resultado de uma entrada manual, os bits «c» e «aa» da palav ra 
(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.001 — 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 rep resentar 
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.001 — 126  
BCDString utiliza uma notação «hstring». O algarismo hexadecima l 
mais à esquerda deve ser o semiocteto mais significativo do pri meiro 
octeto. Para produzir um múltiplo de octetos, inserem-se os nec essários 
semioctetos de zeros à direita, a partir da posição de semiocte to 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âmet ros de 
calibração. Este tipo de dado está relacionado com os requisito s 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 utilizado s 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 co ndutor 
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ár io mais 
antigo, o valor de activityPreviousRecordLength deve ser fixado  em 0.  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 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 (u ma 
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íve is 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 ev entuais 
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 rela tiva à 
travessia de fronteiras do veículo, quando este tiver atravessa do 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ên cia do 
registo de travessia de fronteiras do cartão na estrutura.  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 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 rela tiva à 
travessia de fronteiras do veículo, quando este tiver atravessa do 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 unidad e- 
-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 m emori­
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. «Rest o do 
mundo» (código NationNumeric «FF»H) é utilizado quando a unidad e- 
-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 m emori­
zados).  
gnssPlaceAuthRecord  contém informações respeitantes à posição do 
veículo, quando a unidade-veículo deteta que o veículo atravess ou 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 autent icação.  
vehicleOdometerValue  é o valor do conta-quilómetros, quando 
a unidade-veículo deteta que o veículo atravessou a fronteira d e 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 icSe rialNum­
ber, juntamente com o icManufacturingReferences, identifica a p astilha 
do cartão de forma única. O icSerialNumber sozinho não identifi ca a 
pastilha do cartão de forma única.
  
icSerialNumber  é o número de série do IC.  ▼M3
 02016R0799 — PT — 21.08.2023 — 003.001 — 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 re lativa 
ao último controlo a que o condutor tiver sido sujeito (requisi tos 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 2 73, 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 re tirado o 
cartão.  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 130  
2.17.  CardDriverActivity  
Informação memorizada num cartão de condutor ou de oficina e re lativa 
à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 ma is 
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 ma is 
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: CardActivityDailyRec ord) 
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 memo rização 
prossegue no primeiro byte da cadeia, independentemente de have r des­
continuidade dentro de um elemento de dado. Antes de se colocar em 
novos dados de atividade na cadeia (aumentando o atual activity Daily­
Record ou colocando um novo activityDailyRecord) em substituiçã o dos 
dados de atividade mais antigos, o activityPointerOldestDayReco rd tem 
de ser atualizado, em reflexo da nova localização do mais antig o 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 dad os 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.001 — 131  
2.19.  CardEventData  
Geração 1:  
Informação memorizada num cartão de condutor ou de oficina e re lativa 
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 tent ativas de 
violação da segurança).  
Geração 2:  
Informação memorizada num cartão de condutor ou de oficina e re lativa 
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 tent ativas de 
violação da segurança).  
▼B 
2.20.  CardEventRecord  
Informação memorizada num cartão de condutor ou de oficina e re lativa 
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.001 — 132  
2.21.  CardFaultData  
Informação memorizada num cartão de condutor ou de oficina e re lativa 
à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 re lativa 
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.001 — 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 rela tiva 
aos dados do tipo de carga introduzidos numa unidade-veículo (r equisi­
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 pr imeira 
ocorrência do registo de introdução do tipo de carga no cartão na 
estrutura.  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 134  
cardLoadTypeEntryRecords  é o conjunto de registos que contêm a 
data e hora da introdução dos dados e o tipo de carga introduzi do. 
2.24-B.  CardLoadTypeEntryRecord  
Geração 2, versão 2:  
Informação memorizada num cartão de condutor ou de oficina rela tiva às 
mudanças do tipo de carga introduzidas quando o cartão é inseri do 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 rela tiva à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/descar ga foram 
introduzidas, informação sobre a posição do veículo e o valor d o 
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 re lativa 
às operações de carga/descarga do veículo (requisitos 306-G e 3 56-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.001 — 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úm ero 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 ane xo IC).  ▼M3
 02016R0799 — PT — 21.08.2023 — 003.001 — 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 re lativa 
aos locais onde se iniciam e/ou terminam os períodos de trabalh o 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.001 — 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 estru tura 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 ranhura s 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.001 — 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 tac ográ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 elemento s 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 re lativa 
a um período de utilização de um veículo durante um dia (requis itos 
269, 294, 322 e 345 do anexo 1C).  
Geração 1:
  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 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 utilizado s 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 re lativa 
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.001 — 140  
Informação memorizada num cartão de condutor ou de oficina e re lativa 
a uma unidade-veículo que foi utilizada (requisitos 303 e 351 d o 
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, relativ a 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 rela tiva 
às unidades-veículos utilizadas pelo titular do cartão (requisi tos. 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 r egistos 
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 d e 
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 o s me­
canismos comuns de segurança (apêndice 11): Assinatura (128 byt es) || 
Alerta de chave pública (58 bytes) || Referência da autoridade de certi­
ficação (8 bytes).  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 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 conf ormi­
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 dess a 
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.001 — 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ít ulo 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 igualment e 
utilizar-se como identificador da chave pública de uma 
unidade-veículo se, no momento da geração do certificado, não s e co­
nhecer o número de série da unidade-veículo à qual a chave se d estina.
  
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.001 — 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 identific adores de 
chave.  
Valor atribuído : «01h».  
2.46.  CompanyActivityData  
Informação memorizada num cartão de empresa e relativa às ativi dades 
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.001 — 144  
2.47.  CompanyActivityType  
Código que indica uma atividade executada por uma empresa que u tiliza 
o respetivo cartão.
  
2.48.  CompanyCardApplicationIdentification  
Informação memorizada num cartão de empresa e relativa à identi ficaçã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 à identifi caçã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 à identi ficação 
do seu titular (requisitos 372 e 378 do anexo 1C).
  
companyName  é o nome da empresa titular.  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 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 à ident ificaçã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 à identif icaçã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 à ativi dade 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.001 — 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 à ident ificaçã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.001 — 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.001 — 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 tenh a estado 
inserido numa VU. Este tipo de dado está relacionado com os req uisitos 
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úm ero 
é 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.001 — 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 pr otocolo 
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 u ma 
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.001 — 150  
2.61.  DriverCardApplicationIdentification  
Informação memorizada num cartão de condutor e relativa à ident ifica­
çã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 utilizado s 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.001 — 151  
2.61-A.  DriverCardApplicationIdentificationV2  
Geração 2, versão 2:  
Informação memorizada num cartão de condutor e relativa à ident ifica­
çã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 à ident ifica­
çã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 1 1. ▼M3
 02016R0799 — PT — 21.08.2023 — 003.001 — 152  
2.64.  EGFCertificate  
Geração 2:  
Certificado da chave pública do módulo GNSS externo para autent icaçã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 re lativa 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 apl icação 
tacográfica.
  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 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 Europ a no 
campo de certificados CHA.  
Geração 2:  
▼M1 
Utilizam-se os mesmos valores da geração 1, com as seguintes ob ser­
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-v eí­
culo e o sensor de movimentos, podem ser utilizados em SealReco rd (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.001 — 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 s ensor 
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.001 — 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 s ensor 
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.001 — 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.001 — 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.001 — 158  
2.71.  ExtendedSealIdentifier  
Geração 2:  
O identificador de selo alargado identifica, com caráter exclus ivo, 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 utilizad o 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.001 — 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 resp etiva 
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 inteiro s. 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» (decim al 
8388607).  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 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 pre cisã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 re lativa 
à posição GNSS do veículo, se o tempo de condução acumulado ati ngir 
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 re lativa 
à posição GNSS do veículo, se o tempo de condução acumulado ati ngir 
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.001 — 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 ho ras. 
▼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 t empo de 
condução acumulado atingir um múltiplo de três horas (requisito s 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 p osiçã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 t empo de 
condução acumulado atingir um múltiplo de três horas (requisito s 306-C 
e 356-C do anexo IC). Outras informações relativas à própria po siçã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.001 — 162  
2.79-C.  GNSSPlaceAuthRecord  
Geração 2, versão 2:  
Informação relacionada com a posição GNSS do veículo (requisito s 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 (requisi tos 
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 pe rcorridas 
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.001 — 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 referen ciar 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 GNS S 
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 con hecido 
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.001 — 164  
Chave AES e a respetiva versão da chave associada, utilizada pa ra 
emparelhamento do sensor de movimentos com a VU. Para mais info r­
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 V U. 
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 co ntrolo) 
(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.001 — 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 compr imento, 
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 ativ idades 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 dev e 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.001 — 166  
2.95.  ManufacturerSpecificEventFaultData  
Geração 2:  
Os códigos de erro específicos do fabricante simplificam a anál ise 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 pel a 
autoridade europeia de certificação.
  
2.97.  MemberStateCertificateRecordArray  
Geração 2:  
O certificado do Estado-Membro, mais metadados utilizados no pr oto­
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 comprimento s 
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.001 — 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 co m os 
códigos distintivos utilizados em veículos no tráfego internaci onal (Con­
venção das Nações Unidas sobre Trânsito Viário, Viena, 1968).
  
Os códigos NationAlpha e NationNumeric devem constar de uma lis ta 
publicada no sítio Web do laboratório nomeado para a realização  do 
ensaio de interoperabilidade, conforme estabelecido no requisit o 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ógra fos 
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.001 — 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 ca rtã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 ofi cina 
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 c ondutor 
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 car tã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 emp resa 
pode memorizar.
  
Valor atribuído : ver apêndice 2.  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 169  
2.108.  NoOfControlActivityRecords  
Número de registos de atividade de controlo que um cartão de co ntrolo 
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 memoriz ar.
 
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 memor izar.
 
Valor atribuído : ver apêndice 2.  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 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 dete rmi­
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.001 — 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 con trolo 
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 veloc idade, 
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 I C). 
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 me mori­
zadas num registo diferente (ver o ponto 2.117 PlaceRecord).  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 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 1 C). 
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 utilizado s 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.001 — 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 con dutor 
no momento em que insere o seu cartão numa unidade-veículo (req ui­
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.001 — 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 especific ado.
 
Geração 1:  
Valor atribuído:
  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 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 especificad o.
 
Geração 1:  
Valor atribuído:
  
Geração 2:  
Os códigos RegionNumeric devem constar de uma lista publicada n o 
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.001 — 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 me mori­
zação num cartão. Este tipo de dado está relacionado com o requ isito 
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 me mori­
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 s eal­
Records não utilizados deverá ser fixado em 16, isto é, não uti lizado.  
2.130.  SealRecord  
Geração 2:  
Este tipo de dado memoriza informações sobre um selo que está l igado 
a um componente. Este tipo de dado está relacionado com o requi sito 
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.001 — 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 à identif ica­
çã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 (req uisito 
98 do anexo 1C).  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 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.001 — 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 cr iptográ­
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 receto r 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 à ide n­
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.001 — 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 moviment os. 
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 dado s de 
segurança necessários para emparelhar sensores de movimentos co m 
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 mem o­
rizar até três chaves para emparelhamento do sensor de moviment os 
com a VU. Estas chaves têm diferentes versões principais.
  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 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 à identif ica­
çã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 pe la 
primeira vez com uma VU.  
2.145.  SensorPairedRecord  
Geração 2:  
Informação memorizada numa unidade-veículo e relativa à identif ica­
çã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.001 — 182  
2.147.  SensorSCIdentifier  
Identificador do componente de segurança do sensor de movimento s.
 
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 protoc olo 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 (requis ito 
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 di a em 
questão.  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 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 (requis itos 
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 (requis itos 
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, 1 05a, 
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.001 — 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 primeir a 
geração dos cartões de condutor, controlo e empresa (ver o apên dice 
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.001 — 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.001 — 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.001 — 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 12 1 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.001 — 188  
Informação memorizada numa VU e relativa a mudanças na atividad e 
e/ou na situação da condução e/ou na situação do cartão num det ermi­
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 du as 
palavras ActivityChangeInfo que dão a situação das duas ranhura s às 
00h00 desse dia.  
2.171.  VuActivityDailyRecordArray  
Geração 2:  
Informação memorizada numa VU e relativa a mudanças na atividad e 
e/ou na situação da condução e/ou na situação do cartão num det ermi­
nado dia (requisito 105, 106 e 107 do anexo 1C) e na situação d as 
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 Ac tivity­
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.001 — 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, inclu indo 
eventuais hífenes). Deve estar alinhado à esquerda.  
2.173.  VuCalibrationData  
Geração 1:  
Informação memorizada numa VU e relativa às calibrações do apar elho 
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 11 9 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.001 — 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 pe la 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.001 — 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 e xista),  
rcmSerialNumber  é o número de série do sistema de comunicação à 
distância acoplado à unidade-veículo no final da calibração (ca so 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 f oi trans­
mitida pelo recetor GNSS.  ▼M3
 02016R0799 — PT — 21.08.2023 — 003.001 — 192  
2.175.  VuCalibrationRecordArray  
Geração 2:  
Informação memorizada numa VU e relativa às calibrações do apar elho 
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 ciclo s 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 cicl o de 
inserção e retirada de um cartão de condutor ou de oficina ness a VU 
(requisito 081 do anexo 1B e requisito 102 do anexo 1C).  
Geração 1:
  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 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 rec orre à 
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.001 — 194  
Informação memorizada numa unidade-veículo e relativa aos ciclo s 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 retir ada 
de cartões.  
▼M1 
2.179.  VuCardRecord  
Geração 2:  
Informações memorizadas numa unidade-veículo sobre um cartão ta co­
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 t aco­
gráficos utilizados nesta VU. Estas informações destinam-se à a nálise de 
problemas com cartões na VU (requisito 132 do anexo 1C).
  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 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 bloqu eios 
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.001 — 196  
2.184.  VuCompanyLocksRecord  
Informação memorizada numa unidade-veículo e relativa aos bloqu eios 
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 bloqu eios 
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.001 — 197  
2.185-A.  VuConfigurationLengthRange  
Geração 2, versão 2:  
Número de bytes num cartão tacográfico, disponíveis para memori zar 
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 contr olos 
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 contr olos 
executados por meio da mesma (requisito 102 do anexo 1B e requi sito 
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.001 — 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 contr olos 
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 à velocid ade 
detalhada do veículo num minuto durante o qual o mesmo esteve e m 
movimento (requisito 093 do anexo 1B e requisito 116 do anexo 1 C). ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 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 speedBlockBeginDat e 
(inclusive).  
2.191.  VuDetailedSpeedBlockRecordArray  
Geração 2:  
Informação memorizada numa unidade-veículo e relativa à velocid ade 
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 à velocid ade 
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.001 — 200  
Valor atribuído : tal como especificado no sítio Web específico seguro 
disponibilizado pela Comissão Europeia (requisito 133-K do anex o 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 condut ores 
(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, memo rizada 
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, memo rizada 
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 úl timo 
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.001 — 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 rec orre à 
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 (re qui­
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 incid entes 
(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.001 — 202  
2.198.  VuEventRecord  
Informação memorizada numa unidade-veículo e relativa a um inci dente 
(requisito 094 do anexo 1B e requisito 117 do anexo 1C, com exc eçã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 tev e 
início.  
cardNumberCodriverSlotBegin  identifica o cartão que se encontrava 
inserido na ranhura do ajudante no momento em que o incidente t eve 
início.  
cardNumberDriverSlotEnd  identifica o cartão que se encontrava inse­
rido na ranhura do condutor no momento em que terminou o incide nte. 
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, co m exce­
ção dos incidentes de excesso de velocidade.  
Geração 2:
  
Utilizam-se os seguintes elementos de dados, além dos utilizado s na 
geração 1:  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 203  
manufacturerSpecificEventFaultData  contém informações adicionais, 
específicas do fabricante sobre o incidente.  
Em vez de cardNumberDriverSlotBegin, cardNumberCodriverSlotBe­
gin, cardNumberDriverSlotEnd e cardNumberCodriverSlotEnd, a est ru­
tura de dados da geração 2 recorre aos seguintes elementos de d ados:  
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 ajudant e 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 event End­
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 incid entes 
(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.001 — 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 fal ha 
(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 termi nou. ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 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 est ru­
tura de dados da geração 2 recorre aos seguintes elementos de d ados:  
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 ajudant e 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.001 — 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 ho ras. 
▼M3 
Geração 2, versão 2:  
Informação memorizada numa unidade-veículo relativa à posição G NSS 
do veículo, se o tempo de condução acumulado atingir um múltipl o 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 au ten­
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 fronteir a de um 
país (requisitos 133-A e 133-B do anexo IC).  ▼M1
 02016R0799 — PT — 21.08.2023 — 003.001 — 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. «Res to 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ícu lo 
não é capaz de determinar o país em que o veículo está localiza do (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 r espetivo 
estatuto de autenticação.  
vehicleOdometerValue  é o valor do conta-quilómetros, quando 
a unidade-veículo deteta que o veículo atravessou a fronteira d e um 
país. 
2.203-B.  VuBorderCrossingRecordArray  
Geração 2, versão 2:  
Informação memorizada numa unidade-veículo relativa às travessi as 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.001 — 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 tem po 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 GNS S 
externo; ver o apêndice 12, requisito GNS_3g.
  
▼B 
2.205.  VuIdentification  
Informação memorizada numa unidade-veículo e relativa à identif icaçã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.001 — 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 utilizado s 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.001 — 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 con sen­
timento de um condutor para a utilização de sistemas de transpo rte 
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 con sen­
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.001 — 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.001 — 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 inciden tes 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.001 — 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 inciden tes 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 inciden tes de 
excesso de velocidade (requisito 094 do anexo 1B e requisito 11 7 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.001 — 214  
cardNumberDriverSlotBegin : identifica o cartão que se encontrava 
inserido na ranhura do condutor no momento em que o incidente t eve 
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 inciden tes de 
excesso de velocidade (requisito 094 do anexo 1B e requisito 11 7 do 
anexo 1C).
  
Em vez de cardNumberDriverSlotBegin, a estrutura de dados da ge ra­
çã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 inciden tes 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.001 — 215  
2.218.  VuPlaceDailyWorkPeriodData  
Geração 1:  
Informação memorizada numa unidade-veículo e relativa aos locai s 
onde os condutores iniciam ou terminam um período de trabalho d iá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 loca l 
onde um condutor inicia ou termina um período de trabalho diári o 
(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 loca l 
onde um condutor inicia ou termina um período de trabalho diári o 
(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 rec orre 
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 (re quisito 
087 do anexo 1B e requisitos 108 e 110 do anexo 1C).  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 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 locai s 
onde os condutores iniciam ou terminam um período de trabalho d iá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.001 — 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.001 — 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 ajust amen­
tos do tempo executados fora do âmbito de uma calibração regula r 
(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 ajus ta­
mento do tempo executado fora do âmbito de uma calibração regul ar 
(requisito 101 do anexo 1B e requisitos 124 e 125 do anexo 1C).  
Geração 1:
  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 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 ajust amen­
tos do tempo executados fora do âmbito de uma calibração regula r 
(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 à identi ficação 
da aplicação do cartão (requisitos 307 e 330 do anexo 1C).  
Geração 1:
  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 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 utilizado s 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 à identifi cação 
da aplicação do cartão (requisito 330-A do anexo IC).  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 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 duran te 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 primei ra 
ocorrência do registo de dados adicionais de calibração na estr utura.  
workshopCardCalibrationAddDataRecords  é o conjunto de registos 
que contêm o valor da data e hora antigas, o valor de identific açã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.001 — 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 G NSS. 
▼B 
2.235.  WorkshopCardCalibrationData  
Informação memorizada num cartão de oficina e relativa à ativid ade 
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 ca li­
bração efetuada com esse cartão (requisitos 314 e 337 do anexo 1C). ▼M3
 02016R0799 — PT — 21.08.2023 — 003.001 — 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 pe la ins­
peção.  
vuPartNumber , vuSerialNumber  e sensorSerialNumber : elementos 
de dados relativos à identificação do aparelho de controlo.  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 224  
Geração 2:
  
Utilizam-se os seguintes elementos de dados, além dos utilizado s 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 à identi ficaçã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 (requisito s 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.001 — 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 inciden tes 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 inci dente.  
cardNumberAndGenDriverSlotEnd  identifica o cartão (incluindo a 
sua geração) inserido na ranhura do condutor, no final do incid ente.  
cardNumberAndGenCodriverSlotBegin  identifica o cartão (incluindo 
a sua geração) inserido na ranhura do ajudante, no início do in cidente.  
cardNumberAndGenCodriverSlotEnd  identifica o cartão (incluindo a 
sua geração) inserido na ranhura do ajudante, no final do incid ente.  
similarEventsNumber : número de incidentes similares no dia em ques­
tão. ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 226  
2.241.  VuPowerSupplyInterruptionRecordArray  
Geração 2:  
Informação memorizada numa unidade-veículo e relativa a inciden tes 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 pr oto­
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.001 — 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 se cçã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 re ferência, 
indica-se abaixo a atribuição de valor. Na eventualidade de dis crepân­
cia, a norma ISO/IEC 8824-1 prevalece sobre esta nota informati va.
 
Outras «character strings» ou cadeias de carateres (Address, Na me, 
VehicleRegistrationNumber) utilizam, adicionalmente, os carater es 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  1 3  
ISO/IEC 8859-15 Latim-9  1 5  
ISO/IEC 8859-16 Latim-10 Sudeste da Europa  1 6  
KOI8-R Latim/Cirílico  8 0  
KOI8-U Latim/Cirílico  8 5  
5. CODIFICAÇÃO  
Se a sua codificação for feita segundo as regras ASN.1, os tipo s de 
dados definidos devem ser codificados em conformidade com a nor ma 
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 con tidos na  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 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 ide n­
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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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 car tã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 reque ridas 
pelos cartões tacográficos e pelas VU, para garantir funcioname nto e 
interoperabilidade corretos.  
Os cartões tacográficos cumprem o mais rigorosamente possível a s 
normas ISO/IEC aplicáveis (com destaque para a ISO/IEC 7816). O s 
comandos e protocolos são, no entanto, referidos na íntegra, pa ra 
especificar algumas utilizações restritas ou diferenças eventua is. Salvo 
indicação em contrário, os comandos especificados cumprem integ ral­
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.001 — 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.001 — 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.001 — 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 res triçã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 env io seguro 
de mensagens.  
PWD  A ação só pode ser executada se o PIN do cartão da oficina tiv er 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 se m envio 
seguro de mensagens.  
EXT-AUT-G1  A ação só pode ser executada se o comando EXTERNAL AUTHENTICAT E 
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 segu ro de 
mensagens da geração 1 no modo apenas de autenticação (ver apên dice 11, 
parte A).  
SM-C-MAC-G1  A APDU de comando deve ser aplicada com o envio seguro de mens agens 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 men sagens 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 mens agens 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 segu ro de 
mensagens da geração 2 no modo apenas de autenticação (ver apên dice 11, 
parte B).  
SM-C-MAC-G2  A APDU de comando deve ser aplicada com o envio seguro de mens agens 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 mens agens 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 seguinte s 
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.001 — 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.001 — 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.001 — 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 norm a 
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.001 — 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 0 0  Processamento normal  
61 X X  Processamento normal XX = número de bytes de resposta dispo­
níveis  
62 8 1  Processamento de alerta. Possível corrupção de parte dos dados  
devolvidos  
63 0 0  Falha de autenticação (alerta)  
63 C X  CHV (PIN) errado. Contador de tentativas remanescentes forne­
cido por «X»  
64 0 0  Erro de execução — Estado de memória não viva inalterado. Erro  
de integridade  
65 0 0  Erro de execução — Estado de memória não viva alterado  
65 8 1  Erro de execução — Estado de memória não viva alterado — 
Falha de memória  
66 8 8  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.001 — 242  
SW1  SW2  Significado  
67 0 0  Comprimento errado (Lc ou Le errados)  
68 8 3  Último comando esperado da cadeia  
69 0 0  Comando proibido (não há resposta disponível em T=0)  
69 8 2  Estatuto de segurança não satisfeito  
69 8 3  Método de autenticação bloqueado  
69 8 5  Condições de utilização não satisfeitas  
69 8 6  Comando não permitido (nenhum EF em curso)  
69 8 7  Inexistentes os objetos de dados esperados do envio seguro de 
mensagens  
69 8 8  Incorretos os objetos de dados do envio seguro de mensagens  
6A 8 0  Parâmetros incorretos no campo de dados  
6A 8 2  Ficheiro não encontrado  
6A 8 6  Parâmetros P1-P2 errados  
6A 8 8  Dados referenciados não encontrados  
6B 0 0  Parâmetros errados (deslocamento fora de EF)  
6C X X  Comprimento errado; SW2 indica o comprimento exato. Sem 
devolução de campo de dados  
6D 0 0  Código de instrução não aceite ou inválido  
6E 0 0  Classe não aceite  
6F 0 0  — 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 ca rtões 
tacográficos.  
O apêndice 11 (Mecanismos comuns de segurança para os tacógrafo s 
da geração 1 e da geração 2) indica elementos adicionais, com i m­
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 pa ra o 
comando descrito, surgem em branco os respetivos valor, compri­
mento e descrição.  ▼M1
 02016R0799 — PT — 21.08.2023 — 003.001 — 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 aceita r 
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.001 — 244  
O comando SELECT é utilizado para:  
— selecionar uma aplicação DF (tem de se utilizar seleção por n ome)  
— selecionar um ficheiro elementar correspondente ao ID do fich eiro 
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)  N N  «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.001 — 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, opcio nal­
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 acess o 
ALW para o modo de acesso Read.  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 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»  o u «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 inte gri­
dade dos dados recebidos e proteger a sua confidencialidade cas o 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.001 — 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)  N N  «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.001 — 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)  M M  «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.001 — 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 me io 
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.001 — 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»  o u «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)  N N  «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.001 — 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.001 — 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)  N N  «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.001 — 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 recebid os. 
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)  N N  «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»  o u «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 receb idos. 
Como não é exigida confidencialidade, os dados não são encripta dos. ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 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.001 — 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 me io 
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)  N N  «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.001 — 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»  o u «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)  N N  «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.001 — 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»  o u «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 mens agens 
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.001 — 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»  P 1  
P2 1  «00h»  P 2  
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.001 — 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 re fe­
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õe s dos 
centros de ensaio, o comportamento, ou seja, o código de erro d evol­
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 contado r 
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»  P 1  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 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»  o u 
«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 i nterface 
(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.001 — 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»  o u 
«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»  P 1  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 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»  o u «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 ún ica. 
Neste caso, de acordo com a norma ISO/IEC 7816-4, deve aplicar- se 
o encadeamento do comando e o certificado transmitido em dois P SO 
consecutivos: APDU de verificação do certificado.  
A estrutura do certificado e os parâmetros de domínio são defin idos 
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.001 — 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.001 — 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áfico s 
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»  P 1  
P2 1  «00h»  P 2  
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.001 — 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 o s 
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.001 — 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 pa ra 
o protocolo de autenticação da pastilha (chip) da geração 2 esp ecifi­
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.001 — 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 ca rtã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.001 — 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»  o u 
«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 co m 
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 selecion ar 
os parâmetros da autenticação da pastilha que são executados po r 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.001 — 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 selecion ar 
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 coman do 
PSO: VERIFY DIGITAL SIGNATURE subsequente  
— quer para a verificação da assinatura de um certificado forne cido 
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.001 — 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 d e 
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 resul tado de 
um cálculo HASH sobre alguns dados. Serve para a verificação de  
assinaturas digitais. O valor de HASH é memorizado temporariame nte 
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.001 — 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 SH A-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 ofici na. ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 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 p ermite 
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 o s 
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.001 — 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 ofici na. 
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 ca rtão 
de condutor e o cartão de oficina possuem uma chave de assinatu ra de 
geração 2, os restantes cartões não conseguem executar com suce sso 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 ace s­
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ódi go 
HASH previamente calculado com o comando PSO: 
HASH.  
TCS_127 A chave privada do cartão é utilizada para calcular a a ssi­
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 assina tura 
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.001 — 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, fo rnecida 
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.001 — 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 autent icidade 
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 d a 
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, m as 
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.001 — 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.001 — 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-byte s 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 ta cográ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 pr in­
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.001 — 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 dad os:
 
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 s e 
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.001 — 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 condu tor 
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.001 — 280
  
► (1) (2) M3 ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 281
  
▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 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 conduto r 
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.001 — 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.001 — 284
  
▼M3
 02016R0799 — PT — 21.08.2023 — 003.001 — 285
  
▼M3
 02016R0799 — PT — 21.08.2023 — 003.001 — 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  1 2  1 2  
n 2 NoOfFaultsPerType  2 4  2 4  
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 ofici na 
da geração 1 terá permanentemente as seguintes estrutura 
de ficheiro e regras de acesso do ficheiro:
  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 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.001 — 288
  
▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 289
  
▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 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 ofici na 
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.001 — 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.001 — 292
  
▼M3
 02016R0799 — PT — 21.08.2023 — 003.001 — 293
  
▼M3
 02016R0799 — PT — 21.08.2023 — 003.001 — 294
  
▼M3
 02016R0799 — PT — 21.08.2023 — 003.001 — 295
  
▼M3
 02016R0799 — PT — 21.08.2023 — 003.001 — 296  
TCS_163 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 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  2 4  2 4  
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 contr olo 
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.001 — 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 contr olo 
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.001 — 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.001 — 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.001 — 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 empre sa 
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.001 — 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 empre sa 
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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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 dad os, 
eventualmente identificados por um identificador de bloco.  
Um bloco de dados contém um ou mais registos, eventualmente ide n­
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, de ve 
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 f ormato:  
— carateres a  negro (bold)  indicam texto normal a imprimir (a impres­
são vem em carateres normais),  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 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 com posi­
çã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 r eno­
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
 Combinações de 
pictogramas do car- 
tão 
Código do 
Estado-Membro 
emissor Primeiros 14 carateres do número do cartão 
(que inclui eventualmente um índice consecutivo)
 
Índice de substituição  
Índice de renovação 
▼M3 
— num bloco de dados, o texto após «pi=» refere-se ao pictogram a 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 ve r­
sões),  
— ** dados apenas disponíveis na GEN2, versão 2.  ▼B
02016R0799 — PT — 21.08.2023 — 003.001 — 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.001 — 310
  
► (1) (2) (3)  M3 ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 311
  
► (1) (2) M3 ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 312
  
▼B
02016R0799 — PT — 21.08.2023 — 003.001 — 313
  
► (1) (2) (3) (4)  M3 ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 314
  
▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 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.001 — 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.001 — 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, d e­
vem respeitar o seguinte formato:
  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 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 imp res­
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, deve m 
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 inser idos 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 c urso 
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.001 — 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.001 — 320  
3.6. Impressão do excesso de velocidade  
PRT_013 A impressão do excesso de velocidade deve respeitar o s e­
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 inser idos 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 úl timos 
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 di as 
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 resp eitar 
o seguinte formato:  
▼M3
 ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 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.001 — 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 qualque r 
peça do tacógrafo, e deve corresponder ao seguinte esquema 
(dimensões em milímetros):
  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 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 seguin te 
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.001 — 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 especifi cações 
RS232.  
INT_005 A interface de descarregamento deve utilizar 1 bit de i ní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 men os 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.001 — 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 especi ficaçã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  m A  
U high (out)  4  V  I  =  1  m A  
INT_009 O sinal de entrada/saída deve cumprir os seguintes diag ramas 
cronológicos:
  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 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.001 — 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 Vers ion (Versão 
da interface de descarregamento de dados de transferência de re sposta 
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 (Inci dentes e falhas 
de dados de transferência de resposta positiva)  
2.2.6.5 Positive Response Transfer Data Detailed Speed (Velocid ade 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 exe cução 
dos diversos tipos de descarregamento de dados para meios exter nos de 
memorização ou armazenamento (ESM), juntamente com os protocolo s 
que se devem aplicar para assegurar a transferência correta dos  dados e 
a compatibilidade total do formato dos dados descarregados, a f im 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 equipad o 
com dispositivo de interface para o cartão (IFD),  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 328  
— a partir de um cartão tacográfico, via uma unidade-veículo, p or 
meio de um IDE ligado a essa VU.  
Para possibilitar a verificação da autenticidade e da integrida de 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 d e se­
gurança (Estado-Membro e equipamento) são também descarregados.  O 
verificador dos dados deve possuir, independentemente, uma chav e 
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 s e­
gunda geração) do apêndice 11, exceto quando o controlo dos con du­
tores é efetuado por uma autoridade de controlo que não pertenç a à 
UE, utilizando um cartão de controlo de primeira geração, em cu jo 
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 da dos 
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 da dos 
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 c omo 
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.001 — 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 segui ntes 
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 princi pal/ 
/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 principa lmente 
no Protocolo de palavra-chave 2000 (KWP) (norma ISO 14230-2 Roa d 
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 fever eiro 
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  … …  …  C S  
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.001 — 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 n o 
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  C S  
4 bytes  Comprimento superior a 255 bytes  
é transmitido sob a seguinte forma:  
Cabeçalho  SID  TREP  0 0  0 1  Submensagem 1  C S  
4 bytes  255 bytes  
Cabeçalho  SID  TREP  0 0  0 2  Submensagem 2  C S  
4 bytes  255 bytes  
… 
Cabeçalho  SID  TREP  x x  y y  Submensagem n  C S  
4 bytes  Menos de 255 bytes  
ou sob a seguinte forma:  
Cabeçalho  SID  TREP  0 0  0 1  Submensagem 1  C S  
4 bytes  255 bytes  
Cabeçalho  SID  TREP  0 0  0 2  Submensagem 2  C S  
4 bytes  255 bytes  
… 
Cabeçalho  SID  TREP  x x  y y  Submensagem n  C S  
4 bytes  255 bytes  
Cabeçalho  SID  TREP  x x  yy + 1  C S  
4 bytes  4 bytes  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 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 mensage ns. 
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 ->  <- VU  FMT  TGT  SRC  LEN  SID  DS_ / TRTP  DATA  E C  
Start Communication Request  8 1  E E  F 0  8 1  E 0  
Positive Response Start Communica­
tion 80 F 0  E E  0 3  C 1  EA, 8F  9 B  
Start Diagnostic Session Request  8 0  E E  F 0  0 2  1 0  8 1  F 1  
Positive Response Start Diagnostic  8 0  F 0  E E  0 2  5 0  8 1  3 1  
Link Control Service  
Verify Baud Rate (stage 1)  
9 600 Bd  8 0  E E  F 0  0 4  8 7  0 1  01,01  E C  
19 200 Bd  8 0  E E  F 0  0 4  8 7  0 1  01,02  E D  
38 400 Bd  8 0  E E  F 0  0 4  8 7  0 1  01,03  E E  
57 600 Bd  8 0  E E  F 0  0 4  8 7  0 1  01,04  E F  
115 200 Bd  8 0  E E  F 0  0 4  8 7  0 1  01,05  F 0  
Positive Response Verify Baud Rate  8 0  F 0  E E  0 2  C 7  0 1  2 8  
Transition Baud Rate (stage 2)  8 0  E E  F 0  0 3  8 7  0 2  0 3  E D  
Request Upload  8 0  E E  F 0  0 A  3 5  00,00,00, 
00,00,FF, 
FF,FF,FF  99 
Positive Response Request Upload  8 0  F 0  E E  0 3  7 5  00,FF  D 5  
Transfer Data Request  
Download interface version  8 0  E E  F 0  0 2  3 6  0 0  9 6  
Overview  80 E E  F 0  0 2  3 6  01, 21 ou 31  E C  
Activities  80 E E  F 0  0 6  3 6  02, 22 ou 32  Date  E C  
Events & Faults  80 E E  F 0  0 2  3 6  03, 23 ou 33  Date  E C  
Detailed Speed  80 E E  F 0  0 2  3 6  04 ou 24  Date  E C  
Technical Data  80 E E  F 0  0 2  3 6  05, 25 ou 35  Date  E C  
Card download  80 E E  F 0  02 ou 03  3 6  0 6  Slot  C S  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 332  
Estrutura da mensagem  Máx. 4 Bytes  Máx. 255 Bytes  1 byte  
Cabeçalho  Dados  Soma de 
teste 
IDE ->  <- VU  FMT  TGT  SRC  LEN  SID  DS_ / TRTP  DATA  E C  
Positive Response Transfer Data  8 0  F 0  E E  Len  7 6  TREP  Dados  C S  
Request Transfer Exit  8 0  E E  F 0  0 1  3 7  9 6  
Positive Response Request Transfer 
Exit 80 F 0  E E  0 1  7 7  D 6  
Stop Communication Request  8 0  E E  F 0  0 1  8 2  E 1  
Positive Response Stop Communica­
tion 80 F 0  E E  0 1  C 2  2 1  
Acknowledge sub message  8 0  E E  F 0  Len  8 3  Dados  C S  
Negative responses  
General reject  8 0  F 0  E E  0 3  7 F  Sid Req  1 0  C S  
Service not supported  8 0  F 0  E E  0 3  7 F  Sid Req  1 1  C S  
Sub function not supported  8 0  F 0  E E  0 3  7 F  Sid Req  1 2  C S  
Incorrect Message Length  8 0  F 0  E E  0 3  7 F  Sid Req  1 3  C S  
Conditions not correct or Request se­
quence error  80 F 0  E E  0 3  7 F  Sid Req  2 2  C S  
Request out of range  8 0  F 0  E E  0 3  7 F  Sid Req  3 1  C S  
Upload not accepted  8 0  F 0  E E  0 3  7 F  Sid Req  5 0  C S  
Response pending  8 0  F 0  E E  0 3  7 F  Sid Req  7 8  C S  
Data not available  8 0  F 0  E E  0 3  7 F  Sid Req  F A  C S  
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 compat i­
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 ranhu ra 
do condutor) ou «2» (cartão na ranhura do ajudante)  
— Caso a ranhura não seja especificada, a VU seleciona a ranhur a 1, 
se for inserido um cartão nesta ranhura e seleciona a ranhura 2  
apenas quando esta é especificamente selecionada pelo utilizado r. ▼M3
 02016R0799 — PT — 21.08.2023 — 003.001 — 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 descarr e­
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 europei a, 
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 inicia r 
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.001 — 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) é envi ada 
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  0 0  
Panorâmica  0 1  2 1  3 1  
Atividades de uma data espe­
cificada  02 2 2  3 2  
Incidentes e falhas  0 3  2 3  3 3  
Velocidade detalhada  0 4  2 4  2 4  
Dados técnicos  0 5  2 5  3 5  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 335  
Data transfer 
type TRTP value  
Card download  0 6  
▼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.001 — 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 
< 255) pode ser acusada por intermédio de qualquer um 
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.001 — 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 V U  
Start Communication Request  ⇨ 
⇦  Positive Response  
Start Diagnostic Service Request  ⇨ 
⇦  Positive Response  
Request Upload  ⇨ 
⇦  Positive Response  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 338  
IDE V U  
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<255 Bytes)  
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.001 — 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  2 0  
P2 2 0  1 000 (*)  
P3 1 0  5 000  
P4 5  2 0  
P5 1 0  20 minutos  
(*) Se a VU responder com uma Negative Response contendo um cód igo que signifique «pedido corretamente 
recebido, resposta pendente», este valor é alargado para o mesm o 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 co mu­
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.001 — 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.001 — 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ária s 
mensagens de resposta positiva.  
Os elementos de dados são definidos no apêndice 1 (Dicionário d e 
dados).  
Observação: Em relação aos descarregamentos da geração 2, cada ele­
mento de dados de topo é representado por uma matriz de registo s, 
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 ta manho 
do registo e o número de registos. Nos quadros a seguir, as mat rizes 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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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 tra ns­
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.001 — 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.001 — 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.001 — 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 seguin tes 
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.001 — 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.001 — 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 s e 
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
 D F  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.001 — 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
  n o
  
DF
 
Assinatura do EF
  
no
 D F  
▼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.001 — 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.001 — 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 intercambi ados 
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 a pêndice 6. 
Descreve também o controlo da linha de sinal entrada/saída no c onector 
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 no rmal 
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 — «Se rviços 
de gestão».  
O presente apêndice tem de ser considerado pertinente para amba s as 
gerações de VU e cartões de oficina, em conformidade com os req ui­
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 dispositi vo 
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.001 — 358  
2. TERMOS, DEFINIÇÕES E REFERÊNCIAS  
Os protocolos, mensagens e códigos de erro baseiam-se principal mente 
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 pa râmetros- 
-padrão.  
O termo «dispositivo de teste» refere-se ao equipamento utiliza do 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» (Electro nic 
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 dispo ní­
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.001 — 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  8 1  ■  ■  ■  
StopCommunication  4.2  8 2  ■  
TesterPresent  4.3  3 E  ■  ■  ■  
StartDiagnosticSession  5.1  1 0  ■  ■  ■  
SecurityAccess  5.2  2 7  ■  ■  ■  
ReadDataByIdentifier  6.1  2 2  ■  ■  ■  
WriteDataByIdentifier  6.2  2 E  ■  
InputOutputControlByIdentifier  7.1  2 F  ■  
▼M3 
RoutineControl  8  3 1  ■  ■  
▼B 
■ Este símbolo indica que o serviço é obrigatório na sessão de d iagnóstico. 
A ausência de símbolo indica que o serviço não é permitido na s essã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 c omu­
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 desencade ar 
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 StartCommunicatio n, 
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.001 — 360  
CPR_007 A VU executa então as ações necessárias para desencadea r 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 intro duzido 
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 se r 
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á d e 
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.001 — 361  
CPR_017 Os valores cronológicos para a inicialização rápida e a s 
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 2 0  
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 2 0  
CPR_018 O formato da mensagem de inicialização rápida é indicad o 
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  E E  TGT  
#3 Byte de endereço-fonte  t t  SRC  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 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  C S  
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  t t  TGT  
#3 Byte de endereço-fonte  E E  SRC  
#4 Byte adicional de comprimento  0 3  LEN  
#5 StartCommunication Positive 
Response Service Id  C1 SCRPR  
#6 Byte-chave 1  E A  KB1  
#7 Byte-chave 2  8 F  KB2  
#8 Soma de teste  00-FF  C S  
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.001 — 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  E E  TGT  
#3 Byte de endereço-fonte  t t  SRC  
#4 Byte adicional de comprimento  0 1  LEN  
#5 Id do serviço de pedido Stop ­
Communication  82 SPR  
#6 Soma de teste  00-FF  C S  
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  t t  TGT  
#3 Byte de endereço-fonte  E E  SRC  
#4 Byte adicional de comprimento  0 1  LEN  
#5 StopCommunication Positive 
Response Service Id  C2 SPRPR  
#6 Soma de teste  00-FF  C S  
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  t t  TGT  
#3 Byte de endereço-fonte  E E  SRC  
#4 Byte adicional de comprimento  0 3  LEN  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 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  1 0  RC_GR  
#8 Soma de teste  00-FF  C S  
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 p ara in­
dicar ao servidor que está ainda presente, a fim de evitar que o servidor 
regresse automaticamente ao funcionamento normal e possa interr om­
per a comunicação. Este serviço, enviado periodicamente, mantém  ativa 
a sessão de diagnóstico/comunicação recolocando no seu estado d e 
defeito o cronómetro P3 cada vez que é recebido um pedido relat ivo 
ao serviço.  
4.3.2  Formato da mensagem  
CPR_079 Os formatos das mensagens para as primitivas TesterPres ent 
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  E E  TGT  
#3 Byte de endereço-fonte  t t  SRC  
#4 Byte adicional de comprimento  0 2  LEN  
#5 Id do serviço de pedido Tes ­
terPresent  3E TP  
#6 Sub Função = res­
ponseRequired =  [sim 0 1  RESPREQ_Y  
não ]  0 2  RESPREQ_NO  
#7 Soma de teste  00-FF  C S  
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.001 — 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  t t  TGT  
#3 Byte de endereço-fonte  E E  SRC  
#4 Byte adicional de comprimento  0 1  LEN  
#5 TesterPresent Positive Res ­
ponse Service Id  7E TPPR  
#6 Soma de teste  00-FF  C S  
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  t t  TGT  
#3 Byte de endereço-fonte  E E  SRC  
#4 Byte adicional de comprimento  0 3  LEN  
#5 negative Response Service Id  7F  NR  
#6 Identificação do serviço de pedido 
TesterPresent  3E T P  
#7 response­
Code =  [SubFunctionNotSup­
ported-InvalidFormat  12 RC_SFNS_IF  
incorrectMessage­
Length ]  13 RC_IML  
#8 Soma de teste  00-FF  C S  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 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 ativa r 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 es tabe­
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 StartDiagn os­
ticSession figuram nos quadros seguintes:  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 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  E E  TGT  
#3 Byte de endereço-fonte  t t  SRC  
#4 Byte adicional de comprimento  0 2  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  C S  
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  t t  TGT  
#3 Byte de endereço-fonte  E E  SRC  
#4 Byte adicional de comprimento  0 2  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  C S  
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  t t  TGT  
#3 Byte de endereço-fonte  E E  SRC  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 368  
N. o do byte  Nome do parâmetro  Valor 
hex Mnemónica  
#4 Byte adicional de comprimento  0 3  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  C S  
( α ) — O valor inserido no byte #6 da mensagem de pedido não é ace ite (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.001 — 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 car tã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 CAL I­
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 S tart­
DiagnosticSession.  
CPR_033 O dispositivo de teste utiliza a mensagem SecurityAcces s 
«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 dispositiv o 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 Securit yAc­
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.001 — 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 po r 
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  E E  TGT  
#3 Byte de endereço-fonte  t t  SRC  
#4 Byte adicional de comprimento  0 2  LEN  
#5 Id do serviço de pedido Secu ­
rityAccess  27 SA  
#6 accessType — requestSeed  7 D  AT_RSD  
#7 Soma de teste  00-FF  C S  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 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  t t  TGT  
#3 Byte de endereço-fonte  E E  SRC  
#4 Byte adicional de comprimento  0 4  LEN  
#5 SecurityAccess Positive Res ­
ponse Service Id  67 SAPR  
#6 accessType — requestSeed  7 D  AT_RSD  
#7 Seed elevada  00-FF  SEEDH  
#8 Seed baixa  00-FF  SEEDL  
#9 Soma de teste  00-FF  C S  
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  t t  TGT  
#3 Byte de endereço-fonte  E E  SRC  
#4 Byte adicional de comprimento  0 3  LEN  
#5 negativeResponse Service Id  7F  NR  
#6 Id do serviço de pedido SecurityAc­
cess 27 S A  
#7 response­
Code =  [conditionsNotCorrec­
tOrRequestSequen­
ceError  22 RC_CNC  
incorrectMessage­
Length]  13 RC_IML  
#8 Soma de teste  00-FF  C S  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 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  E E  TGT  
#3 Byte de endereço-fonte  t t  SRC  
#4 Byte adicional de comprimento  m+2  LEN  
#5 Id do serviço de pedido Secu ­
rityAccess  27 SA  
#6 accessType — sendKey  7 E  AT_SK  
#7 to 
#m+6  Key #1 (elevado)  X X  KEY  
… …  
Chave #m (baixa: m deve ser 
no mínimo 4 e no máximo 8)  XX 
#m+7  Soma de teste  00-FF  C S  
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  t t  TGT  
#3 Byte de endereço-fonte  E E  SRC  
#4 Byte adicional de comprimento  0 2  LEN  
#5 SecurityAccess Positive Res ­
ponse Service Id  67 SAPR  
#6 accessType — sendKey  7 E  AT_SK  
#7 Soma de teste  00-FF  C S  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 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  t t  TGT  
#3 Byte de endereço-fonte  E E  SRC  
#4 Byte adicional de comprimento  0 3  LEN  
#5 NegativeResponse Service Id  7F  NR  
#6 Id do serviço de pedido SecurityAc­
cess 27 S A  
#7 Response­
Code =  [generalReject  1 0  RC_GR  
subFunctionNotSup­
ported  12 RC_SFNS  
incorrectMessage­
Length  13 RC_IML  
conditionsNotCorrec­
tOrRequestSequen­
ceError  22 RC_CNC  
invalidKey  3 5  RC_IK  
exceededNumberO­
fAttempts  36 RC_ENA  
requestCorrectlyRe­
ceived-ResponsePen­
ding]  78 RC_RCR_RP  
#8 Soma de teste  00-FF  C S  
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.001 — 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  E E  TGT  
#3 Byte de endereço-fonte  t t  SRC  
#4 Byte adicional de comprimento  0 3  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  C S  
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  t t  TGT  
#3 Byte de endereço-fonte  E E  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.001 — 375  
N. o do byte  Nome do parâmetro  Valor 
hex Mnemónica  
#8 a #m+7  dataRecord[] =  [data#1  X X  DREC_DAT­
A1 
: :  :  
data#m]  X X  DREC_DA­
TAm  
#m+8  Soma de teste  00-FF  C S  
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  t t  TGT  
#3 Byte de endereço-fonte  E E  SRC  
#4 Byte adicional de comprimento  0 3  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  C S  
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.001 — 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.001 — 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 client e 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  E E  TGT  
#3 Byte de endereço-fonte  t t  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  X X  DREC_DAT­
A1 
: :  :  
data#m]  X X  DREC_DA­
TAm  
#m+8  Soma de teste  00-FF  C S  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 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  t t  TGT  
#3 Byte de endereço-fonte  E E  SRC  
#4 Byte adicional de comprimento  0 3  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  C S  
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  t t  TGT  
#3 Byte de endereço-fonte  E E  SRC  
#4 Byte adicional de comprimento  0 3  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  C S  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 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 r egisto 
de dados identificados pelo recordDataIdentifier. Os formatos d os 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 control ar ou 
acompanhar os impulsos de teste por meio de um dispositivo de t este 
adequado.  
CPR_058 Esta linha de calibração de sinal I/O pode ser configur ada 
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 de ve 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.001 — 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 InputOutpu t­
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  E E  TGT  
#3 Byte de endereço-fonte  t t  SRC  
#4 Byte adicional de comprimento  X X  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  C S  
Nota:  O parâmetro controlState está presente somente em 
alguns casos (ver 7.1.3).  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 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  t t  TGT  
#3 Byte de endereço-fonte  E E  SRC  
#4 Byte adicional de comprimento  X X  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  C S  
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  t t  TGT  
#3 Byte de endereço-fonte  E E  SRC  
#4 Byte adicional de comprimento  0 3  LEN  
#5 negativeResponse Service Id  7F  NR  
#6 inputOutputControlByIdentifier 
Request SId  2F IOCBI  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 382  
N. o do byte  Nome do parâmetro  Valor hex  Mnemónica  
#7 responseCode=[  
incorrectMessageLength  1 3  RC_IML  
conditionsNotCorrect  2 2  RC_CNC  
requestOutOfRange  3 1  RC_ROOR  
deviceControlLimitsExceeded]  7 A  RC_DCLE  
#8 Soma de teste  00-FF  C S  
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  0 0  Linha I/O desativada (estado por defeito)  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 383  
Modo  Valor hex  Descrição  
Ativar  0 1  Ativar a linha I/O como speedSignalInput  
Ativar  0 2  Ativar a linha I/O como realTimeSpeedSig­
nalOutputSensor  
Ativar  0 3  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) oferec e 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 RoutineContro l 
(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  8 0  FMT  
#2 Byte de endereço-alvo  E E  TGT  
#3 Byte de endereço-fonte  t t  SRC  
#4 Byte adicional de comprimento  x x  LEN  
#5 RoutineControl Request Sid (Sid de pedido de controlo de rotina)  31  RC  
#6 routineControlType = [startRoutine]  0 1  RCTP_STR  
#7 e #8  routineIdentifier = [TimeAdjustment]  0100  RI_TA  
#9 Soma de teste  00-FF  C S  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 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  8 0  FMT  
#2 Byte de endereço-alvo  t t  TGT  
#3 Byte de endereço-fonte  E E  SRC  
#4 Byte adicional de comprimento  x x  LEN  
#5 RoutineControl Positive Response Sid  71  RCPR  
#6 routineControlType = [startRoutine]  0 1  RCTP_STR  
#7 e #8  routineIdentifier= [TimeAdjustment]  0100  RI_TA  
#9 Soma de teste  00-FF  C S  
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  8 0  FMT  
#2 Byte de endereço-alvo  E E  TGT  
#3 Byte de endereço-fonte  t t  SRC  
#4 Byte adicional de comprimento  x x  LEN  
#5 RoutineControl Request Sid (Sid de pedido de controlo de rotina)  31  RC  
#6 routineControlType = [requestRoutineResults]  0 3  RCTP_RRR  
#7 e #8  routineIdentifier= [TimeAdjustment]  0100  RI_TA  
#9 Soma de teste  00-FF  C S  
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  8 0  FMT  
#2 Byte de endereço-alvo  t t  TGT  
#3 Byte de endereço-fonte  E E  SRC  
#4 Byte adicional de comprimento  x x  LEN  
#5 RoutineControl Positive Response Sid (Sid de resposta positiva de 
controlo de rotina)  71 RCPR  
#6 routineControlType = [requestRoutineResults]  0 3  RCTP_RRR  
#7 e #8  routineIdentifier= [TimeAdjustment]  0100  RI_TA  
#9 routineInfo (ver o quadro 37-F)  X X  RINF_TA  
#10 routineStatusRecord[] = routineStatus#1 (ver o quadro 37-G)  X X  RS_TA  
#11 Soma de teste  00-FF  C S  ▼M3
 02016R0799 — PT — 21.08.2023 — 003.001 — 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  8 0  FMT  
#2 Byte de endereço-alvo  t t  TGT  
#3 Byte de endereço-fonte  E E  SRC  
#4 Byte adicional de comprimento  0 3  LEN  
#5 negativeResponse Service Id (Id de Serviço de resposta negativa)  7F  NR  
#6 inputOutputControlByIdentifier Request SId  3 1  RC  
#7 responseCode=[ 
sub-functionNotSupported 
incorrectMessageLengthOrInvalidFormat 
conditionsNotCorrect 
requestOutOfRange 
] 12 
13 
22 
31 SFNS 
IMLOIF 
CNC 
ROOR  
#8 Soma de teste  00-FF  C S  
Quadro 37-F:  
RoutineControl, rotina (TimeAdjustment), routineInfo  
routineInfo  Valor hex  Descrição  
NormalExitWithResultAvailable  6 1  A rotina foi completamente executada; resultados adicio­
nais da rotina disponíveis.  
RoutineExecutionOngoing  7 8  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 ser viços de 
transmissão de dados, descritos na secção 6.  ▼M3
 02016R0799 — PT — 21.08.2023 — 003.001 — 386  
CPR_067 Todos os parâmetros identificados devem ser suportados 
pela VU.  
CPR_068 Os dados transmitidos pela VU ao dispositivo de teste e m 
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) serve m 
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  F B  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  F E  FE00 a FEFF  FE000000 a FEFFFFFF  0  
Indisponível ou não pedido  F F  FF00 a FFFF  FF000000 a FFFFFFFF  F F  
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 pe los 
serviços ReadDataByIdentifier e WriteDataByIdentifier.  ▼M3
 02016R0799 — PT — 21.08.2023 — 003.001 — 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  1 5  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  1 4  Ver informações no quadro 42  
VIN 1 7  ASCII  ASCII  
SealDataVu  5 5  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  1 4  Ver informações no quadro 47  
CalibrationCountry  3  ASCII  NationAlpha conforme definido 
no apêndice 1  ▼M3
 02016R0799 — PT — 21.08.2023 — 003.001 — 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.001 — 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.001 — 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.001 — 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 compo nente) 
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íve l 
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 pr es­
crito no presente anexo em termos de funções executadas, de rig or 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 pel a autori­
dade nacional no âmbito dos ensaios de funcionalidade, bem como  os 
ensaios mínimos a efetuar pelo organismo competente no âmbito d os 
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 eventualid ade, somente 
os resultados destes ensaios de segurança poderão ser inspecion ados. Para 
informação: os requisitos que, no âmbito da certificação de seg uranç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.001 — 392  
O presente apêndice considera a homologação de tipo do sensor d e mo­
vimentos separadamente da unidade-veículo e do módulo GNSS exte rno, 
como componentes do aparelho de controlo. Cada componente terá o seu 
próprio certificado de homologação de tipo, no qual se menciona rão os 
outros componentes compatíveis. O ensaio de funcionalidade do s ensor 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 s ensor 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 fun ciona­
lidade de uma unidade-veículo ou de um módulo GNSS externo deve  
certificar-se de que o recetor GNSS integrado passou com sucess o os 
ensaios da OSNMA especificados no presente apêndice. Estes ensa ios 
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 a nd 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) — Pro tection 
of electrical equipment against foreign objects, water and acce ss 
ISO 10605:2008 + Technical Corrigendum:2010 + AMD1:2014 Road ve ­
hicles — Test methods for electrical disturbances from electros tatic dis­
charge  
ISO 7637-1:2002 + AMD1: 2008 Road vehicles — Electrical disturb ances 
from conduction and coupling — Part 1: Definitions and general consi­
derations  
ISO 7637-2 Road vehicles — Electrical disturbances from conduct ion and 
coupling — Part 2: Electrical transient conduction along supply  lines only  
ISO 7637-3 Road vehicles — Electrical disturbances from conduct ion and 
coupling — Part 3: Electrical transient transmission by capacit ive and 
inductive coupling via lines other than supply lines  
ISO/IEC 7816-1 Identification cards — Integrated circuit(s) car ds with 
contacts — Part 1: Physical characteristics  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 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 sign als and 
transmission protocol  
ISO/IEC 10373-1:2006 + AMD1:2012 Identification cards — Test me t­
hods — Part 1: General characteristics  
ISO/IEC 10373-3:2010 + Technical Corrigendum:2013 Identificatio n 
cards — Test methods — Part 3: Integrated circuit cards with co ntacts 
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: Diagno stics 
ISO 16844-7 Road vehicles — Tachograph systems — Part 7: Parame ters 
ISO 534 Paper and board — Determination of thickness, density a nd 
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 vehicl es 
with regard to electromagnetic compatibility (United Nation Eco nomic 
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.001 — 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.001 — 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 d o 
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.001 — 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.001 — 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.001 — 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.001 — 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  0 2  
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.001 — 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 , <= 0,5 oct/min 
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, <1 ms, número de 
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.001 — 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 p rocesso 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 ensaio s 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 al terado, 
estes ensaios são necessários.  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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  9 1  
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.001 — 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.001 — 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.001 — 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 óti cas 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.001 — 418  
As densidades óticas das impressões obtidas devem ser medidas d e acordo 
com a norma DIN EN ISO 534.  
As impressões não podem apresentar alterações das dimensões e d evem 
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 dev e 
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 sens ores 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 o s 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 in ci­
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.001 — 419  
9. ENSAIOS DA OSNMA  
9.1. Introdução  
Este capítulo descreve os ensaios destinados a comprovar a impl ementaçã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 ensai os des­
critos neste capítulo podem ser realizados no recetor GNSS como  um 
elemento autónomo. Neste caso, o fabricante do tacógrafo deve a presentar 
um relatório às entidades homologadoras com dados sobre o desen volvi­
mento e os resultados dos ensaios realizados sob a responsabili dade 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 identif icadas.  
— Os critérios podem ser revistos no momento da declaração do s erviç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.001 — 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 mensa gens 
OSNMA. Alternativamente, pode ser utilizado um reprodutor de si nal 
de radiofrequência capaz de reproduzir amostras de sinal GNSS a  partir 
de ficheiros. A profundidade de bits e a taxa de amostragem típ icas são, 
respetivamente, I/Q de 4 bits e 10 MHz.  
Assume-se que o receptor GNSS tem interfaces para comandar a li mpeza 
da memória do recetor (a fim de apagar independentemente a chav e pú­
blica, a KROOT, as informações do relógio, as informações de po sição, a 
efeméride e o almanaque), de modo a definir a realização da hor a local do 
recetor para o requisito de verificação de tempo da OSNMA e par a car­
regar as informações criptográficas. Estes comandos podem ser l imitados 
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 ca racte­
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 superio r a 5  o ; 
— Duração conforme necessário para cada ensaio;  
— Efemérides de navegação constantes dos satélites durante o en saio. 
9.5.2 Condições da OSNMA  
A mensagem da OSNMA transmitida no sinal RF tem as seguintes ca rac­
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.001 — 421  
Exceto quando indicado, a realização do tempo do recetor intern o 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.001 — 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.001 — 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 seg uir 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 cr ité­
rios comuns.  
SEC_003 A Comissão Europeia garantirá que quatro perfis de prot eção confor­
mes com o presente anexo são patrocinados, desenvolvidos, homol o­
gados pelos organismos governamentais de certificação de segura nça 
de TI no âmbito do Grupo de Trabalho Conjunto de 
Interpretação (JIWG) que apoia o reconhecimento mútuo de certif ica­
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 sit uações em que a 
VU é concebida para ser utilizada ou não com um módulo GNSS ext erno. Os 
requisitos de segurança do módulo GNSS externo são fornecidos n o perfil de 
proteção dedicado.  
SEC_004 Os fabricantes de componentes devem aperfeiçoar e compl etar o perfil 
de proteção adequado dos componentes na medida do necessário, s em 
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 a os quais 
podem pedir a certificação de segurança do componente.  
SEC_005 Durante o processo de avaliação, deve indicar-se a conf ormidade es­
trita dos objetivos de segurança específicos com o corresponden te 
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.001 — 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 confid encia­ 
lidade  
6. MECANISMOS DE ASSINATURA DIGITAL DO DESCARRE­ 
GAMENTO DE DADOS  
6.1. Criação da assinatura  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 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úbli ca 
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 movime ntos 
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.001 — 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ânc ia 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, utilizan do 
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 dif e­ 
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.001 — 427  
PREÂMBULO  
O presente apêndice especifica os mecanismos de segurança que g arantem:  
— autenticação mútua entre os diversos componentes do sistema t acográfico  
— confidencialidade, integridade, autenticidade e/ou não-repúdi o 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 de fine 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 si stema tacográfico 
da segunda geração (tacógrafo inteligente).  
Aplicam-se os mecanismos previstos na parte A do presente apênd ice 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 primei ra geração.  
Aplicam-se os mecanismos previstos na parte B se, pelo menos, u m 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 co mponentes 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.001 — 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 abrev iaturas:  
(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.001 — 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 util izam 
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 r e­
lações:  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 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 algoritm o 
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árqui cos 
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.001 — 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 inter ope­
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 dev e ser 
adequadamente mantida durante a criação, o eventual encaminhame nto 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 seguin te: 
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.001 — 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áfi cas 
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 segui n­
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 seguin tes 
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.001 — 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 es trutura 
exata de um certificado de autenticação. Pode ser utilizado com o 
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»
 Marcador alargado da lista de cabeçalho  
Comprimento da lista de cabeçalho  
Marcador CPI  
Comprimento CPI  
Marcador CAR  
Comprimento CAR  
Marcador CHA  
Comprimento CHA  
Marcador EOV  
Comprimento EOV  
Marcador CHR  
Comprimento CHR  
Marcador de chave pública (Construído)  
Comprimento de DO subsequentes  
Marcador do módulo  
Comprimento do módulo  
Marcador do expoente público  
Comprimento do expoente público 
2. A «referência da autoridade de certificação» (CAR) destina-s e a iden­
tificar a autoridade de certificação (CA) emissora do certifica do, de 
modo que o elemento de dados possa ser utilizado ao mesmo tempo  
como identificador de chave de autoridade para referenciar a ch ave 
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 ap licação 
do tacógrafo e no tipo de equipamento a que se refere o certifi cado 
(consoante o elemento de dados
  , «00» para um 
Estado-Membro).  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 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 certifica do. 
5. Os identificadores de chave identificam como únicos os titul ares de 
certificados e as autoridades de certificação. É a seguinte a s ua 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 aparel ho, 
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 ess a 
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 d a 
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 ch ave 
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.001 — 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 u m 
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 c onfiden­
cialidade (o certificado não contém qualquer identificador de o bjeto 
que o especifique).  
3.3.2  Certificados emitidos  
CSM_018 O certificado emitido é uma assinatura digital com recu pera­
çã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 selecio nada 
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 certifica do emitido: 
«7F 21»  «09»  «5F 37»  «81 80»  «5F 38»  «3A»  «42»  «08»
 Marcador do certificado 
CV (construído)  
Comprimento de 
DO subsequentes  
Marcador da assinatura  
Comprimento da assinatura  
Marcador do remanescente  
Comprimento do remanescente  
Marcador da CAR  
Comprimento da CAR ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 436  
3.3.3  Verificação e revelação de certificados  
A verificação e a revelação de um certificado consistem em veri ficar 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 cert ificação 
competente do Estado-Membro, por sua vez certificado pela autor idade 
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.001 — 437  
CSM_020 Utiliza-se o seguinte protocolo (as setas indicam coman dos e 
dados intercambiados — ver apêndice 2):
  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 438
  
▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 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 int egra 
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.001 — 440  
Dado um par de resposta a um comando não seguro:  
Cabeçalho do comando  Corpo do comando  
CLA  INS  P 1  P 2  [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  P 1  P 2  [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»  C C  
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»  C C  
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.001 — 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»  C C  
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»  C C  
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 r ecurso 
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.001 — 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 dura nte 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 un i­
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 mod o 
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.001 — 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 utiliza m 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 obed ece 
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 descarrega dos 
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.001 — 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 refe rê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 ci rcuit 
cards — Part 4: Organization, security and commands for 
interchange. Third edition 2013-04-15  
ISO 7816-8 ISO/IEC 7816-8, Identification cards — Integrated ci rcuit 
cards — Part 8: Commands for security operations. Se­
cond edition 2004-06-01  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 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 abrev iaturas:  
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.001 — 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 certif i­
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 figura m 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.001 — 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 u m 
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.001 — 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.001 — 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  1 2  
CS#3  512/521  256  SHA-512  1 6  
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 autent ica­
çã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 ex ter­
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.001 — 450  
CSM_52 Em todo o sistema tacográfico inteligente europeu, as ch a­
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.001 — 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.001 — 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.001 — 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.001 — 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 priva da 
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.001 — 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.001 — 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.001 — 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 certif icados 
de ligação ERCA, os certificados MSCA e os certificados de equi pa­
mento ou aparelho (VU e cartão) de gerações diferentes são emit idos 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.001 — 458  
Notas ao esquema 1:  
1. As diversas gerações do certificado de raiz são indicadas po r 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 d o qual 
foram emitidos e o segundo a geração do próprio certificado. Po r 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 e mi­
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 emit idos 
ao abrigo de ERCA (1), o que se deve ao facto de os certificado s 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 qua se 
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 ca rtõ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 familiariz ados 
com o conteúdo da norma ISO 16844-3, que descreve a interface e ntre 
uma unidade-veículo e um sensor de movimentos. O processo de em pa­
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 emparelha r 
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.001 — 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-Membr o 
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.001 — 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.001 — 461  
CSM_108 Cada fabricante de sensores de movimentos cria um númer o 
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.001 — 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 d e 
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.001 — 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 g e­
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 comunic a­
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.001 — 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  é  K M  DSRC  . ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 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 d e OKM  e 
K_VU  DSRC  _MAC = últimos octetos  L d e 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 t erã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.001 — 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 d e 
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.001 — 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 co n­
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 ce rtifi­
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 cert ificado 
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.001 — 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  P K  «7F 49»  var  
Parâmetros de domí­
nio DP «06»  var
  
Ponto público  P P  «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 p ara 
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.001 — 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 d e 
domínio normalizados, a utilizar com a chave pública no certifi cado, 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 identificad or 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.001 — 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 d o 
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 hor a 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 hor a 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 c erti­
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 est a 
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.001 — 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 ce rtificado 
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.001 — 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.001 — 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 certifica dos 
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.001 — 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.001 — 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 esq uema 
são os destinados à autenticação mútua. A secção 9.1.4 indica-o s 
como VU_MA.  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 476  
— Os certificados VU.CA e as chaves públicas mencionados no es­
quema são os destinados à assinatura dos certificados da VU e d o 
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 d e 
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 chave s de 
raiz europeia criado pela ERCA e assinado pela chave privada eu ro­
peia anterior.  
— O certificado VU.Link.EUR é o certificado de raiz europeia in dicado 
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.001 — 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 certi fica­
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 apres entado 
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.001 — 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 d e 
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.001 — 479  
Esquema 6  
Protocolo de autenticação da VU
  
▼B 
CSM_172 Se, durante a sua autenticação, a VU enviar vários coma n­
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 autent ica­
çã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.001 — 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 d e 
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.001 — 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.001 — 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.001 — 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.001 — 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 cor respon­
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 comp rimento 
curto ou campos de comprimento alargado; ver norma ISO 7816-4.  
Uma APDU de resposta, com envio seguro de mensagens aplicado, t em a 
seguinte estrutura, consoante a caixa do comando não seguro cor respon­
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 é utiliz ada 
na comunicação entre uma VU e um cartão.  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 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 d a 
caixa 4 autenticada, o esquema 9 apresenta uma APDU de resposta  da 
caixa 1/caixa 3 autenticada e o esquema 10 apresenta uma APDU d e 
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.001 — 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.001 — 487  
CSM_193 O cartão tacográfico interrompe uma sessão de envio seg uro 
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 auten ticaçã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.001 — 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 su a 
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 o s 
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ódu lo 
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.001 — 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 utili za 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.001 — 490  
CSM_207 Após verificar o certificado EGF_MA, a VU memoriza-o pa ra 
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.001 — 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 co ncor­
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  V U  
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.001 — 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 sen sor de 
movimentos e todas as chaves associadas são substituídas period ica­
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 sensor es de 
movimentos até três encriptações de dados diferentes com recurs o a AES 
(baseadas em gerações consecutivas da chave de segurança do sen sor 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.001 — 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 chav es diferentes com 
comprimentos diferentes, conforme se explica no requisito CSM_1 17.
 02016R0799 — PT — 21.08.2023 — 003.001 — 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 a s 
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  1 6  1 6  1 6  
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  1 6  1 6  1 6  
41 Resposta  Chave de emparelha­
mento  16 16 / 24 / 32  1 6  3 2  3 2  
42 Pedido  Chave de sessão  1 6  16 / 24 / 32  1 6  3 2  3 2  
43 Pedido  Informações do em­
parelhamento  24 2 4  3 2  3 2  3 2  
50 Resposta  Informações do em­
parelhamento  24 2 4  3 2  3 2  3 2  
70 Pedido  Dados de autentica­
ção 8 8  1 6  1 6  1 6  
80 Resposta  Valor do contador 
MoS + dados autenti­
cados  8 8  1 6  1 6  1 6  
▼B 
CSM_219 As informações de emparelhamento enviadas nas instruçõe s 
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.001 — 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 bl oco 
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 movime ntos 
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.001 — 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 dad os 
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 envia r estes 
dados pela interface DSRC descrita no apêndice 14 ao interrogad or à 
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 1 4. A 
presente secção descreve a estrutura dos dados de segurança DSR C. 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 concat e­
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.001 — 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.001 — 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.001 — 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 d igitais 
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.001 — 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 control o 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 s egue 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.001 — 501  
Esquema 13  
Protocolo de verificação da assinatura num ficheiro de dados descarregados
  ▼M1
 02016R0799 — PT — 21.08.2023 — 003.001 — 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ícul o 
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.001 — 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 re cetor 
GNSS e os dados GNSS utilizados pela unidade-veículo, incluindo  os 
protocolos a aplicar para garantir a transferência correta e se gura 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 m enos, 
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 refe rê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.001 — 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ítima s 
▼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 funcion amento 
do tacógrafo inteligente. Por conseguinte, convém exigir que es te 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 nav e­
gação por satélite que melhora a qualidade dos sinais do sistem a 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.001 — 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 d e 
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 seguin tes 
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, denom i­
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.001 — 506  
GNS_3e O recetor GNSS deve utilizar o relógio em tempo real (RT C) 
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 t acógrafo 
inteligente para transmitir mensagens de posição padrão e auten ticadas. 
Esta secção aplica-se à configuração do tacógrafo inteligente c om 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.001 — 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 fras e 
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*h h 
1) Hora (UTC):  
2) Estatuto, A = posição autenticada (estabelecida utilizando p elo menos 4 
satélites a partir dos quais a autenticidade das mensagens de n avegação 
foi verificada com sucesso), J = interferência ou O = outro ata que 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 po r 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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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. Relativament e 
à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.001 — 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'  8 5  8 5  
1. a frase GSA NMEA  '02'  8 5  8 5  
2. a frase GSA NMEA  '03'  8 5  8 5  
3. a frase GSA NMEA  '04'  8 5  8 5  
4. a frase GSA NMEA  '05'  8 5  8 5  
5. a frase GSA NMEA  '06'  8 5  8 5  
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.001 — 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' 1 6  1 6  
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'  8 5  8 5  
1. a frase ASA  '12'  8 5  8 5  
2. a frase ASA  '13'  8 5  8 5  
3. a frase ASA  '14'  8 5  8 5  
4. a frase ASA  '15'  8 5  8 5  
5. a frase ASA  '16'  8 5  8 5  
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 hor a 
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.001 — 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.001 — 516  
GNS_23a A VU escreve também a hora RTC da VU e a diferença de t empo 
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 R ead 
Record (ler registo). O envio seguro de mensagens (modo «apenas  
autenticação») é adicionado conforme descrito no apêndice 11 (M eca­
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.001 — 517  
4.2.4  Estrutura do comando WriteRecord  
A presente secção descreve em pormenor a estrutura do comando R ead 
Record (Ler registo). O envio seguro de mensagens (modo apenas de 
autenticação) é adicionado conforme descrito no apêndice 11 (Me ca­
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.001 — 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 d e 
sessão do módulo GNSS externo com a unidade-veículo são descrit os 
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 autentic a­
çã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.001 — 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 rec etor 
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 extraind o 
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.001 — 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 c om 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.001 — 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.001 — 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.001 — 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.001 — 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 condut or 
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 comunic açã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.001 — 525  
1.2. Acrónimos e definições  
No presente apêndice utilizam-se os seguintes acrónimos e defin içõ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 dele s 
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 guar dar os 
dados tacográficos transmitidos através da interface ITS, sem q ual­
quer envolvimento da interface ITS.  
3.1. Tecnologia da comunicação  
ITS_05 A comunicação através da interface ITS deve ser realizad a 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 estabele cida 
após a conclusão do processo de emparelhamento do Bluetooth®.  
ITS_07 Deve ser estabelecida uma comunicação segura e criptogra fada 
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 con trolar a 
transmissão de dados entre dispositivos, em que a VU é o servid or 
e o órgão ITS é o cliente.  ▼M3
 02016R0799 — PT — 21.08.2023 — 003.001 — 526  
3.2. Serviços disponíveis  
ITS_09 Os dados a transmitir através da interface ITS em confor midade 
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 descarregamen to 
especificados no apêndice 7 por via da ligação Bluetooth® do IT S. 
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 especificado s 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 se rviç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 de s­
carregamento especificados no apêndice 6.  
ITS_13 A VU disponibiliza a interface ITS ao utilizador de acor do 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.001 — 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
 Ranhura do ajudante 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ífi co 
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
 Ranhura do ajudante 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 tacog rá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 li gaçã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 I TS 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 disponibiliza dos através 
da interface ITS devem cumprir os requisitos 12 e 13 do anexo I C, 
para além do consentimento do condutor especificado na secção 
3.4 deste apêndice.  ▼M3
 02016R0799 — PT — 21.08.2023 — 003.001 — 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 serv iç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ór ios 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 co n­
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 consider ados 
obrigatórios podem ser disponibilizados através da interface IT S. 
Os dados adicionais que não estão incluídos no ponto 4 devem se r 
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) é regista do na 
memória de dados da unidade-veículo.  
ITS_24 No caso de vários condutores, são partilhados com a inte rface ITS 
apenas os dados pessoais relativos aos condutores que deram o s eu 
consentimento. Por exemplo, no caso de uma equipa de conduto­
res, se apenas o condutor tiver dado o seu consentimento, os da dos 
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 deve m 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  V U  não pessoais  não pessoais  não é necessário o 
consentimento  obrigatória  
CalibrationDate  ISO 16844-7  V U  não pessoais  não pessoais  não é necessário o 
consentimento  obrigatória  
TachographVehicleS­
peed  ISO 16844-7  V U  pessoais  N/A  consentimento do 
condutor  obrigatória  ▼M3
 02016R0799 — PT — 21.08.2023 — 003.001 — 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  V U  pessoais  N/A  consentimento do 
condutor  obrigatória  
Driver2WorkingState  ISO 16844-7  V U  N/A  pessoais  consentimento do 
ajudante  obrigatória  
DriveRecognize  ISO 16844-7  V U  não pessoais  não pessoais  não é necessário o 
consentimento  obrigatória  
Driver1TimeRelatedS­
tates ISO 16844-7  V U  pessoais  N/A  consentimento do 
condutor  obrigatória  
Driver2TimeRelatedS­
tates ISO 16844-7  V U  N/A  pessoais  consentimento do 
ajudante  obrigatória  
DriverCardDriver1  ISO 16844-7  V U  pessoais  N/A  consentimento do 
condutor  obrigatória  
DriverCardDriver2  ISO 16844-7  V U  N/A  pessoais  consentimento do 
ajudante  obrigatória  
OverSpeed  ISO 16844-7  V U  pessoais  N/A  consentimento do 
condutor  obrigatória  
TimeDate  Apêndice 8  V U  não pessoais  não pessoais  não é necessário o 
consentimento  obrigatória  
HighResolutionTotal­
VehicleDistance  ISO 16844-7  V U  não pessoais  não pessoais  não é necessário o 
consentimento  obrigatória  
HighResolutionTrip­
Distance  ISO 16844-7  V U  não pessoais  não pessoais  não é necessário o 
consentimento  obrigatória  
ServiceComponentI­
dentification  ISO 16844-7  V U  não pessoais  não pessoais  não é necessário o 
consentimento  obrigatória  
ServiceDelayCalendar­
TimeBased  ISO 16844-7  V U  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.001 — 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  V U  não pessoais  não pessoais  não é necessário o 
consentimento  obrigatória  
Driver1ContinuousDri­
vingTime  ISO 16844-7  V U  pessoais  N/A  consentimento do 
condutor  obrigatória  
Driver2ContinuousDri­
vingTime  ISO 16844-7  V U  N/A  pessoais  consentimento do 
ajudante  obrigatória  
Driver1Cumulative­
BreakTime  ISO 16844-7  V U  pessoais  N/A  consentimento do 
condutor  obrigatória  
Driver2Cumulative­
BreakTime  ISO 16844-7  V U  N/A  pessoais  consentimento do 
ajudante  obrigatória  
Driver1CurrentDuratio­
nOfSelectedActivity  ISO 16844-7  V U  pessoais  N/A  consentimento do 
condutor  obrigatória  
Driver2CurrentDuratio­
nOfSelectedActivity  ISO 16844-7  V U  N/A  pessoais  consentimento do 
ajudante  obrigatória  
SpeedAuthorised  Apêndice 8  V U  não pessoais  não pessoais  não é necessário o 
consentimento  obrigatória  
TachographCardSlot1  ISO 16844-7  V U  não pessoais  N/A  não é necessário o 
consentimento  obrigatória  
TachographCardSlot2  ISO 16844-7  V U  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  V U  não pessoais  não pessoais  não é necessário o 
consentimento  obrigatória  
ModeOfOperation  ISO 16844-7  V U  não pessoais  não pessoais  não é necessário o 
consentimento  obrigatória  
Driver1CumulatedDri­
vingTimePreviousAnd­
CurrentWeek  ISO 16844-7  V U  pessoais  N/A  consentimento do 
condutor  obrigatória  ▼M3
 02016R0799 — PT — 21.08.2023 — 003.001 — 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  V U  N/A  pessoais  consentimento do 
ajudante  obrigatória  
EngineSpeed  ISO 16844-7  V U  pessoais  N/A  consentimento do 
condutor  facultativa  
RegisteringMemberS­
tate Apêndice 8  V U  não pessoais  não pessoais  não é necessário o 
consentimento  obrigatória  
VehicleRegistration­
Number  Apêndice 8  V U  não pessoais  não pessoais  não é necessário o 
consentimento  obrigatória  
Driver1EndOfLastDai­
lyRestPeriod  ISO 16844-7  V U  pessoais  N/A  consentimento do 
condutor  facultativa  
Driver2EndOfLastDai­
lyRestPeriod  ISO 16844-7  V U  N/A  pessoais  consentimento do 
ajudante  facultativa  
Driver1EndOfLas­
tWeeklyRestPeriod  ISO 16844-7  V U  pessoais  N/A  consentimento do 
condutor  facultativa  
Driver2EndOfLas­
tWeeklyRestPeriod  ISO 16844-7  V U  N/A  pessoais  consentimento do 
ajudante  facultativa  
Driver1EndOfSecon­
dLastWeeklyRestPe­
riod ISO 16844-7  V U  pessoais  N/A  consentimento do 
condutor  facultativa  
Driver2EndOfSecon­
dLastWeeklyRestPe­
riod ISO 16844-7  V U  N/A  Pessoais  consentimento do 
ajudante  facultativa  
Driver1TimeLastLoa­
dUnloadOperation  ISO 16844-7  V U  pessoais  N/A  consentimento do 
condutor  facultativa  
Driver2TimeLastLoa­
dUnloadOperation  ISO 16844-7  V U  N/A  pessoais  consentimento do 
ajudante  facultativa  
Driver1CurrentDaily­
DrivingTime  ISO 16844-7  V U  pessoais  N/A  consentimento do 
condutor  facultativa  
Driver2CurrentDaily­
DrivingTime  ISO 16844-7  V U  N/A  pessoais  consentimento do 
ajudante  facultativa  
Driver1CurrentWeekly­
DrivingTime  ISO 16844-7  V U  pessoais  N/A  consentimento do 
condutor  facultativa  
Driver2CurrentWeekly­
DrivingTime  ISO 16844-7  V U  N/A  pessoais  consentimento do 
ajudante  facultativa  ▼M3
 02016R0799 — PT — 21.08.2023 — 003.001 — 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  V U  pessoais  N/A  consentimento do 
condutor  facultativa  
Driver2TimeLeftUntil­
NewDailyRestPeriod  ISO 16844-7  V U  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  V U  pessoais  N/A  consentimento do 
condutor  facultativa  
Driver2CardNextMan­
datoryDownloadDate  ISO 16844-7  V U  N/A  pessoais  consentimento do 
ajudante  facultativa  
TachographNextMan­
datoryDownloadDate  ISO 16844-7  V U  não pessoais  não pessoais  não é necessário o 
consentimento  facultativa  
Driver1TimeLeftUntil­
NewWeeklyRestPeriod  ISO 16844-7  V U  pessoais  N/A  consentimento do 
condutor  facultativa  
Driver2TimeLeftUntil­
NewWeeklyRestPeriod  ISO 16844-7  V U  N/A  pessoais  consentimento do 
ajudante  facultativa  
Driver1NumberOfTi­
mes9hDailyDrivingTi­
mesExceeded  ISO 16844-7  V U  pessoais  N/A  consentimento do 
condutor  facultativa  
Driver2NumberOfTi­
mes9hDailyDrivingTi­
mesExceeded  ISO 16844-7  V U  N/A  pessoais  consentimento do 
ajudante  facultativa  
Driver1Cumulative­
UninterruptedRestTime  ISO 16844-7  V U  pessoais  N/A  consentimento do 
condutor  facultativa  
Driver2Cumulative­
UninterruptedRestTime  ISO 16844-7  V U  N/A  pessoais  consentimento do 
ajudante  facultativa  
Driver1MinimumDai­
lyRest  ISO 16844-7  V U  pessoais  N/A  consentimento do 
condutor  facultativa  
Driver2MinimumDai­
lyRest  ISO 16844-7  V U  N/A  pessoais  consentimento do 
ajudante  facultativa  ▼M3
 02016R0799 — PT — 21.08.2023 — 003.001 — 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  V U  pessoais  N/A  consentimento do 
condutor  facultativa  
Driver2Minimum­
WeeklyRest  ISO 16844-7  V U  N/A  pessoais  consentimento do 
ajudante  facultativa  
Driver1MaximumDai­
lyPeriod  ISO 16844-7  V U  pessoais  N/A  consentimento do 
condutor  facultativa  
Driver2MaximumDai­
lyPeriod  ISO 16844-7  V U  N/A  pessoais  consentimento do 
ajudante  facultativa  
Driver1MaximumDai­
lyDrivingTime  ISO 16844-7  V U  pessoais  N/A  consentimento do 
condutor  facultativa  
Driver2MaximumDai­
lyDrivingTime  ISO 16844-7  V U  N/A  pessoais  consentimento do 
ajudante  facultativa  
Driver1NumberOfUse­
dReducedDailyRestPe­
riods  ISO 16844-7  V U  pessoais  N/A  consentimento do 
condutor  facultativa  
Driver2NumberOfUse­
dReducedDailyRestPe­
riods  ISO 16844-7  V U  N/A  pessoais  consentimento do 
ajudante  facultativa  
Driver1RemainingCur­
rentDrivingTime  ISO 16844-7  V U  pessoais  N/A  consentimento do 
condutor  facultativa  
Driver2RemainingCur­
rentDrivingTime  ISO 16844-7  V U  N/A  pessoais  consentimento do 
ajudante  facultativa  
VehiclePosition  Apêndice 8  V U  pessoais  pessoais  consentimento do 
condutor e do 
ajudante  obrigatória  
ByDefaultLoadType  Apêndice 8  V U  pessoais  pessoais  consentimento do 
condutor e do 
ajudante  obrigatória  ▼M3
 02016R0799 — PT — 21.08.2023 — 003.001 — 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 d a 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.001 — 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.001 — 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 apen as 
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 age ntes das auto­
ridades de controlo competentes utilizam uma comunicação sem fi os 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 Regula mento (UE)  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 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 pot encial 
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 à monitor i­
zação tacográfica à distância (RTM) podem ser igualmente utiliz ados 
pelas autoridades de controlo para outras aplicações (como os p esos e 
as dimensões máximos dos veículos pesados de mercadorias, defin idos 
na Diretiva (UE) 2015/719) e essas operações podem ser distinta s ou 
sequenciais, ao critério das autoridades de controlo competente s. 
▼B 
O presente apêndice especifica:  
— O equipamento de comunicações, procedimentos e protocolos a u ti­
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 da s 
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 noutr as 
partes do Regulamento (UE) n.  o 165/2014)  
— A forma de apresentação dos dados recolhidos para o agente da s 
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 noutr as 
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.001 — 538  
— Disposições de segurança dos dados (como a encriptação) relat iva­
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 defin içõ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.001 — 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.001 — 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 à total idade ou a 
partes dos regulamentos e normas a seguir indicados e deles dep ende. O 
clausulado do presente apêndice especifica as normas pertinente s ou 
cláusulas pertinentes das normas. Em caso de contradição, preva lecem 
as cláusulas do presente apêndice. Em caso de contradição sem q ue 
esteja claramente determinada qualquer especificação no present e apên­
dice, prevalece a aplicação da Recomendação ERC 70-03 (com ensa io 
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 transporte s 
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 c oo­
perative telematics applications for regulated commercial freig ht 
vehicles (TARV).  
[5] EN 300 674-1: Electromagnetic compatibility and Radio spect rum 
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 In dus­
trial, Scientific and Medical (ISM) band; Part 1: General chara cte­
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.001 — 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 interfa ce 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 l eitor 
é 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.001 — 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 in terface 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 inte rrogaçã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, confo rme 
refere a secção 5 (ver esquema 14.1 — Caso de utilização 1).  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 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 centr o do 
para-brisas do veículo visado quando o veículo do leitor de com unica­
ções de deteção rápida à distância está numa posição particular  per­
tinente para o veículo visado (por exemplo, diretamente em fren te 
num fluxo de tráfego). A interrogação é feita com recurso a int erfaces 
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 67 4-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 (Mec anis­
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 in teli­
gente é apresentada e descrita no esquema 14.3.  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 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.001 — 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.001 — 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 apresent ar ao 
agente das autoridades de controlo os resultados da função de c omuni­
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 autorid ades 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.001 — 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.001 — 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 recolh er 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 c arga 
ú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 dad os para 
o auxiliar a decidir se deve ou não parar o veículo para uma in speção 
pormenorizada, ou pedir a outro agente da autoridade de control o 
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.001 — 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 à int erface 
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 à d is­
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âm e­
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.001 — 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  m s  (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.001 — 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 c onformidade 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.001 — 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.001 — 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 co nformidade 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.001 — 554  
DSC_32 A antena da VU deve ser fixada ou aproximada ao para-bri sas 
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), u ma 
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.001 — 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.001 — 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 utilizad as 
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.001 — 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  d a 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.001 — 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 normaliza da 
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.001 — 559
  
► (2) (3) M1 
► (1) M3 ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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.001 — 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 pedid os 
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_4 8 
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.001 — 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 do octeto 
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.001 — 570
 N.o do octeto 
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 do octeto 
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.001 — 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 do octeto 
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.001 — 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 de octetos 
Atributo/campo  Bits no octeto  Descrição  
1 FLAG  0111 1110  Início do indicador  
2 Private LID  xxxx xxxx  Endereço de ligação da 
DSRC-VU específica  
3 xxxx xxxx  
4 xxxx xxxx  
5 xxxx xxxx  
6 MAC Control field  1100 0000  PDU de comando  
7 LLC Control field  0000 0011  Comando da IU  
8 Fragmentation header  1xxx x001  Sem fragmentação  
9 VST 
SEQUENCE { 
Fill BIT STRING (SIZE(4))  1001  Resposta de inicialização  
0000  Não utilizada e fixada em 
0 
10 Profile INTEGER (0..127,...) 
Aplicações SEQUÊNCIA DE {  0000 0000  Sem extensão. Exemplo 
de perfil 0 
Sem extensão, 1 aplicação  
11 0000 0001  
12 SEQUENCE { 
OPTION indicator 
OPTION indicator 
AID DSRCApplicationEntityID  1 EID presente  
1 Parâmetro presente  
00 0010  Sem extensão. AID= 2 
Carga e frota  
13 EID Dsrc-EID  xxxx xxxx  Definido na OBU e iden­
tificando a instância de 
aplicação.  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 573
 n.o de octetos 
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.001 — 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 do octeto 
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.001 — 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 do octeto 
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.001 — 576
 N.o do octeto 
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 do octeto 
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.001 — 577
 N.o do octeto 
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 i ns­
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.001 — 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.001 — 579  
Quadro 14.15  
▼C2 
Exemplo de estrutura de pedido de ação ECHO
 N.o do octeto 
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.001 — 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 do octeto 
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.001 — 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 interfa ce, 
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.001 — 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 efetu ada 
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.001 — 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.001 — 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 c om 
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 tratad os 
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, particularm ente nas 
combinações «REDCR portátil» e «veículo em movimento» presentes  
nesta aplicação. É, por conseguinte, necessário verificar a dif erenç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, no rmal­
mente, a consequência é voltar a tentar, ou seja, voltar a tran smitir o 
BST e tentar novamente a sequência, que, na maioria das circuns tâ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 durant e 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 es tão devi­
damente emparelhadas (falha de «pontaria»); uma das antenas est á blin­
dada (pode ser deliberado, mas pode igualmente dever-se à prese nça 
física de outro veículo); há interferência do rádio, especialme nte de cerca 
de 5,8 GHz Wi-Fi ou outras comunicações sem fios de acesso públ ico; 
há interferência do radar ou condições atmosféricas adversas (p or exem­
plo, durante um temporal); ou simples movimento para fora do al cance 
da comunicação DSRC. Pela sua natureza, as instâncias individua is 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 ti ver 
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 ocor rido devido 
a adulteração deliberada e, por conseguinte, o agente precisa d e 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 comun i­
cação com êxito, o DSRC-VU não pode fornecer dados sobre a falh a. 
Essa comunicação deve, por conseguinte, ser uma função de conce ção 
de equipamento REDCR.  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 585  
Tecnicamente, «falha de leitura» é diferente de «erro». Neste c ontexto, 
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 dad os po­
derem passar com êxito por um CRC, de modo incorreto, é estatis tica­
mente muito improvável, pelo que pode ser descartada.  
Se o CRC não validar e não houver tempo para retransmitir e rec eber 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 re sultam 
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 apena s 
à 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 c omu­
nicação à distância:  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 586  
1) Ensaio ECHO para validar o  DSRC-REDCR  >>-:-< DSRC- 
-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 tes tar ape­
nas se o  DSRC-REDCR  >>-:-< DSRC-VU  está funcionalmente ativo.  
O objetivo do comando ECHO é autorizar as oficinas ou unidades de 
ensaio de homologações de tipo a testar se a ligação DSRC funci ona 
sem necessidade de acesso a credenciais de segurança. Por conse guinte, 
o equipamento do dispositivo de teste só tem de ser capaz de in icializar 
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  
>>-:-< DSRC-VU ) pode ser validada como funcionando corretamente.  
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 ensai o 
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 ofi cina 
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.001 — 587  
ADENDA  
Regras para o cálculo do tempo diário, semanal e quinzenal de c onduçã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 relevant es memo­
rizados num cartão de condutor (ou de oficina) inserido na ranh ura 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á i nserido na VU.  
Os tempos de condução não são calculados sem o cartão de condut or (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/REPOUS O. 
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 ativi dade), devido a 
sobreposições de tempo entre duas VU diferentes ou devido a aju stamento 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, de vem 
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ári o 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ânci a. 
a) «Turno RTM» é o período entre o final de um período de desca nso 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íod o de 
descanso diário;  
b) «tempo de condução acumulado»: soma da duração de todas as a tividades 
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.001 — 588  
g) «período de repouso diário»: um período de PAUSA/REPOUSO, qu e 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 d e 
repouso semanais, esses períodos de repouso semanais são consid erados 
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 s er 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íod o 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 calcu la 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 h oras.  
Quando um período de repouso diário regular tiver sido interrom pido, a 
VU: 
— não deve incorporar a atividade de condução encontrada durant e 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ári o 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 con tí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 me nos, 3 
horas, mas menos de 9,  
— a segunda parte é um período de repouso contínuo de, pelo men os, 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íod o de 
repouso diário dividido, o período de repouso diário dividido p ode ser 
interrompido no máximo duas vezes por outras atividades com a d uração 
acumulada máxima de uma hora, ou seja:  
— a primeira parte do período de repouso diário dividido pode s er inter­
rompida uma ou duas vezes, ou  
— a segunda parte do período de repouso diário dividido pode se r inter­
rompida uma ou duas vezes, ou  ▼M3
 02016R0799 — PT — 21.08.2023 — 003.001 — 589  
— a primeira parte do período de repouso diário dividido pode s er 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 pri meiro 
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 int errom­
pido por TRAVESSIA DE BATELÃO/COMBOIO.  
— de, pelo menos, três horas, mas menos de 9 horas, para o prim eiro 
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 int errom­
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 V U: 
— não deve incorporar a atividade de condução encontrada durant e 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ári o 
dividido que foi interrompido;  
k) «semana» é o período em hora UTC entre as 00.00 horas de seg unda-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 interrompi do devido a 
travessia de batelão/comboio, a VU deve calcular o tempo de rep ouso 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 pa ra cada 
interrupção detetada se as seguintes condições foram cumpridas:  
— a interrupção faz com que a duração total das interrupções de tetadas, 
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 t raves­
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 de tetadas, 
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 t raves­
sia de batelão/comboio, seja superior a duas,  
— há uma «Introdução do local onde os períodos de trabalho diár ios 
terminam» memorizado após o termo da interrupção.  
Se nenhuma das condições anteriores for satisfeita, o período d e repouso 
contínuo que precede imediatamente a interrupção é adicionado a o tempo 
de repouso acumulado.  ▼M3
 02016R0799 — PT — 21.08.2023 — 003.001 — 590  
Se, pelo menos, uma das condições acima for satisfeita, a VU de ve 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 a pó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 av alia se o 
cálculo do tempo de repouso acumulado deve terminar. A VU inter rompe 
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 acumul ado, 
incluindo, se for caso disso, os períodos de repouso adicionado s na pri­
meira parte de um período de repouso diário dividido também int errom­
pido por travessia de batelão/comboio. Caso contrário, a VU dev e 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 de sativaçã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 ante rior à 
interrupção. Caso contrário, os períodos de repouso contínuos o corridos 
após as respetivas interrupções devem ser adicionados ao cálcul o do pe­
ríodo de repouso diário até que a condição na etapa 4 seja sati sfeita.  
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 d ois 
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/comboi o. 
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.001 — 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.001 — 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 in terrupções 
dos períodos de repouso diário não é adicionado ao cálculo do t empo diário 
de condução, quando tais interrupções se devam a travessia de b atelã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 calculad o um 
período de repouso diário regular ou dividido completo de acord o com o 
ponto 3, os tempos de condução ocorridos durante as interrupçõe s 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.001 — 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 t acográfi­
cos da segunda geração.  ▼M3
 02016R0799 — PT — 21.08.2023 — 003.001 — 594  
Além das disposições desta introdução, convém ter em conta as s eguintes 
informações:  
— os sensores de movimentos da primeira geração não são interop erá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 aparel hos 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 conformi dade 
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 r equisitos  
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 util izar 
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 u tili­
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 seg unda 
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 pa sso que os 
sensores de movimentos da segunda geração são interoperáveis co m 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.001 — 595  
MIG_008 Os sensores de movimentos da segunda geração só podem s er 
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 car tã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 ger açã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.001 — 596  
2.4.3  Descarregamento da unidade-veículo  
MIG_014 Fora do quadro de controlo dos condutores pelas autorid ades 
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 calib raçã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 disponibil izados 
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 ca r­
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 mo vi­
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.001 — 597  
MIG_023a Com efeitos a partir da data de produção, a versão 1 c om 
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 mo vi­
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 c on­
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.001 — 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 ve locidade e 
adaptá-los  
4.2. Induzir os impulsos de entrada no sensor de movimentos inc orporado  
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 el e 
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.001 — 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 homolog ado 
(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 s egu­
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 pr esente 
anexo quando é utilizado um adaptador. Os números dos requisito s do 
anexo IC figuram entre parêntesis retos.  
ADA_005 O aparelho de controlo de um veículo equipado com adapt ador 
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 aparel ho 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.001 — 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 cont rolo são 
as relacionadas com o sensor de movimentos incorporado [88].  
ADA_009 A função de calibração da VU deve permitir emparelhar a uto­
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 ace itar 
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 d eve 
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 conform e 
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 dad os de 
identificação do sensor de movimentos incorporado [95].  ▼B
 02016R0799 — PT — 21.08.2023 — 003.001 — 601  
ADA_016 Os dados da instalação armazenados no sensor de movimen tos 
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 impos si­
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 mo vi­
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étr ica, 
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 i nter­
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.001 — 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 ele mentos 
(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 i nterface 
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 cai xa do 
adaptador.  
ADA_032 O adaptador deve ser colocado o mais próximo possível d a 
parte do veículo que fornece os impulsos de entrada.  
ADA_033 Os cabos que fornecem energia elétrica ao adaptador dev em 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.001 — 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 substitu içã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 ti po 
autonomamente ou como componente de um aparelho de 
controlo.  
ADA_039 Esta homologação de tipo deve incluir ensaios de funcio nali­
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 funciona lidade 
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.001 — 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.001 — 605  
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», seg uida 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  3 4  
República Checa  8  
Dinamarca  1 8  
Alemanha  1  
Estónia  2 9  
Irlanda  2 4  
Grécia  2 3  
Espanha  9  
França  2  
Croácia  2 5  
Itália  3  
Chipre  C Y  
Letónia  3 2  
Lituânia  3 6  
Luxemburgo  1 3  
Hungria  7  
Malta  M T  
Países Baixos  4  
Áustria  1 2  
Polónia  2 0  
Portugal  2 1  
Roménia  1 9  
Eslovénia  2 6  
Eslováquia  2 7  
Finlândia  1 7  
Suécia  5  
Reino Unido  1 1  
e 
▼M1 
b) o número de homologação, correspondente ao número do certifi cado 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.001 — 606  
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 in delé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 respei tada.
 ▼C1 
( 1 ) Valores meramente a título de orientação.
 02016R0799 — PT — 21.08.2023 — 003.001 — 607  
II. CERTIFICADO DE HOMOLOGAÇÃO PARA TACÓGRAFOS 
ANALÓGICOS  
O Estado-Membro que tiver procedido a uma homologação deve conc eder ao 
requerente um certificado de homologação, conforme o modelo a s eguir indicado. 
Para informar outros Estados-Membros das homologações concedida s ou even­
tualmente revogadas, os Estados-Membros devem utilizar cópias d o 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 dis so) 
(assinatura)  ▼C1 
( 1 ) Riscar o que não interessa.
 02016R0799 — PT — 21.08.2023 — 003.001 — 608  
III. CERTIFICADO DE HOMOLOGAÇÃO PARA TACÓGRAFOS DIGITAIS  
O Estado-Membro que tiver procedido a uma homologação deve conc eder ao 
requerente um certificado de homologação, conforme o modelo a s eguir indicado. 
Para informar outros Estados-Membros das homologações concedida s ou even­
tualmente revogadas, os Estados-Membros devem utilizar cópias d o 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 componen te 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 dis so) 
(assinatura)  ▼C1 
( 1 ) Assinalar os quadrados pertinentes. 
( 2 ) Especificar o componente a que se refere a comunicação.
 02016R0799 — PT — 21.08.2023 — 003.001 — 609  
IV. CERTIFICADO DE HOMOLOGAÇÃO PARA TACÓGRAFOS 
INTELIGENTES  
O Estado-Membro que tiver procedido a uma homologação deve conc eder ao 
requerente um certificado de homologação, conforme o modelo a s eguir indicado. 
Para informar outros Estados-Membros das homologações concedida s ou even­
tualmente revogadas, os Estados-Membros devem utilizar cópias d o 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 interoperabilidad e 
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 componen te 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 dis so) 
(assinatura)  ▼C1 
( 1 ) Assinalar os quadrados pertinentes. 
( 2 ) Especificar o componente a que se refere a comunicação.