Onderstaande tekst dient louter ter informatie en is juridisch niet bindend. De EU-instellingen zijn niet aansprakelijk voor de  
inhoud. Alleen de besluiten die zijn gepubliceerd in het Publicatieblad van de Europese Unie (te raadplegen in EUR-Lex) zijn 
authentiek. Deze officiële versies zijn rechtstreeks toegankelijk via de links in dit document  
►B UITVOERINGSVERORDE NING (EU) 2016/799 VAN DE COMMISSIE  
van 18 maart 2016  
tot uitvoering van Verordening (EU) nr. 165/2014 van het Europees Parlement en de Raad tot 
vaststelling van de eisen voor de constructie, het testen, de installatie, de exploitatie en de reparatie 
van tachografen en tachograafonderdelen  
(Voor de EER relevante tekst)  
(PB L 139 van 26.5.2016, blz. 1)  
Gewĳzigd bĳ: 
Publicatieblad  
nr. blz.  datum  
►M1 Uitvoeringsverordening (EU) 2018/502 van de Commissie van 
28 februari 2018  L 85  1  28.3.2018  
►M2 Uitvoeringsverordening (EU) 2020/158 van de Commissie van 
5 februari 2020  L 34  20  6.2.2020  
Gerectificeerd b ĳ: 
►C1 Rectificatie PB L 146 van 3.6.2016, blz. 31 (2016/799)  
►C2 Rectificatie PB L 27 van 1.2.2017, blz. 169 (2016/799)  02016R0799 — NL — 26.02.2020 — 002.001 — 1
02016R0799 — NL — 26.02.2020 — 002.001 — 2  
UITVOERINGSVERORDENING (EU) 2016/799 VAN DE 
COMMISSIE  
van 18 maart 2016  
tot uitvoering van Verordening (EU) nr. 165/2014 van het Europees 
Parlement en de Raad tot vaststelling van de eisen voor de 
constructie, het testen, de installatie, de exploitatie en de reparatie 
van tachografen en tachograafonderdelen  
(Voor de EER relevante tekst)  
Artikel 1  
Onderwerp en werkingssfeer  
1. Bij deze verordening worden de regels vastgesteld die noodzake ­
lijk zijn voor de uniforme toepassing van de volgende aspecten betref ­
fende tachografen:  
a) registratie van de positie van het voertuig op bepaalde momenten 
tijdens de dagelijkse werktijd van de bestuurder;  
b) vroegtijdige detectie op afstand van eventueel manipulatie of mis ­
bruik van slimme tachografen;  
c) interface met intelligente vervoerssystemen;  
d) de administratieve en technische eisen voor de typegoedkeuringspro ­
cedure voor tachografen, met inbegrip van de beveiligingsmechanis ­
men.  
▼M1 
2. Bij de constructie, het testen, de installatie, de inspectie, de ex ­
ploitatie en de reparatie van slimme tachografen en hun onderdelen 
moeten de in bijlage IC bij deze verordening vastgestelde technische 
eisen in acht worden genomen.  
3. Voor de constructie, het testen, de installatie, de inspectie, de 
exploitatie en de reparatie van andere tachografen dan slimme tachogra ­
fen blijven de eisen van bijlage I van Verordening (EU) nr. 165/2014 of 
bijlage IB bij Verordening (EEG) nr. 3821/85 van de Raad (  1 ) van 
toepassing.  
▼B 
4. Overeenkomstig artikel 10 quinquies van Richtlijn 96/53/EG moet 
het systeem voor de vroegtijdige detectie op afstand de gewichtsgege ­
vens die door de interne weegapparatuur van het voertuig worden ge ­
genereerd, doorsturen met het oog op de vroegtijdige detectie van frau ­
de. 
▼M1 
5. Deze verordening doet geen afbreuk aan de toepassing van Richt ­
lijn 2014/53/EU van het Europees Parlement en de Raad (  2 ). 
▼B 
Artikel 2  
Definities  
Voor de toepassing van deze verordening gelden de definities van ar ­
tikel 2 van Verordening (EU) nr. 165/2014.  ▼B 
( 1 ) Verordening (EEG) nr. 3821/85 van de Raad van 20 december 1985 betref ­
fende het controleapparaat in het wegvervoer (PB L 370 van 31.12.1985, 
blz. 8). 
( 2 ) Richtlijn 2014/53/EU van het Europees Parlement en de Raad van 16 april 
2014 betreffende de harmonisatie van de wetgevingen van de lidstaten inzake 
het op de markt aanbieden van radioapparatuur en tot intrekking van Richtlijn 
1999/5/EG (PB L 153 van 22.5.2014, blz. 62)
 02016R0799 — NL — 26.02.2020 — 002.001 — 3  
Bovendien wordt verstaan onder:  
1) „digitale tachograaf” of „tachograaf van de eerste generatie”: een 
andere digitale tachograaf dan een slimme tachograaf;  
2) „extern GNSS-systeem”: het systeem dat de GNSS-ontvanger be ­
vat wanneer de voertuigunit uit meer dan één unit bestaat, alsmede 
de andere onderdelen die nodig zijn voor de bescherming van de 
naar de rest van de voertuigunit doorgestuurde plaatsbepalings ­
gegevens;  
▼M1 
3) „informatiebrochure”: de volledige papieren of elektronische bro ­
chure met alle informatie die door de fabrikant of zijn gemachtigde 
is meegedeeld aan de typegoedkeuringsinstantie met het oog op de 
typegoedkeuring van een tachograaf of tachograafonderdeel, met 
inbegrip van de certificaten als bedoeld in artikel 12, lid 3, van 
Verordening (EU) nr. 165/2014, de uitvoering van de in bijlage IC 
bij deze verordening gedefinieerde testen, alsmede schema's, af ­
beeldingen en andere documenten;  
▼B 
4) „informatiepakket”: de papieren of elektronische informatiebrochu ­
re, vergezeld van de andere tijdens de uitoefening van haar functies 
door de typegoedkeuringsinstantie aan de informatiebrochure toe ­
gevoegde documenten, waaronder het na afloop van de typegoed ­
keuringsprocedure afgegeven EG-typegoedkeuringscertificaat van 
de tachograaf of het tachograafonderdeel;  
5) „index bij het informatiepakket”: het document met een lijst van de 
genummerde inhoud van het informatiepakket en een overzicht van 
alle relevante delen van dat pakket. In het opzet van dit document 
wordt een onderscheid gemaakt tussen de verschillende stappen 
van de EG-typegoedkeuringsprocedure, met vermelding van de 
data waarop het pakket eventueel is herzien of bijgewerkt;  
6) „systeem voor vroegtijdige detectie op afstand”: de apparatuur van 
de voertuigunit die voor de uitvoering van wegcontroles wordt 
gebruikt;  
▼M1 
7) „slimme tachograaf” of „tachograaf van de tweede generatie”: een 
digitale tachograaf die voldoet aan de artikelen 8, 9 en 10 van 
Verordening (EU) nr. 165/2014 en aan bijlage IC bij deze ver ­
ordening;  
8) „tachograafonderdeel”: een van de volgende elementen: de voer ­
tuigunit, de bewegingssensor, het registratieblad, het externe 
GNSS-systeem en het externe systeem voor vroegtijdige detectie 
op afstand;  
▼B 
9) „typegoedkeuringsinstantie”: de instantie van een lidstaat die be ­
voegd is voor de typegoedkeuring van tachografen of tachograaf ­
onderdelen, de goedkeuringsprocedure, de afgifte en desgevallend 
intrekking van typegoedkeuringscertificaten, die optreedt als aan ­
spreekpunt voor de typegoedkeuringsinstanties van andere lidstaten 
en die erop toeziet dat fabrikanten hun verplichtingen op grond van 
deze verordening nakomen;  
▼M1 
10) „voertuigunit”: de tachograaf, met uitzondering van de bewegings ­
opnemer en de kabels waarmee de bewegingsopnemer is aange ­
sloten.  
Het kan gaan om één unit of om meerdere units die zich op 
verschillende plaatsen in het voertuig bevinden, en omvat een ver ­
werkingseenheid, een geheugen, een tijdmetingsfunctie, twee 
smartcard-interfaces voor de bestuurder en bijrijder, een printer,  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 4  
een display, connectoren en voorzieningen voor de invoer van de 
gebruikersgegevens, een GNSS-ontvanger en een systeem voor 
communicatie op afstand.  
De voertuigunit kan uit de volgende onderdelen bestaan, voor 
zover deze over een typegoedkeuring beschikken:  
— voertuigunit, als afzonderlijk onderdeel (met inbegrip van een 
GNSS-ontvanger en een systeem voor communicatie op af ­
stand),  
— hoofdbehuizing van de voertuigunit (met inbegrip van een sys ­
teem voor communicatie op afstand), en een externe GNSS- 
module,  
— hoofdbehuizing van de voertuigunit (met inbegrip van een 
GNSS-ontvanger), en een extern systeem voor communicatie 
op afstand,  
— hoofdbehuizing van de voertuigunit, extern GNSS-systeem, en 
extern systeem voor communicatie op afstand.  
Als de voertuigunit is samengesteld uit meerdere in het voertuig 
verspreide units, moeten de verwerkingseenheid, het geheugen en 
de tijdsmetingsfunctie zich in de hoofdbehuizing bevinden.  
„voertuigunit (VU)” wordt gebruikt voor „voertuigunit” of „hoofd ­
behuizing van de voertuigunit”.  
▼B 
Artikel 3  
Locatiegebaseerde diensten  
1. De fabrikanten zorgen ervoor dat slimme tachografen compatibel 
zijn met de plaatsbepalingsdiensten die worden aangeboden door Gali ­
leo en de European Geostationary Navigation Overlay Service (Egnos).  
2. Boven op de in de eerste alinea genoemde diensten mogen fabri ­
kanten ook de compatibiliteit met andere satellietnavigatiesystemen 
waarborgen.  
Artikel 4  
Procedure voor de typegoedkeuring van tachografen en 
tachograafonderdelen  
1. Een fabrikant of zijn gemachtigde dient een aanvraag voor de 
typegoedkeuring van een tachograaf, tachograafonderdeel of groep on ­
derdelen in bij de door elke lidstaat aangewezen typegoedkeurings ­
instanties. Deze aanvraag omvat een informatiebrochure met informatie 
over alle onderdelen, waaronder desgevallend de typegoedkeuringscer ­
tificaten van andere onderdelen die deel uitmaken van de volledige 
tachograaf, alsmede alle andere relevante documenten.  
2. Een lidstaat verleent een typegoedkeuring voor een tachograaf, 
tachograafonderdeel of groep onderdelen die, naargelang het geval, vol ­
doet aan de administratieve en technische eisen als bedoeld in artikel 1, 
lid 2 of 3. In dat geval verleent de typegoedkeuringsinstantie de aan ­
vrager een typegoedkeuringscertificaat dat overeenstemt met het model 
in bijlage II bij deze verordening.  
3. De typegoedkeuringsinstantie kan de fabrikant of zijn gemachtigde 
om aanvullende informatie verzoeken.  ▼M1
 02016R0799 — NL — 26.02.2020 — 002.001 — 5  
4. De fabrikant of zijn gemachtigde stelt voldoende tachografen of 
tachograafonderdelen ter beschikking van de typegoedkeuringsinstanties 
en de met de afgifte van de in artikel 12, lid 3, van Verordening (EU) 
nr. 165/2014 bedoelde certificaten belaste instanties om de typegoed ­
keuringsprocedure correct te kunnen uitvoeren.  
5. Een fabrikant of zijn gemachtigde die een typegoedkeuring van 
bepaalde tachograafonderdelen of groepen onderdelen aanvraagt, zorgt 
ervoor dat de typegoedkeuringsinstanties kunnen beschikken over de 
andere reeds goedgekeurde tachograafonderdelen, alsmede over alle an ­
dere onderdelen die nodig zijn om een volledige tachograaf samen te 
stellen, zodat de instanties de nodige tests kunnen uitvoeren.  
Artikel 5  
Wijzigingen van typegoedkeuringen  
1. De fabrikant of zijn gemachtigde stelt de typegoedkeuringsinstan ­
tie die de oorspronkelijke typegoedkeuring heeft verleend, onverwijld in 
kennis van alle wijzigingen aan de software of hardware van de tacho ­
graaf of de aard van de in het informatiepakket vermelde materialen 
waaruit de tachograaf is vervaardigd, en dient een verzoek tot wijziging 
van de typegoedkeuring in.  
2. De typegoedkeuringsinstanties kunnen een bestaande typegoed ­
keuring herzien of verlengen, dan wel een nieuwe afgeven in het licht 
van de aard en kenmerken van de wijzigingen.  
Een typegoedkeuring wordt „herzien” wanneer de typegoedkeurings ­
instantie van oordeel is dat de wijzigingen aan de software of hardware 
van de tachograaf of aan de aard van de materialen waaruit deze is 
vervaardigd, minimaal zijn. In dergelijke gevallen stelt de typegoedkeu ­
ringsinstantie herziene documenten van het informatiepakket op met 
vermelding van de aard van de wijzigingen en van de datum waarop 
ze zijn goedgekeurd. Om aan deze eis te voldoen, volstaat een gecon ­
solideerde bijgewerkte versie van het informatiepakket met een nauw ­
keurige beschrijving van de aangebrachte wijzigingen.  
Een typegoedkeuring wordt „verlengd” wanneer de typegoedkeurings ­
instantie van oordeel is dat de wijzigingen aan de software of hardware 
van de tachograaf of aan de aard van de materialen waaruit deze is 
vervaardigd, significant zijn. In dergelijke gevallen kan zij eisen dat 
nieuwe testen worden uitgevoerd en stelt zij de fabrikant of zijn ge ­
machtigde daarvan in kennis. Indien deze testen naar wens verlopen, 
geeft de typegoedkeuringsinstantie een herzien typegoedkeuringscertifi ­
caat af, met een nummer dat naar de toegestane verlenging verwijst. De 
typegoedkeuringsinstantie vermeldt de reden voor de verlenging en de 
datum van afgifte.  
3. In de index van het informatiepakket wordt de datum van de 
jongste verlenging of herziening van de typegoedkeuring vermeld, dan 
wel de datum van de jongste geconsolideerde of bijgewerkte versie van 
de typegoedkeuring.  
4. Een nieuwe typegoedkeuring is noodzakelijk wanneer op basis van 
de gevraagde aanpassingen van de goedgekeurde tachograaf of tacho ­
graafonderdelen een nieuw beveiligings- of interoperabiliteitscertificaat 
moet worden afgegeven.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 6  
Artikel 6  
Inwerkingtreding  
Deze verordening treedt in werking op de twintigste dag na die van de 
bekendmaking ervan in het  Publicatieblad van de Europese Unie . 
Zij is van toepassing met ingang van 2 maart 2016.  
▼M1 
Bijlage IC is evenwel van toepassing met ingang van 15 juni 2019, met 
uitzondering van aanhangsel 16, dat met ingang van 2 maart 2016 van 
toepassing is.  
▼B 
Deze verordening is verbindend in al haar onderdelen en is rechtstreeks 
toepasselijk in elke lidstaat.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 7  
BIJLAGE I C  
Constructie-, test-, installatie- en controlevoorschriften  
INLEIDING  
1 DEFINITIES  
2 ALGEMENE KENMERKEN EN FUNCTIES VAN HET CON ­ 
TROLEAPPARAAT  
2.1 Algemene kenmerken  
2.2 Functies  
2.3 Werkingsmodi  
2.4 Beveiliging  
3 CONSTRUCTIE EN FUNCTIONELE EISEN VOOR CONTRO ­ 
LEAPPARATEN  
3.1 Controle op het inbrengen en uitnemen van kaarten  
3.2 Meting van snelheid, positie en afstand  
3.2.1 Meting van de afgelegde afstand  
3.2.2 Meting van de snelheid  
3.2.3 Bepalen van de positie  
3.3 Tijdmeting  
3.4 Controle op activiteiten van bestuurders  
3.5 Controle op de status van bestuurders  
3.6 Invoer door bestuurders  
3.6.1 Invoer van begin- en eindpunt van de dagelijkse werkperiode  
3.6.2 Manuele invoer van bestuurdersactiviteiten en toestemming van de 
bestuurder voor de ITS-interface  
3.6.3 Invoer van specifieke omstandigheden  
3.7 Beheer van bedrijfsvergrendelingen  
3.8 Bewaken van controleactiviteiten  
3.9 Opsporing van voorvallen en/of fouten  
3.9.1 „Inbrengen van een ongeldige kaart”  
3.9.2 „Kaartconflict”  
3.9.3 „Tijdsoverlapping”  
3.9.4 „Rijden zonder geschikte kaart”  
3.9.5 „Inbrengen van de kaart tijdens het rijden”  
3.9.6 „Laatste kaartsessie niet correct afgesloten”  
3.9.7 „Snelheidsoverschrijding”  
3.9.8 „Onderbreking van de stroomvoorziening”  
3.9.9 „Communicatiefout met het systeem voor communicatie op af ­ 
stand”  
3.9.10 „Ontbreken van plaatsbepalingsinformatie van de GNSS-ontvan ­ 
ger” ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 8  
3.9.11 „Fout in communicatie met de externe GNSS-module”  
3.9.12 „Fout in de bewegingsgegevens”  
3.9.13 „Tegenstrijdige bewegingsgegevens”  
3.9.14 „Poging tot inbreuk op de beveiliging”  
3.9.15 „Tijdsoverlapping”  
3.9.16 „Kaartfout”  
3.9.17 „Controleapparaatfout”  
3.10 Ingebouwde tests en zelftests  
3.11 Lezen van het geheugen  
3.12 Registratie en opslag in het geheugen  
3.12.1 Identificatiegegevens van de uitrusting  
3.12.1.1 Identificatiegegevens van de voertuigunit  
3.12.1.2 Identificatiegegevens van de bewegingssensor  
3.12.1.3 Identificatiegegevens GNSS-systemen  
3.12.2 Sleutels en certificaten  
3.12.3 Gegevens over het inbrengen en uitnemen van de bestuurders- of 
werkplaatskaart  
3.12.4 Gegevens over activiteiten van de bestuurder  
▼M1 
3.12.5 Plaatsen en posities waar de dagelijkse werktijd begint, eindigt 
en/of waar een cumulatieve rijtijd van 3 uur wordt bereikt  
▼B 
3.12.6 Gegevens over de kilometerstand  
3.12.7 Gedetailleerde snelheidsgegevens  
3.12.8 Gegevens over voorvallen  
3.12.9 Gegevens over fouten  
3.12.10 Kalibreringsgegevens  
3.12.11 Tijdafstellingsgegevens  
3.12.12 Gegevens over controleactiviteiten  
3.12.13 Gegevens over bedrijfsvergrendelingen  
3.12.14 Gegevens over overdrachtactiviteiten  
3.12.15 Gegevens over specifieke omstandigheden  
3.12.16 Gegevens tachograafkaart  
3.13 Lezen van de tachograafkaart  
3.14 Registratie en opslag op een tachograafkaart  
3.14.1 Registreren en opslaan op tachograafkaarten van de eerste generatie  
3.14.2 Registreren en opslaan op tachograafkaarten van de tweede gene ­ 
ratie 
3.15 Weergave  
3.15.1 Standaarddisplay  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 9  
3.15.2 Waarschuwingsdisplay  
3.15.3 Toegang tot het menu  
3.15.4 Overige displays  
3.16 Afdrukken  
3.17 Waarschuwingen  
3.18 Downloaden van gegevens met externe media  
3.19 Communicatie op afstand met het oog op gerichte wegcontroles  
3.20 Doorsturen van gegevens naar aanvullende externe apparaten  
3.21 Kalibrering  
3.22 Kalibreringscontrole langs de weg  
3.23 Tijdafstelling  
3.24 Prestatiekenmerken  
3.25 Materialen  
3.26 Opschriften  
4 FUNCTIONELE EN CONSTRUCTIE-EISEN VOOR TACHO ­ 
GRAAFKAARTEN  
4.1 Zichtbare gegevens  
4.2 Beveiliging  
4.3 Normen  
4.4 Milieu- en elektrotechnische specificaties  
4.5 Opslag van gegevens  
4.5.1 Hoofdbestanden voor identificatie en kaartbeheer  
4.5.2 IC-kaartidentificatie  
4.5.2.1 Chipidentificatie  
4.5.2.2 DIR (alleen aanwezig in tachograafkaarten van de tweede genera ­ 
tie) 
4.5.2.3 ATR-informatie (voorwaardelijk, alleen aanwezig in tachograaf ­ 
kaarten van de tweede generatie)  
4.5.2.4 Uitgebreide informatie (voorwaardelijk, alleen aanwezig in tacho ­ 
graafkaarten van de tweede generatie)  
4.5.3 Bestuurderskaart  
4.5.3.1 Tachograaftoepassingen (toegankelijk voor voertuigunits van de 
eerste en tweede generatie)  
4.5.3.1.1 Toepassingsidentificatie  
4.5.3.1.2 Sleutels en certificaten  
4.5.3.1.3 Identificatie van de kaart  
4.5.3.1.4 Identificatie van de kaarthouder  
4.5.3.1.5 Kaartgegevens downloaden  
4.5.3.1.6 Informatie over het rijbewijs  
4.5.3.1.7 Gegevens over voorvallen  
4.5.3.1.8 Gegevens over fouten  
4.5.3.1.9 Gegevens over de activiteiten van de bestuurder  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 10  
4.5.3.1.10 Gegevens over de gebruikte voertuigen  
4.5.3.1.11 Plaatsen waar dagelijkse werkperioden beginnen en/of eindigen  
4.5.3.1.12 Gegevens over kaartsessies  
4.5.3.1.13 Gegevens over controleactiviteiten  
4.5.3.1.14 Gegevens over specifieke omstandigheden  
4.5.3.2 Toepassing tachograaf van de 2de generatie (niet toegankelijk voor 
voertuigunits van de eerste generatie)  
4.5.3.2.1 Toepassingsidentificatie  
4.5.3.2.2 Sleutels en certificaten  
4.5.3.2.3 Identificatie van de kaart  
4.5.3.2.4 Identificatie van de kaarthouder  
4.5.3.2.5 Kaartgegevens downloaden  
4.5.3.2.6 Informatie over het rijbewijs  
4.5.3.2.7 Gegevens over voorvallen  
4.5.3.2.8 Gegevens over fouten  
4.5.3.2.9 Gegevens over de activiteiten van de bestuurder  
4.5.3.2.10 Gegevens over de gebruikte voertuigen  
4.5.3.2.11 Plaatsen en posities waar de dagelijkse werkperioden beginnen 
en/of eindigen  
4.5.3.2.12 Gegevens over kaartsessies  
4.5.3.2.13 Gegevens over controleactiviteiten  
4.5.3.2.14 Gegevens over specifieke omstandigheden  
4.5.3.2.15 Gegevens over de gebruikte voertuigunits  
▼M1 
4.5.3.2.16 Plaats en tijdstip cumulatieve rijtijd van drie uur  
▼B 
4.5.4 Werkplaatskaart  
4.5.4.1 Tachograaftoepassingen (toegankelijk voor voertuigunits van de 
eerste en tweede generatie)  
4.5.4.1.1 Toepassingsidentificatie  
4.5.4.1.2 Sleutels en certificaten  
4.5.4.1.3 Identificatie van de kaart  
4.5.4.1.4 Identificatie van de kaarthouder  
4.5.4.1.5 Kaartgegevens downloaden  
4.5.4.1.6 Gegevens over kalibrering en tijdafstelling  
4.5.4.1.7 Gegevens over voorvallen en fouten  
4.5.4.1.8 Gegevens over de activiteiten van de bestuurder  
4.5.4.1.9 Gegevens over de gebruikte voertuigen  
4.5.4.1.10 Gegevens over het begin en einde van dagelijkse werkperioden  
4.5.4.1.11 Gegevens over kaartsessies  
4.5.4.1.12 Gegevens over controleactiviteiten  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 11  
4.5.4.1.13 Gegevens over specifieke omstandigheden  
4.5.4.2 Toepassing tachograaf van de tweede generatie (niet toegankelijk 
voor voertuigunits van de eerste generatie)  
4.5.4.2.1 Toepassingsidentificatie  
4.5.4.2.2 Sleutels en certificaten  
4.5.4.2.3 Identificatie van de kaart  
4.5.4.2.4 Identificatie van de kaarthouder  
4.5.4.2.5 Kaartgegevens downloaden  
4.5.4.2.6 Gegevens over kalibrering en tijdafstelling  
4.5.4.2.7 Gegevens over voorvallen en fouten  
4.5.4.2.8 Gegevens over de activiteiten van de bestuurder  
4.5.4.2.9 Gegevens over de gebruikte voertuigen  
4.5.4.2.10 Gegevens over het begin en einde van dagelijkse werkperioden  
4.5.4.2.11 Gegevens over kaartsessies  
4.5.4.2.12 Gegevens over controleactiviteiten  
4.5.4.2.13 Gegevens over de gebruikte voertuigunits  
▼M1 
4.5.4.2.14 Plaats en tijdstip cumulatieve rijtijd van drie uur  
▼B 
4.5.4.2.15 Gegevens over specifieke omstandigheden  
4.5.5 Controlekaart  
4.5.5.1 Tachograaftoepassingen (toegankelijk voor voertuigunits van de 
eerste en tweede generatie)  
4.5.5.1.1 Toepassingsidentificatie  
4.5.5.1.2 Sleutels en certificaten  
4.5.5.1.3 Identificatie van de kaart  
4.5.5.1.4 Identificatie van de kaarthouder  
4.5.5.1.5 Gegevens over controleactiviteiten  
4.5.5.2 Tachograaftoepassingen van de tweede generatie (niet toegankelijk 
voor voertuigunits van de eerste generatie)  
4.5.5.2.1 Toepassingsidentificatie  
4.5.5.2.2 Sleutels en certificaten  
4.5.5.2.3 Identificatie van de kaart  
4.5.5.2.4 Identificatie van de kaarthouder  
4.5.5.2.5 Gegevens over controleactiviteiten  
4.5.6 Bedrijfskaart  
4.5.6.1 Tachograaftoepassingen (toegankelijk voor voertuigunits van de 
eerste en tweede generatie)  
4.5.6.1.1 Toepassingsidentificatie  
4.5.6.1.2 Sleutels en certificaten  
4.5.6.1.3 Identificatie van de kaart  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 12  
4.5.6.1.4 Identificatie van de kaarthouder  
4.5.6.1.5 Gegevens over bedrijfsactiviteiten  
4.5.6.2 Tachograaftoepassingen van de tweede generatie (niet toegankelijk 
voor voertuigunits van de eerste generatie)  
4.5.6.2.1 Toepassingsidentificatie  
4.5.6.2.2 Sleutels en certificaten  
4.5.6.2.3 Identificatie van de kaart  
4.5.6.2.4 Identificatie van de kaarthouder  
4.5.6.2.5 Gegevens over bedrijfsactiviteiten  
5 INSTALLATIE VAN HET CONTROLEAPPARAAT  
5.1 Installatie  
5.2 Installatieplaatje  
5.3 Verzegeling  
6 CONTROLES, INSPECTIES EN HERSTELLINGEN  
6.1 Erkenning van installateurs, werkplaatsen en voertuigfabrikanten  
▼M1 
6.2 Controle van nieuwe of herstelde onderdelen  
▼B 
6.3 Installatie-inspectie  
6.4 Periodieke controles  
6.5 Meting van afwijkingen  
6.6 Reparaties  
7 AFGIFTE VAN KAARTEN  
8 TYPEGOEDKEURING VAN CONTROLEAPPARATEN EN TA ­ 
CHOGRAAFKAARTEN  
8.1 Algemeen  
8.2 Veiligheidscertificaat  
8.3 Functiecertificaat  
8.4 Interoperabiliteitscertificaat  
8.5 Typegoedkeuringscertificaat  
8.6 Bijzondere procedure: eerste interoperabiliteitscertificaten voor con ­ 
troleapparaten en tachograafkaarten van de 2de generatie  
INLEIDING  
Digitale tachografen van de eerste generatie worden sinds 1 mei 2006 gebruikt. 
Zij mogen tot einde levensduur worden gebruikt voor binnenlands vervoer. Voor 
internationaal vervoer daarentegen, moeten alle voertuigen uiterlijk 15 jaar na de 
vankrachtwording van deze verordening van de Commissie uitgerust zijn met een 
slimme tachograaf van de tweede generatie als beschreven in deze verordening.  
In deze bijlagen worden de eisen beschreven voor controleapparaten en tacho ­
graafkaarten van de tweede generatie. Vanaf de introductiedatum wordt contro ­
leapparatuur van de tweede generatie geïnstalleerd in voertuigen die voor het 
eerst worden ingeschreven, en worden tachograafkaarten van de tweede generatie 
afgegeven.  
Om een vlotte introductie van de tachograaf van de tweede generatie te waar ­
borgen:  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 13  
— wordt er bij het ontwerp van de tachograafkaarten van de tweede generatie 
voor gezorgd dat ze ook in voertuigunits van de eerste generatie kunnen 
worden gebruikt;  
— zal het niet verplicht zijn geldige kaarten van de eerste generatie op de 
introductiedatum te vervangen.  
Hierdoor kunnen bestuurders hun unieke kaart behouden en deze in beide sys ­
temen gebruiken.  
Controleapparaten van de tweede generatie worden echter alleen gekalibreerd met 
behulp van werkplaatskaarten van de tweede generatie.  
In deze bijlage zijn alle eisen opgenomen in verband met de interoperabiliteit 
tussen de tachografen van de eerste en tweede generatie.  
In aanhangsel 15 is nauwkeurig beschreven hoe het naast elkaar bestaan van de 
twee systemen moet worden beheerd.  
Lijst van aanhangsels  
Aanhangsel 1: DATA DICTIONARY  
Aanhangsel 2: SPECIFICATIE VAN TACHOGRAAFKAARTEN  
Aanhangsel 3: PICTOGRAMMEN  
Aanhangsel 4: AFDRUKKEN  
Aanhangsel 5: DISPLAY  
Aanhangsel 6: FRONTCONNECTOR VOOR KALIBRERING EN 
DOWNLOADEN  
Aanhangsel 7: PROTOCOL VOOR GEGEVENSOVERDRACHT  
Aanhangsel 8: KALIBRERINGSPROTOCOL  
Aanhangsel 9: TYPEGOEDKEURING EN LIJST VAN MINIMAAL VER ­ 
EISTE TESTS  
Aanhangsel 10: BEVEILIGINGSVOORSCHRIFTEN  
Aanhangsel 11: ALGEMENE BEVEILIGINGSMECHANISMEN  
Aanhangsel 12: PLAATSBEPALING OP BASIS VAN WERELDWIJD SA ­ 
TELLIETNAVIGATIESYSTEEM (GNSS)  
Aanhangsel 13: ITS-INTERFACE  
Aanhangsel 14: FUNCTIE VOOR COMMUNICATIE OP AFSTAND  
Aanhangsel 15: MIGRATIE: DE COËXISTENTIE VAN VERSCHIL ­ 
LENDE GENERATIES APPARATUUR BEHEREN  
Aanhangsel 16: ADAPTER VOOR VOERTUIGEN VAN DE CATEGORIE 
M1 EN N1  
1 DEFINITIES  
In deze bijlage wordt verstaan onder:  
a) „activering”:  
de fase waarin de tachograaf volledig operationeel wordt en 
alle functies, inclusief de veiligheidsfuncties, uitvoert, met ge ­
bruikmaking van een werkplaatskaart;  
b) „authenticatie”:  
een functie om een opgegeven identiteit vast te stellen en te 
verifiëren;  
c) „authenticiteit”:  
de eigenschap dat informatie afkomstig is van een persoon 
wiens identiteit kan worden geverifieerd;  
d) „ingebouwd testsysteem (BIT)”:  
tests die op verzoek worden uitgevoerd en door de bestuurder 
of een externe inrichting worden gestart;  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 14  
e) „kalenderdag”:  
een dag van 00.00 uur tot en met 24.00 uur. Alle kalender ­
dagen worden uitgedrukt in UTC-tijd (gecoördineerde univer ­
sele tijd);  
f) „kalibrering” van een digitale tachograaf:  
het bijwerken of bevestigen van voertuigparameters die in het 
geheugen opgeslagen zijn. Voertuigparameters zijn onder an ­
dere voertuigidentificatie (VIN (voertuigidentificatienummer), 
kentekennummer en de lidstaat van registratie) en voertuigken ­
merken (w, k, l, bandenmaat, snelheidsbegrenzer (indien van 
toepassing), actuele UTC-tijd, actuele kilometerstand). Bij de 
kalibrering van een controleapparaat worden het type en de 
identificatiecodes van alle aanwezige verzegelingen die rele ­
vant zijn voor de typekeuring, opgeslagen in het geheugen.  
Het bijwerken of bevestigen van alleen de UTC-tijd wordt 
beschouwd als een tijdafstelling en niet als een kalibrering, 
op voorwaarde dat er geen tegenspraak is met voorschrift 409.  
Voor het kalibreren van een controleapparaat is een werk ­
plaatskaart nodig;  
g) „kaartnummer”:  
een nummer van 16 alfanumerieke tekens dat een tachograaf ­
kaart binnen een lidstaat op unieke wijze identificeert. Het 
kaartnummer omvat een opeenvolgende index van de kaart 
(indien van toepassing), een vervangingsindex van de kaart 
en een vernieuwingsindex van de kaart.  
Een kaart wordt dus op unieke wijze door de code van de 
lidstaat van afgifte en het kaartnummer geïdentificeerd;  
h) „opeenvolgende index van de kaart”:  
het 14e teken van een kaartnummer, dat wordt gebruikt om de 
verschillende kaarten te onderscheiden die zijn afgegeven aan 
een bedrijf, werkplaats of controle-instantie die meerdere ta ­
chograafkaarten mag bezitten. Het bedrijf, de werkplaats of de 
controle-instantie wordt op unieke wijze door de eerste 13 
tekens van het kaartnummer geïdentificeerd;  
i) „vernieuwingsindex van de kaart”:  
het 16e alfanumerieke teken van een kaartnummer, dat bij elke 
vernieuwing van een tachograafkaart verhoogd wordt;  
j) „vervangingsindex van de kaart”:  
het 15e alfanumerieke teken van een kaartnummer, dat bij elke 
vervanging van een tachograafkaart verhoogd wordt;  
k) „kenmerkende coëfficiënt van het voertuig”:  
het getal dat de waarde aangeeft van het uitgangssignaal dat 
door het onderdeel van het voertuig (secundaire as van de 
versnellingsbak of as) dat in verbinding staat met het contro ­
leapparaat, wordt verstuurd wanneer het voertuig een afstand 
van één kilometer heeft afgelegd, gemeten onder normale tes ­
tomstandigheden als gedefinieerd in voorschrift nr. 414. De 
kenmerkende coëfficiënt wordt uitgedrukt in impulsen per ki ­
lometer (w = … imp/km);  
l) „bedrijfskaart”:  
een tachograafkaart die door de autoriteiten van een lidstaat is 
afgegeven aan een vervoersonderneming welke met tachogra ­
fen uitgeruste voertuigen moet gebruiken, die de vervoers ­
onderneming identificeert en waarmee de in de tachografen 
opgeslagen gegevens, die door de vervoersonderneming zijn 
versleuteld, kunnen worden weergegeven, gedownload en af ­
gedrukt;  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 15  
m) „constante van het controleapparaat”:  
het getal dat de waarde aangeeft van het ingangssignaal dat 
nodig is ter aanwijzing en registratie van een afgelegde afstand 
van één kilometer; deze constante moet in impulsen per kilo ­
meter (k = … imp/km) worden uitgedrukt;  
n) de „rijtijd” wordt in het controleapparaat berekend als (  1 ): 
de op dat moment cumulatieve rijtijd van een individuele be ­
stuurder afzonderlijk sinds het verstrijken van zijn laatste BE ­
SCHIKBAARHEID, RUSTPAUZE of ONBEKENDE (  2 ) peri­
ode van 45 minuten of meer (deze periode kan worden opge ­
deeld overeenkomstig Verordening (EG) nr. 561/2006 van het 
Europees Parlement en de Raad (  3 )). De betreffende bereke ­
ningen houden, indien nodig, rekening met eerdere op de be ­
stuurderskaart opgeslagen activiteiten. Wanneer de bestuurder 
zijn kaart niet heeft ingebracht, zijn de betreffende berekenin ­
gen gebaseerd op de geheugenrecords voor de lopende periode 
waarin geen kaart ingebracht was, en met betrekking tot de 
relevante lezer;  
o) „controlekaart”:  
een door de autoriteiten van een lidstaat aan een nationale 
bevoegde controle-instantie afgegeven tachograafkaart die de 
controle-instanties en, eventueel, de controleambtenaar identi ­
ficeert en die toegang verschaft tot de in het geheugen, op de 
bestuurderskaart en, eventueel, op de werkplaatskaart opgesla ­
gen gegevens om deze te lezen, af te drukken en/of te downlo ­
aden.  
Deze kaart dient ook toegang te verschaffen tot de functie voor 
kalibreringscontroles langs de weg en de gegevens op het 
leestoestel voor berichten voor vroegtijdige detectie op afstand;  
p) „cumulatieve rusttijd” wordt in het controleapparaat berekend 
als (  1 ): 
de cumulatieve onderbreking van de rijtijd wordt berekend als 
de op dat moment verzamelde BESCHIKBAARHEIDS-, 
RUSTPAUZE- of ONBEKENDE (  2 ) perioden van 15 minuten 
of meer van elke bestuurder afzonderlijk sinds zijn laatste 
BESCHIKBAARHEIDS-, RUSTPAUZE- of ONBEKEN ­
DE (  3 ) periode van 45 minuten of meer (deze periode kan 
worden opgedeeld overeenkomstig Verordening (EG) nr. 
561/2006).  
De betreffende berekeningen houden, indien nodig, rekening 
met eerdere op de bestuurderskaart opgeslagen activiteiten. Bij 
de berekening wordt geen rekening gehouden met onbekende 
periodes van negatieve duur (begin van een onbekende periode 
> einde van een onbekende periode) ten gevolge van tijds ­
overlapping tussen twee verschillende controleapparaten.  ▼B 
( 1 ) Door deze berekeningswijze van de rijtijd en de cumulatieve rusttijd kan het controleap ­
paraat de rijtijdwaarschuwing berekenen. Hiermee wordt niet vooruitgelopen op de wet ­
telijke interpretatie van deze tijden. Alternatieve manieren voor het berekenen van de 
rijtijd en de cumulatieve rusttijd kunnen worden gebruikt ter vervanging van deze defi ­
nities, indien deze voorbijgestreefd zijn door andere bijgewerkte wetgeving. 
( 2 ) ONBEKENDE periodes komen overeen met periodes waarin de bestuurderskaart niet in 
het controleapparaat ingebracht was en activiteiten van de bestuurder niet manueel zijn 
ingevoerd. 
( 3 ) Verordening (EG) nr. 561/2006 van het Europees Parlement en de Raad van 15 maart 
2006 tot harmonisatie van bepaalde voorschriften van sociale aard voor het wegvervoer, 
tot wijziging van Verordeningen (EEG) nr. 3821/85 en (EG) nr. 2135/98 van de Raad en 
tot intrekking van Verordening (EEG) nr. 3820/85 van de Raad (PB L 102 van 
11.4.2006, blz. 1).
 02016R0799 — NL — 26.02.2020 — 002.001 — 16  
Wanneer de bestuurder zijn kaart niet heeft ingebracht, zijn de 
betreffende berekeningen gebaseerd op de geheugenrecords 
voor de lopende periode waarin geen kaart was ingebracht, 
en voor de relevante lezer;  
q) „geheugen”:  
een elektronisch geheugenmedium dat is ingebouwd in het 
controleapparaat;  
r) „digitale handtekening”:  
gegevens toegevoegd aan, of een cryptografische transformatie 
van, een gegevensblok waarmee de ontvanger van die gege ­
vens de authenticiteit en integriteit van de gegevens kan ve ­
rifiëren;  
s) „downloaden”:  
het kopiëren, samen met een digitale handtekening, van (een 
gedeelte van) de gegevensbestanden die in het geheugen van 
de voertuigunit of in het geheugen van de tachograafkaart zijn 
geregistreerd, op voorwaarde dat dit proces geen opgeslagen 
gegevens wijzigt of vernietigt.  
Fabrikanten van slimme tachografen voor voertuigen en fabri ­
kanten van apparatuur die is ontworpen en bedoeld om gege ­
vens te downloaden, moeten alle maatregelen nemen die rede ­
lijkerwijs haalbaar zijn om ervoor te zorgen dat die gegevens 
met minimale vertraging door vervoersondernemingen of be ­
stuurders kunnen worden gedownload.  
Het downloaden van gedetailleerde snelheidsgegevens is niet 
per definitie nodig om te voldoen aan Verordening (EG) nr. 
561/2006, maar kan worden gebruikt voor andere doeleinden, 
zoals het onderzoeken van ongevallen;  
t) „bestuurderskaart”:  
een door de autoriteiten van een lidstaat aan elke bestuurder 
afzonderlijk afgegeven tachograafkaart die de bestuurder iden ­
tificeert en de activiteiten van de bestuurder registreert;  
u) „effectieve omtrek van de wielen”:  
gemiddelde afstand, afgelegd door elk van de wielen die het 
voertuig aandrijven, (aandrijfwielen) bij een volledige omwen ­
teling. Het meten van deze afstanden moet gebeuren onder 
normale testomstandigheden als gedefinieerd in voorschrift 
nr. 414 en wordt als volgt uitgedrukt: „l = … mm”. Voer ­
tuigfabrikanten kunnen het meten van deze afstanden vervan ­
gen door een theoretische berekening waarbij wordt uitgegaan 
van de verdeling van het gewicht over de assen van een on ­
geladen voertuig in normale rijklare toestand (  1 ). De methode 
voor die theoretische berekening moet worden goedgekeurd 
door de bevoegde instantie van de lidstaat en dat moet gebeu ­
ren voor de tachograaf in werking wordt gesteld;  
v) „voorval”:  
een door de slimme tachograaf gedetecteerd abnormaal func ­
tioneren dat mogelijk het gevolg is van een poging tot fraude;  
w) „externe GNSS-module”:  
wanneer een voertuigunit uit verschillende onderdelen bestaat, 
de voorziening met de GNSS-ontvanger en de andere onder ­
delen die nodig zijn om de overdracht van positiegegevens 
naar de rest van de voertuigunit te beveiligen;  ▼B 
( 1 ) Verordening (EU) nr. 1230/2012 van de Commissie van 12 december 2012 tot uitvoering 
van Verordening (EG) nr. 661/2009 van het Europees Parlement en de Raad wat de 
typegoedkeuringsvoorschriften voor massa's en afmetingen van motorvoertuigen en aan ­
hangwagens daarvan betreft en tot wijziging van Richtlijn 2007/46/EG van het Europees 
Parlement en de Raad (PB L 353 van 21.12.2012, blz. 31), als laatstelijk gewijzigd.
 02016R0799 — NL — 26.02.2020 — 002.001 — 17  
x) „fout”:  
een door de slimme tachograaf ontdekt abnormaal functioneren 
dat mogelijk het gevolg is van een slechte werking van of 
storing in het apparaat;  
y) „GNSS-ontvanger”:  
een elektronisch apparaat dat signalen van een of meer mon ­
diale satellietnavigatiesystemen (in het Engels: GNSS) ont ­
vangt en digitaal verwerkt om de positie-, snelheids- en tijds ­
informatie te verstrekken;  
z) „installatie”:  
de installatie van de tachograaf in een voertuig;  
aa) „interoperabiliteit”:  
het vermogen van systemen en van de daaraan ten grondslag 
liggende bedrijfsprocessen om onderling gegevens uit te wis ­
selen en informatie te delen;  
bb) „interface”:  
een voorziening tussen systemen die de communicatiemidde ­
len verschaft waardoor deze systemen aan elkaar kunnen wor ­
den gekoppeld en onderling kunnen communiceren;  
cc) „positie”:  
geografische coördinaten van een voertuig op een bepaald tijd ­
stip; 
dd) „bewegingssensor”:  
deel van de tachograaf dat een signaal geeft betreffende de 
snelheid van het voertuig en/of de afgelegde afstand;  
ee) „ongeldige kaart”:  
een kaart die ongeldig is of waarvan de eerste authenticatie 
mislukt is, of waarvan de geldigheidstermijn nog niet begon ­
nen is of reeds verstreken is;  
ff) „open norm”:  
een norm vastgelegd in een normspecificatiedocument, gratis 
of tegen geringe kosten verkrijgbaar, die gratis of voor een 
gering bedrag gekopieerd, verspreid en gebruikt mag worden;  
gg) „niet verplicht”:  
gevallen waarin het gebruik van het controleapparaat volgens 
de bepalingen van Verordening (EG) nr. 561/2006 niet vereist 
is; 
hh) „snelheidsoverschrijding”:  
overschrijding van de toegestane maximumsnelheid van het 
voertuig, omschreven als een periode van meer dan 60 secon ­
den waarin de gemeten snelheid van het voertuig hoger ligt 
dan de maximumsnelheid waarop de snelheidsbegrenzer is af ­
gesteld, zoals vastgelegd in Richtlijn 92/6/EEG van de 
Raad (  1 ), als laatstelijk gewijzigd;  
ii) „periodieke controle”:  
een reeks verrichtingen die wordt uitgevoerd om te controleren 
of de tachograaf goed werkt en of de instellingen overeen ­
komen met de voertuigparameters en of er geen manipulatie ­
apparatuur aan de tachograaf is bevestigd;  ▼B 
( 1 ) Richtlijn 92/6/EEG van de Raad van 10 februari 1992 betreffende de installatie en het 
gebruik, in de Gemeenschap, van snelheidsbegrenzers in bepaalde categorieën motor ­
voertuigen (PB L 57 van 2.3.1992, blz. 27).
 02016R0799 — NL — 26.02.2020 — 002.001 — 18  
jj) „printer”:  
deel van het controleapparaat dat opgeslagen gegevens afdrukt;  
kk) „vroegtijdige detectie op afstand”:  
tijdens gerichte wegcontroles de communicatie tussen het sys ­
teem voor vroegtijdige detectie op afstand en het leestoestel 
voor berichten voor vroegtijdige detectie op afstand om op 
afstand mogelijke gevallen van manipulatie van of fraude 
met controleapparaten te kunnen detecteren;  
▼M1 
ll) „systeem voor communicatie op afstand” of „systeem voor 
vroegtijdige detectie”:  
de uitrusting van de voertuigunit die wordt gebruikt voor de 
uitvoering van gerichte wegcontroles;  
▼B 
mm) „leestoestel voor berichten voor de vroegtijdige detectie op 
afstand”:  
het systeem dat door controleambtenaren voor gerichte weg ­
controles wordt gebruikt;  
nn) „vernieuwing”:  
afgifte van een nieuwe tachograafkaart wanneer een bestaande 
kaart verlopen of defect is en teruggestuurd is naar de autori ­
teit van afgifte. Vernieuwing geeft altijd de zekerheid dat er 
geen twee geldige kaarten tegelijk in omloop zijn;  
oo) „reparatie”:  
reparatie van een bewegingssensor, een voertuigunit of een 
kabel waarvoor de stroomvoorziening moet worden losgekop ­
peld, de tachograaf moet worden losgekoppeld van andere 
onderdelen of de bewegingssensor of voertuigunit moet wor ­
den geopend;  
pp) „vervanging van de kaart”:  
afgifte van een tachograafkaart ter vervanging van een be ­
staande kaart, die als verloren, gestolen of defect gemeld is 
en die niet teruggestuurd is naar de autoriteit van afgifte. Bij 
vervanging bestaat altijd het risico dat er twee geldige kaarten 
in omloop zijn;  
qq) „veiligheidscertificering”:  
proces ter certificering, door een gemeenschappelijke certifice ­
ringsinstantie, dat het onderzochte controleapparaat (of een 
onderdeel daarvan) of de tachograafkaart voldoet aan de in 
de toepasselijke beveiligingsprofielen gedefinieerde veilig ­
heidseisen;  
rr) „zelftest”:  
tests die het controleapparaat periodiek en automatisch uitvoert 
om fouten te ontdekken;  
ss) „tijdmeting”:  
een permanente digitale registratie van de gecoördineerde uni ­
versele datum en tijdstip (UTC);  
▼M1 
tt) „tijdsafstelling”:  
een afstelling van de lopende tijd; deze afstelling kan automa ­
tische gebeuren met geregelde tussenpozen, waarbij de door de 
GNSS-ontvanger verstrekte tijd als referentie wordt gebruikt, 
of kan tijdens een kalibrering worden uitgevoerd;  
▼B 
uu) „bandenmaat”:  
de omschrijving van de afmetingen van de banden (externe 
aandrijfwielen) overeenkomstig Richtlijn 92/23/EEG van de 
Raad (  1 ), als laatstelijk gewijzigd;  ▼B 
( 1 ) Richtlijn 92/23/EEG van de Raad van 31 maart 1992 betreffende banden voor motor ­
voertuigen en aanhangwagens daarvan alsmede betreffende de montage ervan (PB L 129 
van 14.5.1992, blz. 95).
 02016R0799 — NL — 26.02.2020 — 002.001 — 19  
vv) „voertuigidentificatie”:  
nummers die het voertuig identificeren: het kentekennummer 
van het voertuig met een indicatie van de lidstaat van regis ­
tratie en het voertuigidentificatienummer (VIN) (  1 ); 
ww) voor de berekening in het controleapparaat betekent „week”:  
het tijdvak tussen maandag 00.00 uur UTC-tijd en zondag 
24.00 uur UTC-tijd;  
xx) „werkplaatskaart”:  
een tachograafkaart, afgegeven door de autoriteiten van een 
lidstaat aan door die lidstaat erkende aangewezen personeels ­
leden van een fabrikant van tachografen, installateur, voertuig ­
fabrikant of werkplaats, die de kaarthouder identificeert en 
waarmee tachografen kunnen worden getest, gekalibreerd en 
geactiveerd en/of waarmee gegevens kunnen worden ge ­
download;  
yy) „adapter”:  
een apparaat dat een signaal afgeeft dat permanent representa ­
tief is voor de snelheid van het voertuig en/of de afgelegde 
afstand, dat verschilt van het signaal dat voor de onafhanke ­
lijke bewegingsdetectie wordt gebruikt en dat:  
▼M1 
— alleen in voertuigen van het type M1 en N1 wordt geïnstal ­
leerd en gebruikt (als gedefinieerd in bijlage II bij Richtlijn 
2007/46/EG van het Europees Parlement en de Raad (  2 ), 
als laatstelijk gewijzigd);  
▼B 
— geïnstalleerd is wanneer het mechanisch niet mogelijk is 
een ander bestaand type bewegingssensor te installeren dat 
verenigbaar is met de bepalingen van deze bijlage en de 
aanhangsels 1 tot en met 15 daarvan;  
— geïnstalleerd is tussen de voertuigunit en de plaats waar de 
snelheids-/afstandsimpulsen worden voortgebracht door 
geïntegreerde sensoren of alternatieve interfaces;  
— gezien vanuit het standpunt van een voertuigunit, hetzelfde 
gedrag vertoont als dat van een bewegingssensor die vol ­
doet aan de voorschriften van deze bijlagen en van aan ­
hangsels 1 t.e.m. 16 en die wordt aangesloten op de voer ­
tuigunit.  
Door in de bovenvermelde voertuigen een dergelijke adapter te 
gebruiken, kan een voertuigunit worden gebruikt en geïnstal ­
leerd die aan alle voorschriften van deze bijlage voldoet.  
Voor die voertuigen bestaat de slimme tachograaf uit kabels, 
een adapter en een voertuigunit;  ▼B 
( 1 ) Richtlijn 76/114/EEG van de Raad van 18 december 1975 betreffende de onderlinge 
aanpassing van de wetgevingen der Lid-Staten inzake de voorgeschreven platen en 
gegevens, en de plaats en wijze waarop zij op motorvoertuigen en aanhangwagens daar ­
van moeten worden aangebracht (PB L 24 van 30.1.1976, blz. 1). 
( 2 ) Richtlijn 2007/46/EG van het Europees Parlement en de Raad van 5 september 2007 tot 
vaststelling van een kader voor de goedkeuring van motorvoertuigen en aanhangwagens 
daarvan en van systemen, onderdelen en technische eenheden die voor dergelijke voer ­
tuigen zijn bestemd (Kaderrichtlijn) (PB L 263 van 9.10.2007, blz. 1).
 02016R0799 — NL — 26.02.2020 — 002.001 — 20  
zz) „integriteit van gegevens”:  
de nauwkeurigheid en coherentie van opgeslagen gegevens, 
aangetoond door het ontbreken van wijzigingen van de gege ­
vens tussen twee updates van een gegevensbestand. Integriteit 
betekent dat de gegevens een exacte kopie zijn van de origi ­
nele versie, d.w.z. dat ze niet beschadigd zijn tijdens het 
schrijven op en aflezen van een tachograafkaart of specifieke 
apparatuur, of tijdens de overdracht via een communicatieka ­
naal;  
aaa) „gegevensprivacy”:  
de algemene technische maatregelen die worden genomen voor 
de correcte toepassing van de beginselen die zijn vastgesteld 
bij Richtlijn 95/46/EG van het Europees Parlement en de 
Raad (  1 ) en bij Richtlijn 2002/58/EG van het Europees Parle ­
ment en de Raad (  2 ); 
bbb) „slimme tachograaf”:  
het controleapparaat, de tachograafkaart en alle uitrusting 
waarmee tijdens de constructie, de installatie, het gebruik, 
het testen en de controle, directe of indirecte interactie bestaat, 
zoals kaarten, leestoestellen voor berichten voor vroegtijdige 
detectie op afstand en andere apparatuur voor het downloaden 
van gegevens, de analyse van gegevens, kalibrering, het gene ­
reren, beheren en invoeren van beveiligingselementen enz.;  
ccc) „datum van invoering”:  
36 maanden na de inwerkingtreding van de gedetailleerde be ­
palingen als bedoeld in artikel 11 van Verordening (EU) nr. 
165/2014 van het Europees Parlement en de Raad (  3 ). 
Dit is de datum waarna voertuigen die voor het eerst zijn 
ingeschreven:  
— worden uitgerust met een tachograaf die verbonden is met 
een plaatsbepalingsdienst op basis van satellietnavigatie;  
— tijdens het rijden gegevens kunnen doorsturen naar de 
controle-instanties met het oog op gerichte wegcontroles;  
— en kunnen worden uitgerust met gestandaardiseerde inter ­
faces die ervoor zorgen dat een extern apparaat gebruik 
kan maken van de door tachografen voor operationeel 
gebruik geregistreerde of gegenereerde gegevens;  
ddd) „beveiligingsprofiel”:  
een document dat wordt gebruik als onderdeel van het certifi ­
ceringsproces op basis van gemeenschappelijke criteria, met 
toepassingsonafhankelijke beveiligingseisen op het gebied 
van informatieborging;  ▼B 
( 1 ) Richtlijn 95/46/EG van het Europees Parlement en de Raad van 24 oktober 1995 be ­
treffende de bescherming van natuurlijke personen in verband met de verwerking van 
persoonsgegevens en betreffende het vrije verkeer van die gegevens (PB L 281 van 
23.11.1995, blz. 31). 
( 2 ) Richtlĳn 2002/58/EG van het Europees Parlement en de Raad van 12 juli 2002 betref ­
fende de verwerking van persoonsgegevens en de bescherming van de persoonl ĳke 
levenssfeer in de sector elektronische communicatie (richtl ĳn betreffende privacy en 
elektronische communicatie) (PB L 201 van 31.7.2002, blz. 37). 
( 3 ) Verordening (EU) nr. 165/2014 van het Europees Parlement en van de Raad van 4 fe ­
bruari 2014 betreffende tachografen in het wegvervoer, tot intrekking van Verordening 
(EEG) nr. 3821/85 van de Raad betreffende het controleapparaat in het wegvervoer en tot 
wijziging van Verordening (EG) nr. 561/2006 van het Europees Parlement en de Raad 
tot harmonisatie van bepaalde voorschriften van sociale aard voor het wegvervoer 
(PB L 60 van 28.2.2014, blz. 1).
 02016R0799 — NL — 26.02.2020 — 002.001 — 21  
eee) „GNSS-nauwkeurigheid”:  
in het kader van de registratie van de positie met de tachograaf 
met behulp van de GNSS-module: de HDOP (horizontal dilu ­
tion of precision) berekend als het minimum van de via de 
beschikbare GNSS-module verzamelde HDOP-waarden;  
▼M1 
fff) „cumulatieve rijtijd”:  
een waarde die overeenkomst met het totale gecumuleerde 
aantal minuten dat met een bepaald voertuig is gereden.  
De cumulatieve rijtijd is een optelling van alle minuten die als 
RIJDEN worden beschouwd door de functie bewaken van de 
rijactviteiten van het controleapparaat, en wordt alleen gebruikt 
om het startsein te geven voor de registratie van de positie van 
het voertuig telkens wanneer een veelvoud van drie uur cumu ­
latieve rijtijd wordt bereikt. De optelling gaat van start op het 
ogenblik dat het controleapparaat wordt geactiveerd. Ze wordt 
niet beïnvloed door een andere toestand, zoals „niet verplicht” 
of „vervoer per veerboot/trein”.  
De waarde van de cumulatieve rijtijd is niet bestemd om te 
worden getoond, geprint of gedownload.  
▼B 
2 ALGEMENE KENMERKEN EN FUNCTIES VAN HET CON ­
TROLEAPPARAAT  
2.1 Algemene kenmerken  
Het controleapparaat moet gegevens betreffende de activiteiten van 
de bestuurder kunnen registreren, opslaan, weergeven, afdrukken en 
uitvoeren.  
Alle met een controleapparaat uitgeruste voertuigen die aan de be ­
palingen van deze bijlage voldoen, moeten voorzien zijn van een 
snelheidsdisplay en een kilometerteller. Deze functies kunnen in het 
controleapparaat worden opgenomen.  
01) Het controleapparaat bestaat uit kabels, een bewegingssen ­
sor en een voertuigunit.  
02) De interface tussen de bewegingssensoren en de voertuig ­
units moet voldoen aan de eisen van aanhangsel 11.  
03) De voertuigunit wordt overeenkomstig de specificaties in 
aanhangsel 12 aangesloten op een GNSS-systeem.  
04) De voertuigunit communiceert met leestoestellen voor be ­
richten voor vroegtijdige detectie op afstand overeenkom ­
stig de specificaties in aanhangsel 14.  
05) De voertuigunit kan een ITS-interface omvatten, als gespe ­
cificeerd in aanhangsel 13.  
Het controleapparaat mag door middel van een extra in ­
terface en/of de optionele ITS-interface op andere syste ­
men worden aangesloten.  
06) Elke integratie of verbinding van een al of niet goedge ­
keurde functie, inrichting of inrichtingen, in c.q. met het 
controleapparaat, mag de juiste en veilige werking van het 
controleapparaat niet schaden of kunnen schaden en mag 
niet in strijd zijn met de bepalingen van deze verordening.  
Gebruikers van controleapparaten identificeren zich door 
middel van een tachograafkaart.  
07) Het controleapparaat geeft selectieve toegangsrechten tot 
gegevens en functies overeenkomstig het type en/of de 
identiteit van de gebruiker.  
Het controleapparaat registreert gegevens en slaat deze op in het 
geheugen, in het systeem voor communicatie op afstand en op de 
tachograafkaart.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 22  
Dit gebeurt met inachtneming van Richtlijn 95/46/EG van 24 oktober 
1995 betreffende de bescherming van natuurlijke personen in ver ­
band met de verwerking van persoonsgegevens en betreffende het 
vrije verkeer van die gegevens (  1 ), Richtlijn 2002/58/EG betreffende 
de verwerking van persoonsgegevens en de bescherming van de 
persoonlijke levenssfeer in de sector elektronische communicatie (  2 ) 
en artikel 7 van Verordening (EU) nr. 165/2014.  
2.2 Functies  
08) Het controleapparaat moet onderstaande functies kunnen 
uitvoeren:  
— bewaken van het invoeren en uitnemen van de kaart,  
— meten van de snelheid, afstand en positie,  
— opnemen van de tijd,  
— bewaken van de activiteiten van de bestuurder,  
— bewaken van de status van de bestuurders,  
— manuele invoer door de bestuurders:  
— invoer van gegevens over het begin- en/of eindpunt 
van de dagelijkse werkperiode,  
— manuele invoer van de activiteiten van de bestuur ­
der, 
— invoer van specifieke omstandigheden,  
— beheer van bedrijfsvergrendelingen,  
— bewaken van controleactiviteiten,  
— detecteren van voorvallen en/of fouten,  
— ingebouwde tests en zelftests.  
— lezen van het geheugen,  
— registreren en opslaan in het geheugen,  
— lezen van de tachograafkaart,  
— registreren en opslaan op de tachograafkaart,  
— weergeven op scherm,  
— afdrukken,  
— waarschuwen,  
— gegevens downloaden met externe media,  
— communicatie op afstand met het oog op gerichte weg ­
controles,  
— gegevensoutput naar aanvullende systemen,  
— kalibrering,  
— kalibreringscontrole langs de weg,  
— tijdafstelling.  
2.3 Werkingsmodi  
09) Het controleapparaat heeft vier werkingsmodi:  
— operationele modus,  
— controlemodus,  
— kalibreringsmodus,  
— bedrijfsmodus.  
10) Het controleapparaat wisselt naar de volgende werkings ­
modus overeenkomstig de geldige tachograafkaart die in 
de kaartinterface ingebracht is. De generatie van de tacho ­
graafkaart is niet relevant om de werkingsmodus te bepa ­
len, voor zover het om een geldige kaart gaat. Een werk ­
plaatskaart van de eerste generatie wordt als ongeldig be ­
schouwd wanneer ze in een voertuigunit van de tweede 
generatie wordt ingevoerd.  ▼B 
( 1 ) PB L 281 van 23.11.1995, blz. 31. 
( 2 ) PB L 201 van 31.7.2002, blz. 37.
 02016R0799 — NL — 26.02.2020 — 002.001 — 23  
Werkingsmodus  Kaartlezer bestuurder  
Geen kaart  Bestuurderskaart  Controlekaart  Werkplaatskaart  Bedrijfskaart
 Kaartlezer bijrijder Geen kaart  Operationeel  Operationeel  Controle  Kalibrering  Bedrijfsmodus  
Bestuurders ­
kaart  Operationeel  Operationeel  Controle  Kalibrering  Bedrijfsmodus  
Controlekaart  Controle  Controle  Controle (*)  Operationeel  Operationeel  
Werkplaats ­
kaart  Kalibrering  Kalibrering  Operationeel  Kalibrering (*)  Operationeel  
Bedrijfskaart  Bedrijfsmodus  Bedrijfsmodus  Operationeel  Operationeel  Bedrijfsmo ­
dus (*)  
(*) in deze gevallen gebruikt het controleapparaat alleen de in lezer van de bestuurder ingevoerde tachograafkaart.  
11) Het controleapparaat negeert ongeldige ingebrachte kaar ­
ten. Het blijft echter mogelijk om gegevens op ongeldige 
kaarten weer te geven, af te drukken of te downloaden.  
12) Alle in 2.2 genoemde functies werken in iedere werkings ­
modus met de onderstaande uitzonderingen:  
— de kalibreringsfunctie is alleen toegankelijk in de kali ­
breringsmodus,  
— de kalibreringscontrole langs de weg is alleen toegan ­
kelijk in de controlemodus,  
— de beheersfunctie van bedrijfsvergrendelingen is alleen 
toegankelijk in de bedrijfsmodus,  
— het bewaken van controleactiviteiten werkt alleen in de 
controlemodus,  
— de downloadfunctie is niet beschikbaar in de operatio ­
nele modus (behalve zoals bepaald in voorschrift 193), 
en behalve bij het downloaden van een bestuurders ­
kaart wanneer er geen ander type kaart in de voertuig ­
unit is ingevoerd.  
13) Het controleapparaat kan gegevens uitvoeren naar een dis ­
play, printer of externe interfaces met de onderstaande 
uitzonderingen:  
— in de operationele modus: persoonsidentificatie (naam 
en voornaam(namen)) die niet overeenkomt met een 
ingebrachte tachograafkaart, wordt niet getoond en 
een kaartnummer dat niet overeenkomt met een in ­
gebrachte tachograafkaart wordt slechts gedeeltelijk ge ­
toond (alle oneven tekens — gelezen van links naar 
rechts — worden niet getoond);  
— in bedrijfsmodus: gegevens over de bestuurder (voor ­
schriften 102, 105 en 108) kunnen alleen worden uit ­
gevoerd tijdens perioden waarvoor geen vergrendeling 
aanwezig is of die niet door een ander bedrijf zijn 
vergrendeld (zoals geïdentificeerd door de eerste 13 
cijfers van het bedrijfskaartnummer),  
— wanneer geen kaart in het controleapparaat ingebracht 
is: kunnen gegevens over de bestuurder alleen worden 
uitgevoerd voor de huidige en de 8 voorafgaande ka ­
lenderdagen,  
— persoonsgegevens van de VU worden slechts via de 
ITS-interface van de VU doorgegeven na controle 
van de instemming door de bestuurder waarop de ge ­
gevens betrekking hebben;  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 24  
— de normale operationele geldigheidsperiode bedraagt 
15 jaar, beginnend op de ingangsdatum van de VU- 
certificaten; na die periode kunnen ze nog 3 maanden 
worden gebruikt, maar alleen om gegevens te downlo ­
aden.  
▼B 
2.4 Beveiliging  
▼M1 
De systeembeveiliging beoogt het geheugen zodanig te beveiligen 
dat niet-geautoriseerde toegang tot en manipulatie van de gegevens 
wordt voorkomen en dat pogingen daartoe worden ontdekt, alsmede 
ter beveiliging van de integriteit en authenticiteit van de tussen de 
bewegingssensor en de voertuigunit uitgewisselde gegevens, van de 
integriteit en authenticiteit van de tussen het controleapparaat en de 
tachograafkaart uitgewisselde gegevens, van de integriteit en authen ­
ticiteit van de tussen de voertuigunit en de eventuele externe GNSS- 
module uitgewisselde gegevens, van de vertrouwelijkheid, integriteit 
en authenticiteit van de via vroegtijdige detectie op afstand uitge ­
wisselde gegevens en ter verificatie van gedownloade gegevens.  
▼B 
14) Om de veiligheid van het systeem te waarborgen, moeten 
de volgende onderdelen voldoen aan de veiligheidseisen 
die zijn vastgelegd in de beveiligingsprofielen overeen ­
komstig de eisen van aanhangsel 10.  
— voertuigunit;  
— tachograafkaart;  
— bewegingssensor,  
— externe GNSS-module (dit profiel is alleen vereist en 
van toepassing voor de externe GNSS-variant).  
3 CONSTRUCTIE EN FUNCTIONELE EISEN VOOR CONTRO ­
LEAPPARATEN  
3.1 Controle op het inbrengen en uitnemen van kaarten  
15) Het controleapparaat bewaakt de kaartinterfaces om het 
inbrengen en uitnemen van kaarten te detecteren.  
16) Bij het inbrengen van de kaart moet het controleapparaat 
bepalen of de ingebrachte kaart geldig is. Indien dit het 
geval is, wordt het kaarttype en de generatie van de kaart 
geïdentificeerd.  
Wanneer er voordien reeds een kaart met hetzelfde kaart ­
nummer en een hogere vernieuwingsindex in het contro ­
leapparaat is ingevoerd, wordt de kaart ongeldig verklaard.  
Wanneer er voordien reeds een kaart met hetzelfde kaart ­
nummer en dezelfde vernieuwingsindex, maar een hogere 
vervangingsindex in het controleapparaat is ingevoerd, 
wordt de kaart ongeldig verklaard.  
17) Nadat een werkplaats de mogelijkheid om tachograafkaar ­
ten van de eerste generatie te gebruiken heeft opgeheven 
overeenkomstig aanhangsel 15 (voorschrift MIG003) wor ­
den tachograafkaarten van de eerste generatie door het 
controleapparaat als ongeldig beschouwd.  
18) Werkplaatskaarten van de eerste generatie die in contro ­
leapparaten van de tweede generatie worden ingevoerd, 
worden als ongeldig beschouwd.  ▼M1
 02016R0799 — NL — 26.02.2020 — 002.001 — 25  
19) Het controleapparaat wordt zodanig geconstrueerd dat de 
tachograafkaart bij juiste invoer in de kaartinterface ver ­
grendeld wordt.  
20) De tachograafkaart kan alleen worden uitgenomen wan ­
neer het voertuig stilstaat en nadat de relevante gegevens 
op de kaart zijn opgeslagen. Het uitnemen van de kaart 
vereist een doelgerichte handeling van de gebruiker.  
3.2 Meting van snelheid, positie en afstand  
21) De bewegingssensor (desgevallend geïntegreerd in de 
adapter) is de belangrijkste bron voor de meting van de 
snelheid en afstand.  
22) Aan de hand van de door de bewegingssensor uitgestuurde 
pulsen, meet deze functie continu de kilometerstand die 
overeenkomt met de totale door het voertuig afgelegde 
afstand en kan ze deze weergeven.  
23) Aan de hand van de door de bewegingssensor uitgestuurde 
pulsen, meet deze functie continu de snelheid van het 
voertuig en kan ze deze weergeven.  
24) De snelheidsmeter geeft ook aan of het voertuig rijdt of 
stilstaat. Het voertuig rijdt wanneer de functie gedurende 
ten minste 5 seconden meer dan 1 imp/s van de be ­
wegingssensor waarneemt. Als dit niet het geval is, wordt 
aangenomen dat het voertuig stilstaat.  
25) Inrichtingen die snelheid (tachometer) en totale afgelegde 
afstand (kilometerteller) zichtbaar maken en geïnstalleerd 
zijn in een voertuig dat uitgerust is met een controleap ­
paraat dat voldoet aan de bepalingen van deze verorde ­
ning, moeten voldoen aan de in deze bijlage vastgestelde 
eisen betreffende de maximumtoleranties (zie 3.2.1 en 
3.2.2).  
26) Om manipulatie van bewegingsgegevens te detecteren, 
moet informatie van de bewegingssensor worden bevestigd 
door informatie over beweging van het voertuig die af ­
komstig is van de GNSS-ontvanger of andere facultatieve 
van de bewegingssensor onafhankelijke bronnen.  
27) Deze functie meet de positie van het voertuig met het oog 
op de automatische registratie van:  
— de posities waar de bestuurder en/of de bijrijder hun 
dagelijkse werktijd aanvatten;  
▼M1 
— de posities waar de cumulatieve rijtijd een veelvoud 
van drie uur bereikt;  
▼B 
— de posities waar de bestuurder en/of de bijrijder hun 
dagelijkse werktijd beëindigen.  
3.2.1  Meting van de afgelegde afstand  
28) De afgelegde afstand kan worden gemeten:  
— hetzij bij vooruitrijden en achteruitrijden,  
— hetzij uitsluitend bij vooruitrijden.  
29) Het controleapparaat moet afstanden van 0 tot 
9 999 999,9 km meten.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 26  
30) De gemeten afstand moet binnen de onderstaande toleran ­
ties liggen (afstanden van ten minste 1 000 m):  
— ± 1 % voor installatie,  
— ± 2 % bij installatie en periodieke controle,  
— ± 4 % in gebruik.  
31) De resolutie van de gemeten afstand bedraagt ten minste 
0,1 km.  
3.2.2  Meting van de snelheid  
32) Het controleapparaat moet snelheden van 0 tot 220 km/h 
meten.  
33) Om een maximumtolerantie op de getoonde snelheid van ± 
6 km/h tijdens gebruik te garanderen en rekening houdend 
met: 
— een tolerantie van ± 2 km/h voor invoervariaties (ban ­
denvariaties, …),  
— een tolerantie van ± 1 km/h voor metingen gedurende 
de installatie of periodieke controles,  
moet het controleapparaat bij snelheden tussen 20 en 
180 km/h en bij kenmerkende coëfficiënten van het voer ­
tuig tussen 4 000 en 25 000 imp/km de snelheid meten met 
een tolerantie van ± 1 km/h (bij constante snelheid).  
Aantekening:  De resolutie van de gegevensopslag geeft 
een extra tolerantie van ± 0,5 km/h aan de door het con ­
troleapparaat opgeslagen snelheid.  
34) De snelheid moet binnen de normale toleranties correct 
worden gemeten binnen 2 seconden na het einde van 
een versnelling wanneer de versnelling maximaal 2 m/s  2 
bedraagt.  
35) De resolutie van de gemeten snelheid bedraagt ten minste 
1 km/h.  
3.2.3  Bepalen van de positie  
36) Het controleapparaat meet de absolute positie van het 
voertuig aan de hand van de GNSS-ontvanger.  
37) De absolute positie wordt gemeten in geografische coördi ­
naten van de lengte- en breedtegraad in graden en minuten 
met een resolutie van 1/10 minuut.  
3.3 Tijdmeting  
38) De tijdmetingsfunctie moet permanent operationeel zijn en 
de UTC-datum en UTC-tijd digitaal leveren.  
39) De UTC-datum en UTC-tijd worden gebruikt voor date ­
ring van gegevens in het controleapparaat (registraties, ge ­
gevensuitwisseling) en voor alle in aanhangsel 4, „Afdruk ­
ken” gespecificeerde afdrukken.  
40) Om de plaatselijke tijd zichtbaar te maken, moet de op het 
display getoonde tijd in stappen van een half uur kunnen 
worden gewijzigd. Andere instellingen dan negatieve of 
positieve veelvouden van een half uur zijn niet toegestaan.  
41) Bij gebrek aan elke vorm van tijdafstelling, mogen afwij ­
kingen niet meer dan ± 2 seconden per dag bedragen 
onder typegoedkeuringsvoorwaarden.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 27  
42) De resolutie van de gemeten tijd bedraagt ten minste 1 
seconde.  
43) De tijdmeting mag niet worden beïnvloed door een externe 
stroomonderbreking van minder dan 12 maanden onder 
typegoedkeuringsvoorwaarden.  
3.4 Controle op activiteiten van bestuurders  
44) Deze functie moet voortdurend en afzonderlijk de activi ­
teiten van een bestuurder en een bijrijder controleren.  
45) Activiteiten van de bestuurder zijn RIJDEN, WERKEN, 
BESCHIKBAARHEID of RUSTPAUZE.  
46) De bestuurder en/of de bijrijder kunnen WERKEN, BE ­
SCHIKBAARHEID of RUSTPAUZE manueel selecteren.  
47) Wanneer het voertuig rijdt, wordt RIJDEN automatisch 
geselecteerd voor de bestuurder en BESCHIKBAARHEID 
voor de bijrijder.  
48) Wanneer het voertuig stopt, wordt WERKEN automatisch 
geselecteerd voor de bestuurder.  
▼M1 
49) Er wordt van uitgegaan dat de eerste verandering van 
activiteit naar ONDERBREKING/RUST of BESCHIK ­
BAARHEID die zich binnen 120 seconden na de automa ­
tische verandering naar WERK als gevolg van het stoppen 
van het voertuig voordoet, heeft plaatsgevonden op het 
moment waarop het voertuig stopt (waardoor de verande ­
ring naar WERK eventueel kan worden geannuleerd).  
▼B 
50) Deze functie moet veranderingen van activiteiten naar de 
registratiefuncties uitvoeren met een resolutie van één mi ­
nuut.  
51) Wanneer binnen de onmiddellijk voorafgaande en de on ­
middellijk volgende kalenderminuut de activiteit RIJDEN 
is geregistreerd, wordt de hele minuut beschouwd als RIJ ­
DEN.  
52) Wanneer een kalenderminuut niet wordt beschouwd als 
RIJDEN overeenkomstig het voorgaande voorschrift 051, 
dan wordt de hele minuut gerekend als de langste on ­
onderbroken activiteit binnen de minuut (of de laatste 
van een aantal even lange activiteiten).  
53) Deze functie moet ook voortdurend de rijtijd en de cumu ­
latieve rusttijd van de bestuurder controleren.  
3.5 Controle op de status van bestuurders  
54) Deze functie moet voortdurend en automatisch de status 
van bestuurders controleren.  
55) De status TEAM wordt geselecteerd wanneer twee geldige 
bestuurderskaarten in het apparaat worden ingebracht, in 
alle andere gevallen wordt de status ALLEEN geselec ­
teerd.  
3.6 Invoer door bestuurders  
3.6.1  Invoer van begin- en eindpunt van de dagelijkse werkperiode  
56) Met deze functie kan het begin- en eindpunt van de dage ­
lijkse werkperiode van een bestuurder en/of een bijrijder 
worden ingevoerd.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 28  
57) Plaatsen worden gedefinieerd als het land en — voorzover 
relevant — de regio, die manueel worden ingevoerd of 
bevestigd.  
58) Bij het uitnemen van een bestuurderskaart moet het con ­
troleapparaat de bestuurder (bijrijder) vragen een „plaats 
waar de dagelijkse werkperiode eindigt” in te voeren.  
▼M1 
59) Daarna voert de bestuurder de huidige plaats van het voer ­
tuig in, die als een tijdelijke invoer wordt beschouwd.  
In de volgende omstandigheden wordt de tijdelijke invoer 
die plaatsvond bij de laatste kaartuitneming gevalideerd 
(d.w.z. niet meer overschreven):  
— invoer van een plaats waar de lopende dagelijkse werk ­
periode begint tijdens manuele invoer overeenkomstig 
voorschrift 61);  
— de volgende invoer van een plaats waar de lopende 
dagelijkse werkperiode begint als de kaarthouder tij ­
dens de manuele invoer overeenkomstig voorschrift 
61) niet invoert op welke plaats de werkperiode begint 
of eindigt.  
In de volgende omstandigheden wordt de tijdelijke invoer 
die plaatsvond bij de laatste kaartuitneming overschreven 
en wordt de nieuwe waarde gevalideerd:  
— de volgende invoer van een plaats waar de lopende 
dagelijkse werkperiode eindigt als de kaarthouder tij ­
dens de manuele invoer overeenkomstig voorschrift 
61) niet invoert op welke plaats de werkperiode begint 
of eindigt.  
▼B 
60) Het moet mogelijk zijn plaatsen waar de dagelijkse werk ­
periode begint en/of eindigt, in te voeren via commando's 
in de menu's. Indien meer dan één dergelijke invoer ge ­
beurt binnen één kalenderminuut, mogen slechts de laatst 
ingevoerde beginplaats en de laatst ingevoerde eindplaats 
binnen die tijdspanne geregistreerd blijven.  
3.6.2  Manuele invoer van bestuurdersactiviteiten en toestemming van de 
bestuurder voor de ITS-interface  
61) Manuele invoer van activiteiten is uitsluitend toegestaan 
bij het inbrengen van een bestuurderskaart of werkplaats ­
kaart. Bij het manueel invoeren van activiteiten worden de 
plaatselijke tijd- en datumwaarden van de tijdszone (UTC 
offset) gebruikt die op dat moment voor de voertuigunit 
zijn ingesteld.  
Bij het inbrengen van een bestuurders- of werkplaatskaart 
wordt de kaarthouder herinnerd aan:  
— de datum en de tijd dat de kaart voor het laatst is 
uitgenomen;  
— en facultatief: de voor de voertuigunit ingestelde plaat ­
selijke tijd.  
Bij de invoer van een bestuurders- of werkplaatskaart die 
voor de voertuigunit nog niet bekend is, wordt de kaart ­
houder gevraagd te bevestigen dat hij ermee instemt dat 
zijn persoonlijke tachograafgegevens via de optionele ITS- 
interface worden doorgegeven.  
Wanneer de bestuurderskaart (resp. werkplaatskaart) is in ­
gegeven, kan de bestuurder (resp. werkplaats) op elk mo ­
ment via het menu zijn of haar instemming geven of in ­
trekken.  
Activiteiten kunnen worden ingevoerd met de volgende 
beperkingen:  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 29  
— Activiteiten zijn WERKEN, BESCHIKBAARHEID of 
RUSTPAUZE.  
— De begin- en eindtijden van elke activiteit liggen enkel 
binnen de laatste periode tussen het uitnemen en in ­
brengen van de kaart.  
— Activiteiten mogen elkaar niet in tijd overlappen.  
Zo nodig is manuele invoer mogelijk wanneer een nog niet 
eerder gebruikte bestuurderskaart (of werkplaatskaart) voor 
het eerst wordt ingebracht.  
De procedure voor manuele invoer van activiteiten bestaat 
uit evenveel opeenvolgende stappen als nodig voor het 
instellen van het type en de begin- en eindtijd van elke 
activiteit. Voor elk willekeurig deel van de laatste periode 
tussen het invoeren en uitnemen van de kaart kan de kaart ­
houder ervoor kiezen geen enkele activiteit op te geven.  
Tijdens de met het inbrengen van een kaart verbonden 
manuele invoer kan de kaarthouder, indien van toepassing, 
het volgende invoeren:  
▼M1 
— een plaats waar een vorige dagelijkse werkperiode is 
geëindigd, alsook de relevante tijd (waarbij de invoer 
tijdens de laatste kaartuitneming wordt overschreven 
en dus gevalideerd),  
— een plaats waar de lopende dagelijkse werkperiode be ­
gint, alsook de relevante tijd (waarbij dus de tijdelijke 
invoer die plaatsvond bij de laatste kaartuitneming 
wordt gevalideerd).  
▼B 
Wanneer de kaarthouder tijdens de met het inbrengen van 
een kaart verbonden manuele invoer niet invoert op welke 
plaats de werkperiode begint of eindigt, wordt er vanuit 
gegaan dat die plaats niet is gewijzigd na de laatste keer 
dat de kaart is uitgenomen. De volgende invoer van een 
plaats waar de vorige dagelijkse werkperiode eindigt, over ­
schrijft in dat geval de tijdelijke invoer bij de laatste kaart ­
uitneming.  
Wanneer een plaats is ingevoerd, wordt deze geregistreerd 
op de relevante tachograafkaart.  
De manuele invoer wordt onderbroken indien:  
— de kaart wordt uitgenomen; of  
— het voertuig in beweging is en de kaart zich in de lezer 
van de bestuurder bevindt.  
Extra onderbrekingen zijn toegestaan, bv. een time-out na 
een zekere periode van inactiviteit van de gebruiker. In ­
dien de manuele invoer wordt onderbroken, valideert het 
controleapparaat elke volledige invoer van plaats en acti ­
viteit (met ondubbelzinnige vermelding van plaats en tijd, 
of type activiteit, begintijd en eindtijd).  
Indien een tweede bestuurders- of werkplaatskaart wordt 
ingebracht terwijl nog manueel wordt ingevoerd voor een 
eerder ingebrachte kaart, mag deze manuele invoer worden 
voltooid voordat de manuele invoer voor de tweede kaart 
begint.  
De kaarthouder kan manueel activiteiten invoeren overeen ­
komstig de volgende minimumprocedure:  
— Voer activiteiten manueel in, in chronologische volg ­
orde, voor de laatste periode tussen het uitnemen en 
inbrengen van de kaart.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 30  
— De begintijd van de eerste activiteit is het tijdstip 
waarop de kaart wordt uitgenomen. Voor elke vol ­
gende invoer wordt de begintijd vooraf ingesteld als 
onmiddellijk volgend op de eindtijd van de voor ­
afgaande invoer. Voor elke activiteit wordt het type 
activiteit en de eindtijd geselecteerd.  
De procedure eindigt wanneer de eindtijd van een manueel 
ingevoerde activiteit gelijk is aan het tijdstip waarop de 
kaart is ingebracht. Het controleapparaat kan vervolgens 
facultatief de kaarthouder een manueel ingevoerde activi ­
teit laten wijzigen, totdat wordt gevalideerd door een spe ­
cifiek commando te selecteren. Daarna kunnen dergelijke 
wijzigingen niet meer worden aangebracht.  
3.6.3  Invoer van specifieke omstandigheden  
62) De bestuurder kan de twee onderstaande specifieke om ­
standigheden in real-time in het controleapparaat invoeren:  
— „NIET VERPLICHT” (begin, einde);  
— „VERVOER PER FERRY/TREIN” (begin, einde).  
„VERVOER PER FERRY/TREIN” is niet toegestaan 
wanneer een „NIET VERPLICHT”-omstandigheid ge ­
opend is.  
Een geopende „NIET VERPLICHT”-omstandigheid moet 
door het controleapparaat automatisch worden gesloten 
wanneer een bestuurderskaart wordt ingebracht of uitgeno ­
men.  
Een geopende „NIET VERPLICHT”-omstandigheid on ­
derdrukt de volgende voorvallen en waarschuwingssigna ­
len: 
— rijden zonder geschikte kaart  
— waarschuwingssignalen in verband met de rijtijd.  
De vlag begin VERVOER PER FERRY/TREIN moet 
zichtbaar zijn voor de bestuurder de motor op de trein 
of ferry stillegt.  
Een openstaande VERVOER PER FERRY/TREIN moet 
aflopen in de volgende gevallen:  
— wanneer de bestuurder het VERVOER PER FERRY/ 
TREIN manueel beëindigt;  
— wanneer de bestuurder zijn kaart uitneemt;  
Een openstaande VERVOER PER FERRY/TREIN wordt 
beëindigd wanneer deze op grond van Verordening (EG) 
nr. 561/2006 niet langer geldig is.  
3.7 Beheer van bedrijfsvergrendelingen  
63) Deze functie beheert de vergrendelingen die een bedrijf 
aanbrengt om ervoor te zorgen dat het alleen zelf toegang 
heeft tot de gegevens in de bedrijfsmodus.  
64) Bedrijfsvergrendelingen bestaan uit een begindatum/-tijd 
(lock-in) en een einddatum/-tijd (lock-out) in combinatie 
met de identiteit van het bedrijf zoals aangegeven door het 
bedrijfskaartnummer (bij lock-in).  
65) Vergrendelingen kunnen alleen in real-time worden „in-” 
of „uitgeschakeld”.  
66) Het uitschakelen van de vergrendeling is alleen mogelijk 
voor het bedrijf waarvan de vergrendeling is „ingescha ­
keld” (zoals geïdentificeerd door de eerste 13 cijfers van 
het bedrijfskaartnummer), of,  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 31  
67) het uitschakelen van de vergrendeling gebeurt automatisch 
wanneer een ander bedrijf de vergrendeling inschakelt.  
68) Indien een bedrijf de vergrendeling inschakelt en de vorige 
vergrendeling voor hetzelfde bedrijf was, dan wordt aange ­
nomen dat de vorige vergrendeling niet is „uitgeschakeld” 
en nog steeds is „ingeschakeld”.  
3.8 Bewaken van controleactiviteiten  
69) Deze functie moet controle uitoefenen op het WEER ­
GEVEN, AFDRUKKEN, DOWNLOADEN van VU en 
kaarten en de KALIBERINGSCONTROLE LANGS DE 
WEG, die in de controlemodus uitgevoerd worden.  
70) Deze functie moet ook controle uitoefenen op de SNEL ­
HEIDSOVERSCHRIJDING in de controlemodus. Con ­
trole van snelheidsoverschrijding wordt geacht te hebben 
plaatsgevonden wanneer, in de controlemodus, de afdruk 
„snelheidsoverschrijding” naar de printer of het display is 
gezonden, of wanneer gegevens over „voorvallen en fou ­
ten” uit het VU-geheugen zijn gedownload.  
3.9 Opsporing van voorvallen en/of fouten  
71) Deze functie detecteert de onderstaande voorvallen en/of 
fouten:  
3.9.1  „Inbrengen van een ongeldige kaart”  
72) Dit voorval treedt op bij het inbrengen van een ongeldige 
kaart, het inbrengen van een reeds vervangen bestuurders ­
kaart en/of wanneer de ingebrachte kaart vervalt.  
3.9.2  „Kaartconflict”  
73) Dit voorval treedt op bij een van de combinaties van 
geldige kaarten die in de onderstaande tabel met een X 
gemerkt zijn:  
Kaartconflict  Kaartlezer bestuurder  
Geen kaart  Bestuurderskaart  Controlekaart  Werkplaatskaart  Bedrijfskaart
 Kaartlezer bijrijder Geen kaart  
Bestuurderskaart  X  
Controlekaart  X  X  X  
Werkplaatskaart  X  X  X  X  
Bedrijfskaart  X  X  X  
3.9.3  „Tijdsoverlapping”  
74) Dit voorval treedt op wanneer de datum/het tijdstip waarop 
de bestuurderskaart de laatste keer is uitgenomen, later is 
dan de actuele datum/tijd van het controleapparaat waarin 
de kaart wordt ingebracht.  
3.9.4  „Rijden zonder geschikte kaart”  
75) Dit voorval treedt op bij combinaties van geldige tacho ­
graafkaarten die in de onderstaande tabel met een X zijn 
aangemerkt, wanneer de activiteit van de bestuurder ver ­
andert in RIJDEN, of wanneer de werkingsmodus tijdens 
het RIJDEN verandert:  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 32  
Rijden zonder geschikte kaart  Kaartlezer bestuurder  
Geen (of ongel ­
dige) kaart  Bestuurderskaart  Controlekaart  Werkplaatskaart  Bedrijfskaart
 Kaartlezer bijrijder Geen (of ongeldige) 
kaart  X X  X  
Bestuurderskaart  X  X  X  X  
Controlekaart  X  X  X  X  X  
Werkplaatskaart  X  X  X  X  
Bedrijfskaart  X  X  X  X  X  
3.9.5  „Inbrengen van de kaart tijdens het rijden”  
76) Dit voorval treedt op wanneer een tachograafkaart tijdens 
het RIJDEN in een lezer wordt ingebracht.  
3.9.6  „Laatste kaartsessie niet correct afgesloten”  
77) Dit voorval treedt op wanneer het controleapparaat bij 
kaartinvoer ontdekt dat, niettegenstaande de bepalingen 
van punt 3.1, de voorafgaande kaartsessie niet correct is 
afgesloten (de kaart is uitgenomen voordat alle relevante 
gegevens op de kaart opgeslagen zijn). Dit mag uitsluitend 
voorkomen bij bestuurders- en werkplaatskaarten.  
3.9.7  „Snelheidsoverschrijding”  
78) Dit voorval treedt op bij elke snelheidsoverschrijding.  
3.9.8  „Onderbreking van de stroomvoorziening”  
79) Dit voorval treedt op bij een onderbreking van ten minste 
200 milliseconden in de stroomvoorziening van de be ­
wegingssensor en/of de voertuigunit, echter niet in de ka ­
librerings- of controlemodus. De drempel van de onder ­
breking wordt door de fabrikant bepaald. De spanningsval 
door het starten van de motor van het voertuig mag dit 
voorval niet veroorzaken.  
3.9.9  „Communicatiefout met het systeem voor communicatie op afstand”  
80) Dit voorval treedt,  behalve in de kalibreringsmodus , op 
wanneer het systeem voor communicatie op afstand na 
meer dan drie pogingen niet bevestigt dat het de door de 
voertuigunit vanop afstand doorgestuurde gegevens heeft 
ontvangen.  
3.9.10  „Ontbreken van plaatsbepalingsinformatie van de GNSS-ontvanger”  
81) Dit voorval treedt,  behalve in kalibreringsmodus , op bij 
het ontbreken van plaatsbepalingsinformatie van de (in ­
terne of externe) GNSS-ontvanger gedurende meer dan 3 
uren cumulatieve rijtijd.  
3.9.11  „Fout in communicatie met de externe GNSS-module”  
82) Dit voorval treedt,  behalve in kalibreringsmodus , op bij 
het ontbreken van communicatie tussen de externe GNSS- 
module en het voertuig gedurende meer dan 20 opeenvol ­
gende minuten terwijl het voertuig aan het rijden is.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 33  
3.9.12  „Fout in de bewegingsgegevens”  
83) Dit voorval treedt,  behalve in de kalibreringsmodus , op 
bij een onderbreking in de normale gegevensstroom tussen 
de bewegingssensor en de voertuigunit en/of bij een fout 
in de integriteit of authenticatie van de gegevens tijdens de 
gegevensuitwisseling tussen de bewegingssensor en de 
voertuigunit.  
3.9.13  „Tegenstrijdige bewegingsgegevens”  
84) Dit voorval treedt,  behalve in de kalibreringsmodus , op 
wanneer de op basis van de bewegingssensor berekende 
bewegingsinformatie verschilt van de bewegingsinformatie 
die is berekend op basis van informatie van de interne 
GNSS-ontvanger of de externe GNSS-module, en eventu ­
ele andere facultatieve bronnen, als gespecificeerd in aan ­
hangsel 12. Dit voorval treedt niet op tijdens vervoer per 
ferry of trein, een „NIET VERPLICHT”-omstandigheid, of 
wanneer er geen plaatsbepalingsinformatie van de GNSS- 
ontvanger beschikbaar is.  
3.9.14.  „Poging tot inbreuk op de beveiliging”  
85) Dit voorval treedt op bij elk ander voorval dat de bevei ­
liging van de bewegingssensor en/of de voertuigunit en/of 
de externe GNSS-module als vereist bij aanhangsel 10 
aantast, echter niet in de kalibreringsmodus.  
▼M1 
3.9.15  „Tijdsoverlapping”  
86) Dit voorval treedt op wanneer een VU  die zich niet in de 
kalibreringsmodus bevindt  een afwijking van meer dan 1 
minuut detecteert tussen de tijd van de meetfunctie van de 
voertuigunit en de tijd die door de GNSS-ontvanger wordt 
doorgestuurd. Dit voorval wordt samen met de interne 
klokwaarde van de voertuigunit opgeslagen en gaat ge ­
paard met een automatische tijdsafstelling. Nadat een tijds ­
overlapping is veroorzaakt, mag de VU de volgende 12 
uur geen andere tijdsoverlapping genereren. Er wordt geen 
tijdsoverlapping gegenereerd wanneer de GNSS-ontvanger 
gedurende minstens 30 dagen geen geldig GNSS-signaal 
heeft kunnen detecteren.  
▼B 
3.9.16  „Kaartfout”  
87) Deze fout wordt veroorzaakt wanneer tijdens de werking 
een storing in de tachograafkaart optreedt.  
3.9.17.  „Controleapparaatfout”  
88) Deze fout wordt veroorzaakt door de onderstaande storin ­
gen, echter niet in de kalibreringsmodus:  
— Interne fout in de VU  
— Printerfout  
— Displayfout  
— Downloadfout  
— Sensorfout  
— Fout met GNSS-ontvanger of externe GNSS-module  
— Fout in systeem voor communicatie op afstand  
▼M1 
— ITS-interfacefout (indien van toepassing)  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 34  
3.10 Ingebouwde tests en zelftests  
89) ►M1 Het controleapparaat detecteert fouten door middel 
van zelftests en ingebouwde tests overeenkomstig onder ­
staande tabel: ◄ 
Onderdelen ter test  Zelftest  Ingebouwde test  
Software  Integriteit  
Geheugen  Toegang  Toegang, gegevensinte ­
griteit  
Kaartinterfaces  Toegang  Toegang  
Toetsenbord  Manuele controle  
Printer  (afhankelijk van 
de fabrikant)  Afdruk  
Display  Visuele controle  
Downloaden 
(alleen uitgevoerd tijdens 
het downloaden)  Correcte werking  
Sensor  Correcte werking  Correcte werking  
Systeem voor communica ­
tie op afstand  Correcte werking  Correcte werking  
GNSS-module  Correcte werking  Correcte werking  
▼M1 
ITS-interface (optioneel)  Correcte werking  
▼B 
3.11 Lezen van het geheugen  
90) Het controleapparaat moet alle gegevens die in zijn geheu ­
gen opgeslagen zijn kunnen lezen.  
3.12 Registratie en opslag in het geheugen  
Voor de toepassing van dit punt  
— wordt „365 dagen” gedefinieerd als 365 kalenderdagen van ge ­
middelde activiteit van de bestuurder in een voertuig. De ge ­
middelde activiteit per dag in een voertuig wordt gedefinieerd 
als ten minste 6 bestuurders of bijrijders, 6 cycli van kaartinvoer 
en -uitname en 256 wijzigingen in de activiteiten. „365 dagen” 
omvat derhalve ten minste 2 190 bestuurders (bijrijders), 2 190 
cycli van kaartinvoer en kaartuitname en 93 440 wijzigingen van 
activiteiten;  
▼M1 
— het gemiddeld aantal posities per dag wordt gedefinieerd als ten 
minste 6 posities bij het begin van de dagelijkse werktijd, 6 
posities wanneer de cumulatieve rijtijd van de bestuurder een 
veelvoud van drie uur bereikt en 6 posities aan het einde van 
de dagelijkse werktijd, zodat „365 dagen” minstens 6570 posi ­
ties omvat;  
▼B 
— wordt de tijd geregistreerd met een resolutie van 1 minuut, tenzij 
anders gespecificeerd;  
— worden kilometerstanden geregistreerd met een resolutie van 1 
kilometer;  
— wordt de snelheid geregistreerd met een resolutie van 1 km/h;  
— posities (lengte en breedte) worden geregistreerd in graden en 
minuten, met een resolutie van 1/10 minuut, met de daaraan 
gekoppelde GNSS-nauwkeurigheid en acquisitietijd.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 35  
91) De in het geheugen opgeslagen gegevens mogen niet wor ­
den beïnvloed door een externe stroomonderbreking van 
minder dan 12 maanden onder typegoedkeuringsvoorwaar ­
den. Gegevens die zijn opgeslagen in het extern systeem 
voor communicatie op afstand, als gedefinieerd in aan ­
hangsel 14, mogen niet worden aangetast door een stroom ­
onderbreking van minder dan 28 dagen.  
92) Het controleapparaat moet in zijn geheugen impliciet of 
expliciet de volgende gegevens registreren en opslaan:  
3.12.1  Identificatiegegevens van de uitrusting  
3.12.1.1 I d e n t i f i c a t i e g e g e v e n s v a n d e v o e r t u i g u n i t  
93) Het controleapparaat moet in zijn geheugen de volgende 
identificatiegegevens van de voertuigunit opslaan:  
— naam van de fabrikant  
— adres van de fabrikant  
— onderdeelnummer  
— serienummer  
— generatie voertuigunit  
— mogelijkheid tachograafkaarten van de eerste generatie 
te gebruiken  
— nummer van de softwareversie  
— installatiedatum van de softwareversie  
— bouwjaar  
— goedkeuringsnummer  
94) Identificatiegegevens van de voertuigunit worden door de 
fabrikant van de voertuigunit definitief geregistreerd en 
opgeslagen, met uitzondering van gegevens in verband 
met de software en het goedkeuringsnummer, die in geval 
van een software-upgrade gewijzigd kunnen worden, en 
compatibiliteit met tachograafkaarten van de eerste gene ­
ratie.  
3.12.1.2 I d e n t i f i c a t i e g e g e v e n s v a n d e b e w e g i n g s s e n s o r  
95) De bewegingssensor moet in zijn geheugen de volgende 
identificatiegegevens opslaan:  
— naam van de fabrikant,  
— serienummer,  
— goedkeuringsnummer,  
— identificatie van ingebouwde veiligheidscomponent 
(bijv. onderdeelnummer van de interne chip/verwer ­
kingseenheid),  
— identificatie van het besturingssysteem (bv. nummer 
van de softwareversie).  
96) De identificatiegegevens van de bewegingssensor worden 
door de fabrikant van de bewegingssensor definitief in de 
bewegingssensor geregistreerd en opgeslagen.  
97) De voertuigunit moet voor de 20 recentste verbindingen 
met bewegingssensoren (indien op één kalenderdag meer ­
dere verbindingen tot stand worden gebracht, worden al ­
leen de eerste en laatste van de dag opgeslagen) de vol ­
gende gegevens kunnen registeren en in zijn geheugen 
opslaan:  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 36  
De volgende gegevens moeten bij elke verbinding worden 
geregistreerd:  
— identificatiegegevens van de bewegingssensor:  
— serienummer  
— goedkeuringsnummer,  
— verbindingsgegevens van de bewegingssensor:  
— datum verbinding.  
3.12.1.3 I d e n t i f i c a t i e g e g e v e n s G N S S - s y s t e m e n  
98) De externe GNSS-module moet in haar geheugen de vol ­
gende identificatiegegevens opslaan:  
— naam van de fabrikant,  
— serienummer,  
— goedkeuringsnummer,  
— identificatie van ingebouwde veiligheidscomponent 
(bijv. onderdeelnummer van de interne chip/verwer ­
kingseenheid),  
— identificatie van het besturingssysteem (bv. nummer 
van de softwareversie).  
99) De identificatiegegevens worden door de fabrikant van de 
externe GNSS-module definitief in de externe GNSS-mo ­
dule geregistreerd en opgeslagen.  
100) De voertuigunit moet voor de 20 recentste koppelingen 
met externe GNSS-systemen (indien op één kalenderdag 
meerdere koppelingen tot stand worden gebracht, worden 
alleen de eerste en laatste van de dag opgeslagen) de 
volgende gegevens kunnen registreren en opslaan in zijn 
geheugen:  
De volgende gegevens moeten bij elke koppeling worden 
geregistreerd:  
— identificatiegegevens van de externe GNSS-module:  
— serienummer,  
— goedkeuringsnummer,  
— koppelingsgegevens van de externe GNSS-module:  
— eerste koppelingsdatum.  
3.12.2  Sleutels en certificaten  
101) Het controleapparaat moet een aantal cryptografische sleu ­
tels en certificaten kunnen opslaan overeenkomstig de spe ­
cificaties in aanhangsel 11, delen A en B.  
3.12.3  Gegevens over het inbrengen en uitnemen van de bestuurders- of 
werkplaatskaart  
102) Telkens een bestuurders- of werkplaatskaart in het appa ­
raat wordt ingebracht of uitgenomen, moet het controleap ­
paraat in zijn geheugen de volgende gegevens registreren 
en opslaan:  
— de naam en voornaam (of namen) van de kaarthouder 
zoals opgeslagen op de kaart;  
— het kaartnummer, de lidstaat van afgifte en de verval ­
datum zoals opgeslagen op de kaart;  
— de generatie van de kaart;  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 37  
— datum en tijdstip van inbrengen;  
— de kilometerstand bij kaartinvoer;  
— de lezer waarin de kaart wordt ingebracht;  
— datum en tijdstip van uitnemen;  
— de kilometerstand bij het uitnemen van de kaart;  
— de volgende informatie over het vorige door de be ­
stuurder gebruikte voertuig zoals opgeslagen op de 
kaart:  
— kentekennummer en registrerende lidstaat;  
— de generatie voertuigunit (indien beschikbaar);  
— datum en tijdstip waarop de kaart wordt uitgeno ­
men;  
— een teken dat aangeeft of de kaarthouder bij de kaart ­
invoer manueel activiteiten heeft ingevoerd.  
103) Het geheugen moet deze gegevens ten minste 365 dagen 
bewaren.  
104) Wanneer de opslagcapaciteit volledig is gebruikt, worden 
de oudste gegevens overschreven door de meest recente.  
3.12.4  Gegevens over activiteiten van de bestuurder  
105) Bij elke wijziging in de activiteiten van de bestuurder 
en/of de bijrijder, bij elke wijziging in de status van de 
bestuurder(s) en telkens wanneer een bestuurders- of werk ­
plaatskaart wordt ingebracht of uitgenomen, worden de 
volgende gegevens door het controleapparaat geregistreerd 
en opgeslagen:  
— de status van de bestuurder(s) (ALLEEN/ALS TEAM);  
— de kaartlezer (BESTUURDER, BIJRIJDER);  
— de status van de kaart in de betreffende kaartlezer (IN ­
GEBRACHT, NIET INGEBRACHT);  
— de activiteiten (RIJDEN, BESCHIKBAARHEID, 
WERKEN, ONDERBREKING/RUST);  
— de datum en het tijdstip van de wijziging.  
INGEBRACHT betekent dat een geldige bestuurders- of 
werkplaatskaart in de lezer ingebracht is. NIET IN ­
GEBRACHT betekent het tegenovergestelde, d.w.z. er is 
geen geldige bestuurders- of werkplaatskaart in de lezer 
ingebracht (er is bv. wel een bedrijfskaart ingebracht of 
er is geen kaart ingebracht).  
Gegevens over activiteiten die door een bestuurder manu ­
eel worden ingevoerd, worden niet in het geheugen ge ­
registreerd.  
106) Het geheugen moet de gegevens over de activiteiten van 
de bestuurder ten minste 365 dagen kunnen bewaren.  
107) Wanneer de opslagcapaciteit volledig is gebruikt, worden 
de oudste gegevens overschreven door de meest recente.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 38  
3.12.5  Plaatsen en posities waar de dagelijkse werktijd begint, eindigt 
en/of waar een cumulatieve rijtijd van 3 uur wordt bereikt  
108) Het controleapparaat moet gegevens registreren en in zijn 
geheugen opslaan met betrekking tot:  
— de plaatsen en posities waar de bestuurder en/of bij ­
rijder hun dagelijkse werktijd aanvatten;  
— de posities waar de cumulatieve rijtijd een veelvoud 
van drie uur bereikt;  
— de plaatsen en posities waar de bestuurder en/of de 
bijrijder hun dagelijkse werktijd beëindigen.  
▼B 
109) Wanneer de positie van het voertuig op die momenten niet 
via de GNSS-ontvanger kan worden bepaald, gebruikt het 
controleapparaat de recentste beschikbare positie en de 
daaraan gekoppelde datum en tijd.  
110) Samen met elke plaats en positie moet het controleapparaat 
gegevens registreren en in zijn geheugen opslaan met be ­
trekking tot:  
— het bestuurderskaartnummer en de lidstaat van afgifte;  
— de generatie van de kaart;  
— de datum en het tijdstip van de ingevoerde gebeurtenis;  
▼M1 
— de aard van die gebeurtenis (begin, einde en/of 3 uur 
cumulatieve rijtijd);  
▼B 
— desgevallend de gerelateerde GNSS-nauwkeurigheid, 
datum- en tijd;  
— de kilometerstand van het voertuig.  
▼M1 
111) Het geheugen moet de plaatsen of posities waar de dage ­
lijkse werkperiodes beginnen, eindigen en/of waar een cu ­
mulatieve rijtijd van 3 uur wordt bereikt ten minste 365 
dagen kunnen bewaren.  
▼B 
112) Wanneer de opslagcapaciteit volledig is gebruikt, worden 
de oudste gegevens overschreven door de meest recente.  
3.12.6  Gegevens over de kilometerstand  
113) Het controleapparaat moet elke kalenderdag om midder ­
nacht de kilometerstand van het voertuig en de bijbeho ­
rende datum in zijn geheugen registreren.  
114) Het geheugen moet deze kilometerstanden ten minste 365 
kalenderdagen kunnen opslaan.  
115) Wanneer de opslagcapaciteit volledig is gebruikt, worden 
de oudste gegevens overschreven door de meest recente.  
3.12.7  Gedetailleerde snelheidsgegevens  
▼M1 
116) Het controleapparaat moet voor elke seconde van ten min ­
ste de laatste 24 uur waarin het voertuig heeft bewogen, de 
snelheid van het voertuig en de corresponderende datum 
en het tijdstip registeren en in het geheugen opslaan.  
▼B 
3.12.8  Gegevens over voorvallen  
Voor de toepassing van dit punt wordt de tijd geregistreerd met een 
resolutie van 1 seconde.  
117) Het controleapparaat moet in zijn geheugen de volgende 
gegevens voor elk gedetecteerd voorval volgens de onder ­
staande opslagvoorschriften registreren en opslaan:  ▼M1
 02016R0799 — NL — 26.02.2020 — 002.001 — 39  
Voorval  Opslagvoorschriften  Te registreren gegevens per voorval  
Inbrengen van een ongel ­
dige kaart  — de 10 meest recente voorvallen  — datum en tijdstip van het voorval 
— type, nummer, lidstaat van afgifte en ge ­
neratie van de kaart die het voorval ge ­
nereert 
— aantal vergelijkbare voorvallen op die 
dag 
Kaartconflict  — de 10 meest recente voorvallen  — datum en tijdstip van het begin van het 
voorval 
— datum en tijdstip van het einde van het 
voorval 
— type, nummer, lidstaat van afgifte en ge ­
neratie van de twee kaarten die een con ­
flict opleveren  
Rijden zonder geschikte 
kaart  — het langste voorval voor elk van de 
laatste 10 dagen waarop een dergelijk 
voorval heeft plaatsgevonden 
— de 5 langste voorvallen gedurende de 
laatste 365 dagen  — datum en tijdstip van het begin van het 
voorval 
— datum en tijdstip van het einde van het 
voorval 
— type, nummer, lidstaat van afgifte en ge ­
neratie van de bij het begin en/of het 
einde van het voorval ingevoerde kaart; 
— aantal vergelijkbare voorvallen op die 
dag 
Inbrengen van kaart tij ­
dens het rijden  — het laatste voorval op elk van de laatste 
10 dagen waarop een dergelijk voorval 
plaatshad  — datum en tijdstip van het voorval 
— type, nummer, lidstaat van afgifte en ge ­
neratie van de kaart 
— aantal vergelijkbare voorvallen op die 
dag 
Laatste kaartsessie niet 
correct afgesloten  — de 10 meest recente voorvallen  — datum en tijdstip van kaartinvoer 
— type, nummer, lidstaat van afgifte en ge ­
neratie van de kaart 
— laatste sessiegegevens zoals af te lezen 
van de kaart: 
— datum en tijdstip van kaartinvoer 
— kentekennummer, lidstaat van in ­
schrijving en generatie voertuigunit  
Snelheidsoverschrijding 
(1) — het ernstigste voorval op elk van de 
laatste 10 dagen waarop een dergelijk 
voorval plaatshad (d.w.z. het voorval 
met de hoogste gemiddelde snelheid) 
— de 5 ernstigste voorvallen gedurende de 
afgelopen 365 dagen 
— het eerste voorval dat is opgetreden na 
de laatste kalibrering  — datum en tijdstip van het begin van het 
voorval 
— datum en tijdstip van het einde van het 
voorval 
— tijdens het voorval gemeten maximum ­
snelheid 
— tijdens het voorval gemeten rekenkun ­
dige maximumsnelheid 
— type, nummer, lidstaat van afgifte en ge ­
neratie van de bestuurderskaart (indien 
van toepassing) 
— aantal vergelijkbare voorvallen op die 
dag ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 40  
Voorval  Opslagvoorschriften  Te registreren gegevens per voorval  
Onderbreking stroomvoor ­
ziening (2)  — het langste voorval voor elk van de 
laatste 10 dagen waarop een dergelijk 
voorval heeft plaatsgevonden 
— de 5 langste voorvallen gedurende de 
laatste 365 dagen  — datum en tijdstip van het begin van het 
voorval 
— datum en tijdstip van het einde van het 
voorval 
— type, nummer, lidstaat van afgifte en ge ­
neratie van de bij het begin en/of het 
einde van het voorval ingevoerde kaart 
— aantal vergelijkbare voorvallen op die 
dag 
Fout in de communicatie 
met het systeem voor 
communicatie op afstand  — het langste voorval voor elk van de 
laatste 10 dagen waarop een dergelijk 
voorval heeft plaatsgevonden 
— de 5 langste voorvallen gedurende de 
laatste 365 dagen  — datum en tijdstip van het begin van het 
voorval 
— datum en tijdstip van het einde van het 
voorval 
— type, nummer, lidstaat van afgifte en ge ­
neratie van de bij het begin en/of het 
einde van het voorval ingevoerde kaart 
— aantal vergelijkbare voorvallen op die 
dag 
Ontbreken van plaatsbepa ­
lingsinformatie van de 
GNSS-ontvanger  — het langste voorval voor elk van de 
laatste 10 dagen waarop een dergelijk 
voorval heeft plaatsgevonden 
— de 5 langste voorvallen gedurende de 
laatste 365 dagen  — datum en tijdstip van het begin van het 
voorval 
— datum en tijdstip van het einde van het 
voorval 
— type, nummer, lidstaat van afgifte en ge ­
neratie van de bij het begin en/of het 
einde van het voorval ingevoerde kaart 
— aantal vergelijkbare voorvallen op die 
dag 
▼M1 
Fout in de communicatie 
met de externe GNSS-mo ­
dule — het langste voorval op elk van de laat ­
ste 10 dagen waarop een dergelijk 
voorval is opgetreden 
— de 5 langste voorvallen gedurende de 
afgelopen 365 dagen  — datum en tijdstip van het begin van het 
voorval 
— datum en tijdstip van het einde van het 
voorval 
— type, nummer, lidstaat van afgifte en ge ­
neratie van de bij het begin en/of het 
einde van het voorval ingevoerde 
kaart(en) 
— aantal vergelijkbare voorvallen op die 
dag 
▼B 
Fout in de bewegings ­
gegevens  — het langste voorval voor elk van de 
laatste 10 dagen waarop een dergelijk 
voorval heeft plaatsgevonden 
— de 5 langste voorvallen gedurende de 
laatste 365 dagen  — datum en tijdstip van het begin van het 
voorval 
— datum en tijdstip van het einde van het 
voorval 
— type, nummer, lidstaat van afgifte en ge ­
neratie van de bij het begin en/of het 
einde van het voorval ingevoerde kaart 
— aantal vergelijkbare voorvallen op die 
dag 
Tegenstrijdige bewegings ­
gegevens,  — het langste voorval voor elk van de 
laatste 10 dagen waarop een dergelijk 
voorval heeft plaatsgevonden, 
— de 5 langste voorvallen gedurende de 
laatste 365 dagen.  — datum en tijdstip van het begin van het 
voorval 
— datum en tijdstip van het einde van het 
voorval, 
— type, nummer, lidstaat van afgifte en ge ­
neratie van de bij het begin en/of het 
einde van het voorval ingevoerde kaart; 
— aantal vergelijkbare voorvallen op die 
dag ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 41  
Voorval  Opslagvoorschriften  Te registreren gegevens per voorval  
Poging tot inbreuk in de 
beveiliging  — de 10 meest recente voorvallen per 
soort voorval  — datum en tijdstip van het begin van het 
voorval 
— datum en tijdstip van het einde van het 
voorval (indien relevant) 
— type, nummer, lidstaat van afgifte en ge ­
neratie van de bij het begin en/of het 
einde van het voorval ingevoerde kaart; 
— soort voorval  
▼M1 
Tijdsoverlapping  — het ergste voorval voor elk van de laat ­
ste 10 dagen waarop een dergelijk 
voorval heeft plaatsgevonden (d.w.z. 
het voorval met het grootste verschil 
tussen de datum en het tijdstip van 
het controleapparaat en de datum en 
het tijdstip van het GNSS) 
— de 5 ergste voorvallen gedurende de 
afgelopen 365 dagen.  — datum en tijdstip controleapparaat 
— GNSS-datum en -tijdstip 
— type, nummer, lidstaat van afgifte en ge ­
neratie van de bij het begin en/of het 
einde van het voorval ingevoerde 
kaart(en) 
— aantal vergelijkbare voorvallen op die 
dag 
▼B 
(1) Het controleapparaat moet ook gegevens registreren en 
in zijn geheugen opslaan met betrekking tot:  
— datum en tijdstip laatste controle op SNELHEIDS ­
OVERSCHRIJDING,  
— datum en tijdstip eerste snelheidsoverschrijding na 
die controle op SNELHEIDSOVERSCHRIJDING.  
— het aantal snelheidsoverschrijdingen na de laatste 
CONTROLE OP DE SNELHEIDSOVERSCHRIJ ­
DING.  
(2) Deze gegevens mogen alleen worden opgeslagen bij 
een herstel van de stroomvoorziening, tijden kunnen 
bekend zijn met een nauwkeurigheid tot één minuut.  
3.12.9  Gegevens over fouten  
Voor de toepassing van dit punt wordt de tijd geregistreerd met een 
resolutie van 1 seconde.  
118) Het controleapparaat moet de volgende gegevens voor elke 
gedetecteerde fout registreren en in zijn geheugen opslaan 
volgens de onderstaande opslagvoorschriften:  
Fout Opslagvoorschriften  Te registreren gegevens per fout  
Kaartfout  — de 10 meest recente bestuurderskaart ­
fouten  — datum en tijdstip begin van de fout 
— datum en tijdstip einde van de fout 
— type, nummer, lidstaat van afgifte en 
generatie van de kaart  
Fouten controleapparaat  — de 10 meest recente fouten van iedere 
soort 
— de eerste fout na de recentste kalibre ­
ring — datum en tijdstip begin van de fout 
— datum en tijdstip einde van de fout 
— soort fout 
— type, nummer, lidstaat van afgifte en 
generatie van de bij het begin en/of 
het einde van het voorval ingevoerde 
kaart ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 42  
3.12.10  Kalibreringsgegevens  
119) Het controleapparaat registreert en bewaart in zijn geheu ­
gen gegevens met betrekking tot:  
— bekende kalibreringsparameters op het moment van 
activering;  
— de eerste kalibrering na activering;  
— de eerste kalibrering in het huidige voertuig (geïdenti ­
ficeerd door zijn VIN);  
— de 20 meest recente kalibreringen (wanneer een aantal 
kalibreringen op dezelfde kalenderdag plaatsvinden, 
worden alleen de eerste en laatste kalibrering van de 
dag opgeslagen).  
120) De volgende gegevens moeten bij elke kalibrering worden 
geregistreerd:  
— doel van de kalibrering (activering, eerste installatie, 
installatie, periodieke controle);  
— naam en adres van de werkplaats;  
— werkplaatskaartnummer, de lidstaat die de kaart afgeeft 
en de vervaldatum van de kaart;  
— voertuigidentificatie;  
— geactualiseerde en bevestigde parameters: w, k, l, ban ­
denmaat, instelling van de snelheidsbegrenzer, kilome ­
terstand (oude en nieuwe waarden), datum en tijdstip 
(oude en nieuwe waarden);  
— types en identificatienummers van alle aanwezige ver ­
zegelingen.  
121) Bovendien moet het controleapparaat in zijn geheugen de 
mogelijkheid opslaan en bewaren om tachograafkaarten 
van de eerste generatie te gebruiken (al dan niet nog ge ­
activeerd).  
122) De bewegingssensor moet de volgende installatiegegevens 
van de bewegingssensor registreren en in zijn geheugen 
opslaan:  
— eerste verbinding met een VU (datum, tijd, goedkeu ­
ringsnummer en serienummer van de VU);  
— laatste verbinding met een VU (datum, tijd, goedkeu ­
ringsnummer en serienummer van de VU).  
123) De externe GNSS-module moet de volgende installatiege ­
gevens van de externe GNSS-module opslaan en in zijn 
geheugen opslaan:  
— eerste koppeling aan een VU (datum, tijd, goedkeu ­
ringsnummer en serienummer van de VU);  
— laatste koppeling aan een VU (datum, tijd, goedkeu ­
ringsnummer en serienummer van de VU).  
3.12.11  Tijdafstellingsgegevens  
124) Het controleapparaat registreert en bewaart in zijn geheu ­
gen alle gegevens met betrekking tot tijdafstellingen die in 
de kalibreringsmodus worden uitgevoerd buiten het bestek 
van een normale kalibrering (def. f):  
— de meest recente tijdafstelling;  
— de 5 grootste tijdafstellingen;  
125) Voor elke tijdafstelling worden de volgende gegevens ge ­
registreerd:  
— datum en tijd, oude waarde;  
— datum en tijd, nieuwe waarde;  
— naam en adres van de werkplaats;  
— werkplaatskaartnummer, de lidstaat die de kaart af ­
geeft, de generatie van de kaart en haar vervaldatum;  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 43  
3.12.12  Gegevens over controleactiviteiten  
126) Het controleapparaat moet de volgende gegevens met be ­
trekking tot de 20 meest recente controleactiviteiten regis ­
treren en in zijn geheugen opslaan:  
— datum en tijdstip van de controle;  
— werkplaatskaartnummer, de lidstaat die de kaart af ­
geeft, en de vervaldatum en generatie van de kaart;  
— aard van de controle (weergeven en/of afdrukken en/of 
VU-gegevens downloaden en/of kaartgegevens 
downloaden en/of kalibreringscontrole langs de weg).  
127) Bij het downloaden worden de gegevens van de oudste en 
van de meest recent gedownloade dagen ook geregistreerd.  
3.12.13  Gegevens over bedrijfsvergrendelingen  
128) Het controleapparaat moet de volgende gegevens met be ­
trekking tot de 255 recentste bedrijfsvergrendelingen regis ­
treren en in zijn geheugen opslaan:  
— datum en tijdstip van vergrendeling;  
— datum en tijdstip van ontgrendeling;  
— bedrijfskaartnummer, de lidstaat die de kaart afgeeft, 
en de vervaldatum en generatie van de kaart;  
— naam en adres van het bedrijf.  
Gegevens die eerder zijn vergrendeld met een vergrende ­
ling die uit het geheugen is verwijderd omwille van de 
bovengenoemde beperking, moeten worden behandeld als 
niet-vergrendeld.  
3.12.14  Gegevens over overdrachtactiviteiten  
129) Het controleapparaat moet de volgende gegevens met be ­
trekking tot de laatste geheugenoverdracht naar externe 
media tijdens de bedrijfs- en kalibreringsmodus registreren 
en in zijn geheugen opslaan:  
— datum en tijdstip van de overdracht;  
— bedrijfs- of werkplaatskaartnummer, de lidstaat die de 
kaart afgeeft, en de vervaldatum en generatie van de 
kaart;  
— naam van het bedrijf of de werkplaats.  
3.12.15  Gegevens over specifieke omstandigheden  
130) Het controleapparaat moet de volgende gegevens met be ­
trekking tot specifieke omstandigheden in zijn geheugen 
registreren:  
— datum en tijdstip van de invoer;  
— aard van de specifieke omstandigheid.  
131) Het geheugen moet gegevens over specifieke omstandig ­
heden ten minste 365 dagen kunnen bewaren (in de ver ­
onderstelling dat gemiddeld 1 omstandigheid per dag 
wordt geopend en gesloten). Wanneer de opslagcapaciteit 
volledig is gebruikt, worden de oudste gegevens over ­
schreven door de meest recente.  
3.12.16  Gegevens tachograafkaart  
132) Het controleapparaat moet de volgende gegevens kunnen 
bewaren in verband met de verschillende tachograafkaarten 
die in de VU zijn gebruikt:  
— het nummer en serienummer van de tachograafkaart;  
— de fabrikant van de tachograafkaart;  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 44  
— het type tachograafkaart;  
— de versie van de tachograafkaart;  
133) Het controleapparaat moet ten minste 88 records kunnen 
opslaan.  
3.13 Lezen van de tachograafkaart  
134) Het controleapparaat moet op tachograafkaarten van de 
eerste en tweede generatie de noodzakelijke gegevens kun ­
nen lezen van om:  
— de kaartsoort, de kaarthouder, het eerder gebruikte 
voertuig, datum en tijdstip van de laatste kaartuitne ­
ming en de op dat moment geselecteerde activiteit te 
identificeren;  
— om te controleren of de laatste kaartsessie correct is 
afgesloten;  
— de rijtijd van de bestuurder, de cumulatieve rustperiode 
en de cumulatieve rijtijden gedurende de voorafgaande 
en de lopende week te berekenen;  
— gevraagde afdrukken met betrekking tot op de bestuur ­
derskaart geregistreerde gegevens te leveren;  
— een bestuurderskaart naar externe media over te bren ­
gen. 
Dit voorschrift geldt alleen voor tachografen van de eerste 
generatie indien het gebruik daarvan niet door een werk ­
plaats is opgeheven.  
135) In het geval van een leesfout moet het controleapparaat 
dezelfde leesopdracht maximaal drie keer opnieuw uitvoe ­
ren. Wanneer de kaart nog steeds niet kan worden gelezen, 
moet ze defect en ongeldig worden verklaard.  
3.14 Registratie en opslag op een tachograafkaart  
3.14.1  Registreren en opslaan op tachograafkaarten van de eerste genera ­
tie 
136) Indien het gebruik van tachograafkaarten van de eerste 
generatie niet door een werkplaats is opgeheven, moet 
het controleapparaat de gegevens op exact dezelfde manier 
als controleapparaten van de eerste generatie opslaan en 
bewaren.  
137) Het controleapparaat moet de „gegevens van de kaartses ­
sie” onmiddellijk na de kaartinvoer op de bestuurderskaart 
of werkplaatskaart zetten.  
138) Het controleapparaat moet de gegevens die op een geldige 
bestuurderskaart, bedrijfskaart, werkplaatskaart en/of con ­
trolekaart zijn opgeslagen, bijwerken met behulp van alle 
noodzakelijke gegevens die verband houden met de peri ­
ode waarin de kaart ingebracht is, en met alle noodzake ­
lijke gegevens betreffende de kaarthouder. In hoofdstuk 4 
is gespecificeerd welke gegevens op die kaarten moeten 
worden opgeslagen.  
139) Het controleapparaat moet de op een geldige bestuurders ­
kaart of werkplaatskaart opgeslagen gegevens over de ac ­
tiviteiten van de bestuurder en plaatsen (zoals gespecifi ­
ceerd in de punten 4.5.3.1.9 en 4.5.3.1.11) bijwerken; ge ­
gevens over activiteiten en plaatsen worden manueel door 
de kaarthouder ingevoerd.  
140) Alle voorvallen die niet zijn gedefinieerd voor controleap ­
paraten van de eerste generatie worden niet op de bestuur ­
ders- en werkplaatskaarten opgeslagen.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 45  
141) Het bijwerken van gegevens op de tachograafkaart moet 
zodanig gebeuren dat, indien noodzakelijk en rekening 
houdend met de opslagcapaciteit de oudste gegevens 
door de nieuwe worden overschreven.  
142) In het geval van een schrijffout moet het controleapparaat 
dezelfde schrijfopdracht maximaal drie keer opnieuw uit ­
voeren. Wanneer de fout blijft optreden, moet de kaart 
defect en ongeldig worden verklaard.  
143) Voordat een bestuurderskaart uitgenomen wordt en nadat 
alle relevante gegevens op de kaart zijn opgeslagen, moet 
het controleapparaat de „gegevens van de kaartsessie” te ­
rugplaatsen.  
3.14.2  Registreren en opslaan op tachograafkaarten van de tweede gene ­
ratie  
144) Tachograafkaarten van de tweede generatie bevatten 2 ver ­
schillende kaarttoepassingen: de eerste is volledig identiek 
aan de TACHO-toepassing van de eerste generatie tacho ­
graafkaarten, de tweede toepassing, „TACHO_G2”, is be ­
schreven in hoofdstuk 4 en aanhangsel 2.  
145) Het controleapparaat moet de „gegevens van de kaartses ­
sie” onmiddellijk na de kaartinvoer op de bestuurderskaart 
of werkplaatskaart zetten.  
146) Het controleapparaat moet de gegevens die zijn opgeslagen 
in toepassingen van de tweede generatie op een geldige 
bestuurderskaart, bedrijfskaart, werkplaatskaart en/of con ­
trolekaart, bijwerken met behulp van alle noodzakelijke 
gegevens die verband houden met de periode waarin de 
kaart ingebracht is, en met alle noodzakelijke gegevens 
betreffende de kaarthouder. In hoofdstuk 4 is gespecifi ­
ceerd welke gegevens op die kaarten moeten worden opge ­
slagen.  
147) Het controleapparaat moet de op een geldige bestuurders ­
kaart of werkplaatskaart opgeslagen gegevens over de 
plaatsen van activiteiten van de bestuurder, alsmede de 
positiegegevens (zoals gespecificeerd in de punten 
4.5.3.1.9, 4.5.3.1.11, 4.5.3.2.9 en 4.5.3.2.11) bijwerken; 
gegevens over activiteiten en plaatsen worden manueel 
door de kaarthouder ingevoerd.  
148) Het bijwerken van gegevens op de tachograafkaart moet 
zodanig gebeuren dat, indien noodzakelijk en rekening 
houdend met de opslagcapaciteit van de kaart, de oudste 
gegevens door de nieuwe worden overschreven.  
149) In het geval van een schrijffout moet het controleapparaat 
dezelfde schrijfopdracht maximaal drie keer opnieuw uit ­
voeren. Wanneer de fout blijft optreden, moet de kaart 
defect en ongeldig worden verklaard.  
150) Voordat een bestuurderskaart uitgenomen wordt en nadat 
alle relevante gegevens op de twee kaarttoepassingen van 
de kaart zijn opgeslagen, moet het controleapparaat de 
„gegevens van de kaartsessie” terugplaatsen.  
3.15 Weergave  
151) Het display moet ten minste 20 tekens bevatten.  
152) De minimale tekengrootte moet 5 mm hoog en 3,5 mm 
breed zijn.  
153) Het display ondersteunt de tekens die zijn gespecificeerd 
in aanhangsel 1, hoofdstuk 4 „Tekensets”. Het display kan 
vereenvoudigde tekens gebruiken (bijv. letters met een 
accent kunnen zonder accent worden getoond, of kleine 
letters kunnen als hoofdletters worden getoond).  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 46  
154) Het display moet voorzien zijn van een voldoende sterke, 
niet verblindende verlichting.  
155) Aanwijzingen moeten aan de buitenzijde van het contro ­
leapparaat zichtbaar zijn.  
156) Het controleapparaat moet het volgende kunnen weer ­
geven:  
— standaardgegevens;  
— gegevens met betrekking tot waarschuwingssignalen;  
— gegevens met betrekking tot de toegang tot het menu;  
— andere door de gebruiker opgevraagde gegevens.  
Aanvullende informatie mag door het controleapparaat 
worden weergegeven indien deze duidelijk te onderschei ­
den is van de hierboven vermelde vereiste informatie.  
157) Het display van het controleapparaat moet de in aanhang ­
sel 3 vermelde pictogrammen of pictogramcombinaties ge ­
bruiken. Extra pictogrammen of pictogramcombinaties mo ­
gen ook op het display worden weergegeven wanneer ze 
duidelijk te onderscheiden zijn van de voornoemde picto ­
grammen of pictogramcombinaties.  
158) Wanneer het voertuig aan het rijden is, moet het display 
altijd ingeschakeld zijn.  
159) Het controleapparaat kan over een manuele of automati ­
sche voorziening beschikken om het display uit te schake ­
len wanneer het voertuig stilstaat.  
Het formaat van het display is gespecificeerd in aanhang ­
sel 5.  
3.15.1  Standaarddisplay  
160) Wanneer geen andere informatie getoond hoeft te worden, 
geeft het controleapparaat standaard de volgende informa ­
tie weer:  
— de plaatselijke tijd (de uitkomst van UTC-tijd + instel ­
ling door de bestuurder);  
— de werkingsmodus;  
— de lopende activiteiten van de bestuurder en de lo ­
pende activiteiten van de bijrijder;  
— informatie met betrekking tot de bestuurder:  
— indien zijn lopende activiteit RIJDEN is: zijn lopende 
rijtijd en zijn lopende cumulatieve rusttijd;  
— indien zijn lopende activiteit niet RIJDEN is: de lo ­
pende duur van zijn activiteit (sinds deze geselecteerd 
werd) en zijn lopende cumulatieve rusttijd.  
161) De gegevens met betrekking tot elke bestuurder moeten 
duidelijk en ondubbelzinnig worden weergegeven. Wan ­
neer de informatie met betrekking tot de bestuurder en 
de bijrijder niet tegelijkertijd kan worden getoond, geeft 
het controleapparaat standaard de informatie weer met be ­
trekking tot de bestuurder en kan de gebruiker de infor ­
matie met betrekking tot de bijrijder zichtbaar maken.  
162) Als het display niet breed genoeg is om standaard de 
werkingsmodus weer te geven, moet het controleapparaat 
kort de nieuwe werkingsmodus weergeven wanneer deze 
wijzigt.  
163) Het controleapparaat moet bij kaartinvoer kort de naam 
van de kaarthouder weergeven.  ▼B
02016R0799 — NL — 26.02.2020 — 002.001 — 47  
164) Wanneer een „NIET VERPLICHT” of „FERRY/TREIN”- 
omstandigheid wordt geopend, moet het standaarddisplay 
door middel van het relevante pictogram weergeven dat 
die specifieke omstandigheid geopend is (daarbij wordt 
aanvaard dat de lopende activiteit van de bestuurder niet 
tegelijkertijd wordt getoond).  
3.15.2 Waarschuwingsdisplay 
165) Het controleapparaat moet waarschuwingssignalen voor ­
namelijk weergeven door middel van de pictogrammen 
van aanhangsel 3, die waar nodig worden aangevuld met 
extra numerieke informatie. Een letterlijke beschrijving 
van de waarschuwing kan in de voorkeurstaal van de be ­
stuurder worden toegevoegd.  
3.15.3 Toegang tot het menu  
166) Het controleapparaat moet de benodigde opdrachten door 
middel van een geschikte menustructuur leveren.  
3.15.4 Overige displays  
167) Er kan voor een selectieve weergave worden geopteerd:  
— de UTC-datum en UTC-tijd, en offset van plaatselijke 
tijd; 
— de inhoud van de zes afgedrukte documenten in het ­
zelfde formaat als de afdrukken zelf;  
— de ononderbroken rijtijd en cumulatieve rusttijd van de 
bestuurder;  
— de ononderbroken rijtijd en cumulatieve rusttijd van de 
bijrijder;  
— de cumulatieve rijtijd van de bestuurder van de voor ­
bije en de lopende week;  
— de cumulatieve rijtijd van de bijrijder van de voorbije 
en de lopende week;  
facultatief:  
— de lopende duur van activiteit van de bijrijder (sinds 
die geselecteerd werd);  
— de cumulatieve rijtijd van de bestuurder van de lo ­
pende week;  
— de cumulatieve rijtijd van de bijrijder voor de lopende 
dagelijkse werkperiode;  
— de cumulatieve rijtijd van de bestuurder voor de lo ­
pende dagelijkse werkperiode.  
168) De inhoud van de afdrukken moet sequentieel, regel voor 
regel, worden weergegeven. Indien de breedte van het dis ­
play minder dan 24 tekens telt, moet de gebruiker de vol ­
ledige informatie op een geschikte manier (een aantal re ­
gels, scrollen, …) aangeboden krijgen.  
Afgedrukte regels voor handgeschreven informatie kunnen 
op het display worden weggelaten.  
3.16 Afdrukken  
169) Het controleapparaat moet informatie uit zijn geheugen 
en/of van de tachograafkaart overeenkomstig de zeven on ­
derstaande documenten afdrukken:  
— dagelijkse afdruk van de activiteiten van de bestuurder 
op de kaart;  
— dagelijkse afdruk van de activiteiten van de bestuurder 
in de VU;  
— afdruk van voorvallen en fouten op de kaart;  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 48  
— afdruk van voorvallen en fouten in de VU;  
— afdruk van technische gegevens;  
— afdruk van snelheidsoverschrijdingen;  
— tachograafkaartgegevens voor een bepaalde VU (zie 
punt 3.12.16).  
De gedetailleerde vorm en inhoud van deze afdrukken zijn 
gespecificeerd in aanhangsel 4.  
Aan het einde van de afdruk kunnen aanvullende gegevens 
worden verstrekt.  
Het controleapparaat mag extra afdrukken leveren, indien 
deze duidelijk te onderscheiden zijn van de zeven voor ­
noemde documenten.  
170) De „dagelijkse afdruk van de activiteiten van de bestuur ­
der op de kaart” en de „afdruk van voorvallen en fouten 
op de kaart” zijn alleen beschikbaar wanneer een bestuur ­
derskaart of een werkplaatskaart in het controleapparaat 
ingebracht is. Het controleapparaat werkt de opgeslagen 
gegevens op de betrokken kaart bij voordat met afdrukken 
wordt begonnen.  
171) Om de „dagelijkse afdruk van de activiteiten van de be ­
stuurder op de kaart” of de „afdruk van voorvallen en 
fouten op de kaart” te leveren moet het controleapparaat:  
— automatisch de bestuurderskaart of de werkplaatskaart 
selecteren indien een van deze kaarten ingebracht is, 
dan wel  
— een opdracht geven om de bronkaart te selecteren of 
om de kaart in de kaartlezer van de bestuurder te se ­
lecteren indien twee kaarten in het controleapparaat 
zijn ingebracht.  
172) De printer moet 24 tekens per regel afdrukken.  
173) De minimale tekengrootte moet 2,1 mm hoog en 1,5 mm 
breed zijn.  
174) De printer ondersteunt de tekens zoals gespecificeerd in 
aanhangsel 1, hoofdstuk 4 „Tekensets”.  
175) De printers zijn zo ontworpen dat zij de bedoelde afdruk ­
ken kunnen maken met een dusdanige afdrukscherpte dat 
leesfouten worden vermeden.  
176) Afmetingen en gegevens moeten bij normale luchtvochtig ­
heid (10-90 %) en temperatuur behouden blijven.  
177) Het door het controleapparaat gebruikte typegekeurde 
printpapier moet over het relevante typegoedkeuringsmerk 
beschikken. Daarnaast moet op het papier vermeld staan 
voor welk(e) type(s) controleapparatuur dit papier geschikt 
is. 
178) De afdrukken moeten onder normale opslagomstandighe ­
den voor wat betreft lichtsterkte, vochtigheid en tempera ­
tuur, gedurende ten minste twee jaar duidelijk leesbaar en 
identificeerbaar blijven.  
179) Afdrukken moeten ten minste voldoen aan de in aanhang ­
sel 9 gedefinieerde testspecificaties.  
180) Bovendien moeten op deze documenten geschreven aan ­
tekeningen, zoals de handtekening van de bestuurder, kun ­
nen worden aangebracht.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 49  
181) Op „paper out” voorvallen tijdens het afdrukken reageert 
het controleapparaat door, zodra het papier is bijgevuld, 
het afdrukken vanaf het begin te hernemen of door te gaan 
met het afdrukken en een ondubbelzinnige referentie naar 
het reeds afgedrukte gedeelte te geven.  
3.17 Waarschuwingen  
182) Het controleapparaat moet de bestuurder waarschuwen als 
een voorval en/of fout wordt gedetecteerd.  
183) Een waarschuwing met betrekking tot een onderbreking in 
de stroomvoorziening mag worden uitgesteld totdat de 
stroomvoorziening is hersteld.  
184) Het controleapparaat moet de bestuurder 15 minuten van 
tevoren waarschuwen bij een naderende overschrijding van 
de maximale rijtijd, en op het tijdstip van overschrijding 
zelf. 
185) Waarschuwingen moeten visueel worden gegeven. Daar ­
naast kunnen akoestische waarschuwingssignalen worden 
gegeven.  
186) De visuele waarschuwingssignalen moeten voor de gebrui ­
ker duidelijk herkenbaar zijn, ze moeten in het gezichts ­
veld van de bestuurder liggen en zowel overdag als 's 
nachts duidelijk leesbaar zijn.  
187) Visuele waarschuwingssignalen kunnen in het controleap ­
paraat ingebouwd zijn en/of zich buiten het controleap ­
paraat bevinden.  
188) In dat geval is een „T”-teken aangebracht.  
189) De waarschuwingssignalen moeten ten minste 30 seconden 
duren, tenzij de bestuurder deze bevestigt door op een of 
meer specifieke toetsen van het controleapparaat te druk ­
ken. Deze eerste bevestiging mag de getoonde reden van 
de waarschuwing zoals bedoeld in de volgende alinea niet 
uitwissen.  
190) De reden van de waarschuwing moet op het controleap ­
paraat worden getoond en zichtbaar blijven totdat de be ­
stuurder deze bevestigt door op een specifieke toets van 
het controleapparaat te drukken of een opdracht te geven.  
191) Aanvullende waarschuwingssignalen kunnen worden inge ­
bouwd, mits de bestuurder hierdoor niet in verwarring 
wordt gebracht met betrekking tot de reeds gedefinieerde 
waarschuwingssignalen.  
3.18 Downloaden van gegevens met externe media  
192) Het controleapparaat moet op verzoek vanuit zijn geheu ­
gen of vanaf een bestuurderskaart via de kalibrerings- 
/downloadverbinding gegevens naar externe opslagmedia 
kunnen doorsturen. Het controleapparaat werkt de opge ­
slagen gegevens op de betrokken kaart bij voordat met 
het downloaden van gegevens wordt begonnen.  
193) Verder is er een optie waardoor het controleapparaat in 
elke werkingsmodus gegevens via een willekeurig ander 
middel naar een door dit kanaal geauthenticeerd bedrijf 
kan doorsturen. In dit geval zijn de gegevenstoegangsrech ­
ten in de bedrijfsmodus van toepassing op de gegevens ­
overdracht.  
194) Opgeslagen gegevens worden door het downloaden niet 
gewijzigd of verwijderd.  
195) De elektrotechnische interface van de kalibrerings- 
/downloadverbinding is gespecificeerd in aanhangsel 6.  
196) Downloadprotocollen zijn gespecificeerd in aanhangsel 7.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 50  
3.19 Communicatie op afstand met het oog op gerichte wegcontroles  
197) Wanneer de motor aan staat, bewaart de voertuigunit in 
het systeem voor communicatie op afstand om de 60 se ­
conden de recentste gegevens die nodig zijn voor gerichte 
wegcontroles. Die gegevens worden versleuteld en onder ­
tekend overeenkomstig de aanhangsels 11 en 14.  
198) Gegevens die op afstand moeten worden gecontroleerd, 
kunnen via een draadloze verbinding worden gelezen 
door de in aanhangsel 14 gespecificeerde apparatuur.  
199) De gegevens die nodig zijn voor gerichte wegcontroles 
hebben betrekking op:  
— de recentste inbreuk op de beveiliging;  
— de langste stroomstoring;  
— fout in de sensor;  
— fout in de bewegingsgegevens;  
— tegenstrijdige bewegingsgegevens;  
— rijden zonder geldige kaart;  
— invoeren van een kaart tijdens het rijden;  
— tijdafstellingsgegevens;  
— kalibreringsgegevens, waaronder de datums van de 
laatste twee bewaarde kalibreringsrecords;  
— het voertuigkenteken;  
— de door de tachograaf geregistreerde snelheid.  
3.20 Doorsturen van gegevens naar aanvullende externe apparaten  
▼M1 
200) Het controleapparaat kan worden uitgerust met gestandaar ­
diseerde interfaces die ervoor zorgen dat een extern appa ­
raat kan gebruikmaken van de door de tachograaf in ope ­
rationele of kalibreringsmodus geregistreerde of gegene ­
reerde gegevens.  
Aanhangsel 13 bevat specificaties en normen voor een 
facultatieve ITS-interface. Andere voertuigunitinterfaces 
zijn eveneens toegestaan indien zij volledig voldoen aan 
de vereisten van aanhangsel 13 inzake de minimumlijst 
van gegevens, beveiliging en instemming door de bestuur ­
der. 
De instemming door de bestuurder geldt niet voor gege ­
vens die door het controleapparaat naar het voertuignet ­
werk worden verstuurd. Wanneer de persoonsgegevens 
die in het voertuignetwerk worden ingevoerd, verder wor ­
den verwerkt buiten het voertuignetwerk, is het de verant ­
woordelijkheid van de voertuigfabrikant om dat proces in 
overeenstemming te brengen met Verordening (EU) 
2016/679 (de „algemene verordening gegevensbescher ­
ming”).  
De instemming door de bestuurder geldt evenmin voor 
tachograafgegevens die worden gedownload naar een op 
afstand aangesloten bedrijf (voorschrift 193), aangezien dit 
scenario wordt gemonitord door het toegangsrecht van de 
bedrijfskaart.  
De volgende eisen zijn van toepassing voor ITS-gegevens 
die via die interface worden verstrekt:  
— de gegevens zijn een set geselecteerde bestaande data 
uit de data dictionary van de tachograaf (aanhangsel 
1); ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 51  
— een deel van die geselecteerde gegevens zijn aangeduid 
als „persoonsgegevens”;  
— de subset van „persoonsgegevens” is alleen beschik ­
baar na de controleerbare bevestiging door de bestuur ­
der dat hij ermee instemt dat zijn persoonsgegevens 
desgevallend het voertuignetwerk mogen verlaten;  
— wanneer de bestuurderskaart is ingebracht, kan de be ­
stuurder op elk moment via het menu zijn instemming 
geven of intrekken;  
— de dataset en -subset worden in een straal rond de 
cabine van het voertuig verzonden via het draadloos 
bluetoothprotocol en om de minuut bijgewerkt;  
— de verbinding tussen het extern apparaat en de ITS- 
interface wordt beveiligd door een specifieke willekeu ­
rige PIN-code van minstens 4 cijfers, die via het dis ­
play van elke voertuigunit wordt opgeslagen en kan 
worden geraadpleegd;  
— de ITS-interface mag de correcte werking en beveili ­
ging van de voertuigunit in geen geval verstoren of 
aantasten.  
Bovenop de set van geselecteerde bestaande gegevens, die 
als minimumlijst geldt, mogen aanvullende gegevens wor ­
den doorgestuurd, voor zover het niet om persoonsgege ­
vens gaat.  
Het controleapparaat moet de instemmingsstatus van de 
bestuurder kunnen meedelen aan andere platforms in het 
voertuignetwerk.  
Wanneer het contact van het voertuig AAN staat, worden 
die gegevens permanent doorgestuurd.  
▼B 
201) Om de achterwaartse compatibiliteit te waarborgen mogen 
tachografen ook worden voorzien van de in bijlage 1B van 
Verordening (EEG) nr. 3821/85, als laatstelijk gewijzigd, 
gespecificeerde seriële verbinding. Voor de verzending van 
persoonsgegevens is steeds de instemming van de bestuur ­
der vereist.  
3.21 Kalibrering  
202) De kalibreringsfunctie moet:  
— de bewegingssensor automatisch aan de VU koppelen;  
— de externe GNSS-module desgevallend automatisch 
koppelen aan de VU;  
— de constante van het controleapparaat (k) digitaal aan ­
passen aan de kenmerkende coëfficiënt van het voer ­
tuig (w);  
— de huidige tijd aanpassen binnen de geldigheidsperiode 
van de ingebrachte werkplaatskaart;  
— de lopende kilometerstand bijstellen;  
— de in het geheugen opgeslagen identificatiegegevens 
van de bewegingssensor bijwerken;  
— de in het geheugen opgeslagen identificatiegegevens 
van de externe GNSS-module bijwerken;  ▼M1
 02016R0799 — NL — 26.02.2020 — 002.001 — 52  
— types en identificatienummers van alle aanwezige ver ­
zegelingen bijwerken;  
— andere parameters van het controleapparaat bijwerken 
of bevestigen: VIN van het voertuig, w, l, bandenmaat 
en instelling van de snelheidsbegrenzer, indien van 
toepassing.  
203) Indien de voorwaarden van aanhangsel 15 zijn vervuld, 
moet de kalibreringsfunctie het bovendien mogelijk maken 
het gebruik van tachograafkaarten van de eerste generatie 
in het controleapparaat op te heffen.  
204) Het verbinden van de bewegingssensor met de VU omvat 
ten minste:  
— het bijwerken van installatiegegevens van de be ­
wegingssensor die door de bewegingssensor worden 
bewaard (indien nodig);  
— het kopiëren van essentiële identificatiegegevens van 
de bewegingssensor naar het geheugen van de VU.  
205) Het koppelen van de externe GNSS-module aan de VU 
omvat ten minste:  
— het bijwerken van de installatiegegevens van de ex ­
terne GNSS-module die in dat systeem zijn opgeslagen 
(indien nodig);  
— het kopiëren van de vereiste identificatiegegevens van 
de externe GNSS-module naar het geheugen van de 
VU, met inbegrip van het serienummer van de externe 
GNSS-module.  
Na de koppeling wordt de GNSS-positie-informatie geveri ­
fieerd.  
206) De kalibreringsfunctie kan via de kalibrerings-/download ­
verbinding essentiële gegevens invoeren in overeenstem ­
ming met het in aanhangsel 8 gedefinieerde kalibrerings ­
protocol. Met de kalibreringsfunctie kunnen ook op andere 
manieren essentiële gegevens worden ingevoerd.  
3.22 Kalibreringscontrole langs de weg  
207) Via de functie voor kalibreringscontroles langs de weg 
moet het mogelijk zijn de serienummers van de op het 
moment van het verzoek aan de VU gekoppelde be ­
wegingssensor (al dat niet geïntegreerd in de adapter) en 
van de externe GNSS-module (indien aanwezig) op te 
vragen.  
208) De nummers moeten op het display van de voertuigunit 
minstens kunnen worden gelezen via commando's in de 
menu's.  
209) Met de functie kalibreringscontrole langs de weg moet de 
I/O-modus van de in aanhangsel 6 gespecificeerde I/O- 
signaallijn voor kalibrering via de K-lijninterface kunnen 
worden geselecteerd. Dat gebeurt via de EDU/Adjustment/ 
Sessie als gespecificeerd in aanhangsel 8, deel 7 „Controle 
van testpulsen — invoer-/uitvoercontrole functionele unit”.  
3.23 Tijdafstelling  
210) Met de tijdafstellingsfunctie kan de lopende tijd worden 
bijgesteld. De tijdafstelling gebeurt op basis van twee 
tijdsregistratiebronnen in het controleapparaat: 1) de in ­
terne klok van de VU, 2) de GNSS-ontvanger.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 53  
211) De tijdsbepaling van de interne klok van de VU wordt om 
de 12 uur automatisch bijgewerkt. Wanneer die bijstelling 
niet mogelijk is omdat er geen GNSS-signaal beschikbaar 
is, gebeurt de tijdsafstelling zodra de VU toegang krijgt tot 
een geldige tijdsaanduiding van de GNSS-ontvanger, naar ­
gelang het contact al dan niet aan staat. De referentietijd 
voor de automatische tijdsafstelling van de interne klok 
van de VU wordt afgeleid van de GNSS-ontvanger.  
▼B 
212) In de kalibreringsmodus kan de tijdafstellingsfunctie voor 
de bijwerking van de huidige tijd worden geactiveerd.  
3.24 Prestatiekenmerken  
213) De voertuigunit moet volledig operationeel zijn bij tempe ­
raturen van – 20 °C tot 70 °C, de externe GNSS-module 
bij temperaturen van – 20 °C tot 70 °C, en de bewegings ­
sensor bij temperaturen van – 40 °C tot 135 °C. De gege ­
vens in het geheugen worden bewaard tot een temperatuur 
van – 40 °C.  
214) De tachograaf moet correct functioneren binnen het voch ­
tigheidsbereik van 10 % tot 90 %.  
215) De in slimme tachografen gebruikte zegels moeten bestand 
zijn tegen dezelfde omstandigheden als die welke gelden 
voor de onderdelen waarop ze zijn aangebracht.  
216) Het controleapparaat moet worden beveiligd tegen over ­
spanning, polariteitsomkering en kortsluiting.  
217) De bewegingssensoren moeten:  
— reageren op een magnetisch veld dat de detectie van 
beweging van het voertuig stoort. In dat geval wordt 
door de voertuigunit een fout in de sensor (voorschrift 
88) geregistreerd en opgeslagen, ofwel  
— een aftastelement bevatten dat beschermd is tegen, of 
ongevoelig is voor, een magnetisch veld.  
218) Het controleapparaat en de externe GNSS-module moeten 
voldoen aan het internationaal Reglement VN-ECE R10 en 
beveiligd zijn tegen elektrostatische ontladingen en stoot ­
spanning.  
3.25 Materialen  
219) Alle onderdelen van het controleapparaat moeten uitge ­
voerd zijn in materiaal van voldoende stabiliteit en mecha ­
nische sterkte en met onveranderlijke elektrische en mag ­
netische eigenschappen.  
220) Alle inwendige delen van het apparaat moeten bij normale 
gebruiksomstandigheden beschermd zijn tegen vocht en 
stof. 
221) De voertuigunit en de externe GNSS-module moeten vol ­
doen aan beschermingsklasse IP 40 en de bewegingssensor 
moet voldoen aan beschermingsklasse IP 64, volgens IEC- 
norm IEC 60529:1989, m.i.v. A1:1999 en A2:2013.  
222) Het ergonomisch ontwerp van het controleapparaat moet 
voldoen aan de toepasselijke technische specificaties.  ▼M1
 02016R0799 — NL — 26.02.2020 — 002.001 — 54  
223) Het controleapparaat moet worden beschermd tegen on ­
opzettelijke beschadiging.  
3.26 Opschriften  
224) Indien het controleapparaat de kilometerstand en snelheid 
van het voertuig weergeeft, moeten onderstaande aandui ­
dingen op het display voorkomen:  
— bij het getal voor de afstandsaanduiding, de voor het 
meten van de afstand gebruikte eenheid, weergegeven 
door het symbool „km”;  
— bij het getal voor de snelheidsaanduiding, de aandui ­
ding „km/h”.  
Het controleapparaat kan ook de snelheid in mijl per uur 
weergeven, in dat geval wordt voor de snelheidsaandui ­
ding het symbool „mph” gebruikt. Het controleapparaat 
kan ook de afstand in mijl per uur weergeven, in welk 
geval voor de afstand het symbool „mi” gebruikt wordt.  
▼M1 
225) Een identificatieplaatje met de volgende gegevens moet op 
elk afzonderlijk samenstellend deel van het controleap ­
paraat worden aangebracht:  
— naam van de fabrikant en zijn adres;  
— onderdeelnummer en bouwjaar van het apparaat;  
— serienummer;  
— typegoedkeuringsmerk.  
226) Wanneer er onvoldoende fysieke ruimte is voor alle voor ­
noemde gegevens, moet ten minsten het volgende op het 
identificatieplaatje zijn vermeld: de naam of het logo van 
de fabrikant en het onderdeelnummer.  
▼B 
4 FUNCTIONELE EN CONSTRUCTIE-EISEN VOOR TACHO ­
GRAAFKAARTEN  
4.1 Zichtbare gegevens  
De voorzijde bevat:  
227) de woorden „Bestuurderskaart”, „Controlekaart”, „Werk ­
plaatskaart” dan wel „Bedrijfskaart”, in hoofdletters, ge ­
drukt in de officiële taal/talen van de lidstaat die de kaart 
afgeeft;  
228) de naam van de lidstaat die de kaart afgeeft (facultatief);  
229) het kenteken van de lidstaat die de kaart afgeeft, negatief 
afgedrukt in een door twaalf gele sterren omringde blauwe 
rechthoek. De kentekens zijn: 
B 
BG 
CZ 
CY België 
Bulgarije 
Tsjechië 
Cyprus  LV 
L 
LT 
M Letland 
Luxemburg 
Litouwen 
Malta  
DK Denemarken  NL  Nederland  
D 
EST Duitsland 
Estland  A 
PL Oostenrijk 
Polen  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 55  
GR Griekenland  P 
RO 
SK 
SLO  Portugal 
Roemenië 
Slowakije 
Slovenië  
E Spanje  FIN  Finland  
F 
HR 
H Frankrijk 
Kroatië 
Hongarije  S Zweden  
IRL Ierland  UK  Verenigd Konink ­
rijk 
I Italië  
230) de gegevens die specifiek zijn voor de afgegeven kaart, 
met de volgende nummers:  
Bestuurderskaart  Controlekaart  Bedrijfs- of Werkplaatskaart  
1. Naam bestuurder  Naam controle-instantie  Naam bedrijf of werkplaats  
2. Voorna(a)men van de be ­
stuurder  Naam controleur 
(indien van toepassing)  Naam kaarthouder 
(indien van toepassing)  
3. Geboortedatum van de 
bestuurder  Voorna(a)men controleur 
(indien van toepassing)  Voorna(a)m(en) kaarthouder 
(indien van toepassing)  
4.a Datum van afgifte van de kaart  
4.b Vervaldatum van de kaart  
4.c Naam van de bevoegde instantie die het rijbewijs afgeeft (mag op achterzijde worden 
afgedrukt)  
4.d Een ander nummer dan dat in rubriek 5, dat nuttig is voor de administratie van de 
kaart (facultatief)  
5. a Nummer van het rijbewijs 
(op het moment van af ­
gifte van de bestuurders ­
kaart)  — —  
5. b Kaartnummer  
6. Foto bestuurder  Foto controleur (faculta ­
tief) Foto installateur (facultatief)  
7. Handtekening houder (facultatief)  
8. Woon- of verblijfplaats of 
postadres van de houder 
(facultatief)  Postadres controle-instan ­
tie Postadres bedrijf of werk ­
plaats  
231) datums worden geschreven in het formaat „dd/mm/jjjj” of 
„dd.mm.jjjj” (dag, maand, jaar).  
De achterkant bevat:  
232) een toelichting bij de genummerde rubrieken op kant 1 
van de kaart;  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 56  
233) Zo nodig, en met de uitdrukkelijke schriftelijke instem ­
ming van de houder, kunnen gegevens die geen verband 
houden met de administratie van de kaart in deze ruimte 
worden opgenomen; de toevoeging van deze vermeldingen 
heeft geen gevolgen voor het gebruik van het model als 
tachograafkaart.  
234) Tachograafkaarten moeten worden gedrukt met de vol ­
gende achtergrondkleuren:  
— bestuurderskaart: wit,  
— controlekaart: blauw,  
— werkplaatskaart: rood,  
— bedrijfskaart: geel.  
235) Tachograafkaarten moeten ten minste de volgende eigen ­
schappen hebben om de kaart te beschermen tegen ver ­
valsing en misbruik:  
— een beveiligd achtergrondontwerp met fijne guilloche ­
patronen en regenboogdruk,  
— bij de foto moeten het beveiligd achtergrondontwerp 
en de foto elkaar overlappen,  
— ten minste één tweekleurige microzeefdrukregel.
  
► (1) M1 
236) Na overleg met de Commissie kunnen lidstaten kleuren of 
aanduidingen, zoals nationale symbolen of beveiligings ­
tekens, toevoegen, onverminderd de andere bepalingen 
van deze bijlage.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 57  
237) Tijdelijke kaarten als bedoeld in artikel 26, lid 4, van 
Verordening (EU) nr. 165/2014 moeten voldoen aan de 
bepalingen in deze bijlage.  
4.2 Beveiliging  
De beveiliging van het systeem beoogt het beschermen van de 
integriteit en authenticiteit van de tussen de kaarten en het contro ­
leapparaat uitgewisselde gegevens, het beschermen van de integriteit 
en authenticiteit van de gegevens die van de kaarten worden ge ­
download, het beletten van bepaalde schrijfopdrachten op de kaarten 
door andere apparaten dan controleapparaten, het coderen van be ­
paalde gegevens, het uitsluiten van mogelijke vervalsing van op de 
kaarten opgeslagen gegevens, alsmede het voorkomen van manipu ­
laties en het detecteren van pogingen daartoe.  
238) Teneinde het systeem te beveiligen, moeten tachograaf ­
kaarten voldoen aan de in de aanhangsels 10 en 11 vast ­
gestelde beveiligingseisen.  
239) Tachograafkaarten moeten door andere apparatuur, zoals 
computers, kunnen worden gelezen.  
4.3 Normen  
240) Tachograafkaarten moeten voldoen aan de volgende nor ­
men:  
— ISO/IEC 7810 Identificatiekaarten — Fysieke kenmer ­
ken 
— ISO/IEC 7816 Identificatiekaarten — Kaarten met 
geïntegreerde schakeling(en)  
— Deel 1: Fysieke kenmerken,  
— Deel 2: Afmetingen en plaats van de contacten 
(ISO/IEC 7816-2:2007),  
— Deel 3: Elektrische eigenschappen van de contac ­
ten, transmissieprotocollen (ISO/IEC 7816-3:2006),  
— Deel 4: Inhoud van de communicatie, datastructuur 
van de chipkaart, veiligheidsarchitectuur en toe ­
gangsmechanismen (ISO/IEC 7816-4:2013 + Cor 
1:2014),  
— Deel 6: Interindustriële data-uitwisselingselementen 
(ISO/IEC 7816-6:2004 + Cor 1:2006),  
— Deel 8: Veiligheidsrelevante commando's (ISO/IEC 
7816-8:2004).  
— Tachograafkaarten worden getest overeenkomstig ISO/ 
IEC 10373-3:2010 Identificatiekaarten — Testmetho ­
des — deel 3: Kaarten met geïntegreerde schake ­
ling(en) met contacten en gerelateerde interfaces.  
4.4 Milieu- en elektrotechnische specificaties  
241) De tachograafkaart moet onder alle klimatologische om ­
standigheden die zich normaliter op het grondgebied van 
de Gemeenschap voordoen, en ten minste binnen het tem ­
peratuurbereik van – 25 °C tot + 70 °C met incidentele 
pieken tot + 85 °C naar behoren kunnen functioneren; 
„incidenteel” betekent niet meer dan 4 uur per keer en 
niet meer dan 100 keer tijdens de levensduur van de kaart.  
242) Tachograafkaarten moeten binnen het vochtigheidsbereik 
van 10 % tot 90 % naar behoren kunnen functioneren.  
243) Tachograafkaarten moeten vijf jaar lang naar behoren kun ­
nen functioneren indien de vastgestelde milieu- en elek ­
trotechnische grenswaarden niet overschreden worden.  
244) Tijdens de werking moeten tachograafkaarten voldoen aan 
de ECE-norm R10 inzake elektromagnetische compatibili ­
teit en moeten de kaarten beveiligd zijn tegen elektrosta ­
tische ontladingen.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 58  
4.5 Opslag van gegevens  
Voor de toepassing van dit punt  
— wordt de tijd geregistreerd met een resolutie van 1 minuut, tenzij 
anders gespecificeerd;  
— worden kilometerstanden geregistreerd met een resolutie van 1 
kilometer;  
— wordt de snelheid geregistreerd met een resolutie van 1 km/h;  
— worden posities (lengte en breedte) geregistreerd in graden en 
minuten, met een resolutie van 1/10 minuut.  
De functies, opdrachten en logische structuren van de tachograaf ­
kaart die voldoen aan de gegevensopslageisen, zijn gespecificeerd in 
aanhangsel 2.  
Tenzij anders bepaald, worden gegevens op tachograafkaarten op 
dusdanige wijze opgeslagen dat de oudste gegevens door nieuwe 
worden overschreven wanneer de beschikbare geheugenruimte 
voor bepaalde records op is.  
245) Dit punt specificeert de minimale opslagcapaciteit voor de 
verschillende gegevensbestanden. Tachograafkaarten moe ­
ten de effectieve opslagcapaciteit van deze gegevens ­
bestanden aan het controleapparaat meedelen.  
246) De opslag van aanvullende gegevens op tachograafkaarten, 
in verband met eventuele andere toepassingen waarvoor de 
kaart als drager fungeert, gebeurt met inachtneming van 
Richtlijn 95/46/EG, Richtlijn 2002/58/EG en artikel 7 van 
Verordening (EU) nr. 165/2014.  
247) Elk stambestand (master file, MF) van een tachograafkaart 
bevat tot vijf hoofdbestanden (elementary files, EF) voor 
het beheer van de kaart en de identificatie van de toepas ­
sing en chip, en twee toepassingsgerichte bestanden (dedi ­
cated files, DF):  
— DF tachograaf bevat de toepassing die toegankelijk is 
voor voertuigunits van de eerste generatie en staat ook 
op de eerste generatie tachograafkaarten;  
— DF tachograaf_G2 bevat de toepassing die alleen toe ­
gankelijk is voor voertuigunits van de tweede generatie 
en staat alleen op tachograafkaarten van de tweede 
generatie.  
De volledige structuur van de tachograafkaarten is gespe ­
cificeerd in aanhangsel 2.  
4.5.1  Hoofdbestanden voor identificatie en kaartbeheer  
4.5.2  IC-kaartidentificatie  
248) Tachograafkaarten moeten de volgende smartcard-identifi ­
catiegegevens kunnen opslaan:  
— klokstop;  
— serienummer van de kaart (inclusief productiereferen ­
ties);  
— typegoedkeuringsnummer van de kaart;  
— persoonlijke identificatie van de kaart (ID);  
— embedder ID;  
— IC-identificatiesymbool;  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 59  
4.5.2.1 C h i p i d e n t i f i c a t i e  
249) Tachograafkaarten moeten de volgende identificatiegege ­
vens van het Integrated Circuit (IC) kunnen opslaan:  
— IC-serienummer,  
— IC-productiereferenties.  
4.5.2.2 D I R ( a l l e e n a a n w e z i g i n t a c h o g r a a f k a a r t e n v a n 
d e t w e e d e g e n e r a t i e )  
250) Tachograafkaarten moeten de in aanhangsel 2 gespecifi ­
ceerde toepassingsidentificatiegegevensobjecten kunnen 
opslaan.  
4.5.2.3 A T R - i n f o r m a t i e ( v o o r w a a r d e l i j k , a l l e e n a a n ­
w e z i g i n t a c h o g r a a f k a a r t e n v a n d e t w e e d e g e n e ­
r a t i e )  
251) Tachograafkaarten moeten de volgende uitgebreide infor ­
matiegegevensobjecten kunnen opslaan:  
— wanneer de tachograafkaart uitgebreide velden onder ­
steunt, het in aanhangsel 2 gespecificeerde uitgebreide 
informatiegegevensobject.  
4.5.2.4 U i t g e b r e i d e i n f o r m a t i e ( v o o r w a a r d e l i j k , a l l e e n 
a a n w e z i g i n t a c h o g r a a f k a a r t e n v a n d e t w e e d e 
g e n e r a t i e )  
252) Tachograafkaarten moeten de volgende uitgebreide infor ­
matiegegevensobjecten kunnen opslaan:  
— wanneer de tachograafkaart uitgebreide velden onder ­
steunt, de in aanhangsel 2 gespecificeerde uitgebreide 
informatiegegevensobjecten.  
4.5.3  Bestuurderskaart  
4.5.3.1 T a c h o g r a a f t o e p a s s i n g e n ( t o e g a n k e l i j k v o o r 
v o e r t u i g u n i t s v a n d e e e r s t e e n t w e e d e g e n e r a t i e )  
4.5.3.1.1 Toepassingsidentificatie  
253) Een bestuurderskaart moet de volgende toepassingsidenti ­
ficatiegegevens kunnen opslaan:  
— toepassingsidentificatie van de tachograaf;  
— type tachograafkaartidentificatie.  
4.5.3.1.2 Sleutels en certificaten  
254) Een bestuurderskaart moet een aantal cryptografische sleu ­
tels en certificaten kunnen opslaan overeenkomstig de spe ­
cificaties in aanhangsel 11, deel A.  
4.5.3.1.3 Identificatie van de kaart  
255) Een bestuurderskaart moet de volgende kaartidentificatie ­
gegevens kunnen opslaan:  
— kaartnummer;  
— lidstaat van afgifte, instantie van afgifte, datum van 
afgifte;  
— datum van afgifte en vervaldatum van de kaart.  
4.5.3.1.4 Identificatie van de kaarthouder  
256) Een bestuurderskaart moet de volgende identificatiegege ­
vens van de kaarthouder kunnen opslaan:  
— naam van de houder;  
— voorna(a)m(en) van de houder;  
— geboortedatum;  
— voorkeurstaal.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 60  
4.5.3.1.5 Kaartgegevens downloaden  
257) Een bestuurderskaart moet de volgende gegevens inzake 
downloads opslaan:  
— datum en tijdstip van het downloaden van de laatste 
kaart (voor andere doeleinden dan controle).  
258) Een bestuurderskaart moet één van deze records kunnen 
bewaren.  
4.5.3.1.6 Informatie over het rijbewijs  
259) Een bestuurderskaart moet de volgende rijbewijsgegevens 
kunnen opslaan:  
— lidstaat van afgifte, autoriteit van afgifte;  
— rijbewijsnummer (op het moment van afgifte van de 
kaart).  
4.5.3.1.7 Gegevens over voorvallen  
Voor de toepassing van dit punt wordt de tijd geregistreerd met een 
resolutie van 1 seconde.  
260) Een bestuurderskaart moet gegevens kunnen opslaan over 
de volgende voorvallen die door het controleapparaat ge ­
detecteerd zijn terwijl de kaart was ingebracht:  
— tijdsoverlapping (indien deze kaart het voorval heeft 
veroorzaakt);  
— kaartinvoer tijdens het rijden (indien het voorval be ­
trekking heeft op deze kaart);  
— laatste kaartsessie niet correct afgesloten (indien het 
voorval betrekking heeft op deze kaart);  
— onderbreking in de stroomvoorziening;  
— fout in de bewegingsgegevens;  
— pogingen tot inbreuk in de beveiliging:  
261) Een bestuurderskaart moet de volgende gegevens over 
deze voorvallen kunnen opslaan:  
— code van het voorval;  
— datum en tijdstip van het begin van het voorval (of van 
de kaartinvoer indien het voorval op dat moment 
plaatsvond);  
— datum en tijdstip van het einde van het voorval (of van 
de kaartinvoer indien het voorval op dat moment 
plaatsvond);  
— kentekennummer en lidstaat van registratie van het 
voertuig waarin het voorval plaatsvond.  
Aantekening: in het geval van „tijdsoverlapping”:  
— moeten de datum en het tijdstip van het begin van het 
voorval overeenkomen met de datum en het tijdstip 
waarop de kaart uit het vorige voertuig is uitgenomen;  
— moeten de datum en het tijdstip van het einde van het 
voorval overeenkomen met de datum en het tijdstip 
van kaartinvoer in het huidige voertuig;  
— moeten de voertuiggegevens overeenkomen met die 
van het voertuig dat het voorval heeft veroorzaakt.  
Aantekening: in het geval van „laatste kaartsessie niet 
correct afgesloten”:  
— moeten de datum en het tijdstip van het begin van het 
voorval overeenkomen met de datum en het tijdstip 
van kaartinvoer van de sessie die niet correct afgeslo ­
ten is;  
— moeten de datum en het tijdstip van het einde van het 
voorval overeenkomen met de datum en het tijdstip 
van kaartinvoer van de sessie tijdens welke het voorval 
ontdekt werd (lopende sessie);  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 61  
— moeten de voertuiggegevens overeenkomen met het 
voertuig waarin de sessie niet correct werd afgesloten.  
262) Een bestuurderskaart moet gegevens over de 6 meest re ­
cente voorvallen van elke soort (d.w.z. 36 voorvallen) 
kunnen opslaan.  
4.5.3.1.8 Gegevens over fouten  
Voor de toepassing van dit punt wordt de tijd geregistreerd met een 
resolutie van 1 seconde.  
263) Een bestuurderskaart moet gegevens kunnen opslaan met 
betrekking tot de volgende fouten die het controleapparaat 
heeft gedetecteerd terwijl de kaart was ingebracht:  
▼M1 
— kaartfout (indien deze kaart de aanleiding is van de 
fout);  
▼B 
— fout in controleapparaat.  
264) Een bestuurderskaart moet de volgende gegevens over 
deze fouten kunnen opslaan:  
— foutcode;  
— datum en tijdstip van het begin van de fout (of van de 
kaartinvoer indien de fout reeds eerder is begonnen);  
— datum en tijdstip van het einde van de fout (of van de 
kaartuitneming indien de fout daarna blijft voortduren);  
— kentekennummer en lidstaat van registratie van het 
voertuig waarin de fout optrad.  
265) Een bestuurderskaart moet gegevens over de twaalf meest 
recente fouten van elke soort (d.w.z. 24 fouten) kunnen 
opslaan.  
4.5.3.1.9 Gegevens over de activiteiten van de bestuurder  
266) Een bestuurderskaart moet de volgende gegevens kunnen 
opslaan voor elke kalenderdag waarop de kaart wordt ge ­
bruikt of waarvoor de bestuurder manueel activiteiten heeft 
ingevoerd:  
— de datum;  
— een dagelijkse aanwezigheidsteller (met één verhoogd 
voor elk van de betrokken kalenderdagen);  
— de totale afstand die de bestuurder gedurende deze dag 
heeft afgelegd;  
— de bestuurdersstatus om 00.00 uur;  
— wanneer de bestuurder zijn activiteiten wijzigt en/of 
wanneer de status van de bestuurder verandert en/of 
wanneer hij zijn kaart heeft ingevoerd of uitgenomen:  
— de status van de bestuurder (ALLEEN/TEAM);  
— de lezer (BESTUURDER, BIJRIJDER);  
— de status van de kaart (INGEVOERD, NIET IN ­
GEVOERD);  
— de activiteiten (RIJDEN, BESCHIKBAARHEID, 
WERKEN, ONDERBREKING/RUST);  
— het tijdstip van de wijziging.  
267) Het geheugen van de bestuurderskaart moet de gegevens 
over de activiteiten van de bestuurder ten minste 28 dagen 
bewaren (een bestuurder wijzigt zijn activiteiten gemiddeld 
93 keer per dag).  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 62  
268) De in de voorschriften 261, 264 en 266 genoemde gege ­
vens moeten zodanig worden opgeslagen dat de activitei ­
ten in de volgorde van optreden kunnen worden opge ­
zocht, zelfs in het geval van tijdsoverlapping.  
4.5.3.1.10 Gegevens over de gebruikte voertuigen  
269) Een bestuurderskaart moet voor elke kalenderdag waarop 
de kaart wordt gebruikt, en voor elke gebruiksperiode van 
een bepaald voertuig op die dag (deze periode omvat de 
opeenvolgende cycli van inbrengen en uitnemen van de 
betrokken kaart in het voertuig) de volgende gegevens 
kunnen opslaan:  
— datum en tijdstip van het eerste gebruik van het voer ­
tuig (d.w.z. de eerste kaartinvoer voor deze gebruiks ­
periode van het voertuig, of 00.00 uur wanneer de 
gebruiksperiode op dat moment voortduurt);  
— kilometerstand van het voertuig op dat moment;  
— datum en tijdstip van het laatste gebruik van het voer ­
tuig (d.w.z. de laatste kaartuitneming voor deze ge ­
bruiksperiode van het voertuig of 23.59 uur wanneer 
de gebruiksperiode op dat moment voortduurt);  
— kilometerstand van het voertuig op dat moment;  
— kentekennummer en lidstaat waar het voertuig geregis ­
treerd is.  
270) Een bestuurderskaart moet ten minste 84 gebruiksrecords 
kunnen opslaan.  
4.5.3.1.11 Plaatsen waar dagelijkse werkperioden beginnen en/of eindigen  
271) Een bestuurderskaart moet de volgende door de bestuurder 
ingevoerde gegevens betreffende de plaatsen waar dage ­
lijkse werkperioden beginnen en/of eindigen, kunnen op ­
slaan:  
— datum en tijdstip van de invoer (of datum/tijd van de 
invoer indien deze manueel gebeurt);  
— het type invoer (begin of einde, omstandigheid van 
invoer);  
— het ingevoerde land en de ingevoerde regio;  
— de kilometerstand van het voertuig.  
272) Het geheugen van de bestuurderskaart moet ten minste 42 
paar records kunnen bewaren.  
4.5.3.1.12 Gegevens over kaartsessies  
273) Een bestuurderskaart moet gegevens opslaan met betrek ­
king tot het voertuig waarin de lopende sessie geopend is:  
— datum en tijdstip waarop de sessie werd geopend 
(d.w.z. kaartinvoer), met een resolutie van één secon ­
de; 
— kentekennummer en lidstaat van registratie.  
4.5.3.1.13 Gegevens over controleactiviteiten  
274) Een bestuurderskaart moet de volgende gegevens met be ­
trekking tot controleactiviteiten opslaan:  
— datum en tijdstip van de controle;  
— controlekaartnummer en lidstaat die de kaart heeft af ­
gegeven;  
— soort controle (weergeven en/of printen en/of downlo ­
aden van VU en/of kaart (zie opmerking));  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 63  
— gedownloade periode, in het geval van downloaden;  
— kentekennummer en lidstaat van registratie van het 
voertuig waarin de controle plaatsvond.  
Aantekening: het downloaden van de kaart wordt uitslui ­
tend geregistreerd wanneer dat via een controleapparaat 
gebeurt.  
275) Een bestuurderskaart moet één van deze records kunnen 
bewaren.  
4.5.3.1.14 Gegevens over specifieke omstandigheden  
276) Een bestuurderskaart moet de volgende gegevens met be ­
trekking tot specifieke omstandigheden kunnen opslaan, 
die ingevoerd werden terwijl de kaart werd ingevoerd (on ­
geacht het slot):  
— datum en tijdstip van de invoer;  
— aard van de specifieke omstandigheid.  
277) Een bestuurderskaart moet minstens 56 records kunnen 
opslaan.  
4.5.3.2 T o e p a s s i n g t a c h o g r a a f v a n d e 2 d e g e n e r a t i e 
( n i e t t o e g a n k e l i j k v o o r v o e r t u i g u n i t s v a n d e 
e e r s t e g e n e r a t i e )  
4.5.3.2.1 Toepassingsidentificatie  
278) Een bestuurderskaart moet de volgende toepassingsidenti ­
ficatiegegevens kunnen opslaan:  
— toepassingsidentificatie van de tachograaf;  
— type tachograafkaartidentificatie.  
4.5.3.2.2 Sleutels en certificaten  
279) Een bestuurderskaart moet een aantal cryptografische sleu ­
tels en certificaten kunnen opslaan overeenkomstig de spe ­
cificaties in aanhangsel 11, deel B.  
4.5.3.2.3 Identificatie van de kaart  
280) Een bestuurderskaart moet de volgende kaartidentificatie ­
gegevens kunnen bewaren:  
— kaartnummer;  
— lidstaat van afgifte, instantie van afgifte, datum van 
afgifte;  
— datum van afgifte en vervaldatum van de kaart.  
4.5.3.2.4 Identificatie van de kaarthouder  
281) Een bestuurderskaart moet de volgende identificatiegege ­
vens van de kaarthouder kunnen opslaan:  
— naam van de houder;  
— voorna(a)m(en) van de houder;  
— geboortedatum;  
— voorkeurstaal.  
4.5.3.2.5 Kaartgegevens downloaden  
282) Een bestuurderskaart moet de volgende gegevens inzake 
downloads opslaan:  
— datum en tijdstip van het downloaden van de laatste 
kaart (voor andere doeleinden dan controle).  
283) Een bestuurderskaart moet één van deze records kunnen 
bewaren.  
4.5.3.2.6 Informatie over het rijbewijs  
284) Een bestuurderskaart moet de volgende rijbewijsgegevens 
kunnen opslaan:  
— lidstaat van afgifte, autoriteit van afgifte,  
— rijbewijsnummer (op het moment van afgifte van de 
kaart).  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 64  
4.5.3.2.7 Gegevens over voorvallen  
Voor de toepassing van dit punt wordt de tijd geregistreerd met een 
resolutie van 1 seconde.  
285) Een bestuurderskaart moet gegevens kunnen opslaan over 
de volgende voorvallen, die door het controleapparaat ge ­
detecteerd zijn terwijl de kaart was ingebracht:  
— tijdsoverlapping (indien deze kaart het voorval heeft 
veroorzaakt);  
— kaartinvoer tijdens het rijden (indien deze kaart aan ­
leiding is voor het voorval);  
— laatste kaartsessie niet correct afgesloten (indien deze 
kaart aanleiding is voor het voorval);  
— onderbreking in de stroomvoorziening;  
— fout in de communicatie met het systeem voor com ­
municatie op afstand  
— ontbreken van positie-informatie van de GNSS-ontvan ­
ger; 
— fout in communicatie met de externe GNSS-module;  
— fout in de bewegingsgegevens,  
— tegenstrijdige bewegingsgegevens,  
— pogingen tot inbreuk op de beveiliging:  
— tijdsoverlapping.  
286) Een bestuurderskaart moet de volgende gegevens over 
deze voorvallen kunnen opslaan:  
— code van het voorval;  
— datum en tijdstip van het begin van het voorval (of van 
de kaartinvoer indien het voorval op dat moment 
plaatsvond);  
— datum en tijdstip van het einde van het voorval (of van 
de kaartinvoer indien het voorval op dat moment 
plaatsvond);  
— kentekennummer en lidstaat van registratie van het 
voertuig waarin het voorval plaatsvond.  
Aantekening: in het geval van „tijdsoverlapping”:  
— moeten de datum en het tijdstip van het begin van het 
voorval overeenkomen met de datum en het tijdstip 
waarop de kaart uit het vorige voertuig is uitgenomen;  
— moeten de datum en het tijdstip van het einde van het 
voorval overeenkomen met de datum en het tijdstip 
van kaartinvoer in het huidige voertuig;  
— moeten de voertuiggegevens overeenkomen met die 
van het voertuig dat het voorval heeft veroorzaakt.  
Aantekening: in het geval van „laatste kaartsessie niet 
correct afgesloten”:  
— moeten de datum en het tijdstip van het begin van het 
voorval overeenkomen met de datum en het tijdstip 
van kaartinvoer van de sessie die niet correct afgeslo ­
ten is;  
— moeten de datum en het tijdstip van het einde van het 
voorval overeenkomen met de datum en het tijdstip 
van kaartinvoer van de sessie tijdens welke het voorval 
ontdekt werd (lopende sessie);  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 65  
— moeten de voertuiggegevens overeenkomen met het 
voertuig waarin de sessie niet correct werd afgesloten.  
287) Een bestuurderskaart moet gegevens over de 6 meest re ­
cente voorvallen van elke soort (d.w.z. 66 voorvallen) 
kunnen opslaan.  
4.5.3.2.8 Gegevens over fouten  
Voor de toepassing van dit punt wordt de tijd geregistreerd met een 
resolutie van 1 seconde.  
288) Een bestuurderskaart moet gegevens kunnen opslaan met 
betrekking tot de volgende fouten, die het controleapparaat 
heeft gedetecteerd terwijl de kaart was ingebracht:  
▼M1 
— kaartfout (indien deze kaart de aanleiding is van de 
fout);  
▼B 
— fout in controleapparaat.  
289) Een bestuurderskaart moet de volgende gegevens over 
deze fouten kunnen opslaan:  
— foutcode;  
— datum en tijdstip van het begin van de fout (of van de 
kaartinvoer indien de fout reeds eerder was begonnen);  
— datum en tijdstip van het einde van de fout (of van de 
kaartuitneming indien de fout daarna bleef voortduren);  
— kentekennummer en lidstaat van registratie van het 
voertuig waarin de fout optrad.  
290) Een bestuurderskaart moet gegevens over de twaalf meest 
recente fouten van elke soort (d.w.z. 24 fouten) kunnen 
opslaan.  
4.5.3.2.9 Gegevens over de activiteiten van de bestuurder  
291) Een bestuurderskaart moet voor elke kalenderdag waarop 
de kaart wordt gebruikt of waarvoor de bestuurder manu ­
eel activiteiten heeft ingevoerd, de volgende gegevens 
kunnen opslaan:  
— de datum;  
— een dagelijkse aanwezigheidsteller (met één verhoogd 
voor elk van de betrokken kalenderdagen);  
— de totale afstand die de bestuurder gedurende deze dag 
heeft afgelegd;  
— de bestuurdersstatus om 00.00 uur;  
— wanneer de bestuurder zijn activiteiten wijzigt en/of 
wanneer de status van de bestuurder verandert en/of 
wanneer hij zijn kaart heeft ingevoerd of uitgenomen:  
— de status van de bestuurder (ALLEEN/TEAM);  
— het slot (BESTUURDER, BIJRIJDER);  
— de status van de kaart (INGEVOERD, NIET IN ­
GEVOERD);  
— de activiteiten (RIJDEN, BESCHIKBAARHEID, 
WERKEN, ONDERBREKING/RUST);  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 66  
— het tijdstip van de wijziging.  
292) Het geheugen van de bestuurderskaart moet de gegevens 
over de activiteiten van de bestuurder ten minste 28 dagen 
bewaren (een bestuurder wijzigt zijn activiteiten gemiddeld 
93 keer per dag).  
293) De in de voorschriften 286, 289 en 291 genoemde gege ­
vens moeten zodanig worden opgeslagen dat de activitei ­
ten in de volgorde van optreden kunnen worden opge ­
zocht, zelfs in het geval van tijdsoverlapping.  
4.5.3.2.10 Gegevens over de gebruikte voertuigen  
294) Een bestuurderskaart moet voor elke kalenderdag waarop 
de kaart wordt gebruikt, en voor elke gebruiksperiode van 
een bepaald voertuig op die dag (deze periode omvat de 
opeenvolgende cycli van inbrengen en uitnemen van de 
betrokken kaart in het voertuig) de volgende gegevens 
kunnen opslaan:  
— datum en tijdstip van het eerste gebruik van het voer ­
tuig (d.w.z. de eerste kaartinvoer voor deze gebruiks ­
periode van het voertuig, of 00.00 uur wanneer de 
gebruiksperiode op dat moment voortduurt);  
— kilometerstand van het voertuig bij eerste gebruik;  
— datum en tijdstip van het laatste gebruik van het voer ­
tuig, (d.w.z. de laatste kaartuitneming voor deze ge ­
bruiksperiode van het voertuig, of 23.59 uur wanneer 
de gebruiksperiode op dat moment voortduurt);  
— kilometerstand van het voertuig bij laatste gebruik;  
— kentekennummer en lidstaat waar het voertuig geregis ­
treerd is;  
— VIN van het voertuig.  
295) Een bestuurderskaart moet minstens 84 records kunnen 
bewaren.  
4.5.3.2.11 Plaatsen en posities waar de dagelijkse werkperioden beginnen en/of 
eindigen  
296) Een bestuurderskaart moet de volgende door de bestuurder 
ingevoerde gegevens betreffende de plaatsen waar dage ­
lijkse werkperioden beginnen en/of eindigen, kunnen op ­
slaan:  
— de datum en tijdstip van de invoer (of de datum/tijd 
van de invoer indien deze manueel gebeurt);  
— het type invoer (begin of einde, omstandigheid van 
invoer);  
— het ingevoerde land en de ingevoerde regio;  
— de kilometerstand van het voertuig;  
— de positie van het voertuig;  
— de GNSS-nauwkeurigheid, datum en tijdstip waarop de 
positie is bepaald.  
297) Het geheugen van de bestuurderskaart moet ten minste 84 
paar records kunnen bewaren.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 67  
4.5.3.2.12 Gegevens over kaartsessies  
298) Een bestuurderskaart moet gegevens opslaan met betrek ­
king tot het voertuig waarin de lopende sessie geopend is:  
— datum en tijdstip waarop de sessie geopend werd 
(d.w.z. kaartinvoer), met een resolutie van 1 seconde;  
— kentekennummer en lidstaat van registratie.  
4.5.3.2.13 Gegevens over controleactiviteiten  
299) Een bestuurderskaart moet de volgende gegevens met be ­
trekking tot controleactiviteiten opslaan:  
— datum en tijdstip van de controle;  
— controlekaartnummer en lidstaat die de kaart heeft af ­
gegeven;  
— soort controle (weergeven en/of printen en/of downlo ­
aden van VU en/of kaart (zie opmerking));  
— gedownloade periode, in het geval van downloaden;  
— kentekennummer en lidstaat van registratie van het 
voertuig waarin de controle plaatsvond.  
Aantekening: de beveiligingseisen impliceren dat het 
downloaden van de kaart uitsluitend geregistreerd wordt 
wanneer dat via een controleapparaat gebeurt.  
300) Een bestuurderskaart moet één van deze records kunnen 
bewaren.  
4.5.3.2.14 Gegevens over specifieke omstandigheden  
301) Met betrekking tot specifieke omstandigheden moeten de 
volgende gegevens die werden ingevoerd terwijl de kaart 
werd ingevoerd (ongeacht het slot), kunnen worden be ­
waard op de bestuurderskaart:  
— datum en tijdstip van de invoer;  
— aard van de specifieke omstandigheid.  
302) Een bestuurderskaart moet minstens 56 records kunnen 
opslaan.  
4.5.3.2.15 Gegevens over de gebruikte voertuigunits  
303) Een bestuurderskaart moet de volgende gegevens kunnen 
bewaren in verband met de verschillende voertuigunits 
waarin ze is gebruikt:  
— de datum en het tijdstip waarop het gebruik in de 
voertuigunit begint (eerste invoer in de VU voor de 
periode);  
— de fabrikant van de voertuigunit;  
— het type voertuigunit;  
— het nummer van de softwareversie van de VU.  
304) Een bestuurderskaart moet minstens 84 records kunnen 
opslaan.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 68  
4.5.3.2.16 Plaats en tijdstip cumulatieve rijtijd van drie uur  
305) Een bestuurderskaart moet de volgende gegevens kunnen 
bewaren in verband met de positie van het voertuig waar 
de cumulatieve rijtijd een veelvoud van drie uur bereikt:  
— de datum en het tijdstip waarop de cumulatieve rijtijd 
een veelvoud van drie uur bereikt;  
— de positie van het voertuig;  
— de GNSS-nauwkeurigheid, de datum en het tijdstip 
waarop de positie is bepaald;  
— de kilometerstand van het voertuig.  
306) Een bestuurderskaart moet minstens 252 records kunnen 
opslaan.  
▼B 
4.5.4  Werkplaatskaart  
4.5.4.1 T a c h o g r a a f t o e p a s s i n g e n ( t o e g a n k e l i j k v o o r 
v o e r t u i g u n i t s v a n d e e e r s t e e n t w e e d e g e n e r a t i e )  
4.5.4.1.1 Toepassingsidentificatie  
307) Een werkplaatskaart moet de volgende toepassingsidentifi ­
catiegegevens kunnen opslaan:  
— toepassingsidentificatie van de tachograaf;  
— type tachograafkaartidentificatie.  
4.5.4.1.2 Sleutels en certificaten  
308) Een werkplaatskaart moet een aantal cryptografische sleu ­
tels en certificaten kunnen opslaan overeenkomstig de spe ­
cificaties in aanhangsel 11, deel A.  
309) Een werkplaatskaart moet een Personal Identification 
Number (pincode) kunnen opslaan.  
4.5.4.1.3 Identificatie van de kaart  
310) Een werkplaatskaart moet de volgende kaartidentificatiege ­
gevens kunnen opslaan:  
— kaartnummer;  
— lidstaat van afgifte, instantie van afgifte, datum van 
afgifte;  
— datum van afgifte van en vervaldatum van de kaart.  
4.5.4.1.4 Identificatie van de kaarthouder  
311) Een werkplaatskaart moet de volgende identificatiegege ­
vens van de kaarthouder kunnen opslaan:  
— naam van de werkplaats;  
— adres van de werkplaats;  
— naam van de houder;  
— voorna(a)m(en) van de houder;  
— voorkeurstaal.  
4.5.4.1.5 Kaartgegevens downloaden  
312) Een werkplaatskaart moet de gegevens over het downloa ­
den van de kaart op dezelfde manier kunnen opslaan als 
een bestuurderskaart.  ▼M1
 02016R0799 — NL — 26.02.2020 — 002.001 — 69  
4.5.4.1.6 Gegevens over kalibrering en tijdafstelling  
313) Een werkplaatskaart moet records kunnen opslaan van ka ­
libreringen en/of tijdafstellingen die worden uitgevoerd 
terwijl de kaart zich in een controleapparaat bevindt.  
314) Elke kalibreringsrecord moet de volgende gegevens kun ­
nen bevatten:  
— doel van de kalibrering (activering, eerste installatie, 
installatie, periodieke controle);  
— identificatie van het voertuig  
— bijgewerkte of bevestigde parameters (w, k, l, banden ­
maat, instelling van de snelheidsbegrenzer, kilometer ­
stand (nieuwe en oude waarde), datum en tijdstip 
(nieuwe en oude waarde));  
— identificatienummer van het controleapparaat (onder ­
deelnummer en serienummer van de VU, serienummer 
van de bewegingssensor).  
315) Een werkplaatskaart moet ten minste 88 records kunnen 
opslaan.  
316) Een werkplaatskaart moet een teller bevatten die het totale 
aantal kalibreringen aangeeft dat met de kaart is uitge ­
voerd.  
317) Een werkplaatskaart moet een teller bevatten die het aantal 
kalibreringen sinds de laatste download aangeeft.  
4.5.4.1.7 Gegevens over voorvallen en fouten  
318) Een werkplaatskaart moet records over voorvallen en fou ­
ten op dezelfde manier kunnen opslaan als een bestuur ­
derskaart.  
319) Een werkplaatskaart moet gegevens over de drie meest 
recente voorvallen van elke soort (d.w.z. 18 voorvallen) 
en de zes meest recente fouten van elke soort (d.w.z. 12 
fouten) kunnen opslaan.  
4.5.4.1.8 Gegevens over de activiteiten van de bestuurder  
320) Een werkplaatskaart moet de gegevens over de activiteiten 
van de bestuurder op dezelfde manier kunnen opslaan als 
een bestuurderskaart.  
321) Een werkplaatskaart moet de gegevens over de activiteiten 
van de bestuurder ten minste gedurende 1 dag met gemid ­
delde activiteiten van de bestuurder bewaren.  
4.5.4.1.9 Gegevens over de gebruikte voertuigen  
322) Een werkplaatskaart moet records over de gebruikte voer ­
tuigen op dezelfde manier kunnen opslaan als een bestuur ­
derskaart.  
323) Een werkplaatskaart moet ten minste 4 records kunnen 
opslaan.  
4.5.4.1.10 Gegevens over het begin en einde van dagelijkse werkperioden  
324) Een werkplaatskaart moet records over het begin en einde 
van dagelijkse werkperioden op dezelfde manier kunnen 
opslaan als een bestuurderskaart.  
325) Een werkplaatskaart moet ten minste 3 paren van derge ­
lijke records kunnen bewaren.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 70  
4.5.4.1.11 Gegevens over kaartsessies  
326) Een werkplaatskaart moet gegevens over het downloaden 
van de kaart op dezelfde manier kunnen opslaan als een 
bestuurderskaart.  
4.5.4.1.12 Gegevens over controleactiviteiten  
327) Een werkplaatskaart moet de gegevens over controleactivi ­
teiten op dezelfde manier kunnen opslaan als een bestuur ­
derskaart.  
4.5.4.1.13 Gegevens over specifieke omstandigheden  
328) Een werkplaatskaart moet gegevens over specifieke om ­
standigheden op dezelfde manier kunnen opslaan als een 
bestuurderskaart.  
329) Een werkplaatskaart moet ten minste 2 records kunnen 
opslaan.  
4.5.4.2 T o e p a s s i n g t a c h o g r a a f v a n d e t w e e d e g e n e r a t i e 
( n i e t t o e g a n k e l i j k v o o r v o e r t u i g u n i t s v a n d e 
e e r s t e g e n e r a t i e )  
4.5.4.2.1 Toepassingsidentificatie  
330) Een werkplaatskaart moet de volgende toepassingsidentifi ­
catiegegevens kunnen opslaan:  
— toepassingsidentificatie van de tachograaf;  
— type tachograafkaartidentificatie.  
4.5.4.2.2 Sleutels en certificaten  
331) Een werkplaatskaart moet een aantal cryptografische sleu ­
tels en certificaten kunnen opslaan overeenkomstig de spe ­
cificaties in aanhangsel 11, deel B.  
332) Een werkplaatskaart moet een Personal Identification 
Number (pincode) kunnen opslaan.  
4.5.4.2.3 Identificatie van de kaart  
333) Een werkplaatskaart moet de volgende kaartidentificatiege ­
gevens kunnen opslaan:  
— kaartnummer;  
— lidstaat van afgifte, instantie van afgifte, datum van 
afgifte;  
— datum van afgifte en vervaldatum van de kaart.  
4.5.4.2.4 Identificatie van de kaarthouder  
334) Een werkplaatskaart moet de volgende identificatiegege ­
vens van de kaarthouder kunnen opslaan:  
— naam van de werkplaats;  
— adres van de werkplaats;  
— naam van de houder;  
— voorna(a)m(en) van de houder;  
— voorkeurstaal.  
4.5.4.2.5 Kaartgegevens downloaden  
335) Een werkplaatskaart moet de gegevens over het downloa ­
den van de kaart op dezelfde manier kunnen opslaan als 
een bestuurderskaart.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 71  
4.5.4.2.6 Gegevens over kalibrering en tijdafstelling  
336) Een werkplaatskaart moet records kunnen opslaan van ka ­
libreringen en/of tijdafstellingen die worden uitgevoerd 
terwijl de kaart zich in een controleapparaat bevindt.  
337) Elke kalibreringsrecord moet de volgende gegevens kun ­
nen bevatten:  
— doel van de kalibrering (activering, eerste installatie, 
installatie, periodieke controle);  
— voertuigidentificatie;  
— bijgewerkte of bevestigde parameters (w, k, l, banden ­
maat, instelling van de snelheidsbegrenzer, kilometer ­
stand (nieuwe en oude waarde), datum en tijdstip 
(nieuwe en oude waarde);  
— identificatie van het controleapparaat (onderdeel- en 
serienummer VU, serienummer bewegingssensor, se ­
rienummer systeem voor communicatie op afstand 
en, indien van toepassing, serienummer externe 
GNSS-module);  
— types en identificatienummers van alle aanwezige ver ­
zegelingen;  
— mogelijkheid van de VU om tachograafkaarten van de 
eerste generatie te gebruiken (geactiveerd of niet).  
338) Een werkplaatskaart moet ten minste 88 records kunnen 
opslaan.  
339) Een werkplaatskaart moet een teller bevatten die het totale 
aantal kalibreringen aangeeft dat met de kaart is uitge ­
voerd.  
340) Een werkplaatskaart moet een teller bevatten die het aantal 
kalibreringen sinds de laatste download aangeeft.  
4.5.4.2.7 Gegevens over voorvallen en fouten  
341) Een werkplaatskaart moet records over voorvallen en fou ­
ten op dezelfde manier kunnen opslaan als een bestuur ­
derskaart.  
342) Een werkplaatskaart moet gegevens over de drie meest 
recente voorvallen van elke soort (d.w.z. 33 voorvallen) 
en de zes meest recente fouten van elke soort (d.w.z. 12 
fouten) kunnen opslaan.  
4.5.4.2.8 Gegevens over de activiteiten van de bestuurder  
343) Een werkplaatskaart moet de gegevens over de activiteiten 
van de bestuurder op dezelfde manier kunnen opslaan als 
een bestuurderskaart.  
344) Een werkplaatskaart moet de gegevens over de activiteiten 
van de bestuurder ten minste gedurende 1 dag met gemid ­
delde activiteiten van de bestuurder bewaren.  
4.5.4.2.9 Gegevens over de gebruikte voertuigen  
345) Een werkplaatskaart moet records over de gebruikte voer ­
tuigen op dezelfde manier kunnen opslaan als een bestuur ­
derskaart.  
346) Een werkplaatskaart moet ten minste 4 records kunnen 
opslaan.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 72  
4.5.4.2.10 Gegevens over het begin en einde van dagelijkse werkperioden  
347) Een werkplaatskaart moet records over het begin en einde 
van dagelijkse werkperioden op dezelfde manier kunnen 
opslaan als een bestuurderskaart.  
348) Een werkplaatskaart moet ten minste 3 paren van derge ­
lijke records kunnen bewaren.  
4.5.4.2.11 Gegevens over kaartsessies  
349) Een werkplaatskaart moet gegevens over het downloaden 
van de kaart op dezelfde manier kunnen opslaan als een 
bestuurderskaart.  
4.5.4.2.12 Gegevens over controleactiviteiten  
350) Een werkplaatskaart moet de gegevens over controleactivi ­
teiten op dezelfde manier kunnen opslaan als een bestuur ­
derskaart.  
4.5.4.2.13 Gegevens over de gebruikte voertuigunits  
351) Een werkplaatskaart moet de volgende gegevens kunnen 
bewaren in verband met de verschillende voertuigunits 
waarin ze is gebruikt:  
— de datum en het tijdstip waarop het gebruik in de 
voertuigunit begint (eerste invoer in de VU voor de 
periode);  
— de fabrikant van de voertuigunit;  
— het type voertuigunit;  
— het nummer van de softwareversie van de VU.  
352) Een werkplaatskaart moet ten minste 4 records kunnen 
opslaan.  
▼M1 
4.5.4.2.14 Plaats en tijdstip cumulatieve rijtijd van drie uur  
353) Een werkplaatskaart moet de volgende gegevens kunnen 
bewaren in verband met de positie van het voertuig waar 
de cumulatieve rijtijd een veelvoud van drie uur bereikt:  
— de datum en het tijdstip waarop de cumulatieve rijtijd 
een veelvoud van drie uur bereikt;  
— de positie van het voertuig;  
— de GNSS-nauwkeurigheid, de datum en het tijdstip 
waarop de positie is bepaald;  
— de kilometerstand van het voertuig.  
354) Een werkplaatskaart moet ten minste 18 records kunnen 
opslaan.  
▼B 
4.5.4.2.15 Gegevens over specifieke omstandigheden  
355) Een werkplaatskaart moet gegevens over specifieke om ­
standigheden op dezelfde manier kunnen opslaan als een 
bestuurderskaart.  
356) Een werkplaatskaart moet ten minste 2 records kunnen 
opslaan.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 73  
4.5.5  Controlekaart  
4.5.5.1 T a c h o g r a a f t o e p a s s i n g e n ( t o e g a n k e l i j k v o o r 
v o e r t u i g u n i t s v a n d e e e r s t e e n t w e e d e g e n e r a t i e )  
4.5.5.1.1 Toepassingsidentificatie  
357) Een controlekaart moet de volgende toepassingsidentifica ­
tiegegevens kunnen opslaan:  
— toepassingsidentificatie van de tachograaf;  
— type tachograafkaartidentificatie.  
4.5.5.1.2 Sleutels en certificaten  
358) Een controlekaart moet een aantal cryptografische sleutels 
en certificaten kunnen opslaan overeenkomstig de specifi ­
caties in aanhangsel 11, deel A.  
4.5.5.1.3 Identificatie van de kaart  
359) Een controlekaart moet de volgende kaartidentificatiegege ­
vens kunnen opslaan:  
— kaartnummer;  
— lidstaat van afgifte, instantie van afgifte, datum van 
afgifte;  
— ingangsdatum van de geldigheid van de kaart en datum 
waarop de kaart vervalt (indien van toepassing).  
4.5.5.1.4 Identificatie van de kaarthouder  
360) Een controlekaart moet de volgende identificatiegegevens 
van de kaarthouder kunnen opslaan:  
— naam van de controle-instantie;  
— adres van de controle-instantie;  
— naam van de houder;  
— voorna(a)m(en) van de houder;  
— voorkeurstaal.  
4.5.5.1.5 Gegevens over controleactiviteiten  
361) Een controlekaart moet de volgende gegevens met betrek ­
king tot controleactiviteiten kunnen opslaan:  
— datum en tijdstip van de controle;  
— aard van de controle (weergeven en/of afdrukken en/of 
VU-gegevens downloaden en/of kaartgegevens 
downloaden en/of kalibreringscontrole langs de weg);  
— gedownloade periode (indien van toepassing);  
— kentekennummer en lidstaat waarin het gecontroleerde 
voertuig is ingeschreven;  
— kaartnummer en lidstaat die de gecontroleerde bestuur ­
derskaart heeft afgegeven.  
362) Een controlekaart moet ten minste 230 records kunnen 
bewaren.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 74  
4.5.5.2 T a c h o g r a a f t o e p a s s i n g e n v a n d e t w e e d e g e n e r a ­
t i e ( n i e t t o e g a n k e l i j k v o o r v o e r t u i g u n i t s v a n d e 
e e r s t e g e n e r a t i e )  
4.5.5.2.1 Toepassingsidentificatie  
363) Een controlekaart moet de volgende toepassingsidentifica ­
tiegegevens kunnen opslaan:  
— toepassingsidentificatie van de tachograaf;  
— type tachograafkaartidentificatie.  
4.5.5.2.2 Sleutels en certificaten  
364) Een controlekaart moet een aantal cryptografische sleutels 
en certificaten kunnen opslaan overeenkomstig de specifi ­
caties in aanhangsel 11, deel B.  
4.5.5.2.3 Identificatie van de kaart  
365) Een controlekaart moet de volgende kaartidentificatiegege ­
vens kunnen opslaan:  
— kaartnummer;  
— lidstaat van afgifte, instantie van afgifte, datum van 
afgifte;  
— ingangsdatum van de geldigheid van de kaart en datum 
waarop de kaart vervalt (indien van toepassing).  
4.5.5.2.4 Identificatie van de kaarthouder  
366) Een controlekaart moet de volgende identificatiegegevens 
van de kaarthouder kunnen opslaan:  
— naam van de controle-instantie;  
— adres van de controle-instantie;  
— naam van de houder;  
— voorna(a)m(en) van de houder;  
— voorkeurstaal.  
4.5.5.2.5 Gegevens over controleactiviteiten  
367) Een controlekaart moet de volgende gegevens met betrek ­
king tot controleactiviteiten kunnen opslaan:  
— datum en tijdstip van de controle;  
— aard van de controle (weergeven en/of afdrukken en/of 
VU-gegevens downloaden en/of kaartgegevens 
downloaden en/of kalibreringscontrole langs de weg).  
— gedownloade periode (indien van toepassing);  
— kentekennummer en lidstaat waarin het gecontroleerde 
voertuig is ingeschreven;  
— kaartnummer en lidstaat die de gecontroleerde bestuur ­
derskaart heeft afgegeven.  
368) Een controlekaart moet ten minste 230 records kunnen 
bewaren.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 75  
4.5.6  Bedrijfskaart  
4.5.6.1 T a c h o g r a a f t o e p a s s i n g e n ( t o e g a n k e l i j k v o o r 
v o e r t u i g u n i t s v a n d e e e r s t e e n t w e e d e g e n e r a t i e )  
4.5.6.1.1 Toepassingsidentificatie  
369) Een bedrijfskaart moet de volgende toepassingsidentifica ­
tiegegevens kunnen opslaan:  
— toepassingsidentificatie van de tachograaf;  
— type tachograafkaartidentificatie.  
4.5.6.1.2 Sleutels en certificaten  
370) Een bedrijfskaart moet een aantal cryptografische sleutels 
en certificaten kunnen opslaan overeenkomstig de specifi ­
caties in aanhangsel 11, deel A.  
4.5.6.1.3 Identificatie van de kaart  
371) Een bedrijfskaart moet de volgende kaartidentificatiegege ­
vens kunnen opslaan:  
— kaartnummer;  
— lidstaat van afgifte, instantie van afgifte, datum van 
afgifte;  
— ingangsdatum van de geldigheid van de kaart en datum 
waarop de kaart vervalt (indien van toepassing).  
4.5.6.1.4 Identificatie van de kaarthouder  
372) Een bedrijfskaart moet de volgende identificatiegegevens 
van de kaarthouder kunnen opslaan:  
— naam van het bedrijf;  
— adres van het bedrijf.  
4.5.6.1.5 Gegevens over bedrijfsactiviteiten  
373) Een bedrijfskaart moet de volgende gegevens over be ­
drijfsactiviteiten kunnen opslaan:  
— datum en tijdstip van de activiteit;  
— soort activiteit (vergrendeling en/of ontgrendeling van 
VU en/of VU-gegevens downloaden en/of kaartgege ­
vens downloaden);  
— gedownloade periode (indien van toepassing);  
— kentekennummer en registrerende instantie van de lid ­
staat van het voertuig;  
— kaartnummer en lidstaat die de kaart heeft afgegeven 
(bij het downloaden van de kaart).  
374) Een bedrijfskaart moet ten minste 230 van dergelijke re ­
cords kunnen bewaren.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 76  
4.5.6.2 T a c h o g r a a f t o e p a s s i n g e n v a n d e t w e e d e g e n e r a ­
t i e ( n i e t t o e g a n k e l i j k v o o r v o e r t u i g u n i t s v a n d e 
e e r s t e g e n e r a t i e )  
4.5.6.2.1 Toepassingsidentificatie  
375) Een bedrijfskaart moet de volgende toepassingsidentifica ­
tiegegevens kunnen opslaan:  
— toepassingsidentificatie van de tachograaf;  
— type tachograafkaartidentificatie.  
4.5.6.2.2 Sleutels en certificaten  
376) Een bedrijfskaart moet een aantal cryptografische sleutels 
en certificaten kunnen opslaan overeenkomstig de specifi ­
caties in aanhangsel 11, deel B.  
4.5.6.2.3 Identificatie van de kaart  
377) Een bedrijfskaart moet de volgende kaartidentificatiegege ­
vens kunnen opslaan:  
— kaartnummer;  
— lidstaat van afgifte, instantie van afgifte, datum van 
afgifte;  
— ingangsdatum van de geldigheid van de kaart en datum 
waarop de kaart vervalt (indien van toepassing).  
4.5.6.2.4 Identificatie van de kaarthouder  
378) Een bedrijfskaart moet de volgende identificatiegegevens 
van de kaarthouder kunnen opslaan:  
— naam van het bedrijf;  
— adres van het bedrijf.  
4.5.6.2.5 Gegevens over bedrijfsactiviteiten  
379) Een bedrijfskaart moet de volgende gegevens over be ­
drijfsactiviteiten kunnen opslaan:  
— datum en tijdstip van de activiteit;  
— soort activiteit (vergrendeling en/of ontgrendeling van 
VU en/of VU-gegevens downloaden en/of kaartgege ­
vens downloaden);  
— gedownloade periode (indien van toepassing);  
— kentekennummer en registrerende instantie van de lid ­
staat van het voertuig;  
— kaartnummer en lidstaat die de kaart heeft afgegeven 
(bij het downloaden van de kaart).  
380) Een bedrijfskaart moet ten minste 230 van dergelijke re ­
cords kunnen bewaren.  
5 INSTALLATIE VAN HET CONTROLEAPPARAAT  
5.1 Installatie  
381) Nieuwe controleapparaten moeten in niet-geactiveerde toe ­
stand geleverd worden aan installateurs of voertuigfabri ­
kanten. Alle kalibreringsparameters, als vermeld in punt 
3.21, moeten daarbij ingesteld zijn op de juiste en geldige 
standaardwaarden. Indien geen specifieke waarde geschikt 
is, moeten de letters op „?” en de cijfers op „0” worden 
gezet. Indien nodig kan tijdens de beveiligingscertificering 
de levering van voor beveiliging relevante onderdelen van 
het controleapparaat worden beperkt.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 77  
382) Vóór de activering moet het controleapparaat toegang ge ­
ven tot de kalibreringsfunctie, zelfs wanneer het apparaat 
zich niet in de kalibreringsmodus bevindt.  
383) Vóór de activering mag het controleapparaat geen gege ­
vens als bedoeld in de punten 3.12.3, 3.12.9 en 3.12.12 tot 
en met 3.12.15 opslaan.  
384) Tijdens de installatie moeten de voertuigfabrikanten alle 
bekende parameters instellen.  
385) Voertuigfabrikanten of installateurs moeten het geïnstal ­
leerde controleapparaat activeren uiterlijk voordat het voer ­
tuig wordt gebruikt in het kader van Verordening (EG) nr. 
561/2006.  
386) De activering van het controleapparaat moet automatisch 
worden opgestart bij de eerste invoer van een geldige 
werkplaatskaart in een van zijn kaartinterfaces.  
387) Eventuele specifieke verbindingen tussen de bewegings ­
sensor en de voertuigunit moeten automatisch gebeuren 
voor of tijdens de activering.  
388) Op dezelfde manier moeten het tot stand brengen van de 
koppeling tussen de externe GNSS-module en de voertuig ­
unit, indien van toepassing, automatisch gebeuren voor of 
tijdens de activering.  
389) Na de activering moet het controleapparaat alle functies 
uitvoeren en toegang geven tot alle gegevens.  
390) Na de activering, stuurt het controleapparaat alle bevei ­
ligde gegevens die nodig zijn voor de uitvoering van ge ­
richte wegcontroles door naar het systeem voor controle 
op afstand.  
391) De registratie- en opslagfuncties van het controleapparaat 
moeten na de activering volledig operationeel zijn.  
392) Na de installatie moet een kalibrering volgen. Bij de eerste 
kalibrering wordt niet noodzakelijk het voertuigregistratie ­
nummer (VRN) ingevoerd, wanneer dat niet bekend is bij 
de erkende werkplaats die de kalibrering uitvoert. In dat 
geval, en alleen op dat moment, kan de eigenaar van het 
voertuig het VRN invoeren met behulp van zijn bedrijfs ­
kaart voordat het voertuig gebruikt wordt in het kader van 
Verordening (EG) nr. 561/2006 (bv. door middel van com ­
mando's in een juiste menustructuur van de mens-machine- 
interface van de voertuigunit.) (  1 ) Deze invoer mag alleen 
met behulp van een werkplaatskaart worden bijgewerkt of 
bevestigd.  
393) Voor de installatie van een externe GNSS-module moet 
dat systeem aan de voertuigunit worden gekoppeld en 
moet vervolgens de GNSS-positie-informatie worden ge ­
verifieerd.  
394) Het controleapparaat moet zodanig in het voertuig worden 
geïnstalleerd dat de bestuurder gemakkelijk vanaf zijn zit ­
plaats toegang heeft tot de noodzakelijke functies.  ▼B 
( 1 ) PB L 102 van 11.4.2006, blz. 1.
 02016R0799 — NL — 26.02.2020 — 002.001 — 78  
5.2 Installatieplaatje  
395) Na controle van het controleapparaat bij de installatie 
wordt op het controleapparaat een gegraveerd of onuitwis ­
baar bedrukt installatieplaatje aangebracht. Dat plaatje 
moet duidelijk zichtbaar en gemakkelijk toegankelijk zijn. 
Waar dat niet mogelijk is, moet het plaatje worden aange ­
bracht op de B-stijl van het voertuig, zodat het duidelijk 
zichtbaar is. Voor voertuigen zonder B-stijl moet het in ­
stallatieplaatje worden aangebracht op de deurlijst aan de 
bestuurderskant van het voertuig, en altijd duidelijk zicht ­
baar zijn.  
Na iedere controle door een erkende installateur of werk ­
plaats dient het oude plaatje door een nieuw te worden 
vervangen.  
▼M1 
396) Op het plaatje moeten ten minste de volgende gegevens 
zijn aangebracht:  
— naam, adres of handelsnaam van de erkende installa ­
teur of werkplaats;  
— kenmerkende coëfficiënt van het voertuig in de vorm 
„w = … imp/km”;  
— constante van het controleapparaat in de vorm „k = … 
imp/km”;  
— effectieve omtrek van de wielbanden, in de vorm „l = 
… mm”;  
— bandenmaat;  
— de datum waarop de kenmerkende coëfficiënt van het 
voertuig is vastgesteld en waarop de effectieve omtrek 
van de wielbanden is gemeten;  
— VIN-nummer van het voertuig;  
— de aanwezigheid (of afwezigheid) van een externe 
GNSS-module;  
— het serienummer van de externe GNSS-module, indien 
van toepassing;  
— het serienummer van het systeem voor communicatie 
op afstand, indien van toepassing;  
— het serienummer van alle aanwezige verzegelingen;  
— het gedeelte van het voertuig waarin de adapter even ­
tueel is geïnstalleerd;  
— het gedeelte van het voertuig waarin de bewegingssen ­
sor is geïnstalleerd, wanneer deze niet is aangesloten 
op de versnellingsbak of wanneer geen adapter wordt 
gebruikt;  
— een beschrijving van de kleur van de kabel tussen de 
adapter en het gedeelte van het voertuig dat impulsen 
naar de adapter stuurt;  
— het serienummer van de ingebouwde bewegingssensor 
van de adapter.  
▼B 
397) Uitsluitend voor voertuigen van categorie M1 en N1 die 
zijn uitgerust met een adapter volgens Verordening (EG) 
nr. 68/2009 van de Commissie (  1 ), als laatstelijk gewijzigd, 
en waarbij niet alle benodigde informatie kan worden ver ­
meld, zoals beschreven in voorschrift 396, mag gebruik 
worden gemaakt van een tweede, extra plaatje. In derge ­
lijke gevallen moeten op dit extra plaatje minimaal de 
laatste vier in voorschrift 396 beschreven streepjes staan.  ▼B 
( 1 ) Verordening (EG) nr. 68/2009 van de Commissie van 23 januari 2009 betreffende de 
negende aanpassing aan de vooruitgang van de techniek van Verordening (EEG) nr. 
3821/85 van de Raad betreffende het controleapparaat in het wegvervoer (PB L 21 
van 24.1.2009, blz. 3).
 02016R0799 — NL — 26.02.2020 — 002.001 — 79  
Dit tweede plaatje moet worden aangebracht in de buurt 
van of naast het in voorschrift 396 beschreven eerste pri ­
maire plaatje en moet op dezelfde manier worden be ­
schermd. Voorts moeten op het secundaire plaatje even ­
eens de naam, het adres of de handelsnaam van de erkende 
installateur of werkplaats die de installatie heeft uitge ­
voerd, en de datum van installatie zijn vermeld.  
5.3 Verzegeling  
398) De volgende onderdelen moeten worden verzegeld:  
— alle verbindingen die, wanneer ze verbroken zouden 
worden, tot niet-traceerbare wijzigingen of niet-traceer ­
baar verlies van gegevens zouden leiden (dit kan bv. 
het geval zijn voor de aansluiting van de bewegings ­
sensor op de versnellingsbank, de adapter voor voer ­
tuigen van de categorieën M1/N1, de externe GNSS- 
verbinding of de voertuigunit);  
— het installatieplaatje, tenzij het zodanig is aangebracht 
dat het niet kan worden verwijderd zonder de daarop 
aangebrachte aanduidingen te vernietigen.  
▼M1 
398 bis) De bovengenoemde verzegelingen worden gecertificeerd 
overeenkomstig norm EN 16882:2016.  
▼B 
399) De bovengenoemde verzegelingen mogen worden verwij ­
derd:  
— in noodgevallen;  
— voor het plaatsen, afstellen of repareren van een snel ­
heidsbegrenzer of alle andere inrichtingen die bijdra ­
gen tot de verkeersveiligheid, op voorwaarde dat het 
controleapparaat betrouwbaar en correct blijft functio ­
neren en na het plaatsen van de snelheidsbegrenzer of 
andere inrichtingen die bijdragen tot de verkeersveilig ­
heid onmiddellijk opnieuw door een erkende installa ­
teur of werkplaats (als bedoeld in hoofdstuk 6) wordt 
verzegeld; of binnen zeven dagen in andere gevallen.  
400) Iedere verbreking van deze zegels moet schriftelijk worden 
gemotiveerd; deze motivering dient ter beschikking van de 
bevoegde autoriteit te worden gehouden.  
401) Op de zegels is een door de fabrikant toegekend identifi ­
catienummer aanwezig. Dat nummer moet uniek zijn en 
verschillen van alle andere door andere fabrikanten van 
zegels toegekende zegelnummers.  
▼M1 
Het unieke identificatienummer wordt als volgt gedefini ­
eerd: MMNNNNNNNN door een niet-verwijderbaar merk ­
teken, waarbij MM een unieke identificatiecode van de 
fabrikant is (de registratie in de databank wordt beheerd 
door de EC) en NNNNNNNN een alfanumeriek zegel ­
nummer is binnen het domein van de fabrikant.  
▼B 
402) Op de zegels moet een vrije ruimte beschikbaar zijn waar 
erkende installateurs, werkplaatsen of voertuigfabrikanten 
een merkteken kunnen aanbrengen overeenkomstig arti ­
kel 22, lid 3, van Verordening (EU) nr. 165/2014.  
Het merkteken mag het identificatienummer van het zegel 
niet bedekken.  
▼M1 
403) Zegelfabrikanten worden opgenomen in een specifieke da ­
tabank wanneer zij een zegelmodel krijgen dat gecertifi ­
ceerd is volgens EN 16882:2016, en maken hun zegeli ­
dentificatienummers bekend door middel van een door de 
Europese Commissie vastgestelde procedure.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 80  
404) Erkende werkplaatsen en voertuigfabrikanten gebruiken in 
het kader van Verordening (EU) nr. 165/2014 alleen ze ­
gels die gecertificeerd zijn volgens EN 16882:2016 en 
geproduceerd zijn door in de voornoemde databank opge ­
nomen zegelfabrikanten.  
▼B 
405) Fabrikanten en distributeurs van zegels waarborgen de vol ­
ledige traceerbaarheid van de voor gebruik in het kader 
van Verordening (EU) nr. 165/2014 verkochte zegels en 
zorgen ervoor dat zij die gegevens indien nodig kunnen 
verstrekken aan de bevoegde nationale instanties.  
406) De unieke zegelidentificatienummer moeten zichtbaar zijn 
op het installatieplaatje.  
6 CONTROLES, INSPECTIES EN HERSTELLINGEN  
Voorschriften betreffende de omstandigheden waarin verzegelingen 
verwijderd mogen worden, als bedoeld in artikel 22, lid 5, van 
Verordening (EU) nr. 165/2014, zijn gedefinieerd in punt 5.3 van 
deze bijlage.  
6.1 Erkenning van installateurs, werkplaatsen en voertuigfabrikan ­
ten 
De lidstaten erkennen, certificeren en controleren regelmatig de in ­
stanties die de  
— installaties,  
— controles,  
— inspecties en  
— reparaties verrichten.  
Werkplaatskaarten worden uitsluitend afgegeven aan voor het acti ­
veren en/of kalibreren van controleapparaten erkende installateurs 
en/of werkplaatsen die voldoen aan deze bijlage en, tenzij voldoende 
gerechtvaardigd:  
— niet in aanmerking komen voor een bedrijfskaart;  
— wiens andere bedrijfsactiviteiten geen potentieel gevaar voor de 
totale veiligheid van het systeem opleveren zoals vereist in aan ­
hangsel 10.  
▼M1 
6.2 Controle van nieuwe of herstelde onderdelen  
407) Iedere afzonderlijke inrichting, zij het nieuw of hersteld, 
wordt gecontroleerd uit het oogpunt van juiste werking en 
nauwkeurigheid van de aflezing en registratie, waarbij de 
in de punten 3.2.1, 3.2.2, 3.2.3 en 3.3 vastgelegde grens ­
waarden moeten worden gehanteerd.  
▼B 
6.3 Installatie-inspectie  
▼M1 
408) Na plaatsing in een voertuig moeten de volledige installa ­
tie en het controleapparaat voldoen aan de bepalingen be ­
treffende de maximumtoleranties zoals vastgelegd in de 
punten 3.2.1, 3.2.2, 3.2.3 en 3.3. De volledige installatie 
wordt verzegeld overeenkomstig hoofdstuk 5.3 en omvat 
een kalibrering.  
▼B 
6.4 Periodieke controles  
409) Periodieke controles van de in de voertuigen geïnstalleerde 
inrichtingen moeten plaatsvinden na iedere reparatie van 
de inrichting, of na iedere wijziging van de kenmerkende 
coëfficiënt van het voertuig of van de effectieve omtrek 
van de wielbanden, of wanneer de UTC-tijd van de inrich ­
ting meer dan 20 minuten afwijkt, of wanneer het kente ­
kennummer gewijzigd is en ten minste om de twee jaar 
(24 maanden) na de laatste controle.  ▼M1
 02016R0799 — NL — 26.02.2020 — 002.001 — 81  
410) Die inspecties omvatten de volgende controles:  
— de correcte werking van het controleapparaat, met 
name de gegevensopslag op de tachograafkaart en de 
communicatie met toestellen om berichten op afstand 
te lezen;  
— de naleving van het bepaalde in de punten 3.2.1 en 
3.2.2 inzake de maximumtoleranties bij installatie;  
— de naleving van het bepaalde in de punten 3.2.3 en 
3.3; 
— de aanwezigheid van het typegoedkeuringsmerk op het 
controleapparaat;  
— dat het installatieplaatje, zoals omschreven in voor ­
schrift 396, en het identificatieplaatje, zoals omschre ­
ven in voorschrift 225, zijn aangebracht;  
— de bandenmaat en de werkelijke omtrek van de ban ­
den; 
— dat er geen manipulatiemiddelen aanwezig zijn;  
— dat de zegels correct zijn aangebracht, in goede staat 
zijn en over een geldig identificatienummer beschikken 
(erkende zegelfabrikant in de EC-databank), en dat hun 
identificatienummer overeenstemt met de merktekens 
op het identificatieplaatje (zie voorschrift 401).  
411) Indien een van de in punt 3.9 (Detectie van voorvallen 
en/of fouten) genoemde voorvallen zich heeft voorgedaan 
sinds de laatste inspectie en door tachograaffabrikanten 
en/of de nationale overheid wordt beschouwd als moge ­
lijke bedreiging voor de beveiliging van het apparaat, moet 
de werkplaats:  
a. een vergelijking maken tussen de identificatiegegevens 
van de op de versnellingsbak aangesloten bewegings ­
sensor en de in de voertuigunit opgeslagen gegevens 
van de gekoppelde bewegingssensor;  
b. controleren of de informatie op het installatieplaatje 
overeenkomt met de in de voertuigunit opgeslagen in ­
formatie;  
c. controleren of het serienummer en het goedkeurings ­
nummer van de bewegingssensor, indien deze op de 
bewegingssensor zijn afgedrukt, overeenkomen met de 
in het geheugen van het controleapparaat opgeslagen 
informatie;  
d. de op het identificatieplaatje van de externe GNSS-mo ­
dule aangebrachte gegevens, indien van toepassing, ver ­
gelijken met de in het geheugen van de VU opgeslagen 
gegevens.  
412) Werkplaatsen moeten in hun inspectieverslag melding ma ­
ken van eventueel aangetroffen verbroken zegels of mani ­
pulatiemiddelen. Deze rapporten moeten minstens 2 jaar 
worden bewaard en op verzoek aan de bevoegde autoriteit 
worden overgelegd.  
413) Bij die controles moet een kalibrering plaatsvinden en 
moeten de zegels waarvan de aanwezigheid onder de ver ­
antwoordelijkheid van de werkplaats valt preventief wor ­
den vervangen.  
6.5 Meting van afwijkingen  
414) De meting van de afwijkingen bij installatie en gebruik 
gebeurt onder de volgende omstandigheden, die be ­
schouwd moeten worden als normale testomstandigheden:  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 82  
— onbelast voertuig, in normale rijklare toestand;  
— bandenspanning overeenkomstig de door de fabrikant 
verstrekte gegevens,  
— slijtage van de banden binnen de door de nationale 
voorschriften toegestane grenzen;  
— rijdend voertuig:  
— het voertuig moet zich, aangedreven door zijn eigen 
motor, langs een rechte lijn over een vlakke onder ­
grond bewegen met een snelheid van 50 ± 5 km/u. 
Het meettraject moet ten minste 1 000 m lang zijn;  
— de test mag ook uitgevoerd worden met alternatieve 
methoden, zoals op een geschikte proefbank, op voor ­
waarde dat deze even nauwkeurig zijn.  
6.6 Reparaties  
415) Werkplaatsen kunnen gegevens van het controleapparaat 
downloaden en deze gegevens teruggeven aan de betref ­
fende vervoersonderneming.  
416) Erkende werkplaatsen moeten een certificaat van onmoge ­
lijkheid tot het downloaden van gegevens aan de vervoers ­
ondernemingen afgeven, wanneer vooraf geregistreerde ge ­
gevens ten gevolge van de slechte werking van het con ­
troleapparaat zelfs na reparatie door de betrokken werk ­
plaats niet kunnen worden gedownload. De werkplaatsen 
bewaren een kopie van elk afgegeven certificaat gedurende 
ten minste twee jaar.  
7 AFGIFTE VAN KAARTEN  
De door de lidstaten vastgestelde werkwijze voor de afgifte van 
kaarten moet aan het volgende voldoen:  
417) Het kaartnummer van het eerste exemplaar van een tacho ­
graafkaart dat aan een aanvrager verstrekt wordt, moet een 
opeenvolgende index (indien van toepassing), een vervan ­
gingsindex en een vernieuwingsindex op de stand „0” 
hebben.  
418) Van de kaartnummers van alle niet-persoonlijke tacho ­
graafkaarten, die aan een bepaalde controle-instantie, een 
bepaalde werkplaats of een bepaalde vervoersonderneming 
zijn afgegeven, moeten de eerste 13 cijfers hetzelfde zijn. 
Verder moeten ze allemaal een andere opeenvolgende in ­
dex hebben.  
419) Een tachograafkaart die ter vervanging van een bestaande 
tachograafkaart wordt afgegeven, moet hetzelfde kaart ­
nummer hebben als de vervangen kaart, met uitzondering 
van de vervangingsindex die met „1” moet worden ver ­
hoogd (in de volgorde 0, …, 9, A, …, Z).  
420) Een tachograafkaart die ter vervanging van een bestaande 
tachograafkaart wordt afgegeven, moet dezelfde vervalda ­
tum hebben als de vervangen kaart.  
421) Een tachograafkaart die ter vernieuwing van een bestaande 
tachograafkaart wordt afgegeven, moet hetzelfde kaart ­
nummer hebben als de bestaande kaart met uitzondering 
van de vervangingsindex die op „0” moet worden terug ­
gezet en de vernieuwingsindex die met „1” moet worden 
verhoogd (in de volgorde 0, …, 9, A, …, Z).  
422) Het ruilen van een bestaande tachograafkaart met het oog 
op de wijziging van administratieve gegevens moet in 
dezelfde lidstaat gebeuren volgens de voorschriften voor 
vernieuwing, of de voorschriften voor de eerste afgifte 
wanneer de kaart in een andere lidstaat wordt geruild.  
423) In het geval van niet-persoonlijke werkplaats- of contro ­
lekaarten moet bij de „naam van de kaarthouder” de naam 
van de werkplaats of de controle-instantie worden inge ­
vuld, of de naam van de installateur of controleur indien 
de lidstaten daartoe besluiten.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 83  
424) De lidstaten wisselen elektronisch gegevens uit om het 
unieke karakter te waarborgen van de bestuurderskaarten 
die zij afgeven overeenkomstig artikel 31 van Verordening 
(EU) nr. 165/2014.  
8 TYPEGOEDKEURING VAN CONTROLEAPPARATEN EN TA ­
CHOGRAAFKAARTEN  
8.1 Algemeen  
▼M1 
In dit punt wordt onder „controleapparaat” verstaan: „controleap ­
paraat of de componenten daarvan”. Er is geen typegoedkeuring 
vereist voor de kabels waarmee de bewegingssensor, de externe 
GNSS-module of het systeem voor communicatie op afstand op 
de VU worden aangesloten. Het in het controleapparaat gebruikte 
papier wordt als een onderdeel van het controleapparaat beschouwd.  
Elke fabrikant kan een typegoedkeuring vragen van onderdelen van 
het controleapparaat die om het even welke andere onderdelen van 
controleapparaten bevatten, op voorwaarde dat elk onderdeel voldoet 
aan de voorschriften van deze bijlage. Fabrikanten kunnen als alter ­
natief ook een typegoedkeuring voor hun controleapparaten aanvra ­
gen. 
Zoals beschreven in definitie 10 van artikel 2 van deze verordening, 
kunnen voertuigunits zijn samengesteld uit diverse onderdelen. On ­
geacht uit welke onderdelen de voertuigunit is samengesteld, maken 
de externe antenne en (indien aanwezig) de antennesplitter die is 
aangesloten op de GNSS-ontvanger of het systeem voor communi ­
catie op afstand, geen deel uit van de typegoedkeuring van het 
voertuig.  
Desondanks houden fabrikanten die typegoedkeuring voor contro ­
leapparaten hebben verkregen een openbaar beschikbare lijst bij van 
antennes en splitters die compatible zijn met elke voertuigunit, met 
elke externe GNSS-module en met elk extern systeem voor com ­
municatie op afstand waarvoor typegoedkeuring is verleend.  
▼B 
425) Het controleapparaat moet met alle geïntegreerde aanvul ­
lende systemen ter goedkeuring worden aangeboden.  
426) De typegoedkeuring van het controleapparaat en van de 
tachograafkaarten omvat tests van de beveiliging, functie ­
tests en interoperabiliteitstests. Positieve testresultaten wor ­
den op een relevant certificaat vermeld.  
▼M1 
427) De goedkeuringsautoriteiten van de lidstaten geven pas 
een typegoedkeuringscertificaat af wanneer zij beschikken 
over:  
— een beveiligingscertificaat (indien vereist uit hoofde 
van deze bijlage),  
— een functiecertificaat,  
— een interoperabiliteitscertificaat (indien vereist uit 
hoofde van deze bijlage)  
voor het controleapparaat of de tachograafkaart waarvoor 
de typegoedkeuring wordt aangevraagd.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 84  
428) De autoriteit die de goedkeuring voor het apparaat ver ­
leende, moet vooraf in kennis worden gesteld van elke 
wijziging in de software of hardware van het apparaat of 
in de aard van de voor de fabricage gebruikte materialen. 
Deze autoriteit bevestigt de verlenging van de goedkeuring 
aan de fabrikant of eist een aanpassing of een bevestiging 
van de relevante functie-, beveiligings- en/of interoperabi ­
liteitscertificaten.  
429) Procedures voor een in-situ upgrade van de software van 
het controleapparaat moeten worden goedgekeurd door de 
autoriteit die de typegoedkeuring voor het controleapparaat 
heeft verleend. Een aanpassing van de software mag de in 
het controleapparaat opgeslagen gegevens over de activi ­
teiten van de bestuurder wijzigen noch verwijderen. Soft ­
ware mag alleen worden aangepast onder de verantwoor ­
delijkheid van de fabrikant van het apparaat.  
430) De typegoedkeuring van softwarewijzigingen met het oog 
op een upgrade van voorheen goedgekeurde apparatuur 
mag niet worden geweigerd indien de wijzigingen alleen 
betrekking hebben op functies die niet in deze bijlage zijn 
gespecificeerd. Indien technisch niet uitvoerbaar, mag de 
invoering van nieuwe tekensets bij de software-upgrade 
van controleapparaten achterwege worden gelaten.  
8.2 Veiligheidscertificaat  
431) Het veiligheidscertificaat wordt afgegeven in overeenstem ­
ming met de bepalingen van aanhangsel 10 van deze bij ­
lage. De onderdelen van het controleapparaat die moeten 
worden gecertificeerd, zijn de voertuigunit, de bewegings ­
sensor, de externe GNSS-module en de tachograafkaart.  
432) In het uitzonderlijke geval dat de autoriteiten voor bevei ­
ligingscertificering weigeren een nieuw apparaat te certifi ­
ceren op grond van veroudering van de beveiligings ­
mechanismen, wordt alleen typegoedkeuring verleend in 
dit specifieke en uitzonderlijke geval en wanneer er geen 
andere, met de verordening in overeenstemming zijnde 
oplossing bestaat.  
433) In dat geval stelt de lidstaat onverwijld de Europese Com ­
missie op de hoogte, die binnen twaalf kalendermaanden 
na de verleende typegoedkeuring een procedure start om 
ervoor te zorgen dat de beveiliging weer op haar oorspron ­
kelijke niveau wordt gebracht.  
8.3 Functiecertificaat  
434) Elke aanvrager van een typegoedkeuring moet de goed ­
keuringsautoriteit van de lidstaat de door die autoriteit 
noodzakelijk geachte materialen en documentatie verschaf ­
fen. 
435) De fabrikanten dienen binnen één maand nadat daarom is 
verzocht de relevante monsters van goedgekeurde produc ­
ten en de bijbehorende documentatie te verstrekken die de 
met het uitvoeren van functionele tests belaste laboratoria 
nodig hebben. Alle uit dat verzoek voortvloeiende kosten 
worden gedragen door de partij die daarom vraagt. De 
laboratoria dienen commercieel gevoelige informatie ver ­
trouwelijk te behandelen.  
436) Een functiecertificaat wordt alleen aan de fabrikant afge ­
geven nadat in elk geval alle functiebeproevingen als ge ­
specificeerd in aanhangsel 9, succesvol afgesloten zijn.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 85  
437) De typegoedkeuringsautoriteit geeft het functiecertificaat 
af. Dit certificaat moet behalve de naam van de ontvanger 
en de identificatie van het model ook een gedetailleerde 
lijst van uitgevoerde tests en behaalde resultaten vermel ­
den. 
438) Op het functiecertificaat van een controleapparaat moeten 
ook de typegoedkeuringsnummers zijn aangegeven van 
alle andere goedgekeurde compatibele onderdelen van 
dat apparaat die voor de certificering van het controleap ­
paraat zijn getest.  
439) Op het functiecertificaat van een onderdeel van een con ­
troleapparaat wordt vermeld aan welke ISO of CEN-norm 
de functionele interface is getoetst.  
8.4 Interoperabiliteitscertificaat  
440) Interoperabiliteitstests worden door een laboratorium uitge ­
voerd in opdracht en onder verantwoordelijkheid van de 
Europese Commissie.  
441) Het laboratorium moet de verzoeken van fabrikanten om 
interoperabiliteitstests in chronologische volgorde van ont ­
vangst registreren.  
442) Verzoeken worden officieel geregistreerd wanneer het la ­
boratorium in het bezit is van:  
— alle materialen en documenten die nodig zijn voor de 
interoperabiliteitstests;  
— het corresponderende beveiligingscertificaat;  
— het corresponderende functiecertificaat.  
De fabrikant moet over de registratiedatum van het ver ­
zoek worden geïnformeerd.  
443) Het laboratorium voert geen interoperabiliteitstests uit voor 
controleapparaten of tachograafkaarten waarvoor geen be ­
veiligingscertificaat en functiecertificaat is afgegeven, be ­
halve in de uitzonderlijke omstandigheden die zijn be ­
schreven in voorschrift 432.  
444) Een fabrikant die een interoperabiliteitstest aanvraagt, moet 
alle materialen en documenten die nodig zijn voor het 
uitvoeren van de test verstrekken aan het voor deze test 
verantwoordelijke laboratorium.  
445) De interoperabiliteitstests worden, overeenkomstig aan ­
hangsel 9 van deze bijlage, uitgevoerd met alle types con ­
troleapparatuur of tachograafkaarten  
— waarvan de typegoedkeuring nog steeds geldig is of  
— waarvan de typegoedkeuring is aangevraagd en waar ­
voor een geldig interoperabiliteitscertificaat is verleend.  
446) De interoperabiliteitstests bestrijken alle generaties van 
controleapparaten of tachograafkaarten die nog worden ge ­
bruikt.  
447) Het laboratorium geeft het interoperabiliteitscertificaat al ­
leen aan de fabrikant af nadat alle vereiste interoperabili ­
teitstest zijn geslaagd.  
448) Indien de interoperabiliteitstests bij een of meer contro ­
leapparaten of tachograafkaarten niet zijn geslaagd, wordt 
het interoperabiliteitscertificaat pas afgegeven nadat de be ­
treffende fabrikant de noodzakelijke wijzigingen heeft aan ­
gebracht en de apparatuur respectievelijk kaarten de daar ­
opvolgende interoperabiliteitstest met goed gevolg hebben  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 86  
doorstaan. Het laboratorium moet de oorzaak van het pro ­
bleem met de hulp van de betreffende fabrikanten vast ­
stellen en moet de fabrikant die het verzoek heeft in ­
gediend, helpen om een technische oplossing te zoeken. 
Als de fabrikant zijn product heeft gewijzigd, dient hij bij 
de bevoegde instantie na te vragen of het veiligheidscerti ­
ficaat en het functiecertificaat geldig blijven.  
449) Het interoperabiliteitscertificaat is zes maanden geldig. 
Aan het einde van deze periode wordt het ingetrokken 
wanneer de fabrikant geen corresponderend goedkeurings ­
certificaat heeft ontvangen. Het certificaat moet door de 
fabrikant naar de goedkeuringsautoriteit van de lidstaat 
worden gezonden die het functiecertificaat heeft afgege ­
ven. 
450) Elk onderdeel dat aan de basis van een interoperabiliteits ­
fout kan liggen, mag niet worden gebruikt om voordelen 
of een dominante positie te verkrijgen.  
8.5 Typegoedkeuringscertificaat  
451) De goedkeuringsautoriteit van de lidstaat geeft het goed ­
keuringscertificaat af zodra de autoriteit in het bezit is van 
de drie vereiste certificaten.  
452) Op het typegoedkeuringscertificaat van onderdelen van een 
controleapparaat moeten ook de typegoedkeuringsnummers 
van alle andere goedgekeurde interoperabele controleap ­
paraten worden vermeld  
453) Op het moment van afgifte aan de fabrikant moet de ty ­
pegoedkeuringsautoriteit een kopie van het typegoedkeu ­
ringscertificaat aan het voor de interoperabiliteitstest ver ­
antwoordelijke laboratorium verstrekken.  
454) Het voor de interoperabiliteitstests bevoegde laboratorium 
moet een publiek toegankelijke website beheren waarop de 
lijst van types controleapparaten of tachograafkaarten 
wordt bijgewerkt:  
— waarvoor een verzoek tot uitvoering van interoperabi ­
liteitstests is geregistreerd;  
— waarvoor een interoperabiliteitscertificaat (ook tijde ­
lijk) is afgegeven;  
— waarvoor een typegoedkeuringscertificaat is afgegeven.  
8.6 Bijzondere procedure: eerste interoperabiliteitscertificaten voor 
controleapparaten en tachograafkaarten van de 2de generatie  
455) Tot vier maanden nadat de eerste combinatie van contro ­
leapparaat van de 2de generatie en tachograafkaart van de 
2de generatie (bestuurders-, werkplaats-, controle- en be ­
drijfskaart) als interoperabel gecertificeerd is, wordt een 
afgegeven interoperabiliteitscertificaat (inclusief de aller ­
eerste) met betrekking tot tijdens deze periode geregis ­
treerde verzoeken, als tijdelijk beschouwd.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 87  
456) Wanneer aan het einde van deze periode alle betreffende 
producten onderling interoperabel zijn, worden alle corres ­
ponderende interoperabiliteitscertificaten definitief.  
457) Wanneer tijdens deze periode interoperabiliteitsfouten wor ­
den ontdekt, moet het voor de interoperabiliteitstests ver ­
antwoordelijke laboratorium de oorzaak van de problemen 
met hulp van alle betrokken fabrikanten vaststellen en 
moeten de fabrikanten de noodzakelijke wijzigingen aan ­
brengen.  
458) Indien zich aan het einde van deze periode nog steeds 
interoperabiliteitsproblemen voordoen, moet het voor de 
interoperabiliteitstests verantwoordelijke laboratorium in 
samenwerking met de betreffende fabrikanten en de goed ­
keuringsautoriteiten die de corresponderende functiecertifi ­
caten hebben afgegeven, de oorzaken van de interoperabi ­
liteitsfouten detecteren en vaststellen welke wijzigingen 
door de betreffende fabrikanten moeten worden aange ­
bracht. Het zoeken naar technische oplossingen duurt 
maximaal twee maanden, waarna, indien geen algemene 
oplossing gevonden wordt, de Commissie na overleg met 
het voor de interoperabiliteitstests verantwoordelijke labo ­
ratorium beslist welke apparaten en kaarten een definitief 
interoperabiliteitscertificaat krijgen. De Commissie moti ­
veert haar beslissing.  
459) Elk verzoek tot uitvoering van interoperabiliteitstests dat 
door het laboratorium geregistreerd wordt tussen het einde 
van de periode van vier maanden nadat het eerste tijdelijke 
interoperabiliteitscertificaat is afgegeven en de datum van 
het besluit van de Commissie als bedoeld in voorschrift 
455, moet worden opgeschort totdat de aanvankelijke in ­
teroperabiliteitsproblemen opgelost zijn. Die verzoeken 
worden vervolgens in chronologische volgorde van regis ­
tratie behandeld.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 88  
Aanhangsel 1  
DATA DICTIONARY  
INHOUDSOPGAVE  
1. INLEIDING  
1.1. Methoden voor de definitie van soorten gegevens  
1.2. Referentienormen  
2. DEFINITIES VAN SOORTEN GEGEVENS  
2.1. ActivityChangeInfo  
2.2. Address  
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  
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  
2.25. CardMACertificate  
2.26. CardNumber  
2.27. CardPlaceDailyWorkPeriod  
2.28. CardPrivateKey  
2.29. CardPublicKey  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 89  
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. Certificate  
2.42. CertificateContent  
2.43. CertificateHolderAuthorisation  
2.44. CertificateRequestID  
2.45. CertificationAuthorityKID  
2.46. CompanyActivityData  
2.47. CompanyActivityType  
2.48. CompanyCardApplicationIdentification  
2.49. CompanyCardHolderIdentification  
2.50. ControlCardApplicationIdentification  
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. Distance  
2.61. DriverCardApplicationIdentification  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 90  
2.62. DriverCardHolderIdentification  
▼M1 
2.63. Gereserveerd voor toekomstig gebruik  
▼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  
2.74. FullCardNumberAndGeneration  
2.75. Generation  
2.76. GeoCoordinates  
2.77. GNSSAccuracy  
▼M1 
2.78. GNSSAccumulatedDriving  
2.79. GNSSAccumulatedDrivingRecord  
▼B 
2.80. GNSSPlaceRecord  
2.81. HighResOdometer  
2.82. HighResTripDistance  
2.83. HolderName  
2.84. InternalGNSSReceiver  
2.85. K-ConstantOfRecordingEquipment  
2.86. KeyIdentifier  
2.87. KMWCKey  
2.88. Language  
2.89. LastCardDownload  
2.90. LinkCertificate  
2.91. L-TyreCircumference  
2.92. MAC  
2.93. ManualInputFlag  
2.94. ManufacturerCode  
2.95. ManufacturerSpecificEventFaultData  
2.96. MemberStateCertificate  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 91  
2.97. MemberStateCertificateRecordArray  
2.98. MemberStatePublicKey  
2.99. Name  
2.100. NationAlpha  
2.101. NationNumeric  
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  
▼B 
2.112. NoOfSpecificConditionRecords  
2.113. OdometerShort  
2.114. OdometerValueMidnight  
2.115. OdometerValueMidnightRecordArray  
2.116. OverspeedNumber  
2.117. PlaceRecord  
2.118. PreviousVehicleInfo  
2.119. PublicKey  
2.120. RecordType  
2.121. RegionAlpha  
2.122. RegionNumeric  
2.123. RemoteCommunicationModuleSerialNumber  
2.124. RSAKeyModulus  
2.125. RSAKeyPrivateExponent  
2.126. RSAKeyPublicExponent  
2.127. RtmData  
2.128. SealDataCard  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 92  
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. Handtekening  
2.150. SignatureRecordArray  
2.151. SimilarEventsNumber  
2.152. SpecificConditionRecord  
2.153. SpecificConditions  
2.154. SpecificConditionType  
2.155. Speed  
2.156. SpeedAuthorised  
2.157. SpeedAverage  
2.158. SpeedMax  
2.159. TachographPayload  
▼M1 
2.160. Gereserveerd voor toekomstig gebruik  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 93  
2.161. TDesSessionKey  
2.162. TimeReal  
2.163. TyreSize  
2.164. VehicleIdentificationNumber  
2.165. VehicleIdentificationNumberRecordArray  
2.166. VehicleRegistrationIdentification  
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  
2.179. VuCardRecord  
2.180. VuCardRecordArray  
2.181. VuCertificate  
2.182. VuCertificateRecordArray  
2.183. VuCompanyLocksData  
2.184. VuCompanyLocksRecord  
2.185. VuCompanyLocksRecordArray  
2.186. VuControlActivityData  
2.187. VuControlActivityRecord  
2.188. VuControlActivityRecordArray  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 94  
2.189. VuDataBlockCounter  
2.190. VuDetailedSpeedBlock  
2.191. VuDetailedSpeedBlockRecordArray  
2.192. VuDetailedSpeedData  
2.193. VuDownloadablePeriod  
2.194. VuDownloadablePeriodRecordArray  
2.195. VuDownloadActivityData  
2.196. VuDownloadActivityDataRecordArray  
2.197. VuEventData  
2.198. VuEventRecord  
2.199. VuEventRecordArray  
2.200. VuFaultData  
2.201. VuFaultRecord  
2.202. VuFaultRecordArray  
▼M1 
2.203. VuGNSSADRecord  
2.204. VuGNSSADRecordArray  
▼B 
2.205. VuIdentification  
2.206. VuIdentificationRecordArray  
2.207. VuITSConsentRecord  
2.208. VuITSConsentRecordArray  
2.209. VuManufacturerAddress  
2.210. VuManufacturerName  
2.211. VuManufacturingDate  
2.212. VuOverSpeedingControlData  
2.213. VuOverSpeedingControlDataRecordArray  
2.214. VuOverSpeedingEventData  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 95  
2.215. VuOverSpeedingEventRecord  
2.216. VuOverSpeedingEventRecordArray  
2.217. VuPartNumber  
2.218. VuPlaceDailyWorkPeriodData  
2.219. VuPlaceDailyWorkPeriodRecord  
2.220. VuPlaceDailyWorkPeriodRecordArray  
2.221. VuPrivateKey  
2.222. VuPublicKey  
2.223. VuSerialNumber  
2.224. VuSoftInstallationDate  
2.225. VuSoftwareIdentification  
2.226. VuSoftwareVersion  
2.227. VuSpecificConditionData  
2.228. VuSpecificConditionRecordArray  
2.229. VuTimeAdjustmentData  
▼M1 
2.230. Gereserveerd voor toekomstig gebruik  
2.231. Gereserveerd voor toekomstig gebruik  
▼B 
2.232. VuTimeAdjustmentRecord  
2.233. VuTimeAdjustmentRecordArray  
2.234. WorkshopCardApplicationIdentification  
2.235. WorkshopCardCalibrationData  
2.236. WorkshopCardCalibrationRecord  
2.237. WorkshopCardHolderIdentification  
2.238. WorkshopCardPIN  
2.239. W-VehicleCharacteristicConstant  
2.240. VuPowerSupplyInterruptionRecord  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 96  
2.241. VuPowerSupplyInterruptionRecordArray  
2.242. VuSensorExternalGNSSCoupledRecordArray  
2.243. VuSensorPairedRecordArray  
3. DEFINITIES VAN WAARDEN- EN AFMETINGENBEREIK  
4. TEKENSETS  
5. CODERING  
6. OBJECTIDENTIFICATIE EN TOEPASSINGSIDENTIFICATIE  
6.1. Objectidentificatie  
6.2. Toepassingsidentificaties  
1. INLEIDING  
In dit aanhangsel worden gegevensformaten, -elementen en -structuren 
gespecificeerd voor gebruik in controleapparaten en op tachograafkaar ­
ten. 
1.1. Methoden voor de definitie van soorten gegevens  
In dit aanhangsel wordt Abstract Syntax Notation One (ASN.1) gebruikt 
om soorten gegevens te definiëren. Daardoor is het mogelijk enkelvou ­
dige en gestructureerde gegevens te definiëren zonder een toepassings- 
en omgevingsafhankelijke specifieke overdrachtssyntaxis (coderings ­
regels).  
ASN.1-conventies voor soortbenaming worden gebruikt in overeenstem ­
ming met ISO/IEC 8824-1. Dat betekent dat:  
— waar mogelijk de betekenis van de gegevenssoort door middel van 
de geselecteerde benamingen wordt aangeduid;  
— waar een gegevenssoort een samenstelling van andere gegevenssoor ­
ten is, de benaming van de gegevenssoort toch een enkele reeks 
alfabetische tekens is die begint met een hoofdletter. Hoofdletters 
worden echter in de benaming gebruikt om de corresponderende 
betekenis te verduidelijken;  
— de benamingen van de soorten gegevens in het algemeen betrekking 
hebben op de benaming van de soorten gegevens waaruit ze zijn 
samengesteld, de apparatuur waarin de gegevens zijn opgeslagen en 
de aan de gegevens gerelateerde functie.  
Als een ASN.1-soort reeds als onderdeel van een andere norm is gede ­
finieerd en als hij relevant is voor gebruik in het controleapparaat, wordt 
die ASN.1-soort in dit aanhangsel gedefinieerd.  
Om verscheidene soorten coderingsregels mogelijk te maken, is een 
aantal ASN.1-soorten in dit aanhangsel beperkt door identificatiesymbo ­
len voor het waardenbereik. Die identificatiesymbolen voor het waarden ­
bereik zijn gedefinieerd in punt 3 en aanhangsel 2.  
1.2. Referentienormen  
In dit aanhangsel worden de volgende referentienormen gebruikt:  
ISO 639 Code voor namen van talen. Eerste uitgave: 1988.  
ISO 3166 Codes voor de weergave van landnamen en hun on ­
derverdelingen — Deel 1: Landencodes, 2013.  
ISO 3779 Wegvoertuigen — Voertuig-identificatienummer 
(VIN) — Inhoud en structuur. 2009.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 97  
ISO/IEC 7816-5 Identification cards — Integrated circuit cards — Part 
5: Registration of application providers.  
Second edition: 2004.  
ISO/IEC 7816-6 Identification cards — Integrated circuit cards — Part 
6: Interindustry data elements for interchange, 2004 + 
Technical Corrigendum 1: 2006.  
ISO/IEC 8824-1 Information technology — Abstract Syntax Notation 
One (ASN.1): Specification of basic notation. 2008 + 
Technical Corrigendum 1: 2012 and Technical Corri ­
gendum 2: 2014.  
ISO/IEC 8825-2 Information technology — ASN.1 encoding rules: 
Specification of Packed Encoding Rules (PER). 2008.  
ISO/IEC 8859-1 Information technology — 8-bit single-byte coded 
graphic character sets — Part 1: Latin alphabet No. 
1 First edition: 1998.  
ISO/IEC 8859-7 Information technology — 8-bit single-byte coded 
graphic character sets — Part 7: Latin/Greek alphabet. 
2003.  
ISO 16844-3 Wegvoertuigen — Tachograafsystemen — Aanslui ­
ting van bewegingssensor. 2004 + Technical Corri ­
gendum 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. DEFINITIES VAN SOORTEN GEGEVENS  
Voor elk van de volgende gegevenssoorten bestaat de standaardwaarde 
voor een ”onbekende” of een ”niet-toepasbare” inhoud in het opvullen 
van het dataelement met ‘FF’-bytes.  
Alle gegevenssoorten worden gebruikt voor toepassingen van de 1e en 
2e generatie, tenzij anders bepaald.  
▼M1 
Voor kaartgegevenstypes die worden gebruikt voor toepassingen van de 
eerste en tweede generatie is het in dit aanhangsel gespecificeerde for ­
maat dat voor toepassingen van de tweede generatie. Het formaat voor 
toepassingen van de eerste generatie wordt geacht reeds bekend te zijn 
bij de lezer. Het voorschrift van bijlage IC met betrekking tot dergelijke 
gegevenstypes heeft betrekking op toepassingen van zowel de eerste als 
de tweede generatie.  
▼B 
2.1. ActivityChangeInfo  
Met deze gegevenssoort kan de status van een lezer op 00:00 en/of de 
status van een bestuurder op 00:00 en/of wijzigingen van activiteit en/of 
wijzigingen in de status van de bestuurder en/of wijzigingen in de status 
van een kaart voor een bestuurder of een bijrijder gecodeerd worden 
binnen een woord van twee bytes. Deze gegevenssoort is gerelateerd aan 
de voorschriften 105, 266, 291, 320, 321, 343 en 344 van bijlage 1C.
  
Waardetoekenning  — Octet-uitgericht : ‘scpaattttttttttt’B (16-bits)  
Voor geheugenrecords (of status van de lezer):  
‘s’B Lezer:  
‘0’B: BESTUURDER,  
‘1’B: BIJRIJDER,  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 98  
‘c’B Status van de bestuurder:  
‘0’B: ALLEEN,  
‘1’B: MET EEN TEAM,  
‘p’B Status van de bestuurderskaart (of werkplaatskaart) in 
de relevante lezer:  
‘0’B: INGEBRACHT, een kaart is ingebracht,  
‘1’B: NIET INGEBRACHT, er is geen kaart in ­
gebracht (of er is een kaart uitgenomen),  
‘aa’B Activiteit:  
‘00’B: PAUZE/RUST,  
‘01’B: BESCHIKBAARHEID,  
‘10’B: WERKEN,  
‘11’B: RIJDEN,  
‘ttttttttttt’B Tijd van de wijziging: aantal minuten vanaf 00.00 uur 
op de betreffende dag.  
Voor bestuurderskaartregistraties (of werkplaatskaartregistraties) (en sta ­
tus van de bestuurder):  
‘s’B Lezer (niet relevant als ‘p’ = 1, behoudens onder ­
staande opmerking):  
‘0’B: BESTUURDER,  
‘1’B: BIJRIJDER,  
‘c’B Status van de bestuurder (geval ‘p’ = 0) of  
Volgende activiteitstatus (geval ‘p’ = 1):  
‘0’B: ALLEEN,  
‘0’B: ONBEKEND,  
‘1’B: MET EEN TEAM,  
‘1’B: BEKEND (= manueel ingevoerd)  
‘p’B Status van de kaart:  
‘0’B: INGEBRACHT, de kaart is in een controleap ­
paraat ingebracht,  
‘1’B: NIET INGEBRACHT, de kaart is niet in ­
gebracht (of de kaart is uitgenomen),  
‘aa’B Activiteit (niet relevant als ‘p’ = 1 en ‘c’ = 0, behou ­
dens onderstaande opmerking):  
‘00’B: PAUZE/RUST,  
‘01’B: BESCHIKBAARHEID,  
‘10’B: WERKEN,  
‘11’B: RIJDEN,  
‘ttttttttttt’B Tijd van de wijziging: aantal minuten vanaf 00.00 uur 
op de betreffende dag.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 99  
Opmerking in geval van ”kaartuitneming”:  
Als de kaart is uitgenomen:  
— ‘s’ is relevant en geeft de lezer aan waar de kaart is uitgenomen,  
— ‘c’ moet op 0 worden gezet,  
— ‘p’ moet op 1 worden gezet,  
— ‘aa’ moet de lopende, op dat moment geselecteerde activiteit code ­
ren. 
Ten gevolge van een manuele invoer kunnen de bits ‘c’ en ‘aa’ van het 
(op een kaart opgeslagen) woord later worden overschreven om de in ­
voer weer te geven.  
2.2. Address  
Een adres.
  
codePage  specificeert een tekenset zoals gedefinieerd in hoofdstuk 4,  
address  is een adres dat is gecodeerd met de gespecificeerde tekenset.  
2.3. AESKey  
2e generatie:  
Een AES-sleutel met een lengte van 128, 192 of 256 bits.
  
Waardetoekenning : niet nader gespecificeerd.  
2.4. AES128Key  
2e generatie:  
Een AES128-sleutel.
  
length  geeft de lengte van de AES128-sleutel in bytes aan.  
aes128Key  is een AES-sleutel met een lengte van 128 bits.  
Waardetoekenning:  
de lengte heeft waarde 16.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 100  
2.5. AES192Key  
2e generatie:  
Een AES192-sleutel.
  
length  geeft de lengte van de AES192-sleutel in bytes aan.  
aes192Key  is een AES-sleutel met een lengte van 192 bits.  
Waardetoekenning:  
de lengte heeft waarde 24.  
2.6. AES256Key  
2e generatie:  
Een AES256-sleutel.
  
length  geeft de lengte van de AES256-sleutel in bytes aan.  
aes256Key  is een AES-sleutel met een lengte van 256 bits.  
Waardetoekenning:  
de lengte heeft waarde 32.  
2.7. BCDString  
BCDString wordt toegepast voor de BCD-weergave (Binary Code De ­
cimal, binair gecodeerde decimaal). Deze datasoort wordt gebruikt om 
een decimaal cijfer in een semi-byte (4 bits) weer te geven. BCDString is 
gebaseerd op het ‘CharacterStringType’ van ISO/IEC 8824-1.
  
BCDString gebruikt een ”hstring”-notatie. Het uiterst linkse hexadeci ­
male cijfer moet de meest significante semi-byte van de eerste byte zijn. 
Om een veelvoud van bytes aan te maken, moeten zoveel semi-bytes 
eindigend op nul worden ingebracht als nodig zijn vanaf de uiterst linkse 
semi-bytepositie in de eerste byte.  
Toegestane cijfers zijn: 0, 1, …, 9.  
2.8. CalibrationPurpose  
Code die verklaart waarom een verzameling kalibratieparameters werd 
geregistreerd. Deze gegevenssoort is gerelateerd aan de voorschriften 
097 en 098 van bijlage 1B en voorschrift 119 van bijlage 1C.
  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 101  
Waardetoekenning:  
1e generatie:  
‘00’H gereserveerde waarde,  
‘01’H activering: registratie van kalibratieparameters die op 
het moment van activering van de voertuigunit (VU) 
bekend zijn,  
‘02’H eerste installatie: eerste kalibratie van de VU na ac ­
tivering,  
‘03’H installatie: eerste kalibratie van de VU in het huidige 
voertuig,  
‘04’H periodieke controle.  
2e generatie:  
Als aanvulling op de 1e generatie worden de volgende waarden gebruikt:  
‘05’H invoering van kentekennummer door de onderneming,  
‘06’H tijdafstelling zonder kalibratie,  
‘07’H tot ‘7F’H RFU,  
‘80’H tot ‘FF’H Specifiek voor de fabrikant.  
2.9. CardActivityDailyRecord  
Op een kaart opgeslagen informatie met betrekking tot de activiteiten 
van de bestuurder op een bepaalde dag. Deze gegevenssoort is gerela ­
teerd aan de voorschriften 266, 291, 320 en 343 van bijlage 1C.
  
activityPreviousRecordLength  is de totale lengte in bytes van de voor ­
afgaande dagelijkse registratie. De maximale waarde wordt toegekend 
door de lengte van de OCTET STRING die deze records bevat (zie 
CardActivityLengthRange aanhangsel 2, punt 4). Als die record de oud ­
ste dagelijkse registratie is, moet de waarde van activityPreviousRecord ­
Length op 0 worden gezet.  
activityRecordLength  is de totale lengte in bytes van deze record. De 
maximale waarde wordt toegekend door de lengte van de OCTET 
STRING die deze records bevat.  
activityRecordDate  is de datum van de record.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 102  
activityDailyPresenceCounter  is de dagelijkse aanwezigheidsteller voor 
de kaart op die dag.  
activityDayDistance  is de totale op die dag afgelegde afstand.  
activityChangeInfo  is de verzameling ActivityChangeInfo-gegevens 
voor de bestuurder op die dag. Het kan maximaal 1440 waarden bevat ­
ten (één activiteitswijziging per minuut). De verzameling bevat altijd de 
activityChangeInfo waarmee de bestuurderstatus op 00:00 wordt geco ­
deerd.  
2.10.  CardActivityLengthRange  
Aantal beschikbare bytes op een bestuurders- of werkplaatskaart voor het 
opslaan van records van de activiteiten van de bestuurder.
  
Waardetoekenning : zie aanhangsel 2.  
2.11.  CardApprovalNumber  
Typegoedkeuringsnummer van de kaart.
  
Waardetoekenning:  
het goedkeuringsnummer wordt verstrekt zoals het is bekendgemaakt op 
de overeenkomstige website van de Europese Commissie, bijv. met 
eventuele koppeltekens. Het goedkeuringsnummer wordt links uitgelijnd.  
2.12.  CardCertificate  
1e generatie:  
Certificaat van de openbare sleutel van een kaart.
  
2.13.  CardChipIdentification  
Op een kaart opgeslagen informatie met betrekking tot de identificatie 
van het geïntegreerd circuit (IC) van de kaart (voorschrift 249 van bij ­
lage 1C). Het icSerialNumber vormt samen met de icManufacturingRe ­
ferences de unieke identificatie van de kaartchip. Het icSerialNumber 
alleen is geen unieke identificatie van de kaartchip.
  
icSerialNumber  is het serienummer van het IC.  
icManufacturingReferences  is het specifieke identificatiesymbool van 
de fabrikant van het IC.  
2.14.  CardConsecutiveIndex  
Opeenvolgende index van de kaart (definitie h)).
  
Waardetoekenning : (zie bijlage 1C, hoofdstuk 7).  
Volgorde van verhoging: ‘0, …, 9, A, …, Z, a, …, z’  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 103  
2.15.  CardControlActivityDataRecord  
Op een bestuurders- of werkplaatskaart opgeslagen informatie met be ­
trekking tot de laatste controle van de bestuurder (voorschriften 274, 
299, 327 en 350 van bijlage 1C).
  
controlType  is de soort controle.  
controlTime  is de datum en het tijdstip van de controle.  
controlCardNumber  is het FullCardNumber van de controleur die de 
controle heeft uitgevoerd.  
controlVehicleRegistration  is het kentekennummer en de registrerende 
lidstaat van het voertuig waarin de controle plaatsvond.  
controlDownloadPeriodBegin  en controlDownloadPeriodEnd  is de 
gedownloade periode in geval van download.  
2.16.  CardCurrentUse  
Informatie over het werkelijke gebruik van de kaart (voorschriften 273, 
298, 326 en 349 van bijlage 1C).
  
sessionOpenTime  is het tijdstip waarop de kaart voor het huidige ge ­
bruik ingebracht wordt. Dat element wordt bij kaartuitneming op nul 
gezet.  
sessionOpenVehicle  is de identificatie van het thans gebruikte voertuig, 
die wordt ingesteld bij kaartinbrenging. Dat element wordt bij kaartuit ­
neming op nul gezet.  
2.17.  CardDriverActivity  
Op een bestuurders- of werkplaatskaart opgeslagen informatie met be ­
trekking tot de activiteiten van de bestuurder (voorschriften 267, 268, 
292, 293, 321 en 344 van bijlage 1C).
  
activityPointerOldestDayRecord  is de specificatie van het begin van de 
geheugenplaats (aantal bytes vanaf het begin van de string) van de 
oudste volledige dagregistratie in de activityDailyRecords-string. De 
maximale waarde wordt door de lengte van de string aangegeven.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 104  
activityPointerNewestRecord  is de specificatie van het begin van de 
geheugenplaats (aantal bytes vanaf het begin van de string) van de meest 
recente dagregistratie in de activityDailyRecords-string. De maximale 
waarde wordt door de lengte van de string aangegeven.  
activityDailyRecords  is de ruimte die beschikbaar is om de gegevens 
over de activiteit van de bestuurder op te slaan (gegevensstructuur: Card ­
ActivityDaily record) voor elke kalenderdag waarop de kaart is gebruikt.  
Waardetoekenning : deze bytestring wordt periodiek met registraties van 
de CardActivityDailyRecord gevuld. Bij het eerste gebruik begint de 
opslag met de eerste byte van de string. Alle nieuwe records worden 
aan het einde van de voorgaande record toegevoegd. Als de string vol is, 
gaat de opslag verder bij de eerste byte van de string, onafhankelijk van 
een onderbreking binnen een gegevenselement. Voor het invoeren van 
nieuwe gegevens over activiteiten in de string (uitbreiden van de lopende 
activityDailyRecord of invoeren van een nieuwe activityDailyRecord), 
die oudere gegevens over activiteiten vervangen, moet de activityPoin ­
terOldestDayRecord worden bijgewerkt om de nieuwe locatie van de 
oudste volledige dagregistratie weer te geven; de activityPreviousRecord ­
Length van deze (nieuwe) oudste volledige dagregistratie moet op 0 
worden teruggezet.  
2.18.  CardDrivingLicenceInformation  
Op een bestuurderskaart opgeslagen informatie met betrekking tot de 
rijbewijsgegevens van de kaarthouder (voorschriften 259 en 284 van 
bijlage 1C).
  
drivingLicenceIssuingAuthority  is de autoriteit die verantwoordelijk is 
voor de afgifte van het rijbewijs.  
drivingLicenceIssuingNation  is de nationaliteit van de autoriteit die het 
rijbewijs heeft afgegeven.  
drivingLicenceNumber  is het nummer van het rijbewijs.  
▼M1 
2.19.  CardEventData  
1e generatie:  
Op een bestuurders- of werkplaatskaart opgeslagen informatie met be ­
trekking tot de aan de kaarthouder te wijten voorvallen (Bijlage IC, 
voorschriften 260 en 318).
  
CardEventData  is een sequentie, gerangschikt op oplopende waarde 
van EventFaultType, van cardEventRecords (uitgezonderd records die 
verband houden met pogingen tot inbreuk op de beveiliging, die in de 
laatste reeks van de sequentie worden verzameld).  
cardEventRecords  is een reeks voorvalrecords van een bepaald type 
voorval (of categorie voor voorvallen met betrekking tot pogingen tot 
inbreuk op de beveiliging).  
2e generatie:  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 105  
Op een bestuurders- of werkplaatskaart opgeslagen informatie met be ­
trekking tot de aan de kaarthouder te wijten voorvallen (Bijlage IC, 
voorschriften 285 en 341).
  
CardEventData  is een sequentie, gerangschikt op oplopende waarde 
van EventFaultType, van cardEventRecords (uitgezonderd records die 
verband houden met pogingen tot inbreuk op de beveiliging, die in de 
laatste reeks van de sequentie worden verzameld).  
cardEventRecords  is een reeks voorvalrecords van een bepaald type 
voorval (of categorie voor voorvallen met betrekking tot pogingen tot 
inbreuk op de beveiliging).  
▼B 
2.20.  CardEventRecord  
Op een bestuurders- of werkplaatskaart opgeslagen informatie met be ­
trekking tot een aan de kaarthouder te wijten voorval (voorschriften 261, 
286, 318 en 341 van bijlage 1C).
  
eventType  is het soort voorval.  
eventBeginTime  is de datum en het tijdstip van het begin van het voor ­
val. 
eventEndTime  is de datum en het tijdstip van het einde van het voorval.  
eventVehicleRegistration  is het kentekennummer en de registrerende 
lidstaat van het voertuig waarin het voorval plaatsvond.  
2.21.  CardFaultData  
Op een bestuurders- of werkplaatskaart opgeslagen informatie met be ­
trekking tot aan de kaarthouder te wijten fouten (voorschriften 263, 288, 
318 en 341 van bijlage 1C).
  
CardFaultData  is een sequentie van een recordsverzameling van con ­
troleapparaatfouten gevolgd door een recordsverzameling van kaartfou ­
ten. 
cardFaultRecords  is een reeks foutenrecords van een bepaalde fouten ­
categorie (controleapparaat of kaart).  
2.22.  CardFaultRecord  
Op een bestuurders- of werkplaatskaart opgeslagen informatie met be ­
trekking tot een aan de kaarthouder te wijten fout (voorschriften 264, 
289, 318 en 341 van bijlage 1C).
  
faultType  is het soort fout.  ▼M1
 02016R0799 — NL — 26.02.2020 — 002.001 — 106  
faultBeginTime  is de datum en het tijdstip van het begin van de fout.  
faultEndTime  is de datum en het tijdstip van het einde van de fout.  
faultVehicleRegistration  is het kentekennummer en de registrerende 
lidstaat van het voertuig waarin de fout plaatsvond.  
2.23.  CardIccIdentification  
Op een kaart opgeslagen informatie met betrekking tot de identificatie 
van het geïntegreerde circuit (IC) van de kaart (voorschrift 248 van 
bijlage 1C).
  
clockStop  is de klokstopmodus zoals gedefinieerd in aanhangsel 2.  
cardExtendedSerialNumber  is het unieke serienummer van de IC-kaart 
zoals verder gespecificeerd door de gegevenssoort ExtendedSerialNum ­
ber. 
cardApprovalNumber  is het typegoedkeuringsnummer van de kaart.  
cardPersonaliserID  is de persoonlijke identificatie (ID) van de kaart 
gecodeerd als ManufacturerCode.  
embedderIcAssemblerId  geeft informatie over de embedder/IC-assem ­
bleur.  
icIdentifier  is het identificatiesymbool van het IC op de kaart en van de 
fabrikant van het IC zoals gedefinieerd in ISO/IEC 7816-6.  
2.24.  CardIdentification  
Op een kaart opgeslagen informatie met betrekking tot de identificatie 
van de kaart (voorschriften 255, 280, 310, 333, 359, 365, 371 en 377 
van bijlage 1C).
  
cardIssuingMemberState  is de code van de lidstaat die de kaart heeft 
afgegeven.  
cardNumber  is het nummer van de kaart.  
cardIssuingAuthorityName  is de naam van de autoriteit die de kaart 
heeft afgegeven.  
cardIssueDate  is de datum van afgifte van de kaart aan de huidige 
houder.  
cardValidityBegin  is de datum waarop de geldigheid van de kaart in ­
gaat. ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 107  
cardExpiryDate  is de datum waarop de geldigheid van de kaart afloopt.  
2.25.  CardMACertificate  
2e generatie:  
Certificaat van de openbare sleutel van de kaart voor wederzijdse au ­
thenticatie met een VU. De structuur van dat certificaat is gespecificeerd 
in aanhangsel 11.
  
2.26.  CardNumber  
Kaartnummer zoals gedefinieerd in definitie g.
  
driverIdentification  is de unieke identificatie van een bestuurder in een 
lidstaat.  
ownerIdentification  is de unieke identificatie van een bedrijf of een 
werkplaats of een controle-instantie in een lidstaat.  
cardConsecutiveIndex  is de opeenvolgende index van de kaart.  
cardReplacementIndex  is de vervangingsindex van de kaart.  
cardRenewalIndex  is de vernieuwingsindex van de kaart.  
De eerste keuzesequentie is geschikt voor het coderen van een bestuur ­
derskaartnummer, de tweede keuzesequentie is geschikt voor het coderen 
van werkplaats-, controle- en bedrijfskaartnummers.  
2.27.  CardPlaceDailyWorkPeriod  
Op een bestuurders- en werkplaatskaart opgeslagen informatie met be ­
trekking tot de plaatsen waar dagelijkse werkperioden beginnen en/of 
eindigen (voorschriften 272, 297, 325 en 348 van bijlage 1C).
  
placePointerNewestRecord  is de index van de laatst bijgewerkte plaats ­
records.  
Waardetoekenning : cijfer dat correspondeert met de teller van de 
plaatsrecord, beginnend met ‘0’ voor de eerste plaatsrecord in de struc ­
tuur. 
placeRecords  is de reeks records die de informatie met betrekking tot 
ingevoerde plaatsen bevat.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 108  
2.28.  CardPrivateKey  
1e generatie:  
De particuliere sleutel van een kaart.
  
2.29.  CardPublicKey  
De openbare sleutel van een kaart.
  
▼M1 
2.30.  CardRenewalIndex (Vernieuwingsindex van de kaart)  
Vernieuwingsindex van de kaart (definitie i).
  
Waardetoekenning : (zie hoofdstuk 7 van deze bijlage).  
„0” Eerste afgifte.  
Volgorde van verhoging: „0, …, 9, A, …, Z”  
▼B 
2.31.  CardReplacementIndex  
Vervangingsindex van de kaart (definitie j).
  
Waardetoekenning : (zie hoofdstuk VII van deze bijlage).  
‘0’ Originele kaart.  
Volgorde van verhoging: ‘0, …, 9, A, …, Z’  
2.32.  CardSignCertificate  
2e generatie:  
Certificaat van de openbare sleutel van de kaart voor ondertekening. De 
structuur van dat certificaat is gespecificeerd in aanhangsel 11.
  
2.33.  CardSlotNumber  
Code ter onderscheiding van de twee lezers van een VU.
  
Waardetoekenning : niet nader gespecificeerd.  
2.34.  CardSlotsStatus  
Code die de soort kaarten aangeeft die in de twee lezers van de VU zijn 
ingebracht.
  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 109  
Waardetoekenning  — Octet-uitgericht : ‘ccccdddd’B  
‘cccc’B Identificatie van de soort kaart die is ingebracht in de 
lezer van de bijrijder,  
‘dddd’B Identificatie van de soort kaart die is ingebracht in de 
lezer van de bestuurder,  
met de volgende identificatiecodes:  
‘0000’B er is geen kaart ingebracht,  
‘0001’B er is een bestuurderskaart ingebracht,  
‘0010’B er is een werkplaatskaart ingebracht,  
‘0011’B er is een controlekaart ingebracht,  
‘0100’B er is een bedrijfskaart ingebracht.  
2.35.  CardSlotsStatusRecordArray  
2e generatie:  
De CardSlotsStatus plus metagegevens zoals gebruikt in het download ­
protocol.
  
recordType  geeft de soort record aan (CardSlotsStatus).  Waardetoe ­
kenning : zie RecordType.  
recordSize  is de grootte van de CardSlotsStatus in bytes.  
noOfRecords  is het aantal records in de reeks records.  
records  is de reeks CardSlotsStatus-records.  
2.36.  CardStructureVersion  
Code die de versie aangeeft van de in een tachograafkaart geïmplemen ­
teerde structuur.
  
Waardetoekenning : ‘aabb’H:  
‘aa’H Index voor wijzigingen van de structuur.  
‘00’H voor toepassingen van de 1e generatie.  
‘01’H voor toepassingen van de 2e generatie.  
‘bb’H Index voor wijzigingen betreffende het gebruik van de 
voor de structuur gedefinieerde gegevenselementen, ge ­
geven door de high byte.  
‘00’H voor deze versie van toepassingen van de 1e 
generatie.  
‘00’H voor deze versie van toepassingen van de 2e 
generatie.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 110  
2.37.  CardVehicleRecord  
Op een bestuurders- of werkplaatskaart opgeslagen informatie met be ­
trekking tot de gebruiksperiode van een voertuig gedurende een kalen ­
derdag (voorschriften 269, 294, 322 en 345 van bijlage 1C).  
1e generatie:
  
vehicleOdometerBegin  is de kilometerstand van het voertuig aan het 
begin van de gebruiksperiode van het voertuig.  
vehicleOdometerEnd  is de kilometerstand van het voertuig aan het 
einde van de gebruiksperiode van het voertuig.  
vehicleFirstUse  is de datum en het tijdstip van het begin van de ge ­
bruiksperiode van het voertuig.  
vehicleLastUse  is de datum en het tijdstip van het einde van de ge ­
bruiksperiode van het voertuig.  
vehicleRegistration  is het kentekennummer en de registrerende lidstaat 
van het voertuig.  
vuDataBlockCounter  is de waarde van de VuDataBlockCounter bij de 
laatste selectie van de gebruiksperiode van het voertuig.  
2e generatie:
  
Als aanvulling op de 1e generatie wordt het volgende gegevenselement 
gebruikt:  
VehicleIdentificationNumber  is het identificatienummer van het voer ­
tuig dat naar het voertuig als geheel verwijst.  
2.38.  CardVehiclesUsed  
Op een bestuurders- of werkplaatskaart opgeslagen informatie met be ­
trekking tot de door de kaarthouder gebruikte voertuigen (voorschriften 
270, 295, 323 en 346 van bijlage 1C).
  
vehiclePointerNewestRecord  is de index van de laatst bijgewerkte 
voertuigrecords.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 111  
Waardetoekenning : cijfer dat correspondeert met de teller van de voer ­
tuigrecords, beginnend met ‘0’ voor de eerste voertuigrecords in de 
structuur.  
cardVehicleRecords  is de reeks records die informatie over gebruikte 
voertuigen bevat.  
2.39.  CardVehicleUnitRecord  
2e generatie:  
Op een bestuurders- of werkplaatskaart opgeslagen informatie met be ­
trekking tot een gebruikte voertuigunit (voorschriften 303 en 351 van 
bijlage 1C).
  
timeStamp  is het begin van de gebruiksperiode van de VU (d.w.z. de 
eerste invoering van de kaart in de VU voor die periode).  
manufacturerCode  identificeert de fabrikant van de VU.  
deviceID  identificeert de soort VU van een fabrikant. De waarde is 
fabrikantspecifiek.  
vuSoftwareVersion  is het nummer van de softwareversie van de VU.  
2.40.  CardVehicleUnitsUsed  
2e generatie:  
Op een bestuurders- of werkplaatskaart opgeslagen informatie met be ­
trekking tot de door de kaarthouder gebruikte voertuigunits (voorschrif ­
ten 306 en 352 van bijlage 1C).
  
vehiclePointerNewestRecord  is de index van de laatst bijgewerkte VU- 
record.  
Waardetoekenning : cijfer dat correspondeert met de teller van de VU- 
record, beginnend met ‘0’ voor de eerste VU-record in de structuur.  
cardVehicleRecords  is de reeks records die informatie over gebruikte 
VU's bevat.  
2.41.  Certificate  
Het certificaat van een openbare sleutel afgegeven door een certifice ­
ringsautoriteit.  
1e generatie:
  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 112  
Waardetoekenning : digitale handtekening met gedeeltelijk herstel van 
een CertificateContent overeenkomstig de algemene beveiligingsmecha ­
nismen in aanhangsel 11: handtekening (128 bytes) || restant openbare 
sleutel (58 bytes) || referentie certificeringsautoriteit (8 bytes).  
2e generatie:
  
Waardetoekenning: zie aanhangsel 11.  
2.42.  CertificateContent  
1e generatie:  
De (duidelijke) inhoud van het certificaat van een openbare sleutel over ­
eenkomstig de algemene beveiligingsmechanismen in aanhangsel 11.
  
certificateProfileIdentifier  is de versie van het corresponderende certi ­
ficaat.  
Waardetoekenning : ‘01h’ voor deze versie.  
certificationAuthorityReference  identificeert de certificeringsautoriteit 
die het certificaat afgeeft. Het verwijst ook naar de openbare sleutel 
van die certificeringsautoriteit.  
certificateHolderAuthorisation  identificeert de rechten van de certifi ­
caathouder.  
certificateEndOfValidity  is de datum waarop het certificaat administra ­
tief vervalt.  
certificateHolderReference  identificeert de certificaathouder. Het ver ­
wijst ook naar zijn openbare sleutel.  
publicKey  is de openbare sleutel die door dat certificaat gecertificeerd 
wordt.  
2.43.  CertificateHolderAuthorisation  
Identificatie van de rechten van een certificaathouder.
  
1e generatie:  
tachographApplicationID  is het toepassingsidentificatiesymbool voor 
de tachograaftoepassing.  
Waardetoekenning : ‘FFh’ ‘54h’ ‘41h’ ‘43h’ ‘48h’ ‘4Fh’. Dit AID is 
een particulier niet-geregistreerd toepassingsidentificatiesymbool over ­
eenkomstig ISO/IEC 7816-5.  
equipmentType  is de identificatie van het type apparaat waarvoor het 
certificaat bedoeld is.  
Waardetoekenning : overeenkomstig gegevenssoort EquipmentType.  0 
als het een certificaat van een lidstaat betreft.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 113  
2e generatie:  
tachographApplicationID  verwijst naar de zes significantste bytes van 
het toepassingsidentificatiesymbool (AID) van de tachograafkaart van de 
2e generatie. De AID voor de tachograafkaarttoepassing is gespecifi ­
ceerd in hoofdstuk 6.2.  
Waardetoekenning : ‘FF 53 4D 52 44 54’.  
equipmentType  is de identificatie van het type voor de 2e generatie 
gespecificeerde apparaat waarvoor het certificaat bedoeld is.  
Waardetoekenning : overeenkomstig gegevenssoort EquipmentType.  
2.44.  CertificateRequestID  
Unieke identificatie van een certificaatverzoek. Dit kan ook als een 
identificatiesymbool van de openbare sleutel van een VU worden ge ­
bruikt als het serienummer van de VU waarvoor de sleutel bedoeld is, 
ten tijde van de ontwikkeling van het certificaat niet bekend is.
  
requestSerialNumber  is een serienummer voor het certificaatverzoek, 
uniek voor de fabrikant en de hieronder genoemde maand.  
requestMonthYear  is de identificatie van de maand en het jaar van het 
certificaatverzoek.  
Waardetoekenning : BCD-codering van maand (twee cijfers) en jaar 
(twee laatste cijfers).  
crIdentifier : is een identificatiesymbool om een certificaatverzoek van 
een toegevoegd serienummer te kunnen onderscheiden.  
Waardetoekenning : ‘FFh’.  
manufacturerCode : is de numerieke code van de fabrikant die het 
certificaat aanvraagt.  
2.45.  CertificationAuthorityKID  
Identificatiesymbool van de openbare sleutel van een certificeringsauto ­
riteit (een lidstaat of de Europese certificeringsautoriteit).
  
nationNumeric  is de numerieke nationale code van de certificerings ­
autoriteit.  
nationAlpha  is de alfanumerieke nationale code van de certificerings ­
autoriteit.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 114  
keySerialNumber  is een serienummer om de verschillende sleutels van 
de certificeringsautoriteit te onderscheiden in het geval dat sleutels wor ­
den gewijzigd.  
additionalInfo  is een veld van twee bytes voor aanvullende codering 
(specifiek voor de certificeringsautoriteit).  
caIdentifier  is een identificatiesymbool om het sleutelidentificatiesym ­
bool van een certificeringsautoriteit van andere sleutelidentificatiesym ­
bolen te onderscheiden.  
Waardetoekenning : ‘01h’.  
2.46.  CompanyActivityData  
Op een bedrijfskaart opgeslagen informatie met betrekking tot activitei ­
ten die met de kaart worden uitgevoerd (voorschriften 373 en 379 van 
bijlage 1C).
  
companyPointerNewestRecord  is de index van het laatst bijgewerkte 
companyActivityRecord.  
Waardetoekenning : cijfer corresponderend met de teller van de records 
van bedrijfsactiviteiten, beginnend met ‘0’ voor de eerste record van 
bedrijfsactiviteiten in de structuur.  
companyActivityRecords  is de verzameling van alle records van be ­
drijfsactiviteiten.  
companyActivityRecord  is de sequentie van informatie met betrekking 
tot één bedrijfsactiviteit.  
companyActivityType  is de soort bedrijfsactiviteit.  
companyActivityTime  is de datum en het tijdstip van de bedrijfsactivi ­
teit. 
cardNumberInformation  is het kaartnummer en de lidstaat van afgifte 
van de gedownloade kaart, indien van toepassing.  
vehicleRegistrationInformation  is het kentekennummer en de registre ­
rende lidstaat van het gedownloade, vergrendelde of ontgrendelde voer ­
tuig. 
downloadPeriodBegin  en downloadPeriodEnd  is de vanaf de VU ge ­
downloade periode, indien van toepassing.  
2.47.  CompanyActivityType  
Code die een activiteit aangeeft die door een bedrijf met gebruikmaking 
van zijn bedrijfskaart is uitgevoerd.
  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 115  
2.48.  CompanyCardApplicationIdentification  
Op een bedrijfskaart opgeslagen informatie met betrekking tot de toe ­
passingsidentificatie van de kaart (voorschriften 369 en 375 van bijlage 
1C).
 
typeOfTachographCardId  specificeert de geïmplementeerde kaartsoort.  
cardStructureVersion  specificeert de versie van de op de kaart geïm ­
plementeerde structuur.  
noOfCompanyActivityRecords  specificeert het aantal bedrijfsactivitei ­
ten dat op de kaart kan worden opgeslagen.  
2.49.  CompanyCardHolderIdentification  
Op een bedrijfskaart opgeslagen informatie met betrekking tot de iden ­
tificatie van de kaarthouder (voorschriften 372 en 378 van bijlage 1C).
  
companyName  is de naam van het bedrijf van de houder.  
companyAddress  is het adres van het bedrijf van de houder.  
cardHolderPreferredLanguage  is de voorkeurtaal van de kaarthouder.  
2.50.  ControlCardApplicationIdentification  
Op een controlekaart opgeslagen informatie met betrekking tot de toe ­
passingsidentificatie van de kaart (voorschriften 357 en 363 van bijlage 
1C).
 
typeOfTachographCardId  specificeert de geïmplementeerde kaartsoort.  
cardStructureVersion  specificeert de versie van de structuur die op de 
kaart geïmplementeerd is.  
noOfControlActivityRecords  is het aantal records van controleactivitei ­
ten dat op de kaart kan worden opgeslagen.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 116  
2.51.  ControlCardControlActivityData  
Op een controlekaart opgeslagen informatie met betrekking tot contro ­
leactiviteiten die met de kaart worden uitgevoerd (voorschriften 361 en 
367 van bijlage 1C).
  
controlPointerNewestRecord  is de index van de laatst gewijzigde re ­
cord van controleactiviteiten.  
Waardetoekenning : cijfer corresponderend met de teller van de record 
van controleactiviteiten, beginnend met ‘0’ voor de eerste record van de 
controleactiviteiten die in de structuur voorkomt.  
controlActivityRecords  is de verzameling van alle records van contro ­
leactiviteiten.  
controlActivityRecord  is de sequentie van informatie met betrekking tot 
een controle.  
controlType  is de soort controle.  
controlTime  is de datum en het tijdstip van de controle.  
controlledCardNumber  is het kaartnummer en de lidstaat van afgifte 
van de gecontroleerde kaart.  
controlledVehicleRegistration  is het kentekennummer en de registre ­
rende lidstaat van het voertuig waarin de controle plaatsvond.  
controlDownloadPeriodBegin  en controlDownloadPeriodEnd  is de 
mogelijk gedownloade periode.  
2.52.  ControlCardHolderIdentification  
Op een controlekaart opgeslagen informatie met betrekking tot de iden ­
tificatie van de kaarthouder (voorschriften 360 en 366 van bijlage 1C).
  
controlBodyName  is de naam van de controle-instantie van de kaart ­
houder.  
controlBodyAddress  is het adres van de controle-instantie van de kaart ­
houder.  
cardHolderName  is de naam en voorna(a)m(en) van de houder van de 
controlekaart.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 117  
cardHolderPreferredLanguage  is de voorkeurtaal van de kaarthouder.  
2.53.  ControlType  
Code die de tijdens een controle uitgevoerde activiteiten aangeeft. Deze 
gegevenssoort is gerelateerd aan de voorschriften 126, 274, 299, 327 en 
350 van bijlage 1C.
  
1e generatie:  
Waardetoekenning  — Octet-uitgericht : ‘cvpdxxxx’B (8-bits)  
‘c’B kaartdownload:  
‘0’B: kaart niet gedownload tijdens deze controleactivi ­
teit, 
‘1’B: kaart gedownload tijdens deze controleactiviteit  
‘v’B VU-download:  
‘0’B: VU niet gedownload tijdens deze controleactivi ­
teit, 
‘1’B: voertuig gedownload tijdens deze controleactivi ­
teit 
‘p’B afdrukken:  
‘0’B: geen afdrukken gemaakt tijdens deze controleac ­
tiviteit,  
‘1’B: afdrukken gemaakt tijdens deze controleactiviteit  
‘d’B display:  
‘0’B: geen display gebruikt tijdens deze controleactivi ­
teit, 
‘1’B: display gebruikt tijdens deze controleactiviteit  
‘xxxx’B Niet gebruikt.  
2e generatie:  
Waardetoekenning  — Octet-uitgericht : ‘cvpdexxx’B (8-bits)  
‘c’B kaartdownload:  
‘0’B: kaart niet gedownload tijdens deze controleactivi ­
teit, 
‘1’B: kaart gedownload tijdens deze controleactiviteit  
‘v’B VU-download:  
‘0’B: VU niet gedownload tijdens deze controleactivi ­
teit, 
‘1’B: VU gedownload tijdens deze controleactiviteit  
‘p’B afdrukken:  
‘0’B: geen afdrukken gemaakt tijdens deze controleac ­
tiviteit,  
‘1’B: afdrukken gemaakt tijdens deze controleactiviteit  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 118  
‘d’B display:  
‘0’B: geen display gebruikt tijdens deze controleactivi ­
teit, 
‘1’B: display gebruikt tijdens deze controleactiviteit  
‘e’B kalibratiecontrole langs de weg:  
‘0’B: kalibratieparameters niet gecontroleerd tijdens 
deze controleactiviteit,  
‘1’B: kalibratieparameters gecontroleerd tijdens deze 
controleactiviteit,  
‘xxx’B RFU.  
2.54.  CurrentDateTime  
De huidige datum en het tijd van het controleapparaat.
  
Waardetoekenning : niet nader gespecificeerd.  
2.55.  CurrentDateTimeRecordArray  
2e generatie:  
De huidige datum en tijd plus metagegevens zoals gebruikt in het 
downloadprotocol.
  
recordType  geeft de soort record aan (CurrentDateTime).  Waardetoe ­
kenning : zie RecordType.  
recordSize  is de grootte van CurrentDateTime in bytes.  
noOfRecords  is het aantal records in de reeks records.  
records  is een reeks records van de huidige datum en tijd.  
2.56.  DailyPresenceCounter  
Op een bestuurders- of werkplaatskaart opgeslagen teller die met één 
wordt verhoogd voor elke kalenderdag waarop de kaart in een VU is 
ingebracht. Deze gegevenssoort is gerelateerd aan de voorschriften 266, 
299, 320 en 343 van bijlage 1C.
  
Waardetoekenning : opeenvolgend getal met een maximale waarde = 9 
999, waarna het opnieuw met 0 begint. Bij de eerste afgifte van de kaart 
wordt het getal op 0 gezet.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 119  
2.57.  Datef  
Datum weergegeven in een gemakkelijk af te drukken numerieke vorm.
  
Waardetoekenning:  
yyyy jaar  
mm maand  
dd dag  
‘00000000’H geeft expliciet geen datum aan.  
2.58.  DateOfDayDownloaded  
2e generatie:  
De datum en het tijdstip van de download.
  
Waardetoekenning : niet nader gespecificeerd.  
2.59.  DateOfDayDownloadedRecordArray  
2e generatie:  
De datum en tijd van de download plus metagegevens zoals gebruikt in 
het downloadprotocol.
  
recordType  geeft de soort record aan (DateOfDayDownloaded).  Waar­
detoekenning : zie RecordType.  
recordSize  is de grootte van CurrentDateTime in bytes.  
noOfRecords  is het aantal records in de reeks records.  
records  is de verzameling van datums en tijden van de download ­
records.  
2.60.  Distance  
Een afgelegde afstand (resultaat van de berekening van het verschil 
tussen twee kilometerstanden van het voertuig in kilometers).
  
Waardetoekenning : niet-getekend binair getal. Waarde in km in het 
operationele bereik van 0 tot 9 999 km.  
2.61.  DriverCardApplicationIdentification  
Op een bestuurderskaart opgeslagen informatie met betrekking tot de 
toepassingsidentificatie van de kaart (voorschriften 253 en 278 van bij ­
lage 1C).  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 120  
1e generatie:
  
typeOfTachographCardId  specificeert de geïmplementeerde kaartsoort.  
cardStructureVersion  specificeert de versie van de op de kaart geïm ­
plementeerde structuur.  
noOfEventsPerType  is het aantal voorvallen per soort voorval dat de 
kaart kan registreren.  
noOfFaultsPerType  is het aantal fouten per soort fout dat de kaart kan 
registreren.  
activityStructureLength  geeft het aantal beschikbare bytes aan voor het 
opslaan van records van activiteiten.  
noOfCardVehicleRecords  is het aantal voertuigrecords dat de kaart kan 
bevatten.  
noOfCardPlaceRecords  is het aantal plaatsen dat de kaart kan regis ­
treren.  
2e generatie:  
▼M1
 
Als aanvulling op de 1e generatie worden de volgende gegevenselemen ­
ten gebruikt:  
noOfGNSSCDRecords  is het aantal GNSS-records van de cumulatieve 
rijtijd dat op de kaart kan worden opgeslagen.  
noOfSpecificConditionRecords  is het aantal records van specifieke om ­
standigheden dat op de kaart kan worden opgeslagen.  
noOfCardVehicleUnitRecords  is het aantal voertuigrecords dat op de 
kaart kan worden opgeslagen.  
▼B 
2.62.  DriverCardHolderIdentification  
Op een bestuurderskaart opgeslagen informatie met betrekking tot de 
identificatie van de kaarthouder (voorschriften 256 en 281 van bijlage 
1C).
 
cardHolderName  is de naam en voorna(a)m(en) van de houder van de 
bestuurderskaart.  
cardHolderBirthDate  is de geboortedatum van de houder van de be ­
stuurderskaart.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 121  
cardHolderPreferredLanguage  is de voorkeurtaal van de kaarthouder.  
▼M1 
2.63.  Gereserveerd voor toekomstig gebruik  
▼B 
2.64.  EGFCertificate  
2e generatie:  
Certificaat van de openbare sleutel van de externe GNSS-module voor 
wederzijdse authenticatie met een VU. De structuur van dat certificaat is 
gespecificeerd in aanhangsel 11.
  
2.65.  EmbedderIcAssemblerId  
Geeft informatie over de IC-embedder.
  
countryCode  is de tweeletterige landcode van de embedder van de 
module, overeenkomstig ISO 3166.  
moduleEmbedder  identificeert de embedder van de module.  
manufacturerInformation  voor intern gebruik door de fabrikant.  
2.66.  EntryTypeDailyWorkPeriod  
Code die een onderscheid maakt tussen begin en einde van invoer van 
een plaats van de dagelijkse werkperiode en voorwaarde van de invoer.  
1e generatie
  
Waardetoekenning : overeenkomstig ISO/IEC8824-1.  
2e generatie
  
Waardetoekenning : overeenkomstig ISO/IEC8824-1.  
2.67.  EquipmentType  
Code die de verschillende soorten apparatuur voor de tachograaftoepas ­
sing onderscheidt.
  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 122  
1e generatie:
  
Waardetoekenning : overeenkomstig ISO/IEC8824-1.  
Waarde 0 is gereserveerd voor vermelding van een lidstaat of Europa in 
het CHA-veld van certififaten.  
2e generatie:  
▼M1 
Er wordt gebruik gemaakt van dezelfde waarden als in de 1e generatie, 
met de volgende aanvullingen:
  
Opmerking 1:  de waarden van de 2e generatie voor het installatieplaat ­
je, de adapter en de externe GNSS-verbinding en de waarden van de 1e 
generatie voor de VU en de bewegingssensor kunnen, indien van toe ­
passing, in SealRecord worden gebruikt.  
Opmerking 2:  in het veld CardHolderAuthorisation (CHA) van een cer ­
tificaat van de 2e generatie wijzen de waarden (1), (2) en (6) op een 
certificaat van wederzijdse authenticatie voor het desbetreffende type 
apparatuur. Om het respectieve certificaat voor het opstellen van een 
digitale handtekening aan te geven, moeten de waarden (17), (18) of 
(19) worden gebruikt.  
▼B 
2.68.  EuropeanPublicKey  
1e generatie:  
De Europese openbare sleutel.
  
2.69.  EventFaultRecordPurpose  
Code die aangeeft waarom een voorval of een fout geregistreerd werd.
  
Waardetoekenning:  ▼B
02016R0799 — NL — 26.02.2020 — 002.001 — 123 
een van de 10 meest recente (of laatste) voorvallen of fouten 
het langste voorval gedurende een van de laatste 10 dagen waarin het is opgetreden 
een van de 5 langste voorvallen gedurende de afgelopen 365 dagen 
het laatste voorval gedurende een van de laatste 10 dagen waarin het is opgetreden 
het ernstigste voorval gedurende een van de laatste 10 dagen waarin het is opgetreden 
een van de 5 ernstigste voorvallen gedurende de afgelopen 365 dagen 
eerste na de laatste kalibrering opgetreden voorval of fout 
een actief(actieve)/aan de gang zijnd(e) voorval of fout 
RFU 
specifiek voor de fabrikant  
2.70. EventFaultType 
Code die een voorval of een fout aanduidt.
  
Waardetoekenning:  
1e generatie:
  
Algemene voorvallen, 
Geen verdere details, 
Inbrengen van een ongeldige kaart, 
Kaartconflict, 
Tijdsoverlapping, 
Rijden zonder geschikte kaart, 
Inbrengen van de kaart tijdens het rijden, 
Laatste kaartsessie niet correct afgesloten, 
Snelheidsoverschrijding, 
Onderbreking in de stroomvoorziening, 
Fout in de bewegingsgegevens, 
Tegenstrijdige bewegingsgegevens, 
RFU,
  
Poging tot inbreuk op de beveiliging van de voertuigunit, 
Geen verdere details, 
Authenticatiefout van de bewegingssensor, 
Authenticatiefout van de tachograafkaart, 
Niet-geautoriseerde wijziging van de bewegingssensor, 
Integriteitsfout in de gegevensinvoer op de kaart, 
Integriteitsfout in de opgeslagen gebruikersgegevens, 
Overdrachtsfout in de interne gegevens, 
Niet-geautoriseerde opening van de unit, 
Hardwaresabotage, 
RFU,
  
Poging tot inbreuk op de beveiliging van de sensor, 
Geen verdere details, 
Authenticatiefout, 
Integriteitsfout in de opgeslagen gegevens, 
Overdrachtsfout in de interne gegevens, 
Niet-geautoriseerde opening van het omhulsel, 
Hardwaresabotage, 
RFU,
  
Fouten van het controleapparaat, 
Geen verdere details, 
Interne fout in de VU 
Printerfout, 
Displayfout, 
Downloadfout, 
Sensorfout, 
RFU,  ▼B
02016R0799 — NL — 26.02.2020 — 002.001 — 124 
Kaartfouten, 
Geen verdere details, 
RFU,
  
RFU,
  
Specifiek voor de fabrikant.  
▼M1
2e generatie:
  
Algemene voorvallen, 
Geen verdere details, 
Inbrengen van een ongeldige kaart, 
Kaartconflict, 
Tijdsoverlapping, 
Rijden zonder geschikte kaart, 
Inbrengen van de kaart tijdens het rijden, 
Laatste kaartsessie niet correct afgesloten, 
Snelheidsoverschrijding, 
Onderbreking in de stroomvoorziening, 
Fout in de bewegingsgegevens, 
Tegenstrijdige bewegingsgegevens, 
Tijdsconflict (tussen GNSS en de interne klok van de VU), 
Fout in de communicatie met het systeem voor communicatie op afstand, 
Ontbreken van plaatsbepalingsinformatie van de GNSS-ontvanger, 
Fout in de communicatie met de externe GNSS-module, 
RFU,
  
Poging tot inbreuk op de beveiliging van de voertuigunit, 
Geen verdere details, 
Authenticatiefout van de bewegingssensor, 
Authenticatiefout van de tachograafkaart, 
Niet-geautoriseerde wijziging van de bewegingssensor, 
Integriteitsfout in de gegevensinvoer op de kaart, 
Integriteitsfout in de opgeslagen gebruikersgegevens, 
Overdrachtsfout in de interne gegevens, 
Niet-geautoriseerde opening van het omhulsel, 
Hardwaresabotage, 
GNSS is gemanipuleerd, 
Authenticatiefout van de externe GNSS-module, 
Certificaat van de externe GNSS-module is vervallen, 
RFU,
  
Poging tot inbreuk op de beveiliging van de sensor, 
Geen verdere details, 
Authenticatiefout, 
Integriteitsfout in de opgeslagen gegevens, 
Overdrachtsfout in de interne gegevens, 
Niet-geautoriseerde opening van het omhulsel, 
Hardwaresabotage, 
RFU,  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 125
  
Fouten van het controleapparaat, 
Geen verdere details, 
Interne fout in de VU, 
Printerfout, 
Displayfout, 
Downloadfout, 
Sensorfout, 
Interne GNSS-ontvanger, 
Externe GNSS-module, 
Systeem voor communicatie op afstand, 
ITS-interface, 
RFU,
  
Kaartfouten, 
Geen verdere details, 
RFU,
  
RFU,
  
Specifiek voor de fabrikant.  
2.71.  ExtendedSealIdentifier  
2e generatie:  
De verlengde zegelidentificatiecode identificeert een zegel op unieke 
wijze (voorschrift 401 van bijlage IC).
  
manufacturerCode  is een code van de zegelfabrikant.  
sealIdentifier  is een zegelidentificatienummer dat uniek is voor de fa ­
brikant.  
▼B 
2.72.  ExtendedSerialNumber  
Unieke identificatie van een apparaat. Dit kan ook als een identificatie ­
symbool van de openbare sleutel van het apparaat worden gebruikt.  
1e generatie:
  
serialNumber  is een serienummer voor het apparaat, uniek voor de 
fabrikant, het soort apparaat en onderstaande maand en jaar.  
monthYear  is de identificatie van de maand en het jaar van fabricage 
(of van toekenning van het serienummer).  ▼M1
 02016R0799 — NL — 26.02.2020 — 002.001 — 126  
Waardetoekenning : BCD-codering van maand (twee cijfers) en jaar 
(twee laatste cijfers).  
type is een identificatiesymbool voor het soort apparaat.  
Waardetoekenning : specifiek voor de fabrikant, met gereserveerde 
waarde ‘FFh’.  
manufacturerCode : de numerieke code aan de hand waarvan een fa ­
brikant van een apparaat met typegoedkeuring wordt geïdentificeerd.  
2e generatie:
  
serialNumber  zie 1e generatie  
monthYear  zie 1e generatie  
type geeft het soort apparaat aan  
manufacturerCode : zie 1e generatie.  
2.73.  FullCardNumber  
Code die een tachograafkaart volledig identificeert.
  
cardType  is de soort tachograafkaart.  
cardIssuingMemberState  is de code van de lidstaat die de kaart heeft 
afgegeven.  
cardNumber  is het kaartnummer.  
2.74.  FullCardNumberAndGeneration  
2e generatie:  
Code die een tachograafkaart en haar generatie volledig identificeert.
  
fullcardNumber  identificeert de tachograafkaart.  
generation  geeft de generatie van de gebruikte tachograafkaart aan.  
2.75.  Generation  
2e generatie:  
Geeft de generatie van de gebruikte tachograafkaart aan.
  
Waardetoekenning:  
‘00’H RFU  
‘01’H 1e generatie  
‘02’H 2e generatie  
‘03’H .. ‘FF’H RFU  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 127  
2.76.  GeoCoordinates  
2e generatie:  
De geografische coördinaten zijn gecodeerd als gehele getallen. Die 
gehele getallen zijn veelvouden van de ± DDMM.M-codering voor de 
breedte en ± DDDMM.M-codering voor de lengte. In dit geval worden 
met ± DD en ± DDD de graden en met MM.M de minuten aangeduid.
  
latitude  is gecodeerd als een veelvoud (factor 10) van de ± DDMM.M- 
weergave.  
longitude  is gecodeerd als een veelvoud (factor 10) van de ± 
DDDMM.M-weergave.  
2.77.  GNSSAccuracy  
2e generatie:  
De nauwkeurigheid van de GNSS-positiegegevens (definitie eee). De 
nauwkeurigheid is gecodeerd als een geheel getal en is een veelvoud 
(factor 10) van de X.Y-waarde in de GSA NMEA-zin.
  
▼M1 
2.78.  GNSSAccumulatedDriving  
2e generatie:  
Op een bestuurders- of werkplaatskaart opgeslagen informatie met be ­
trekking tot de GNSS-positie van het voertuig als de cumulatieve rijtijd 
een veelvoud van drie uur bereikt (voorschriften 306 en 354 van bijlage 
IC).
 
gnssADPointerNewestRecord  is de index van de laatst gewijzigde 
GNSS-record van cumulatieve rijtijd.  
Waardetoekenning  is het cijfer dat correspondeert met de teller van de 
GNSS-record van cumulatieve rijtijd, beginnend met „0” voor de eerste 
GNSS-record van cumulatieve rijtijd in de structuur.  
gnssAccumulatedDrivingRecords  is de reeks records die de datum en 
tijd bevat waarop de cumulatieve rijtijd een veelvoud van drie uur 
bereikt en informatie over de positie van het voertuig.  
2.79.  GNSSAccumulatedDrivingRecord  
2e generatie:  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 128  
Op een bestuurders- of werkplaatskaart opgeslagen informatie met be ­
trekking tot de GNSS-positie van het voertuig als de cumulatieve rijtijd 
een veelvoud van drie uur bereikt (voorschriften 305 en 353 van bijlage 
IC).
 
timeStamp  is de datum en het tijdstip waarop de cumulatieve rijtijd een 
veelvoud van drie uur bereikt;  
gnssPlaceRecord  bevat informatie over de positie van het voertuig.  
vehicleOdometerValue  is de kilometerstand op het ogenblik dat de 
cumulatieve rijtijd een veelvoud van drie uur bereikt.  
▼B 
2.80.  GNSSPlaceRecord  
2e generatie:  
Informatie met betrekking tot de GNSS-positie van het voertuig (voor ­
schriften 108, 109, 110, 296, 305, 347 en 353 van bijlage 1C).
  
timeStamp  is de datum en tijd waarop de GNSS-positie van het voer ­
tuig werd bepaald.  
gnssAccuracy  is de nauwkeurigheid van de GNSS-positiegegevens.  
geoCoordinates  is de met gebruik van GNSS geregistreerde plaats.  
2.81.  HighResOdometer  
Kilometerstand van het voertuig: totale door het voertuig afgelegde af ­
stand tijdens de gebruiksperiode.
  
Waardetoekenning : niet-getekend binair getal. Waarde in 1/200 km in 
het operationele bereik van 0 tot 21 055 406 km.  
2.82.  HighResTripDistance  
Een afgelegde afstand tijdens de gehele reis of een gedeelte daarvan.
  
Waardetoekenning : niet-getekend binair getal. Waarde in 1/200 km in 
het operationele bereik van 0 tot 21 055 406 km.  
2.83.  HolderName  
Naam en voorna(a)men van een kaarthouder.
  
holderSurname  is de achternaam (familienaam) van de houder. Deze 
achternaam bevat geen titels.  
Waardetoekenning : Wanneer een kaart niet persoonlijk is, bevat de 
holderSurname dezelfde informatie als companyName of workshop ­
Name of controlBodyName.  ▼M1
 02016R0799 — NL — 26.02.2020 — 002.001 — 129  
holderFirstNames  omvat de voornaam (voornamen) en initialen van de 
houder.  
2.84.  InternalGNSSReceiver  
2e generatie:  
Geeft aan of de voertuigunit over een interne of externe GNSS-ontvan ­
ger beschikt. ”True” betekent dat de VU een interne GNSS-ontvanger 
heeft. ”False” betekent dat het om een externe GNSS-ontvanger gaat.
  
2.85.  K-ConstantOfRecordingEquipment  
Constante van het controleapparaat (definitie m).
  
Waardetoekenning : pulsen per kilometer in het operationele bereik van 
0 tot 64 255 pulsen/km.  
▼M1 
2.86.  KeyIdentifier  
Een uniek identificatiesymbool van een openbare sleutel dat wordt ge ­
bruikt ter verwijzing naar of selectie van de sleutel. Het identificeert 
tevens de houder van de sleutel.
  
Met de eerste keuze wordt verwezen naar de openbare sleutel van een 
voertuigunit, een tachograafkaart of een externe GNSS-module.  
Met de tweede keuze wordt verwezen naar de openbare sleutel van een 
voertuigunit (wanneer het serienummer van de voertuigunit op het mo ­
ment van ontwikkeling van het certificaat nog niet bekend is).  
Met de derde keuze wordt verwezen naar de openbare sleutel van een 
lidstaat.  
▼B 
2.87.  KMWCKey  
2e generatie:  
AES-sleutel en de geassocieerde sleutelversie die wordt gebruikt om de 
VU te verbinden met de bewegingssensor. Zie voor details aanhang ­
sel 11.
  
kMWCKey  is de lengte van de AES-sleutel aaneengeschakeld met de 
sleutel die wordt gebruikt om de VU te verbinden met de bewegings ­
sensor.  
keyVersion  duidt de sleutelversie van de AES-sleutel aan.  
2.88.  Language  
Code die een taal identificeert.
  
Waardetoekenning : een code van twee onderkastletters overeenkomstig 
ISO 639.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 130  
2.89.  LastCardDownload  
Op een bestuurderskaart opgeslagen datum en tijd van het downloaden 
van de laatste kaart (voor andere doeleinden dan controle) (voorschriften 
257 en 282 van bijlage 1C). Deze datum kan worden aangepast door een 
VU of een kaartlezer.
  
Waardetoekenning : niet nader gespecificeerd.  
2.90.  LinkCertificate  
2e generatie:  
Het verbindingscertificaat tussen European Root CA-sleutelparen.
  
2.91.  L-TyreCircumference  
Effectieve omtrek van de wielbanden (definitie u).
  
Waardetoekenning : niet-getekend binair getal, waarde in 1/8 mm in het 
operationele bereik van 0 tot 8 031 mm.  
▼M1 
2.92.  MAC  
2e generatie:  
Een cryptografische controlesom met een lengte van 8, 12 of 16 bytes 
die overeenkomt met het in aanhangsel 11 gespecificeerde cijfer
  
▼B 
2.93.  ManualInputFlag  
Code die aangeeft of een kaarthouder manueel activiteiten van de be ­
stuurder bij kaartinbrenging heeft ingevoerd of niet (voorschrift 081 van 
bijlage 1B en voorschrift 102 van bijlage 1C).
  
Waardetoekenning : niet nader gespecificeerd.  
2.94.  ManufacturerCode  
Code die een fabrikant van apparatuur met typegoedkeuring identificeert.
  
Het voor interoperabiliteitstests bevoegde laboratorium onderhoudt de 
lijst met fabrikantcodes en publiceert die lijst op zijn website (voorschrift 
454 van bijlage 1C).  
ManufacturerCodes worden tijdelijk toegewezen aan ontwikkelaars van 
apparatuur voor tachografen, op aanvraag bij het laboratorium dat be ­
voegd is voor interoperabiliteitstests.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 131  
2.95.  ManufacturerSpecificEventFaultData  
2e generatie:  
Foutcodes die specifiek voor een fabrikant zijn, vereenvoudigen de fou ­
tenanalyse en het onderhoud van voertuigunits.
  
manufacturerCode  identificeert de fabrikant van de VU.  
manufacturerSpecificErrorCode  is een foutcode specifiek voor de fa ­
brikant.  
2.96.  MemberStateCertificate  
Het door de Europese certificeringsautoriteit afgegeven certificaat van de 
openbare sleutel van een lidstaat.
  
2.97.  MemberStateCertificateRecordArray  
2e generatie:  
Het lidstaatcertificaat plus metagegevens zoals gebruikt in het download ­
protocol.
  
recordType  geeft de soort record aan (MemberStateCertificate).  Waar­
detoekenning : zie RecordType.  
recordSize  is de grootte van MemberStateCertificate in bytes.  
noOfRecords  is het aantal records in de reeks records. De waarde wordt 
op 1 gezet, omdat certificaten een verschillende lengte kunnen hebben.  
records  is de reeks lidstaatcertificaten.  
2.98.  MemberStatePublicKey  
1e generatie:  
De openbare sleutel van een lidstaat.
  
2.99.  Name  
Een naam.
  
codePage  specificeert een tekenset zoals gedefinieerd in hoofdstuk 4,  
name  is een naam die is gecodeerd met de gespecificeerde tekenset.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 132  
2.100.  NationAlpha  
Alfabetische verwijzing naar een land in overeenstemming met de ken ­
tekens op voertuigen in internationaal verkeer (Verdrag van Wenen 
inzake wegverkeer, 1968, van de Verenigde Naties).
  
De codes NationAlpha en NationNumeric worden bijgehouden op een 
lijst die wordt onderhouden op de website van het laboratorium dat 
belast is met het uitvoeren van de interoperabiliteitstests, zoals vast ­
gesteld in voorschrift 440 van bijlage 1C.  
2.101.  NationNumeric  
Numerieke referentie naar een land.
  
Waardetoekenning : zie gegevenssoort 2.100 (NationAlpha)  
De hierboven beschreven specificatie van NationAlpha of NationNume ­
ric wordt pas gewijzigd of bijgewerkt nadat het aangewezen laborato ­
rium de fabrikanten van typegoedgekeurde voertuigunits van digitale en 
slimme tachografen heeft geraadpleegd.  
2.102.  NoOfCalibrationRecords  
Aantal kalibreringsrecords dat op een werkplaatskaart kan worden opge ­
slagen.  
1e generatie:
  
Waardetoekenning : zie aanhangsel 2.  
2e generatie:
  
Waardetoekenning : zie aanhangsel 2.  
2.103.  NoOfCalibrationsSinceDownload  
Teller die het aantal met een werkplaatskaart uitgevoerde kalibreringen 
sinds de laatste download aangeeft (voorschriften 317 en 340 van bijlage 
1C).
 
Waardetoekenning : niet nader gespecificeerd.  
2.104.  NoOfCardPlaceRecords  
Aantal plaatsrecords dat op een bestuurders- of werkplaatskaart kan 
worden opgeslagen.  
1e generatie:
  
Waardetoekenning : zie aanhangsel 2.  
2e generatie:
  
Waardetoekenning : zie aanhangsel 2.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 133  
2.105.  NoOfCardVehicleRecords  
Aantal records van gebruikte voertuigen dat op een bestuurders- of 
werkplaatskaart kan worden opgeslagen.
  
Waardetoekenning : zie aanhangsel 2.  
2.106.  NoOfCardVehicleUnitRecords  
2e generatie:  
Aantal records van gebruikte voertuigunits dat op een bestuurders- of 
werkplaatskaart kan worden opgeslagen.
  
Waardetoekenning : zie aanhangsel 2.  
2.107.  NoOfCompanyActivityRecords  
Aantal records van bedrijfsactiviteiten dat op een bedrijfskaart kan wor ­
den opgeslagen.
  
Waardetoekenning : zie aanhangsel 2.  
2.108.  NoOfControlActivityRecords  
Aantal records van controleactiviteiten dat op een controlekaart kan 
worden opgeslagen.
  
Waardetoekenning : zie aanhangsel 2.  
2.109.  NoOfEventsPerType  
Aantal voorvallen per soort voorval dat op een kaart kan worden opge ­
slagen.
  
Waardetoekenning : zie aanhangsel 2.  
2.110.  NoOfFaultsPerType  
Aantal fouten per soort fout dat opeen kaart kan worden opgeslagen.
  
Waardetoekenning : see Appendix 2.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 134  
2.111.  NoOfGNSSADRecords  
2e generatie:  
Aantal GNSS-records van cumulatieve rijtijd dat op een kaart kan wor ­
den opgeslagen.
  
Waardetoekenning:  zie aanhangsel 2.  
▼B 
2.112.  NoOfSpecificConditionRecords  
2e generatie:  
Aantal records van specifieke omstandigheden dat op een kaart kan 
worden opgeslagen.
  
Waardetoekenning : zie aanhangsel 2.  
2.113.  OdometerShort  
Kilometerstand van het voertuig in een verkorte vorm.
  
Waardetoekenning : niet-getekend binair getal. Waarde in km in het 
operationele bereik van 0 tot 9 999 999 km.  
2.114.  OdometerValueMidnight  
De kilometerstand van het voertuig om 0.00 uur op een bepaalde dag 
(voorschrift 090 van bijlage 1B en voorschrift 113 van bijlage 1C).
  
Waardetoekenning : niet nader gespecificeerd.  
2.115.  OdometerValueMidnightRecordArray  
2e generatie:  
De OdometerValueMidnight plus metagegevens zoals gebruikt in het 
downloadprotocol.
  
recordType  geeft de soort record aan (OdometerValueMidnight).  
Waardetoekenning : zie RecordType.  
recordSize  is de grootte van OdometerValueMidnight in bytes.  
noOfRecords  is het aantal records in de reeks records.  
records  is de reeks OdometerValueMidnight-records.  ▼M1
 02016R0799 — NL — 26.02.2020 — 002.001 — 135  
2.116.  OverspeedNumber  
Aantal snelheidsoverschrijdingen sinds de laatste controle van snelheids ­
overschrijdingen.
  
Waardetoekenning : 0 betekent dat er sinds de laatste controle van 
snelheidsoverschrijdingen geen snelheidsoverschrijding heeft plaats ­
gevonden; 1 betekent dat er sinds de laatste controle van snelheidsover ­
schrijdingen een snelheidsoverschrijding heeft plaatsgevonden; … 255 
betekent 255 of meer snelheidsoverschrijdingen sinds de laatste controle 
van snelheidsoverschrijdingen.  
2.117.  PlaceRecord  
Informatie met betrekking tot een plaats waar een dagelijkse werkperi ­
ode begint of eindigt (voorschriften 108, 271, 296, 324 en 347 van 
bijlage 1C).  
1e generatie:
  
entryTime  is een datum en tijdstip met betrekking tot de invoer.  
entryTypeDailyWorkPeriod  is de soort invoer.  
dailyWorkPeriodCountry  is het ingevoerde land.  
dailyWorkPeriodRegion  is de ingevoerde regio.  
vehicleOdometerValue  is de kilometerstand op het moment van invoer 
van de plaats.  
2e generatie:
  
Als aanvulling op de 1e generatie wordt de volgende component ge ­
bruikt:  
entryGNSSPlaceRecord  is de geregistreerde plaats en tijd.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 136  
2.118.  PreviousVehicleInfo  
Informatie met betrekking tot het vorige door een bestuurder gebruikte 
voertuig wanneer hij zijn kaart in een voertuigunit inbrengt (voorschrift 
081 van bijlage 1B en voorschrift 102 van bijlage 1C).  
1e generatie:
  
vehicleRegistrationIdentification  is het kentekennummer en de regis ­
trerende lidstaat van het voertuig.  
cardWithdrawalTime  is de datum en het tijdstip van kaartuitneming.  
2e generatie:
  
Als aanvulling op de 1e generatie wordt het volgende gegevenselement 
gebruikt:  
vuGeneration  identificeert de generatie van de VU.  
2.119.  PublicKey  
1e generatie:  
Een openbare RSA-sleutel.
  
rsaKeyModulus  is de modulus van het sleutelpaar.  
rsaKeyPublicExponent  is de openbare exponent van het sleutelpaar.  
2.120.  RecordType  
2e generatie:  
Verwijzing naar een soort record. Deze gegevenssoort wordt gebruikt in 
RecordArrays.
  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 137  
Waardetoekenning:
  
► (1) M1 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, 
RFU, 
Specifiek voor de fabrikant.  
2.121.  RegionAlpha  
Alfabetische verwijzing naar een regio in een gespecificeerd land.
  
1e generatie:  
Waardetoekenning:
  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 138  
2e generatie:  
De RegionAlpha-codes worden bijgehouden op een lijst die wordt on ­
derhouden op de website van het laboratorium dat belast is met het 
uitvoeren van de interoperabiliteitstests.  
2.122.  RegionNumeric  
Numerieke verwijzing naar een regio in een gespecificeerd land.
  
1e generatie:  
Waardetoekenning:
  
2e generatie:  
De RegionNumeric-codes worden bijgehouden op een lijst die wordt 
onderhouden op de website van het laboratorium dat belast is met het 
uitvoeren van de interoperabiliteitstests.  
2.123.  RemoteCommunicationModuleSerialNumber  
2e generatie:  
Serienummer van de module voor communicatie op afstand.
  
2.124.  RSAKeyModulus  
1e generatie:  
De modulus van een RSA-sleutelpaar.
  
Waardetoekenning : niet gespecificeerd.  
2.125.  RSAKeyPrivateExponent  
1e generatie:  
De particuliere exponent van een RSA-sleutelpaar.
  
Waardetoekenning : niet gespecificeerd.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 139  
2.126.  RSAKeyPublicExponent  
1e generatie:  
De openbare exponent van een RSA-sleutelpaar.
  
Waardetoekenning : niet gespecificeerd.  
2.127.  RtmData  
2e generatie:  
Zie aanhangsel 14 voor de definitie van deze gegevenssoort.  
2.128.  SealDataCard  
2e generatie:  
Deze gegevenssoort slaat informatie op over de zegels die aan de ver ­
schillende onderdelen van een voertuig zijn gehecht en dient te worden 
opgeslagen op een kaart. Deze gegevenssoort is gerelateerd aan voor ­
schrift 337 van bijlage 1C.
  
noOfSealRecords  is het aantal records in sealRecords.  
sealRecords  is een reeks zegelrecords.  
2.129.  SealDataVu  
2e generatie:  
Deze gegevenssoort slaat informatie op over de zegels die aan de ver ­
schillende onderdelen van een voertuig zijn gehecht en dient te worden 
opgeslagen in een voertuigunit.
  
sealRecords  is een reeks zegelrecords. Als er minder dan vijf zegels 
zijn, wordt de waarde van EquipmentType in alle ongebruikte seal ­
Records op 16 gezet, d.w.z. ongebruikt.  
2.130.  SealRecord  
2e generatie:  
Deze gegevenssoort slaat informatie op over een zegel dat aan een 
onderdeel is gehecht. Deze gegevenssoort is gerelateerd aan voorschrift 
337 van bijlage 1C.
  
equipmentType  identificeert het soort apparaat waaraan het zegel is 
gehecht.  
extendedSealIdentifier  is het identificatiesymbool van het zegel dat aan 
het apparaat is gehecht.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 140  
2.131.  SensorApprovalNumber  
Typegoedkeuringsnummer van de sensor.  
1e generatie:
  
Waardetoekenning : niet gespecificeerd.  
2e generatie:
  
Waardetoekenning:  
Het goedkeuringsnummer wordt verstrekt zoals het is bekendgemaakt op 
de overeenkomstige website van de Europese Commissie, bijv. met 
eventuele koppeltekens. Het goedkeuringsnummer wordt links uitgelijnd.  
2.132.  SensorExternalGNSSApprovalNumber  
2e generatie:  
Typegoedkeuringsnummer van de externe GNSS-module.
  
Waardetoekenning:  
Het goedkeuringsnummer wordt verstrekt zoals het is bekendgemaakt op 
de overeenkomstige website van de Europese Commissie, bijv. met 
eventuele koppeltekens. Het goedkeuringsnummer wordt links uitgelijnd.  
2.133.  SensorExternalGNSSCoupledRecord  
2e generatie:  
In een voertuigunit opgeslagen informatie met betrekking tot de identi ­
ficatie van de met de voertuigunit verbonden externe GNSS-module 
(voorschrift 100 van bijlage 1C).
  
sensorSerialNumber  is het serienummer van de met de voertuigunit 
verbonden externe GNSS-module.  
sensorApprovalNumber  is het goedkeuringsnummer van deze externe 
GNSS-module.  
sensorCouplingDate  is de datum waarop deze externe GNSS-module 
met de voertuigunit is verbonden.  
2.134.  SensorExternalGNSSIdentification  
2e generatie:  
Informatie met betrekking tot de identificatie van de externe GNSS- 
module (voorschrift 98 van bijlage 1C).  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 141
  
sensorSerialNumber  is het verlengde serienummer van de externe 
GNSS-module.  
sensorApprovalNumber  is het goedkeuringsnummer van de externe 
GNSS-module.  
sensorSCIdentifier  is het identificatiesymbool van de beveiligingscom ­
ponent van de externe GNSS-module.  
sensorOSIdentifier  is het identificatiesymbool van het besturingssys ­
teem van de externe GNSS-module.  
2.135.  SensorExternalGNSSInstallation  
2e generatie:  
In de externe GNSS-module opgeslagen informatie met betrekking tot de 
installatie van de externe GNSS-sensor (voorschrift 123 van bijlage 1C).
  
sensorCouplingDateFirst  is de datum van de eerste verbinding van de 
externe GNSS-module met een voertuigunit.  
firstVuApprovalNumber  is het goedkeuringsnummer van de eerste 
voertuigunit die met de externe GNSS-module verbonden wordt.  
firstVuSerialNumber  is het serienummer van de eerste voertuigunit die 
met de externe GNSS-module verbonden wordt.  
sensorCouplingDateCurrent  is de datum van de huidige verbinding 
van de externe GNSS-module met een voertuigunit.  
currentVuApprovalNumber  is het goedkeuringsnummer van de voer ­
tuigunit die op dat moment met de externe GNSS-module verbonden is.  
currentVuSerialNumber  is het serienummer van de voertuigunit die op 
dat moment met de externe GNSS-module verbonden is.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 142  
2.136.  SensorExternalGNSSOSIdentifier  
2e generatie:  
Identificatiesymbool van het besturingssysteem van de externe GNSS- 
module.
  
Waardetoekenning : specifiek voor de fabrikant.  
2.137.  SensorExternalGNSSSCIdentifier  
2e generatie:  
Deze soort wordt gebruikt om bijv. de cryptografische module van de 
externe GNSS-module te identificeren.  
Identificatiesymbool van de beveiligingscomponent van de externe 
GNSS-module.
  
Waardetoekenning : specifiek voor de fabrikant van het onderdeel.  
2.138.  SensorGNSSCouplingDate  
2e generatie:  
Datum van een verbinding van de externe GNSS-module met een voer ­
tuigunit.
  
Waardetoekenning : niet gespecificeerd.  
2.139.  SensorGNSSSerialNumber  
2e generatie:  
Deze soort wordt gebruikt om het serienummer van de GNSS-ontvanger 
op te slaan, zowel binnen als buiten de VU.  
Serienummer van de GNSS-ontvanger.
  
2.140.  SensorIdentification  
In een bewegingssensor opgeslagen informatie met betrekking tot de 
identificatie van de bewegingssensor (voorschrift 077 van bijlage 1B 
en voorschrift 95 van bijlage 1C).
  
sensorSerialNumber  is het verlengde serienummer van de bewegings ­
sensor (inclusief onderdeelnummer en code van de fabrikant).  
sensorApprovalNumber  is het goedkeuringsnummer van de be ­
wegingssensor.  
sensorSCIdentifier  is het identificatiesymbool van de beveiligingscom ­
ponent van de bewegingssensor.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 143  
sensorOSIdentifier  is het identificatiesymbool van het besturingssys ­
teem van de bewegingssensor.  
2.141.  SensorInstallation  
In een bewegingssensor opgeslagen informatie met betrekking tot de 
installatie van de bewegingssensor (voorschrift 099 van bijlage 1B en 
voorschrift 122 van bijlage 1C).
  
sensorPairingDateFirst  is de datum van de eerste verbinding van de 
bewegingssensor met een voertuigunit.  
firstVuApprovalNumber  is het goedkeuringsnummer van de eerste 
voertuigunit die met de bewegingssensor verbonden wordt.  
firstVuSerialNumber  is het serienummer van de eerste met de be ­
wegingssensor verbonden voertuigunit.  
sensorPairingDateCurrent  is de datum van de huidige verbinding van 
de bewegingssensor met de voertuigunit.  
currentVuApprovalNumber  is het goedkeuringsnummer van de op dat 
moment met de bewegingssensor verbonden voertuigunit.  
currentVUSerialNumber  is het serienummer van de op dat moment 
met de bewegingssensor verbonden voertuigunit.  
2.142.  SensorInstallationSecData  
Op een werkplaatskaart opgeslagen informatie met betrekking tot de 
benodigde beveiligingsgegevens bij verbinding van een bewegingssensor 
met een voertuigunit (voorschriften 308 en 331 van bijlage 1C).  
1e generatie:
  
Waardetoekenning : overeenkomstig ISO 16844-3.  
2e generatie:  
Zoals beschreven in aanhangsel 11 worden op een werkplaatskaart maxi ­
maal drie sleutels voor de verbinding van de VU met de bewegings ­
sensor opgeslagen. Die sleutels hebben verschillende sleutelversies.
  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 144  
2.143.  SensorOSIdentifier  
Identificatiesymbool van het besturingssysteem van de bewegingssensor.
  
Waardetoekenning : specifiek voor de fabrikant.  
2.144.  SensorPaired  
1e generatie:  
In een voertuigunit opgeslagen informatie met betrekking tot de identi ­
ficatie van de met de voertuigunit verbonden bewegingssensor (voor ­
schrift 079 van bijlage 1B).
  
sensorSerialNumber  is het serienummer van de op dat moment met de 
voertuigunit verbonden bewegingssensor.  
sensorApprovalNumber  is het goedkeuringsnummer van de op dat 
moment met de voertuigunit verbonden bewegingssensor.  
sensorPairingDateFirst  is de datum van de eerste verbinding met een 
voertuigunit van de op dat moment met de voertuigunit verbonden be ­
wegingssensor.  
2.145.  SensorPairedRecord  
2e generatie:  
In een voertuigunit opgeslagen informatie met betrekking tot de identi ­
ficatie van de met de voertuigunit verbonden bewegingssensor (voor ­
schrift 97 van bijlage 1C).
  
sensorSerialNumber  is het serienummer van een met de voertuigunit 
verbonden bewegingssensor.  
sensorApprovalNumber  is het goedkeuringsnummer van die be ­
wegingssensor.  
sensorPairingDate  is een datum waarop die externe bewegingssensor 
met de voertuigunit is verbonden.  
2.146.  SensorPairingDate  
Datum van een verbinding van de bewegingssensor met een voertuig ­
unit.
 
Waardetoekenning : niet gespecificeerd.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 145  
2.147.  SensorSCIdentifier  
Identificatiesymbool van de beveiligingscomponent van de bewegings ­
sensor.
  
Waardetoekenning : specifiek voor de fabrikant van de component.  
2.148.  SensorSerialNumber  
Serienummer van de bewegingssensor.
  
2.149.  Handtekening  
Een digitale handtekening.  
1e generatie:
  
Waardetoekenning : overeenkomstig de algemene beveiligingsmecha ­
nismen in aanhangsel 11.  
2e generatie:
  
Waardetoekenning : overeenkomstig de algemene beveiligingsmecha ­
nismen in aanhangsel 11.  
2.150.  SignatureRecordArray  
2e generatie:  
Een reeks handtekeningen plus metagegevens zoals gebruikt in het 
downloadprotocol.
  
recordType  geeft de soort record aan (Signature).  Waardetoekenning : 
zie RecordType.  
recordSize  is de grootte van Signature in bytes.  
noOfRecords  is het aantal records in de reeks records. De waarde wordt 
op 1 gezet, omdat de handtekeningen een verschillende lengte kunnen 
hebben.  
records  is de reeks handtekeningen.  
2.151.  SimilarEventsNumber  
Het aantal soortgelijke voorvallen op een bepaalde dag (voorschrift 094 
van bijlage 1B en voorschrift 117 van bijlage 1C).
  
Waardetoekenning : 0 is niet-gebruikt; 1 betekent dat er op die dag 
maar een voorval van die soort heeft plaatsgevonden en opgeslagen is; 
2 betekent dat 2 voorvallen van die soort op die dag hebben plaats ­
gevonden (een ervan is opgeslagen), … 255 betekent dat 255 of meer 
voorvallen van die soort hebben plaatsgevonden op die dag.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 146  
2.152.  SpecificConditionRecord  
Op een bestuurderskaart, een werkplaatskaart of in een voertuigunit 
opgeslagen informatie met betrekking tot een specifieke omstandigheid 
(voorschriften 130, 276, 301, 328 en 355 van bijlage 1C).
  
entryTime  is de datum en het tijdstip van de invoer.  
specificConditionType  is de code die de specifieke omstandigheid iden ­
tificeert.  
2.153.  SpecificConditions  
Op een bestuurderskaart, een werkplaatskaart of in een voertuigunit 
opgeslagen informatie met betrekking tot een specifieke omstandigheid 
(voorschriften 131, 277, 302, 329 en 356 van bijlage 1C).  
2e generatie:
  
contditionPointerNewestRecord  is de index van de laatst gewijzigde 
record van een specifieke omstandigheid.  
Waardetoekenning : cijfer dat correspondeert met de teller van de re ­
cord van specifieke omstandigheden, beginnend met ‘0’ voor de eerste 
record van specifieke omstandigheden in de structuur.  
specificConditionRecords  is de reeks records die informatie over de 
geregistreerde specifieke omstandigheden bevat.  
2.154.  SpecificConditionType  
Code die een specifieke omstandigheid identificeert (voorschriften 050b, 
105a, 212a en 230a van bijlage 1B en voorschrift 62 van bijlage 1C).
  
1e generatie:  
Waardetoekenning:  
‘00’H RFU  
‘01’H niet verplicht — Begin  
‘02’H niet verplicht — Einde  
‘03’H Vervoer per veerboot/trein  
‘04’H .. ‘FF’H RFU  
2e generatie:  
Waardetoekenning:  
‘00’H RFU  
‘01’H niet verplich — Begin  
‘02’H niet verplicht — Einde  
‘03’H Vervoer per veerboot/trein — Begin  
‘04’H Vervoer per veerboot/trein — Einde  
‘05’H .. ‘FF’H RFU  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 147  
2.155.  Speed  
Snelheid van het voertuig (km/u).
  
Waardetoekenning : kilometer per uur in het operationele bereik van 0 
tot 220 km/u.  
2.156.  SpeedAuthorised  
Toegestane maximumsnelheid van het voertuig (definitie hh).
  
2.157.  SpeedAverage  
Gemiddelde snelheid tijdens een vooraf gedefinieerde periode (km/u).
  
2.158.  SpeedMax  
Maximumsnelheid gemeten tijdens een vooraf gedefinieerde periode.
  
2.159.  TachographPayload  
2e generatie:  
Zie aanhangsel 14 voor de definitie van deze datasoort.  
▼M1 
2.160.  Gereserveerd voor toekomstig gebruik  
▼B 
2.161.  TDesSessionKey  
1e generatie:  
Een triple DES-sessiesleutel.
  
Waardetoekenning : niet nader gespecificeerd.  
▼M1 
2.162.  TimeReal  
Code voor een gecombineerd veld voor datum en tijd, waarin de datum 
en het tijdstip worden uitgedrukt in seconden na 00u.00m.00s. op 1 ja ­
nuari 1970 UTC.
  
Waardetoekenning  – Octet-uitgericht : aantal seconden sinds midder ­
nacht 1 januari 1970 UTC.  
De laatst mogelijke datum/tijd is in het jaar 2106.  
▼B 
2.163.  TyreSize  
Aanduiding van de afmetingen van de banden.
  
Waardetoekenning : overeenkomstig Richtlijn 92/23/EEG van 31 maart 
1992 (PB L 129 van 14.5.1992, blz. 95).  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 148  
2.164.  VehicleIdentificationNumber  
Identificatienummer van het voertuig (VIN) dat verwijst naar het voer ­
tuig als geheel, in de regel het chassisnummer.
  
Waardetoekenning : zoals gedefinieerd in ISO 3779.  
2.165.  VehicleIdentificationNumberRecordArray  
2e generatie:  
Het identificatienummer van het voertuig plus metagegevens zoals ge ­
bruikt in het downloadprotocol.
  
recordType  geeft de soort record aan (VehicleIdentificationNumber).  
Waardetoekenning : zie RecordType.  
recordSize  is de grootte van VehicleIdentificationNumber in bytes.  
noOfRecords  is het aantal records in de reeks records.  
records  is de reeks identificatienummers van voertuigen.  
2.166.  VehicleRegistrationIdentification  
Identificatie van een voertuig, uniek voor Europa (kentekennummer en 
lidstaat).
  
vehicleRegistrationNation  is het land waar het voertuig geregistreerd is.  
vehicleRegistrationNumber  is het kentekennummer van het voertuig 
(VRN).  
2.167.  VehicleRegistrationNumber  
Kentekennummer van het voertuig (VRN). Het kentekennummer wordt 
toegewezen door de vergunningverlenende autoriteit.
  
codePage  specificeert een tekenset zoals gedefinieerd in hoofdstuk 4,  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 149  
vehicleRegNumber  is een VRN die is gecodeerd met de gespecificeerde 
tekenset.  
Waardetoekenning : specifiek voor een land.  
2.168.  VehicleRegistrationNumberRecordArray  
2e generatie:  
Het kentekennummer van het voertuig plus metagegevens zoals gebruikt 
in het downloadprotocol.
  
recordType  geeft de soort record aan (VehicleRegistrationNumber).  
Waardetoekenning : zie RecordType.  
recordSize  is de grootte van VehicleregistrationNumber in bytes.  
noOfRecords  is het aantal records in de reeks records.  
records  is de reeks kentekennummers van voertuigen.  
2.169.  VuAbility  
2e generatie:  
In een voertuigunit opgeslagen informatie over de mogelijkheid om in 
de VU al dan niet tachograafkaarten van de eerste generatie te gebruiken 
(voorschrift 121 van bijlage 1C).
  
Waardetoekenning  — Octet-uitgericht : ‘xxxxxxxa’B (8-bits)  
Mogelijkheid om 1e generatie te ondersteunen:  
‘a’B Mogelijkheid om tachograafkaarten van de 1e genera ­
tie te ondersteunen:  
‘0’B 1e generatie ondersteund  
‘1’B 1e generatie niet ondersteund  
‘xxxxxxx’B RFU  
2.170.  VuActivityDailyData  
1e generatie:  
In een VU opgeslagen informatie met betrekking tot wijzigingen in de 
activiteiten en/of wijzigingen in de rijstatus en/of wijzigingen in de 
kaartstatus voor een bepaalde kalenderdag (voorschrift 084 van bijlage 
1B en voorschriften 105, 106 en 107 van bijlage 1C) en in de status van 
lezers op 00:00 die dag.
  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 150  
noOfActivityChanges  is het aantal ActivityChangeInfo-woorden in de 
reeks activityChangeInfos.  
activityChangeInfos  is de reeks ActivityChangeInfo-woorden die in de 
VU is opgeslagen die dag. Het bevat altijd twee ActivityChangeInfo- 
woorden waarin de status van de twee lezers wordt gegeven op 00:00 
die dag.  
2.171.  VuActivityDailyRecordArray  
2e generatie:  
In een VU opgeslagen informatie met betrekking tot wijzigingen in de 
activiteiten en/of wijzigingen in de rijstatus en/of wijzigingen in de 
kaartstatus voor een bepaalde kalenderdag (voorschriften 105, 106 en 
107 van bijlage 1C) en in de status van lezers op 00:00 die dag.
  
recordType  geeft de soort record aan (ActivityChangeInfo).  Waarde ­
toekenning : zie RecordType.  
recordSize  is de grootte van ActivityChangeInfo in bytes.  
noOfRecords  is het aantal records in de reeks records.  
records  is de reeks ActivityChangeInfo-woorden die in de VU is opge ­
slagen die dag. Het bevat altijd twee ActivityChangeInfo-woorden 
waarin de status van de twee lezers wordt gegeven op 00:00 die dag.  
2.172.  VuApprovalNumber  
Typegoedkeuringsnummer van de voertuigunit.  
1e generatie:
  
Waardetoekenning : niet gespecificeerd.  
2e generatie:
  
Waardetoekenning:  
Het goedkeuringsnummer wordt verstrekt zoals het is bekendgemaakt op 
de overeenkomstige website van de Europese Commissie, bijv. met 
eventuele koppeltekens. Het goedkeuringsnummer wordt links uitgelijnd.  
2.173.  VuCalibrationData  
1e generatie:  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 151  
In een voertuigunit opgeslagen informatie met betrekking tot de kalibre ­
ringen van het controleapparaat (voorschrift 098 van bijlage 1B).
  
noOfVuCalibrationRecords  is het aantal records in de vuCalibration ­
Records-reeks.  
vuCalibrationRecords  is de reeks kalibreringsrecords.  
2.174.  VuCalibrationRecord  
In een voertuigunit opgeslagen informatie met betrekking tot de kalibre ­
ring van het controleapparaat (voorschrift 098 van bijlage 1B en voor ­
schriften 119 en 120 van bijlage 1C).  
1e generatie:
  
calibrationPurpose  is het doel van de kalibrering.  
workshopName, workshopAddress  zijn de naam en het adres van de 
werkplaats.  
workshopCardNumber  identificeert de werkplaatskaart die tijdens de 
kalibrering wordt gebruikt.  
workshopCardExpiryDate  is de vervaldatum van de kaart.  
vehicleIdentificationNumber  is het VIN.  
vehicleRegistrationIdentification  bevat het kentekennummer en de re ­
gisterende lidstaat.  
wVehicleCharacteristicConstant  is de kenmerkende coëfficiënt van het 
voertuig.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 152  
kConstantOfRecordingEquipment  is de constante van het controleap ­
paraat.  
lTyreCircumference  is de effectieve omtrek van de wielbanden.  
tyreSize  is de aanduiding van de afmeting van de banden waarmee het 
voertuig uitgerust is.  
authorisedSpeed  is de toegestane snelheid van het voertuig.  
oldOdometerValue , newOdometerValue  zijn de oude en nieuwe kilo ­
meterstanden.  
oldTimeValue, newTimeValue  zijn de oude en nieuwe waarden van 
datum en tijd.  
nextCalibrationDate  is de datum van de volgende in CalibrationPur ­
pose gespecificeerde soort kalibrering die door de bevoegde controleau ­
toriteit moet worden uitgevoerd.  
2e generatie:
  
Als aanvulling op de 1e generatie wordt het volgende gegevenselement 
gebruikt:  
sealDataVu  geeft informatie over de zegels die aan de verschillende 
onderdelen van het voertuig zijn gehecht.  
2.175.  VuCalibrationRecordArray  
2e generatie:  
In een voertuigunit opgeslagen informatie met betrekking tot de kalibre ­
ringen van het controleapparaat (voorschrift 119 en 120 van bijlage 1C).  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 153
  
recordType  geeft de soort record aan (VuCalibrationRecord).  Waarde ­
toekenning : zie RecordType.  
recordSize  is de grootte van VuCalibrationRecord in bytes.  
noOfRecords  is het aantal records in de reeks records.  
records  is de reeks kalibreringsrecords.  
2.176.  VuCardIWData  
1e generatie:  
In een voertuigunit opgeslagen informatie met betrekking tot cycli van 
inbrengen in en uitnemen uit een voertuigunit van bestuurders- of werk ­
plaatskaarten (voorschrift 081 van bijlage 1B en voorschrift 103 van 
bijlage 1C).
  
noOfIWRecords  is het aantal records in de reeks vuCardIWRecords.  
vuCardIWRecords  is een reeks records met betrekking tot cycli van 
inbrengen en uitnemen van een kaart.  
2.177.  VuCardIWRecord  
In een voertuigunit opgeslagen informatie met betrekking tot cycli van 
inbrengen in en uitnemen uit een voertuigunit van bestuurders- of werk ­
plaatskaarten (voorschrift 081 van bijlage 1B en voorschrift 102 van 
bijlage 1C).  
1e generatie:
  
cardHolderName  is de op de kaart opgeslagen naam en voornaam 
(voornamen) van de houder van de bestuurders- of werkplaatskaart.  
fullCardNumber  is de op de kaart opgeslagen soort kaart, de lidstaat 
van afgifte en het kaartnummer.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 154  
cardExpiryDate  is de op de kaart opgeslagen vervaldatum van de kaart.  
cardInsertionTime  is de datum en het tijdstip van inbrenging.  
vehicleOdometerValueAtInsertion  is de kilometerstand van het voer ­
tuig bij kaartinbrenging.  
cardSlotNumber  is de lezer waarin de kaart is ingebracht.  
cardWithdrawalTime  is de datum en het tijdstip van uitneming.  
vehicleOdometerValueAtWithdrawal  is de kilometerstand van het 
voertuig bij kaartuitneming.  
previousVehicleInfo  bevat de op de kaart opgeslagen informatie over 
het vorige door de bestuurder gebruikte voertuig.  
manualInputFlag  is een teken dat identificeert of de kaarthouder bij de 
kaartinbrenging manueel activiteiten van de bestuurder heeft ingevoerd.  
2e generatie:
  
In de gegevensstructuur van de 2e generatie is fullCardNumber vervan ­
gen door het volgende gegevenselement:  
fullCardNumberAndGeneration  is de op de kaart opgeslagen soort 
kaart, de lidstaat van afgifte, het kaartnummer en de generatie.  
2.178.  VuCardIWRecordArray  
2e generatie:  
In een voertuigunit opgeslagen informatie met betrekking tot cycli van 
inbrengen in en uitnemen uit een voertuigunit van bestuurders- of werk ­
plaatskaarten (voorschrift 103 van bijage 1C).
  
recordType  geeft de soort record aan (VuCardIWRecord).  Waardetoe ­
kenning : zie RecordType.  
recordSize  is de grootte van VuCardIWRecord in bytes.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 155  
noOfRecords  is het aantal records in de reeks records.  
records  is een reeks records met betrekking tot cycli van inbrengen en 
uitnemen van een kaart.  
▼M1 
2.179.  VuCardRecord  
2e generatie:  
In een voertuigunit opgeslagen informatie over een gebruikte tachograaf ­
kaart (voorschrift 132 van bijlage IC).
  
cardNumberAndGenerationInformation  is het volledige kaartnummer 
en de generatie van de gebruikte kaart (data type 2.74).  
cardExtendedSerialNumber  zoals afgelezen uit het bestand EF_ICC 
onder het stambestand van de kaart.  
cardStructureVersion  zoals afgelezen uit het bestand EF_Applicati ­
on_Identification onder DF Tachograaf_G2.  
cardNumber  zoals afgelezen uit het bestand EF_Identification onder 
DF_Tachograaf_G2.  
▼B 
2.180.  VuCardRecordArray  
2e generatie:  
In een voertuigunit opgeslagen informatie over de in die VU gebruikte 
tachograafkaarten. Deze informatie is bedoeld voor de analyse van VU- 
of kaartproblemen (voorschrift 132 van bijlage 1C).
  
recordType  geeft de soort record aan (VuCardRecord).  Waardetoeken ­
ning : zie RecordType.  
recordSize  is de grootte van VuCardRecord in bytes.  
noOfRecords  is het aantal records in de reeks records.  
records  is een reeks records met betrekking tot de in de VU gebruikte 
tachograafkaarten.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 156  
2.181.  VuCertificate  
Certificaat van de openbare sleutel van een voertuigunit.
  
2.182.  VuCertificateRecordArray  
2e generatie:  
Het VU-certificaat plus metagegevens zoals gebruikt in het download ­
protocol.
  
recordType  geeft de soort record aan (VuCertificate).  Waardetoeken ­
ning : zie RecordType.  
recordSize  is de grootte van VuCertificate in bytes.  
noOfRecords  is het aantal records in de reeks records. De waarde wordt 
op 1 gezet, omdat certificaten een verschillende lengte kunnen hebben.  
records  is een reeks VU-certificaten.  
2.183.  VuCompanyLocksData  
1e generatie:  
In een voertuigunit opgeslagen informatie met betrekking tot bedrijfs ­
vergrendelingen (voorschrift 104 van bijlage 1B).
  
noOfLocks  is het aantal in vuCompanyLocksRecords opgenomen ver ­
grendelingen.  
vuCompanyLocksRecords  is de reeks records van bedrijfsvergrendelin ­
gen. 
2.184.  VuCompanyLocksRecord  
In een voertuigunit opgeslagen informatie met betrekking tot een be ­
drijfsvergrendeling (voorschrift 104 van bijlage 1B en voorschrift 128 
van bijlage 1C).  
1e generatie:
  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 157  
lockInTime, lockOutTime  zijn de datum en het tijdstip van vergrende ­
ling en ontgrendeling.  
companyName, companyAddress  zijn de naam en het adres van het 
vergrendelende bedrijf.  
companyCardNumber  identificeert de kaart die bij de vergrendeling 
wordt gebruikt.  
2e generatie:
  
In de gegevensstructuur van de 2e generatie is companyCardNumber 
vervangen door het volgende gegevenselement:  
companyCardNumberAndGeneration  identificeert de kaart, inclusief 
de generatie, die bij de vergrendeling wordt gebruikt.  
2.185.  VuCompanyLocksRecordArray  
2e generatie:  
In een voertuigunit opgeslagen informatie met betrekking tot bedrijfs ­
vergrendelingen (voorschrift 128 van bijlage 1C.
  
recordType  geeft de soort record aan (VuCompanyLocksRecord).  
Waardetoekenning : zie RecordType.  
recordSize  is de grootte van VuCompanyLocksRecord in bytes.  
noOfRecords  is het aantal records in de reeks registraties. Waarde 
0..255.  
records  is de reeks records van bedrijfsvergrendelingen.  
2.186.  VuControlActivityData  
1e generatie:  
In een voertuigunit opgeslagen informatie met betrekking tot controles 
die met deze VU worden uitgevoerd (voorschrift 102 van bijlage 1B).
  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 158  
noOfControls  is het aantal in vuControlActivityRecords opgenomen 
controles.  
vuControlActivityRecords  is de reeks records van controleactiviteiten.  
2.187.  VuControlActivityRecord  
In een voertuigunit opgeslagen informatie met betrekking tot een con ­
trole die met deze VU wordt uitgevoerd (voorschrift 102 van bijlage 1B 
en voorschrift 126 van bijlage 1C).  
1e generatie:
  
controlType  is de soort controle.  
controlTime  is de datum en het tijdstip van de controle.  
ControlCardNumber  identificeert de bij de controle gebruikte contro ­
lekaart.  
downloadPeriodBeginTime  is de begintijd van de gedownloade perio ­
de, in geval van download.  
downloadPeriodEndTime  is de eindtijd van de gedownloade periode, 
in geval van download.  
2e generatie:
  
In de gegevensstructuur van de 2e generatie is controlCardNumber ver ­
vangen door het volgende gegevenselement:  
ControlCardNumberAndGeneration  identificeert de bij de controle 
gebruikte controlekaart, inclusief de generatie.  
2.188.  VuControlActivityRecordArray  
2e generatie:  
In een voertuigunit opgeslagen informatie met betrekking tot controles 
die met deze VU worden uitgevoerd (voorschrift 126 van bijlage 1C).  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 159
  
recordType  geeft de soort record aan (VuControlActivityRecord).  
Waardetoekenning : zie RecordType.  
recordSize  is de grootte van VuControlActivityRecord in bytes.  
noOfRecords  is het aantal records in de reeks records.  
records  is de reeks records van VU-controleactiviteiten.  
2.189.  VuDataBlockCounter  
Op een kaart opgeslagen teller die de cycli van kaartinbrenging in en 
kaartuitneming uit voertuigunits opeenvolgend identificeert.
  
Waardetoekenning : opeenvolgend cijfer met een maximale waarde van 
9 999, waarna het opnieuw met 0 begint.  
2.190.  VuDetailedSpeedBlock  
In een voertuigunit opgeslagen informatie met betrekking tot de gedetail ­
leerde snelheid van het voertuig gedurende een minuut waarin het voer ­
tuig rijdt (voorschrift 093 van bijlage 1B en voorschrift 116 van bijlage 
1C).
 
speedBlockBeginDate  is de datum en het tijdstip van de eerste snel ­
heidswaarde in het blok.  
speedsPerSecond  is de chronologische sequentie van gemeten snelhe ­
den gedurende elke seconde van de minuut die begint met speedBlock ­
BeginDate (inclusief).  
2.191.  VuDetailedSpeedBlockRecordArray  
2e generatie:  
In een voertuigunit opgeslagen informatie met betrekking tot de gedetail ­
leerde snelheid van het voertuig.
  
recordType  geeft de soort record aan (VuDetailedSpeedBlock).  Waar­
detoekenning : zie RecordType.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 160  
recordSize  is de grootte van VuDetailedSpeedBlock in bytes.  
noOfRecords  is het aantal records in de reeks records.  
records  is de reeks gedetailleerde snelheidsblokken.  
2.192.  VuDetailedSpeedData  
1e generatie:  
In een voertuigunit opgeslagen informatie met betrekking tot de gedetail ­
leerde snelheid van het voertuig.
  
noOfSpeedBlocks  is het aantal snelheidsblokken in de vuDetailed ­
SpeedBlocks-reeks.  
vuDetailedSpeedBlocks  is de reeks gedetailleerde snelheidsblokken.  
2.193.  VuDownloadablePeriod  
De eerste en laatste datum waarvan een voertuigunit gegevens met be ­
trekking tot activiteiten van de bestuurder bewaart (voorschriften 081, 
084 of 087 van bijlage 1B en voorschriften 102, 105 en 108 van bijlage 
1C).
 
minDownloadableTime  is de datum en het tijdstip van de eerste in de 
VU opgeslagen kaartinbrenging, van de wijziging van activiteiten of van 
de invoer van de plaats.  
maxDownloadableTime  is de datum en het tijdstip van de laatste in de 
VU opgeslagen kaartuitneming, van de wijziging van activiteiten of van 
invoer van de plaats.  
2.194.  VuDownloadablePeriodRecordArray  
2e generatie:  
De VUDownloadablePeriod plus metagegevens zoals gebruikt in het 
downloadprotocol.
  
recordType  geeft de soort record aan (VuDownloadablePeriod).  Waar­
detoekenning : zie RecordType.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 161  
recordSize  is de grootte van VuDownloadablePeriod in bytes.  
noOfRecords  is het aantal records in de reeks records.  
records  is de reeks VuDownloadablePeriod-records.  
2.195.  VuDownloadActivityData  
In een voertuigunit opgeslagen informatie met betrekking tot de laatste 
download (voorschrift 105 van bijlage 1B en voorschrift 129 van bijlage 
1C). 
1e generatie:
  
downloadingTime  is de datum en het tijdstip van downloaden.  
fullCardNumber  identificeert de kaart die wordt gebruikt om de 
download te autoriseren.  
companyOrWorkshopName  is de naam van het bedrijf of de werk ­
plaats.  
2e generatie:
  
In de gegevensstructuur van de 2e generatie is fullCardNumber vervan ­
gen door het volgende gegevenselement:  
fullCardNumberAndGeneration  identificeert de kaart die wordt ge ­
bruikt om de download te autoriseren.  
2.196.  VuDownloadActivityDataRecordArray  
2e generatie:  
Informatie met betrekking tot de laatste VU-download (voorschrift 129 
van bijlage 1C).
  
recordType  geeft de soort record aan (VuDownloadActivityData).  
Waardetoekenning : zie RecordType.  
recordSize  is de grootte van VuDownloadActivityData in bytes.  
noOfRecords  is het aantal records in de reeks records.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 162  
records  is de reeks records van downloadactiviteitgegevens.  
2.197.  VuEventData  
1e generatie:  
In een voertuigunit opgeslagen informatie met betrekking tot voorvallen 
(voorschrift 094 van bijlage 1B, met uitzondering van snelheidsover ­
schrijding).
  
noOfVuEvents  is het aantal in de vuEventRecords-reeks opgenomen 
voorvallen.  
vuEventRecords  is een reeks voorvallenrecords.  
2.198.  VuEventRecord  
In een voertuigunit opgeslagen informatie met betrekking tot een voorval 
(voorschrift 094 van bijlage 1B en voorschrift 117 van bijlage 1C, met 
uitzondering van snelheidsoverschrijding).  
1e generatie:
  
eventType  is het soort voorval.  
eventRecordPurpose  is het doel waarvoor dit voorval geregistreerd 
werd.  
eventBeginTime  is de datum en het tijdstip van het begin van het 
voorval.  
eventEndTime  is de datum en het tijdstip van het einde van het voorval.  
cardNumberDriverSlotBegin  identificeert de aan het begin van het 
voorval in de lezer van de bestuurder ingebrachte kaart.  
cardNumberCodriverSlotBegin  identificeert de aan het begin van het 
voorval in de lezer van de bijrijder ingebrachte kaart.  
cardNumberDriverSlotEnd  identificeert de aan het einde van het voor ­
val in de lezer van de bestuurder ingebrachte kaart.  
cardNumberCodriverSlotEnd  identificeert de aan het einde van het 
voorval in de lezer van de bijrijder ingebrachte kaart.  
similarEventsNumber  is het aantal vergelijkbare voorvallen op die dag.  
Deze sequentie kan worden gebruikt voor alle voorvallen met uitzon ­
dering van snelheidsoverschrijdingen.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 163  
2e generatie:
  
Als aanvulling op de 1e generatie worden de volgende gegevenselemen ­
ten gebruikt:  
manufacturerSpecificEventFaultData  bevat aanvullende informatie 
over het voorval, specifiek voor de fabrikant.  
In de gegevensstructuur van de 2e generatie zijn cardNumberDriverSlot ­
Begin, cardNumberCodriverSlotBegin, cardNumberDriverSlotEnd en 
cardNumberCodriverSlotEnd vervangen door de volgende gegevensele ­
menten:  
cardNumberAndGenDriverSlotBegin  identificeert de aan het begin 
van het voorval in de lezer van de bestuurder ingebrachte kaart, inclusief 
de generatie.  
cardNumberAndGenCodriverSlotBegin  identificeert de aan het begin 
van het voorval in de lezer van de bijrijder ingebrachte kaart, inclusief 
de generatie.  
cardNumberAndGenDriverSlotEnd  identificeert de aan het einde van 
het voorval in de lezer van de bestuurder ingebrachte kaart, inclusief de 
generatie.  
cardNumberAndGenCodriverSlotEnd  identificeert de aan het einde 
van het voorval in de lezer van de bijrijder ingebrachte kaart, inclusief 
de generatie.  
Als het om een tijdsconflict gaat, moeten eventBeginTime en eventEnd ­
Time als volgt worden geïnterpreteerd:  
eventBeginTime  is de datum en het tijdstip van het controleapparaat.  
eventEndTime  is de datum en het tijdstip van het GNSS.  
2.199.  VuEventRecordArray  
2e generatie:  
In een voertuigunit opgeslagen informatie met betrekking tot voorvallen 
(voorschrift 117 van bijlage 1C, met uitzondering van snelheidsover ­
schrijding).
  
recordType  geeft de soort record aan (VuEventRecord).  Waardetoe ­
kenning : zie RecordType.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 164  
recordSize  is de grootte van VuEventRecord in bytes.  
noOfRecords  is het aantal records in de reeks records.  
records  is een reeks voorvallenrecords.  
2.200.  VuFaultData  
1e generatie:  
In een voertuigunit opgeslagen informatie met betrekking tot fouten 
(voorschrift 096 van bijlage 1B).
  
noOfVuFaults  is het aantal in de vuFaultRecords-reeks opgenomen 
fouten.  
vuFaultRecords  is een reeks foutenrecords.  
2.201.  VuFaultRecord  
In een voertuigunit opgeslagen informatie met betrekking tot een fout 
(voorschrift 096 van bijlage 1B en voorschrift 118 van bijlage 1C).  
1e generatie:
  
faultType  is de soort fout van het controleapparaat.  
faultRecordPurpose  is het doel waarvoor deze fout geregistreerd werd.  
faultBeginTime  is de datum en het tijdstip van het begin van de fout.  
faultEndTime  is de datum en het tijdstip van het einde van de fout.  
cardNumberDriverSlotBegin  identificeert de aan het begin van de fout 
in de lezer van de bestuurder ingebrachte kaart.  
cardNumberCodriverSlotBegin  identificeert de aan het begin van de 
fout in de lezer van de bijrijder ingebrachte kaart.  
cardNumberDriverSlotEnd  identificeert de aan het einde van de fout 
in de lezer van de bestuurder ingebrachte kaart.  
cardNumberCodriverSlotEnd  identificeert de aan het einde van de fout 
in de lezer van de bijrijder ingebrachte kaart.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 165  
2e generatie:
  
Als aanvulling op de 1e generatie wordt het volgende gegevenselement 
gebruikt:  
manufacturerSpecificEventFaultData  bevat aanvullende informatie 
over de fout, specifiek voor de fabrikant.  
In de gegevensstructuur van de 2e generatie zijn cardNumberDriverSlot ­
Begin, cardNumberCodriverSlotBegin, cardNumberDriverSlotEnd en 
cardNumberCodriverSlotEnd vervangen door de volgende gegevensele ­
menten:  
cardNumberAndGenDriverSlotBegin  identificeert de aan het begin 
van de fout in de lezer van de bestuurder ingebrachte kaart, inclusief 
de generatie.  
cardNumberAndGenCodriverSlotBegin  identificeert de aan het begin 
van de fout in de lezer van de bijrijder ingebrachte kaart, inclusief de 
generatie.  
cardNumberAndGenDriverSlotEnd  identificeert de aan het einde van 
de fout in de lezer van de bestuurder ingebrachte kaart, inclusief de 
generatie.  
cardNumberAndGenCodriverSlotEnd  identificeert de aan het einde 
van de fout in de lezer van de bijrijder ingebrachte kaart, inclusief de 
generatie.  
2.202.  VuFaultRecordArray  
2e generatie:  
In een voertuigunit opgeslagen informatie met betrekking tot fouten 
(voorschrift 118 van bijlage 1C).
  
recordType  geeft de soort record aan (VuFaultRecord).  Waardetoeken ­
ning : zie RecordType.  
recordSize  is de grootte van VuFaultRecord in bytes.  
noOfRecords  is het aantal records in de reeks records.  
records  is een reeks foutrecords.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 166  
2.203.  VuGNSSADRecord  
2e generatie:  
In een voertuigunit opgeslagen informatie met betrekking tot de GNSS- 
positie van het voertuig als de cumulatieve rijtijd een veelvoud van drie 
uur bereikt (voorschriften 108 en 110 van bijlage IC).
  
timeStamp  is de datum en het tijdstip waarop de cumulatieve rijtijd een 
veelvoud van drie uur bereikt;  
cardNumberAndGenDriverSlot  identificeert de in de lezer van de be ­
stuurder ingebrachte kaart, inclusief de generatie.  
cardNumberAndGenCodriverSlot  identificeert de in de lezer van de 
bijrijder ingebrachte kaart, inclusief de generatie.  
gnssPlaceRecord  bevat informatie over de positie van het voertuig.  
vehicleOdometerValue  is de kilometerstand op het ogenblik dat de 
cumulatieve rijtijd een veelvoud van drie uur bereikt.  
2.204.  VuGNSSADRecordArray  
2e generatie:  
In een voertuigunit opgeslagen informatie met betrekking tot de GNSS- 
positie van het voertuig als de cumulatieve rijtijd een veelvoud van drie 
uur bereikt (voorschriften 108 en 110 van bijlage IC).
  
recordType  geeft de soort record aan (VuGNSSADRecord).  
Waardetoekenning : See RecordType.  
recordSize  is de grootte van VuGNSSADRecord in bytes.  
noOfRecords  is het aantal records in de reeks records.  
records  is een reeks GNSS-records van de cumulatieve rijtijd.  
▼B 
2.205.  VuIdentification  
In een voertuigunit opgeslagen informatie met betrekking tot de identi ­
ficatie van het controleapparaat (voorschrift 075 van bijlage 1B en voor ­
schriften 93 en 121 van bijlage 1C).  ▼M1
 02016R0799 — NL — 26.02.2020 — 002.001 — 167  
1e generatie:
  
vuManufacturerName  is de naam van de fabrikant van de voertuigunit.  
vuManufacturerAddress  is het adres van de fabrikant van de voertuig ­
unit. 
vuPartNumber  is het onderdeelnummer van de voertuigunit.  
vuSerialNumber  is het serienummer van de VU.  
vuSoftwareIdentification  identificeert de software die in de voertuigunit 
geïmplementeerd is.  
vuManufacturingDate  is het bouwjaar van de voertuigunit.  
vuApprovalNumber  is het typegoedkeuringsnummer van de voertuig ­
unit. 
2e generatie:
  
Als aanvulling op de 1e generatie worden de volgende gegevenselemen ­
ten gebruikt:  
vuGeneration  identificeert de generatie van de VU.  
vuAbility  geeft aan of de voertuigunit al dan niet tachograafkaarten van 
de 1e generatie ondersteunt  
2.206.  VuIdentificationRecordArray  
2e generatie:  
De VuIdentification plus metagegevens zoals gebruikt in het download ­
protocol.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 168
  
recordType  geeft de soort record aan (VuIdentification).  Waardetoe ­
kenning : zie RecordType.  
recordSize  is de grootte van VuIdentification in bytes.  
noOfRecords  is het aantal records in de reeks records.  
records  is een reeks VuIdentification-records.  
2.207.  VuITSConsentRecord  
2e generatie:  
In een voertuigunit opgeslagen informatie met betrekking tot de toestem ­
ming van de bestuurder om intelligente vervoerssystemen te gebruiken.
  
cardNumberAndGen  identificeert de kaart, inclusief de generatie. Dit 
moet een bestuurders- of werkplaatskaart zijn.  
consent  is een teken dat aangeeft of de bestuurder toestemming heeft 
gegeven om in zijn voertuig/voertuigunit intelligente vervoerssystemen 
te gebruiken.  
Waardetoekenning:  
TRUE geeft dat de bestuurder heeft toegestemd om intel ­
ligente vervoerssystemen te gebruiken  
FALSE geeft dat de bestuurder heeft geweigerd om intel ­
ligente vervoerssystemen te gebruiken  
2.208.  VuITSConsentRecordArray  
2e generatie:  
In een voertuigunit opgeslagen informatie met betrekking tot de toestem ­
ming van de bestuurder om intelligente vervoerssystemen te gebruiken 
(voorschrift 200 van bijlage 1C).
  
recordType  geeft de soort record aan (VuITSConsentRecord).  Waar­
detoekenning : zie RecordType.  
recordSize  is de grootte van VuITSConsentRecord in bytes.  
noOfRecords  is het aantal records in de reeks records.  
records  is de reeks records van toestemmingen om ITS te gebruiken.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 169  
2.209.  VuManufacturerAddress  
Adres van de fabrikant van de voertuigunit.
  
Waardetoekenning : niet gespecificeerd.  
2.210.  VuManufacturerName  
Naam van de fabrikant van de voertuigunit.
  
Waardetoekenning : niet gespecificeerd.  
2.211.  VuManufacturingDate  
Bouwjaar van de voertuigunit.
  
Waardetoekenning : niet gespecificeerd.  
2.212.  VuOverSpeedingControlData  
In een voertuigunit opgeslagen informatie met betrekking tot snelheids ­
overschrijdingen sinds de laatste controle van de snelheidsoverschrijding 
(voorschrift 095 van bijlage 1B en voorschrift 117 van bijlage 1C).
  
lastOverspeedControlTime  is de datum en het tijdstip van de laatste 
controle van de snelheidsoverschrijding.  
firstOverspeedSince  is de datum en het tijdstip van de eerste snelheids ­
overschrijding na deze controle van de snelheidsoverschrijding.  
numberOfOverspeedSince  is het aantal snelheidsoverschrijdingen na de 
laatste controle van de snelheidsoverschrijding.  
2.213.  VuOverSpeedingControlDataRecordArray  
2e generatie:  
De VuOverSpeedingControlData plus metagegevens zoals gebruikt in 
het downloadprotocol.
  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 170  
recordType  geeft de soort records aan (VuOverSpeedingControlData).  
Waardetoekenning : zie RecordType.  
recordSize  is de grootte van VuOverSpeedingControlData in bytes.  
noOfRecords  is het aantal records in de reeks records.  
records  is een reeks records van gegevens over snelheidsoverschrij ­
dingscontroles.  
2.214.  VuOverSpeedingEventData  
1e generatie:  
In een voertuigunit opgeslagen informatie met betrekking tot voorvallen 
van snelheidsoverschrijding (voorschrift 094 van bijlage 094).
  
noOfVuOverSpeedingEvents  is het aantal in de vuOverSpeedingEvent ­
Records-reeks opgenomen voorvallen.  
vuOverSpeedingEventRecords  is een reeks voorvallenrecords van snel ­
heidsoverschrijding.  
2.215.  VuOverSpeedingEventRecord  
1e generatie:  
In een voertuigunit opgeslagen informatie met betrekking tot voorvallen 
van snelheidsoverschrijding (voorschrift 094 van bijlage 1B en voor ­
schrift 117 van bijlage 1C).
  
eventType  is het soort voorval.  
eventRecordPurpose  is het doel waarvoor dit voorval geregistreerd 
werd.  
eventBeginTime  is de datum en het tijdstip van het begin van het 
voorval.  
eventEndTime  is de datum en het tijdstip van het einde van het voorval.  
maxSpeedValue  is de tijdens het voorval gemeten maximumsnelheid.  
averageSpeedValue  is de tijdens het voorval gemeten rekenkundige 
gemiddelde snelheid.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 171  
cardNumberDriverSlotBegin  identificeert de aan het begin van het 
voorval in de lezer van de bestuurder ingebrachte kaart.  
similarEventsNumber  is het aantal vergelijkbare voorvallen op die dag.  
2e generatie:  
In een voertuigunit opgeslagen informatie met betrekking tot voorvallen 
van snelheidsoverschrijding (voorschrift 094 van bijlage 1B en voor ­
schrift 117 van bijlage 1C).
  
In de gegevensstructuur van de 2e generatie is cardNumberDriverSlot ­
Begin vervangen door het volgende gegevenselement:  
cardNumberAndGenDriverSlotBegin  identificeert de aan het begin 
van het voorval in de lezer van de bestuurder ingebrachte kaart, inclusief 
de generatie.  
2.216.  VuOverSpeedingEventRecordArray  
2e generatie:  
In een voertuigunit opgeslagen informatie met betrekking tot voorvallen 
van snelheidsoverschrijding (voorschrift 117 van bijlage 1C).
  
recordType  geeft de soort record aan (VuOverSpeedingEventRecord).  
Waardetoekenning : zie RecordType.  
recordSize  is de grootte van VuOverSpeedingEventRecord in bytes.  
noOfRecords  is het aantal records in de reeks records.  
records  is een reeks voorvallenrecords van snelheidsoverschrijding.  
2.217.  VuPartNumber  
Onderdeelnummer van de voertuigunit.
  
Waardetoekenning : specifiek voor de fabrikant van de VU.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 172  
2.218.  VuPlaceDailyWorkPeriodData  
1e generatie:  
In een voertuigunit opgeslagen informatie met betrekking tot plaatsen 
waar bestuurders een dagelijkse werkperiode beginnen of eindigen 
(voorschrift 087 van bijlage 1B en voorschriften 108 en 110 van bijlage 
1C).
 
noOfPlaceRecords  is het aantal in de vuPlaceDailyWorkPeriodRecords- 
reeks opgenomen records.  
vuPlaceDailyWorkPeriodRecords  is een reeks records met betrekking 
tot de plaats.  
2.219.  VuPlaceDailyWorkPeriodRecord  
1e generatie:  
In een voertuigunit opgeslagen informatie met betrekking tot plaatsen 
waar een bestuurder een dagelijkse werkperiode begint of eindigt (voor ­
schrift 087 van bijlage 1B en voorschriften 108 en 110 van bijlage 1C).
  
fullCardNumber  is de soort bestuurderskaart, de lidstaat van afgifte en 
het kaartnummer.  
placeRecord  bevat de informatie met betrekking tot de ingevoerde 
plaats.  
2e generatie:  
In een voertuigunit opgeslagen informatie met betrekking tot een plaats 
waar een bestuurder een dagelijkse werkperiode begint of eindigt (voor ­
schrift 087 van bijlage 1B en voorschriften 108 en 110 van bijlage 1C).
  
In de gegevensstructuur van de 2e generatie is fullCardNumber vervan ­
gen door het volgende gegevenselement:  
fullCardNumberAndGeneration  is de op de kaart opgeslagen soort 
kaart, de lidstaat van afgifte, het kaartnummer en de generatie.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 173  
2.220.  VuPlaceDailyWorkPeriodRecordArray  
2e generatie:  
In een voertuigunit opgeslagen informatie met betrekking tot plaatsen 
waar bestuurders een dagelijkse werkperiode beginnen of eindigen 
(voorschrift 108 en 110 van bijlage 1C).
  
recordType  geeft de soort record aan (VuPlaceDailyWorkPeriod ­
Record).  Waardetoekenning : zie RecordType.  
recordSize  is de grootte van VuPlaceDailyWorkPeriodRecord in bytes.  
noOfRecords  is het aantal records in de reeks records.  
records  is een reeks records met betrekking tot de plaats.  
2.221.  VuPrivateKey  
1e generatie:  
De particuliere sleutel van een voertuigunit.
  
2.222.  VuPublicKey  
1e generatie:  
De openbare sleutel van een voertuigunit.
  
2.223.  VuSerialNumber  
Serienummer van de voertuigunit (voorschrift 075 van bijlage 1B en 
voorschrift 93 van bijlage 1C).
  
2.224.  VuSoftInstallationDate  
Datum van installatie van de softwareversie in de voertuigunit.
  
Waardetoekenning : niet gespecificeerd.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 174  
2.225.  VuSoftwareIdentification  
In een voertuigunit opgeslagen informatie met betrekking tot de geïnstal ­
leerde software.
  
vuSoftwareVersion  is het nummer van de softwareversie van de VU.  
vuSoftInstallationDate  is de datum van installatie van de softwarever ­
sie. 
2.226.  VuSoftwareVersion  
Nummer van de softwareversie van de voertuigunit.
  
Waardetoekenning : niet gespecificeerd.  
2.227.  VuSpecificConditionData  
1e generatie:  
In een voertuigunit opgeslagen informatie met betrekking tot specifieke 
omstandigheden.
  
noOfSpecificConditionRecords  is het aantal in de specificCondition ­
Records-reeks opgenomen records.  
specificConditionRecords  is een reeks records met betrekking tot spe ­
cifieke omstandigheden.  
2.228.  VuSpecificConditionRecordArray  
2e generatie:  
In een voertuigunit opgeslagen informatie met betrekking tot specifieke 
omstandigheden (voorschrift 130 van bijlage 1C).
  
recordType  geeft de soort record aan (SpecificConditionRecord).  
Waardetoekenning : zie RecordType.  
recordSize  is de grootte van SpecificConditionRecord in bytes.  
noOfRecords  is het aantal records in de reeks records.  
records  is een reeks records met betrekking tot specifieke omstandig ­
heden.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 175  
2.229.  VuTimeAdjustmentData  
1e generatie:  
In een voertuigunit opgeslagen informatie met betrekking tot de buiten 
het kader van een geregelde kalibrering uitgevoerde tijdafstellingen 
(voorschrift 101 van bijlage 1B).
  
noOfVuTimeAdjRecords  is het aantal records in de vuTimeAdjust ­
mentRecords.  
vuTimeAdjustmentRecords  is een reeks tijdafstellingsrecords.  
▼M1 
2.230.  Gereserveerd voor toekomstig gebruik  
2.231.  Gereserveerd voor toekomstig gebruik  
▼B 
2.232.  VuTimeAdjustmentRecord  
In een voertuigunit opgeslagen informatie met betrekking tot de buiten 
het kader van een geregelde kalibrering uitgevoerde tijdafstellingen 
(voorschrift 101 van bijlage 1B en voorschriften 124 en 125 van bijlage 
1C). 
1e generatie:
  
oldTimeValue, newTimeValue  zijn de oude en nieuwe waarden van 
datum en tijd.  
workshopName, workshopAddress  zijn de naam en het adres van de 
werkplaats.  
workshopCardNumber  identificeert de voor de tijdafstelling gebruikte 
werkplaatskaart.  
2e generatie:
  
In de gegevensstructuur van de 2e generatie is workshopCardNumber 
vervangen door het volgende gegevenselement:  
workshopCardNumberAndGeneration  identificeert de voor de tijd ­
afstelling gebruikte werkplaatskaart, inclusief de generatie.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 176  
2.233.  VuTimeAdjustmentRecordArray  
2e generatie:  
In een voertuigunit opgeslagen informatie met betrekking tot de buiten 
het kader van een geregelde kalibrering uitgevoerde tijdafstellingen 
(voorschriften 124 en 125 van bijlage 1C).
  
recordType  geeft de soort record aan (VuTimeAdjustmentRecord).  
Waardetoekenning : zie RecordType.  
recordSize  is de grootte van VuTimeAdjustmentRecord in bytes.  
noOfRecords  is het aantal records in de reeks records.  
records  is een reeks records van tijdafstellingen.  
2.234.  WorkshopCardApplicationIdentification  
Op een werkplaatskaart opgeslagen informatie met betrekking tot de 
toepassingsidentificatie van de kaart (voorschriften 307 en 330 van bij ­
lage 1C).  
1e generatie:
  
typeOfTachographCardId  specificeert de geïmplementeerde kaartsoort.  
cardStructureVersion  specificeert de versie van de op de kaart geïm ­
plementeerde structuur.  
noOfEventsPerType  is het aantal voorvallen per soort voorval dat de 
kaart kan registreren.  
noOfFaultsPerType  is het aantal fouten per soort fout dat de kaart kan 
registreren.  
activityStructureLength  geeft het aantal beschikbare bytes aan voor het 
opslaan van activiteitenrecords.  
noOfCardVehicleRecords  is het aantal voertuigregistraties dat de kaart 
kan bevatten.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 177  
noOfCardPlaceRecords  is het aantal plaatsen dat de kaart kan regis ­
treren.  
noOfCalibrationRecords  is het aantal kalibreringsrecords dat de kaart 
kan opslaan.  
2e generatie:  
▼M1
 
Als aanvulling op de 1e generatie worden de volgende gegevenselemen ­
ten gebruikt:  
noOfGNSSCDRecords  is het aantal GNSS-records van de cumulatieve 
rijtijd dat op de kaart kan worden opgeslagen.  
noOfSpecificConditionRecords  is het aantal records van specifieke om ­
standigheden dat op de kaart kan worden opgeslagen.  
noOfCardVehicleUnitRecords  is het aantal voertuigrecords dat op de 
kaart kan worden opgeslagen.  
▼B 
2.235.  WorkshopCardCalibrationData  
Op een werkplaatskaart opgeslagen informatie met betrekking tot de met 
de kaart uitgevoerde activiteiten van de werkplaats (voorschriften 314, 
316, 337 en 339 van bijlage 1C).
  
calibrationTotalNumber  is het totale aantal met de kaart uitgevoerde 
kalibreringen.  
calibrationPointerNewestRecord  is de index van de laatst bijgewerkte 
kalibreringsrecord.  
Waardetoekenning : getal dat correspondeert met de teller van de kali ­
breringsrecord, beginnend met ‘0’ voor de eerste kalibreringsrecord in de 
structuur.  
calibrationRecords  is de reeks records die informatie over kalibrering 
en/of tijdafstelling bevat.  
2.236.  WorkshopCardCalibrationRecord  
Op een werkplaatskaart opgeslagen informatie met betrekking tot een 
met de kaart uitgevoerde kalibrering (voorschriften 314 en 337 van 
bijlage 1C).  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 178  
1e generatie:
  
calibrationPurpose  is het doel van de kalibrering.  
vehicleIdentificationNumber  is het VIN.  
vehicleRegistration  bevat het kentekennummer en de registrerende lid ­
staat.  
wVehicleCharacteristicConstant  is de kenmerkende coëfficiënt van het 
voertuig.  
kConstantOfRecordingEquipment  is de constante van het controleap ­
paraat.  
lTyreCircumference  is de effectieve omtrek van de wielbanden.  
tyreSize  is de aanduiding van de afmeting van de banden waarmee het 
voertuig uitgerust is.  
authorisedSpeed  is de toegestane maximumsnelheid van het voertuig.  
oldOdometerValue, newOdometerValue  zijn de oude en nieuwe kilo ­
meterstanden.  
oldTimeValue, newTimeValue  zijn de oude en nieuwe waarden van 
datum en tijd.  
nextCalibrationDate  is de datum van de volgende in CalibrationPur ­
pose gespecificeerde soort kalibrering die door de bevoegde controleau ­
toriteit moet worden uitgevoerd.  
vuPartNumber, vuSerialNumber  en sensorSerialNumber  zijn de ge ­
gevenselementen voor identificatie van het controleapparaat.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 179  
2e generatie:
  
Als aanvulling op de 1e generatie worden de volgende gegevenselemen ­
ten gebruikt:  
sensorGNSSSerialNumber  identificeert een externe GNSS-module.  
rcmSerialNumber  identificeert een module voor communicatie op af ­
stand.  
sealDataCard  geeft informatie over de zegels die aan de verschillende 
onderdelen van het voertuig zijn gehecht.  
2.237.  WorkshopCardHolderIdentification  
Op een werkplaatskaart opgeslagen informatie met betrekking tot de 
identificatie van de kaarthouder (voorschriften 311 en 334 van bijlage 
1C).
 
workshopName  is de naam van de werkplaats van de kaarthouder.  
workshopAddress  is het adres van de werkplaats van de kaarthouder.  
cardHolderName  is de naam en voornaam (voornamen) van de houder 
(bijv. de naam van de monteur).  
cardHolderPreferredLanguage  is de voorkeurtaal van de kaarthouder.  
2.238.  WorkshopCardPIN  
Persoonlijk identificatienummer (PIN-code) van de werkplaatskaart 
(voorschriften 309 en 332 van bijlage 1C).
  
Waardetoekenning : de bij de kaarthouder bekende PIN-code, rechts 
met ‘FF’ bytes tot maximaal 8 bytes opgevuld.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 180  
2.239.  W-VehicleCharacteristicConstant  
Kenmerkende coëfficiënt van het voertuig (definitie k).
  
Waardetoekenning : pulsen per kilometer in het operationele bereik van 
0 tot 64 255 pulsen/km.  
2.240.  VuPowerSupplyInterruptionRecord  
2e generatie:  
In een voertuigunit opgeslagen informatie met betrekking tot onderbre ­
kingen in de stroomvoorziening (voorschrift 117 van bijlage 1C).
  
eventType  is het soort voorval.  
eventRecordPurpose  is het doel waarvoor dit voorval geregistreerd 
werd.  
eventBeginTime  is de datum en het tijdstip van het begin van het 
voorval.  
eventEndTime  is de datum en het tijdstip van het einde van het voorval.  
cardNumberAndGenDriverSlotBegin  identificeert de aan het begin 
van het voorval in de lezer van de bestuurder ingebrachte kaart, inclusief 
de generatie.  
cardNumberAndGenDriverSlotEnd  identificeert de aan het eind van 
het voorval in de lezer van de bestuurder ingebrachte kaart, inclusief de 
generatie.  
cardNumberAndGenCodriverSlotBegin  identificeert de aan het begin 
van het voorval in de lezer van de bijrijder ingebrachte kaart, inclusief 
de generatie.  
cardNumberAndGenCodriverSlotEnd  identificeert de aan het eind 
van het voorval in de lezer van de bijrijder ingebrachte kaart, inclusief 
de generatie.  
similarEventsNumber  is het aantal vergelijkbare voorvallen op die dag.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 181  
2.241.  VuPowerSupplyInterruptionRecordArray  
2e generatie:  
In een voertuigunit opgeslagen informatie met betrekking tot onderbre ­
kingen in de stroomvoorziening (voorschrift 117 van bijlage 1C).
  
recordType  staat voor de soort record (VuPowerSupplyInterruption ­
Record).  Waardetoekenning : zie RecordType.  
recordSize  is de grootte van VuPowerSupplyInterruptionRecord in by ­
tes. 
noOfRecords  is het aantal records in de reeks records.  
records  is een reeks records van onderbrekingen in de stroomvoorzie ­
ning.  
2.242.  VuSensorExternalGNSSCoupledRecordArray  
2e generatie:  
Een reeks SensorExternalGNSSCoupledRecord plus metagegevens die 
worden gebruikt in het downloadprotocol.
  
recordType  staat voor de soort record (SensorExternalGNSSCoupled ­
Record).  Waardetoekenning : zie RecordType.  
recordSize  is de grootte van SensorExternalGNSSCoupledRecord in 
bytes.  
noOfRecords  is het aantal records in de reeks records.  
records  is een reeks SensorExternalGNSSCoupledRecords.  
2.243.  VuSensorPairedRecordArray  
2e generatie:  
Een reeks SensorPairedRecord plus metagegevens die worden gebruikt 
in het downloadprotocol.
  
recordType  staat voor de soort record (SensorPairedRecord).  Waarde ­
toekenning : zie RecordType.  
recordSize  is de grootte van SensorPairedRecord in bytes.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 182  
noOfRecords  is het aantal records in de reeks records.  
records  is een reeks SensorPairedRecords.  
3. DEFINITIES VAN WAARDEN- EN AFMETINGENBEREIK  
Definitie van variabele waarden die gebruikt zijn bij de definities in 
paragraaf 2.
  
4. TEKENSETS  
IA5-Strings gebruiken de ASCII-tekens zoals gedefinieerd in ISO/IEC 
8824-1. Voor de leesbaarheid en voor gemakkelijke verwijzing wordt de 
waardetoekenning hieronder gegeven. In geval van afwijkingen geldt 
ISO/IEC 8824-1 boven deze informatieve notitie.
  
Andere tekenstrings (Address, Name, VehicleRegistrationNumber) ge ­
bruiken bovendien tekens die worden gedefinieerd door de codes 161 
tot en met 255 van de volgende 8-bits standaardtekensets, gespecificeerd 
door het CodePagenummer: 
Standaardtekenset  Code Page 
(decimaal)  
ISO/IEC 8859-1 Latijns-1 West-Europees  1  
ISO/IEC 8859-2 Latijns-2 Centraal-Europees  2  
ISO/IEC 8859-3 Latijns-3 Zuid-Europees  3  
ISO/IEC 8859-5 Latijns / Cyrillisch  5  
ISO/IEC 8859-7 Latijns / Grieks  7  
ISO/IEC 8859-9 Latijns-5 Turks  9  
ISO/IEC 8859-13 Latijns-7 Baltische regio  13  
ISO/IEC 8859-15 Latijns-9  15  
ISO/IEC 8859-16 Latijns-10 Zuid-Oost-Europees  16  
KOI8-R Latijns / Cyrillisch  80  
KOI8-U Latijns / Cyrillisch  85  
5. CODERING  
In het geval van codering met ASN.1-coderegels moeten alle gedefini ­
eerde gegevenssoorten gecodeerd worden overeenkomstig ISO/IEC 
8825-2, uitgerichte variant.  
6. OBJECTIDENTIFICATIE EN TOEPASSINGSIDENTIFICATIE  
6.1. Objectidentificatie  
De in dit hoofdstuk opgenomen objectidentificatiesymbolen (OID's) heb ­
ben alleen betrekking op de 2e generatie. Die OID's zijn gespecificeerd  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 183  
in TR-03110-3 en worden hier voor de volledigheid herhaald. Ze zijn 
opgenomen in de substructuur van bsi-de:
  
VU-authenticatieprotocolidentificatoren
  
Voorbeeld:  Als VU-authenticatie moet worden uitgevoerd met SHA-384, 
is het te gebruiken objectidentificatiesymbool (in ASN.1-notatie)
  
. De waarde 
van dit objectidentificatiesymbool in puntnotatie is
  
. 
Puntnotatie  Bytenotatie
  
‘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’  
Chipauthenticatieprotocolidentificatoren
  
Voorbeeld:  Veronderstel dat chipauthenticatie moet worden uitgevoerd 
met het ECDH-algoritme, wat resulteert in een AES-sessiesleutel met 
een lengte van 128 bits. Die sessiesleutel wordt vervolgens gebruikt in 
CBC-modus om de vertrouwelijkheid van de gegevens te verzekeren en 
met het CMAC-algoritme om de authenticiteit van de gegevens te ver ­
zekeren. Het te gebruiken objectidentificatiesymbool (in ASN.1-notatie) 
is daarom
  . De 
waarde van dit objectidentificatiesymbool in puntnotatie is
  
. 
Puntnotatie  Bytenotatie
  
‘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 — NL — 26.02.2020 — 002.001 — 184  
6.2. Toepassingsidentificaties  
2e generatie:  
Het toepassingsidentificatiesymbool (AID) voor de externe GNSS-mo ­
dule (2e generatie) wordt gegeven door ‘FF 44 54 45 47 4D’. Dit is een 
particuliere AID overeenkomstig ISO/IEC 7816-4.  
Opmerking:  De laatste 5 bytes coderen DTEGM voor een externe 
GNSS-module van een slimme tachograaf.  
Het toepassingsidentificatiesymbool (AID) voor de tachograafkaartappli ­
catie van de 2e generatie) wordt gegeven door ‘FF 53 4D 52 44 54’. Dit 
is een particuliere AID overeenkomstig ISO/IEC 7816-4.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 185  
Aanhangsel 2  
SPECIFICATIE VAN TACHOGRAAFKAARTEN  
INHOUDSOPGAVE  
1. INLEIDING  
1.1. Afkortingen  
1.2. Referentienormen  
2. ELEKTRONISCHE EN FYSIEKE KENMERKEN  
2.1. Toevoerspanning en stroomverbruik  
2.2. Programmeerspanning V  pp 
2.3. Klokgenerering en klokfrequentie  
2.4. I/O-contact  
2.5. Statussen van de kaart  
3. HARDWARE EN COMMUNICATIE  
3.1. Inleiding  
3.2. Overbrengingsprotocol  
3.2.1 Protocollen  
3.2.2 ATR  
3.2.3 PTS  
3.3. Toegangsregels  
3.4. Overzicht van commando's en foutcodes  
3.5. Beschrijving van commando's  
3.5.1 SELECT (Selecteer)  
3.5.2 READ BINARY (Lees binair getal)  
3.5.3 UPDATE BINARY (Werk binair getal bij)  
3.5.4 GET CHALLENGE (Vraag naar identiteit)  
3.5.5 VERIFY (Verifieer)  
3.5.6 GET RESPONSE (Haal antwoord op)  
3.5.7 PSO: VERIFY CERTIFICATE (PSO: verifieer certificaat)  
3.5.8 INTERNAL AUTHENTICATE (Interne authenticatie)  
3.5.9 EXTERNAL AUTHENTICATE (Externe authenticatie)  
3.5.10 GENERAL AUTHENTICATE (Algemene authenticatie)  
3.5.11 MANAGE SECURITY ENVIRONMENT (Beheer beveiligingsomge ­ 
ving)  
3.5.12 PSO: HASH  
3.5.13 PERFORM HASH OF FILE (Voer hash van bestand uit)  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 186  
3.5.14 PSO: COMPUTE DIGITAL SIGNATURE (PSO: bereken digitale 
handtekening)  
3.5.15 PSO: VERIFY DIGITAL SIGNATURE (PSO: verifieer digitale hand ­ 
tekening)  
3.5.16 PROCESS DSRC MESSAGE (Verwerk dsrc-bericht)  
4. BESTANDSSTRUCTUUR VAN DE TACHOGRAAFKAARTEN  
4.1. Stambestand (MF)  
4.2. Tachograaftoepassingen voor de bestuurderskaart  
4.2.1 Tachograaftoepassing van de eerste generatie voor de bestuurderskaart  
4.2.2 Tachograaftoepassing van de tweede generatie voor de bestuurders ­ 
kaart  
4.3. Tachograaftoepassingen voor de werkplaatskaart  
4.3.1 Tachograaftoepassing van de eerste generatie voor de werkplaatskaart  
4.3.2 Tachograaftoepassing van de tweede generatie voor de werkplaats ­ 
kaart  
4.4. Tachograaftoepassingen voor de controlekaart  
4.4.1 Tachograaftoepassing van de eerste generatie voor de controlekaart  
4.4.2 Tachograaftoepassing van de tweede generatie voor de controlekaart  
4.5. Tachograaftoepassingen voor de bedrijfskaart  
4.5.1 Tachograaftoepassing van de eerste generatie voor de bedrijfskaart  
4.5.2 Tachograaftoepassing van de tweede generatie voor de bedrijfskaart  
1. INLEIDING  
1.1. Afkortingen  
In dit aanhangsel worden de volgende afkortingen gebruikt.  
AC Toegangscondities  
AES Advanced Encryption Standard  
AID Toepassingsidentificator  
ALW Altijd  
APDU Toepassingsprotocol gegevensunit (commandostructuur)  
ATR Antwoord op terugstellen  
AUT Geauthenticeerd  
C6, C7 Contacten nr. 6 en 7 van de kaart, zoals beschreven in 
ISO/IEC 7816-2  
cc Klokcycli  
▼M1 
CHA Autorisatie van de certificaathouder  
▼B 
CHV Verificatie-informatie van de kaarthouder  
CLA Bytecategorie van het APDU-commando  
▼M1 
DO Gegevensobject  
▼B 
DSRC Speciale korteafstandscommunicatie  
DF Toepassingsgericht bestand. Een DF kan andere bestan ­
den (EF of DF) bevatten  
ECC Elliptische-krommecryptografie  
EF Hoofdbestand  
etu Elementaire tijdeenheid  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 187  
G1 Eerste generatie  
G2 Tweede generatie  
IC Geïntegreerde schakeling  
ICC Chipkaart  
ID Identificator  
IFD Interface-inrichting  
IFS Grootte van het informatieveld  
IFSC Grootte van het informatieveld voor de kaart  
IFSD Inrichting voor de grootte van het informatieveld (voor 
het werkstation)  
INS Instructiebyte van een APDU-commando  
Lc Lengte van invoergegevens voor een APDU-commando  
Le Lengte van de verwachte gegevens (uitvoergegevens voor 
een commando)  
MF Stambestand (hoofd-DF)  
NAD Knooppuntadres gebruikt in het protocol T = 1  
NEV Nooit  
P1-P2 Parameterbytes  
PIN Persoonlijk identificatienummer (pincode)  
PRO SM Beschermd door beveiligde berichtenuitwisseling  
PTS Protocol voor transmissieselectie  
RFU Gereserveerd voor toekomstig gebruik  
RST Terugstellen (van de kaart)  
SFID Korte EF-identificator  
SM Beveiligde berichtenuitwisseling  
SW1-SW2 Statusbytes  
TS Initieel ATR-teken  
VPP Programmeerspanning  
VU Voertuigunit  
XXh Waarde XX in hexadecimale notatie  
‘XXh’ Waarde XX in hexadecimale notatie  
|| Samenvoegingssymbool 03||04 = 0304  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 188  
1.2. Referentienormen  
De onderstaande referentienormen worden in dit aanhangsel gebruikt:  
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. ELEKTRISCHE EN FYSIEKE KENMERKEN  
TCS_01 Tenzij anders gespecificeerd, zijn alle elektronische signa ­
len in overeenstemming met ISO/IEC 7816-3.  
TCS_02 De plaats en afmetingen van de contacten van de kaart 
voldoen aan ISO/IEC 7816-2.  
2.1. Toevoerspanning en stroomverbruik  
TCS_03 De kaart werkt overeenkomstig de specificaties binnen de 
in ISO/IEC 7816-3 gespecificeerde verbruikslimieten.  
TCS_04 De kaart werkt met Vcc = 3 V (± 0,3 V) of met Vcc = 5 V 
(± 0,5 V).  
De spanning wordt geselecteerd overeenkomstig ISO/IEC 
7816-3.  
2.2. Programmeerspanning V  pp 
TCS_05 De kaart gebruikt geen programmeerspanning op pin C6. 
Pin C6 wordt naar verwachting niet aangesloten in een 
IFD. Contact C6 kan worden verbonden met V  cc in de 
kaart, maar niet met de aarde. Deze spanning mag in 
geen geval worden omgezet.  
2.3. Klokgenerering en klokfrequentie  
TCS_06 De kaart werkt binnen een frequentiebereik van 1 tot 
5 MHz en kan hogere frequenties ondersteunen. Tijdens 
een kaartsessie kan de klokfrequentie ± 2 % variëren. De 
klokfrequentie wordt door de voertuigunit en niet door de 
kaart zelf gegenereerd. De inschakelduur kan variëren tus ­
sen 40 en 60 %.  
TCS_07 Onder de in het kaartbestand EF ICC opgenomen voor ­
waarden kan de externe klok worden stilgezet (“klokstop”). 
De eerste byte van het EF ICC-bestandsdeel codeert de 
voorwaarden voor de klokstop.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 189  
Laag  Hoog  
Bit 3  Bit 2  Bit 1  
0 0  1  klokstop toegestaan, geen voorkeurniveau  
0 1  1  klokstop toegestaan, bij voorkeur hoog niveau  
1 0  1  klokstop toegestaan, bij voorkeur laag niveau  
0 0  0  klokstop niet toegestaan  
0 1  0  klokstop alleen toegestaan op hoog niveau  
1 0  0  klokstop alleen toegestaan op laag niveau  
De bits 4 tot en met 8 worden niet gebruikt.  
2.4. I/O-contact  
TCS_08 Het I/O-contact C7 wordt gebruikt om gegevens te ontvan ­
gen van en over te brengen naar de IFD. Alleen tijdens de 
werking staat ofwel de kaart, ofwel de IFD in overbren ­
gingsmodus. Indien beide units in overbrengingsmodus 
staan, mag er geen schade aan de kaart ontstaan. De kaart 
staat in ontvangstmodus, tenzij gegevens worden over ­
gebracht.  
2.5. Statussen van de kaart  
TCS_09 De kaart werkt in twee statussen wanneer de toevoerspan ­
ning aangesloten is:  
operationele status wanneer commando's worden uitgevoerd 
of verbinding wordt gemaakt met de digitale unit,  
inactieve status op alle andere tijdstippen; in deze status 
blijven alle gegevens bewaard op de kaart.  
3. HARDWARE EN COMMUNICATIE  
3.1. Inleiding  
In dit punt wordt een beschrijving gegeven van de minimaal vereiste 
functionaliteit voor tachograafkaarten en VU's om een correcte wer ­
king en interoperabiliteit te waarborgen.  
Tachograafkaarten voldoen zo veel mogelijk aan de beschikbare, toe ­
passelijke ISO/IEC-normen (in het bijzonder ISO/IEC 7816). Com ­
mando's en protocollen worden echter volledig beschreven om beperkt 
gebruik of eventueel aanwezige verschillen te specificeren. Tenzij 
anders aangegeven, voldoen de gespecificeerde commando's integraal 
aan de genoemde normen.  
3.2. Overbrengingsprotocol  
TCS_10 Het overbrengingsprotocol voldoet aan ISO/IEC 7816-3 
voor T = 0 en T = 1. De VU herkent in het bijzonder 
door de kaart verzonden verlengingen van de wachttijd.  
3.2.1  Protocollen  
TCS_11 De kaart biedt zowel protocol  T = 0  als protocol  T = 1 . 
Bovendien kan de kaart aanvullende contactgerichte proto ­
collen ondersteunen.  
TCS_12  T = 0  is het standaardprotocol; bijgevolg is een  PTS -com­
mando noodzakelijk om het protocol te wijzigen in  T = 1 . ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 190  
TCS_13 Inrichtingen ondersteunen de  directe conventie  in beide 
protocollen: bijgevolg is de directe conventie verplicht 
voor de kaart.  
TCS_14 De byte voor de  grootte van het informatieveld  wordt 
weergegeven in teken TA3 van het ATR. Deze waarde is 
ten minste gelijk aan ‘F0h’ (= 240 bytes).  
De onderstaande beperkingen zijn van toepassing op de protocollen:  
TCS_15  T = 0  
— De interface-inrichting ondersteunt een antwoord op I/O 
na de oplopende rand van het signaal bij RST vanaf 
400 cc.  
— De interface-inrichting kan met 12 etu's gescheiden te ­
kens lezen.  
— De interface-inrichting kan een foutief teken en de her ­
haling daarvan lezen, indien gescheiden met 13 etu's. 
Indien een foutief teken wordt vastgesteld, kan de I/O- 
foutsignalering tussen 1 etu en 2 etu's voorkomen. De 
inrichting ondersteunt een vertraging van 1 etu.  
— De interface-inrichting accepteert een ATR van 33 by ­
tes (TS + 32).  
— Indien TC1 in het ATR staat, is Extra Guard Time 
aanwezig voor door de interface-inrichting verzonden 
tekens. Niettemin kunnen door de kaart verzonden te ­
kens nog steeds met 12 etu's worden gescheiden. Dit 
geldt ook voor het door de kaart verzonden ACK-teken 
na een door de interface-inrichting gezonden P3-teken.  
— De interface-inrichting houdt rekening met een door de 
kaart gezonden NUL-teken.  
— De interface-inrichting accepteert de complementaire 
modus voor ACK.  
— Het GET RESPONSE-commando kan niet in ketting ­
modus worden gebruikt om een gegeven op te halen dat 
langer kan zijn dan 255 bytes.  
TCS_16  T = 1  
— NAD-byte: niet gebruikt (NAD wordt op ‘00’ gezet).  
— S-blok ABORT: niet gebruikt.  
— S-blok VPP state error: niet gebruikt.  
— De totale kettinglengte voor een gegevensveld bedraagt 
ten hoogste 255 bytes (te waarborgen door de IFD).  
— De inrichting voor de grootte van het informatieveld 
(IFSD) wordt onmiddellijk na het ATR door de IFD 
aangegeven: de IFD brengt het S-blok IFS-verzoek na 
het ATR over en de kaart zendt het S-blok IFS terug. 
De aanbevolen waarde voor IFSD is 254 bytes.  
— De kaart vraagt geen IFS-bijstelling.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 191  
3.2.2  ATR  
TCS_17 De inrichting controleert de ATR-bytes overeenkomstig 
ISO/IEC 7816-3. Historische tekens van het ATR worden 
niet geverifieerd.  
Voorbeeld van basis-biprotocol ATR overeenkomstig ISO/ 
IEC 7816-3  
Teken  Waarde  Opmerkingen  
TS ‘3Bh’  Geeft directe conventie aan  
T0 ‘85h’  TD1 aanwezig; 5 historische bytes zijn aanwezig  
TD1 ‘80h’  TD2 aanwezig; T=0 moet worden gebruikt  
TD2 ‘11h’  TA3 aanwezig; T=1 moet worden gebruikt  
TA3 ‘XXh’ (ten minste 
‘F0h’)  Grootte van het informatieveld voor de kaart (IFSC)  
TH1 t/m TH5  ‘XXh’  Historische tekens  
TCK  ‘XXh’  Controleer teken (exclusieve OF (XOR))  
TCS_18 Het stambestand (MF) wordt na het ATR impliciet gese ­
lecteerd en geldt als geldige map (directory).  
3.2.3  PTS  
TCS_19 Het standaardprotocol is T = 0. Om het protocol T = 1 in te 
stellen, moet de inrichting een PTS (ook PPS genoemd) 
naar de kaart verzenden.  
TCS_20 Aangezien de protocollen T = 0 en T = 1 verplicht zijn 
voor de kaart, is het basis-PTS voor protocolwisseling ver ­
plicht voor de kaart.  
Zoals aangegeven in ISO/IEC 7816-3, kan het PTS worden 
gebruikt om te wisselen naar hogere baudsnelheden dan de 
standaardsnelheid die de kaart in het eventuele ATR aan ­
geeft (TA(1) byte).  
Hogere baudsnelheden zijn facultatief voor de kaart.  
TCS_21 Indien geen andere baudsnelheid dan de standaardsnelheid 
wordt ondersteund (of indien de geselecteerde baudsnelheid 
niet wordt ondersteund), reageert de kaart correct op het 
PTS, overeenkomstig ISO/IEC 7816-3, door de PPS1-byte 
weg te laten.  
Voorbeelden van het basis-PTS voor protocolselectie:  
Teken  Waarde  Opmerkingen  
PPSS  ‘FFh’  Startteken  
PPS0  ‘00h’ of ‘01h’  PPS1 t/m PPS3 niet aanwezig; ‘00h’ om T0 te selecteren, 
‘01h’ om T1 te selecteren  
PK ‘XXh’  Controleteken: ‘XXh’ = ‘FFh’ als PPS0 = ‘00h’ 
‘XXh’ = ‘FEh’ als PPS0 = ‘01h’  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 192  
3.3. Toegangsregels  
TCS_22 Een toegangsregel specificeert de toepasselijke beveili ­
gingsvoorwaarden voor een toegangsmodus, dat wil zeggen 
een commando. Indien aan deze beveiligingsvoorwaarden 
is voldaan, wordt het corresponderende commando ver ­
werkt.  
TCS_23 De volgende beveiligingsvoorwaarden worden gebruikt 
voor de tachograafkaart:  
Afkorting  Betekenis  
ALW  De actie is altijd mogelijk en kan zonder enige beperking worden uitgevoerd. 
Het APDU-commando en -antwoord worden ongecodeerd verzonden, dat wil 
zeggen zonder beveiligde berichtenuitwisseling.  
NEV  De actie is nooit mogelijk.  
PLAIN-C  Het APDU-commando wordt ongecodeerd verzonden, dat wil zeggen zonder 
beveiligde berichtenuitwisseling.  
PWD  De actie kan alleen worden uitgevoerd indien de pincode van de werkplaats ­
kaart met succes is geverifieerd, dat wil zeggen indien de interne beveiligings ­
status van de kaart is ingesteld op „PIN_Verified”. Het commando moet 
zonder beveiligde berichtenuitwisseling worden verzonden.  
EXT-AUT-G1  De actie kan alleen worden uitgevoerd indien het External Authenticate-com ­
mando voor authenticatie van de eerste generatie (zie ook aanhangsel 11, deel 
A) met succes werd uitgevoerd.  
SM-MAC-G1  Het APDU-commando en -antwoord moeten worden toegepast met beveiligde 
berichtenuitwisseling van de eerste generatie in alleen-authenticeren-modus 
(zie aanhangsel 11, deel A).  
SM-C-MAC-G1  Het APDU-commando moet worden toegepast met beveiligde berichtenuit ­
wisseling van de eerste generatie in alleen-authenticeren-modus (zie aanhang ­
sel 11, deel A).  
SM-R-ENC-G1  Het APDU-antwoord moet worden toegepast met beveiligde berichtenuitwis ­
seling van de eerste generatie in coderingsmodus (zie aanhangsel 11, deel A); 
er wordt bijgevolg geen berichtauthenticatiecode teruggezonden.  
SM-R-ENC- 
MAC-G1  Het APDU-antwoord moet worden toegepast met beveiligde berichtenuitwis ­
seling van de eerste generatie in eerst-coderen-dan-authenticeren-modus (zie 
aanhangsel 11, deel A).  
SM-MAC-G2  Het APDU-commando en -antwoord moeten worden toegepast met beveiligde 
berichtenuitwisseling van de tweede generatie in alleen-authenticeren-modus 
(zie aanhangsel 11, deel B).  
SM-C-MAC-G2  Het APDU-commando moet worden toegepast met beveiligde berichtenuit ­
wisseling van de tweede generatie in alleen-authenticeren-modus (zie aan ­
hangsel 11, deel B).  
SM-R-ENC- 
MAC-G2  Het APDU-antwoord moet worden toegepast met beveiligde berichtenuitwis ­
seling van de tweede generatie in eerst-coderen-dan-authenticeren-modus (zie 
aanhangsel 11, deel B).  
▼M1 
TCS_24 Deze beveiligingsvoorwaarden kunnen op de volgende wij ­
zen aan elkaar worden gekoppeld:  
AND: alle beveiligingsvoorwaarden moeten worden nage ­
leefd.  
OR: ten minste één beveiligingsvoorwaarde moet worden 
nageleefd.  
De toegangsregels voor het bestandssysteem, dat wil zeg ­
gen de SELECT-, READ BINARY- en UPDATE BINA ­
RY-commando’s, worden gespecificeerd in hoofdstuk 4. 
De toegangsregels voor de overige commando’s worden 
gespecificeerd in de volgende tabellen. De uitdrukking 
„niet van toepassing” wordt gebruikt wanneer er geen voor ­
schrift bestaat ter ondersteuning van het commando In dat 
geval kan het commando al dan niet worden ondersteund, 
maar de toegangsvoorwaarde is „niet verplicht”.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 193  
TCS_25 In de toepassing DF Tachograaf G1 worden de volgende 
toegangsregels gebruikt:  
▼M1 
Commando  Bestuurderskaart  Werkplaatskaart  Controlekaart  Bedrijfskaart  
External Authenticate  
— Voor authenticatie van de 
eerste generatie  ALW  ALW  ALW  ALW  
— Voor authenticatie van de 
tweede generatie  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  Niet van toe ­
passing  Niet van toe ­
passing  Niet van toe ­
passing  Niet van toe ­
passing  
PSO: Compute Digital Signature  ALW of 
SM-MAC- 
G2 ALW of 
SM-MAC- 
G2 Niet van toe ­
passing  Niet van toe ­
passing  
PSO: Hash  Niet van toe ­
passing  Niet van toe ­
passing  ALW  Niet van toe ­
passing  
PERFORM HASH OF FILE  ALW of 
SM-MAC- 
G2 ALW of 
SM-MAC- 
G2 Niet van toe ­
passing  Niet van toe ­
passing  
PSO: Verify Certificate  ALW  ALW  ALW  ALW  
PSO: Verify Digital Signature  Niet van toe ­
passing  Niet van toe ­
passing  ALW  Niet van toe ­
passing  
Verify  Niet van toe ­
passing  ALW  Niet van toe ­
passing  Niet van toe ­
passing  
▼B 
TCS_26 In de toepassing DF Tachograaf_G2 worden de volgende 
toegangsregels gebruikt:  
▼M1 
Commando  Bestuurderskaart  Werkplaatskaart  Controlekaart  Bedrijfskaart  
External Authenticate  
— Voor authenticatie van de 
eerste generatie  Niet van toe ­
passing  Niet van toe ­
passing  Niet van toe ­
passing  Niet van toe ­
passing  
— Voor authenticatie van de 
tweede generatie  ALW  PWD  ALW  ALW  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 194  
Commando  Bestuurderskaart  Werkplaatskaart  Controlekaart  Bedrijfskaart  
Internal Authenticate  Niet van toe ­
passing  Niet van toe ­
passing  Niet van toe ­
passing  Niet van toe ­
passing  
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  Niet van toe ­
passing  ALW  ALW  Niet van toe ­
passing  
PSO: Compute Digital Signature  ALW of 
SM-MAC- 
G2 ALW of 
SM-MAC- 
G2 Niet van toe ­
passing  Niet van toe ­
passing  
PSO: Hash  Niet van toe ­
passing  Niet van toe ­
passing  ALW  Niet van toe ­
passing  
PERFORM HASH OF FILE  ALW of 
SM-MAC- 
G2 ALW of 
SM-MAC- 
G2 Niet van toe ­
passing  Niet van toe ­
passing  
PSO: Verify Certificate  ALW  ALW  ALW  ALW  
PSO: Verify Digital Signature  Niet van toe ­
passing  Niet van toe ­
passing  ALW  Niet van toe ­
passing  
Verify  Niet van toe ­
passing  ALW  Niet van toe ­
passing  Niet van toe ­
passing  
▼B 
TCS_27 In het stambestand (MF) worden de volgende toegangs ­
regels gebruikt:  
▼M1 
Commando  Bestuurderskaart  Werkplaatskaart  Controlekaart  Bedrijfskaart  
External Authenticate  
— Voor authenticatie van de 
eerste generatie  Niet van toe ­
passing  Niet van toe ­
passing  Niet van toe ­
passing  Niet van toe ­
passing  
— Voor authenticatie van de 
tweede generatie  ALW  PWD  ALW  ALW  
Internal Authenticate  Niet van toe ­
passing  Niet van toe ­
passing  Niet van toe ­
passing  Niet van toe ­
passing  
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 — NL — 26.02.2020 — 002.001 — 195  
Commando  Bestuurderskaart  Werkplaatskaart  Controlekaart  Bedrijfskaart  
Process DSRC Message  Niet van toe ­
passing  Niet van toe ­
passing  Niet van toe ­
passing  Niet van toe ­
passing  
PSO: Compute Digital Signature  Niet van toe ­
passing  Niet van toe ­
passing  Niet van toe ­
passing  Niet van toe ­
passing  
PSO: Hash  Niet van toe ­
passing  Niet van toe ­
passing  Niet van toe ­
passing  Niet van toe ­
passing  
PERFORM HASH OF FILE  Niet van toe ­
passing  Niet van toe ­
passing  Niet van toe ­
passing  Niet van toe ­
passing  
PSO: Verify Certificate  ALW  ALW  ALW  ALW  
PSO: Verify Digital Signature  Niet van toe ­
passing  Niet van toe ­
passing  Niet van toe ­
passing  Niet van toe ­
passing  
Verify  Niet van toe ­
passing  ALW  Niet van toe ­
passing  Niet van toe ­
passing  
▼B 
TCS_28 Een tachograafkaart kan al dan niet een commando accep ­
teren met een hoger beveiligingsniveau dan in de beveili ­
gingsvoorwaarden is voorgeschreven. Indien bijvoorbeeld 
ALW (of PLAIN-C) geldt als beveiligingsvoorwaarde, 
kan de kaart een commando ontvangen met beveiligde be ­
richtenuitwisseling (in coderings- en/of authenticatiemo ­
dus). Indien in de beveiligingsvoorwaarde beveiligde be ­
richtenuitwisseling in authenticatiemodus wordt opgelegd, 
kan de tachograafkaart een commando met beveiligde be ­
richtenuitwisseling van dezelfde generatie accepteren in au ­
thenticatie- en coderingsmodus.  
Opmerking:  in de beschrijving van commando's wordt na ­
der toegelicht welke commando's door de verschillende 
soorten tachograafkaarten en DF's worden ondersteund.  
3.4. Overzicht van commando's en foutcodes  
De commando's en bestandsorganisatie zijn afgeleid van en voldoen 
aan ISO/IEC 7816-4.  
In dit punt wordt een beschrijving gegeven van de volgende APDU- 
commando-antwoordparen. In de beschrijving van commando's wordt 
aangegeven welke varianten van commando's door toepassingen van 
de eerste en tweede generatie worden ondersteund.  
Commando  INS  
SELECT  ‘A4h’  
READ BINARY  ‘B0h’, ‘B1h’  
UPDATE BINARY  ‘D6h’, ‘D7h’  
GET CHALLENGE  ‘84h’  
VERIFY  ‘20h’  
GET RESPONSE  ‘C0h’  ▼M1
 02016R0799 — NL — 26.02.2020 — 002.001 — 196  
Commando  INS  
PERFORM SECURITY OPERATI ­
ON ‘2Ah’  
— VERIFY CERTIFICATE  
— COMPUTE DIGITAL SIGNA ­
TURE  
— VERIFY DIGITAL SIGNATU ­
RE 
— 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 De statuswoorden SW1 en SW2 worden in een antwoord ­
bericht teruggezonden en geven de verwerkingsstatus van 
het commando aan.  
SW1  SW2  Betekenis  
90 00  Normale verwerking  
61 XX  Normale verwerking XX = aantal beschikbare antwoordbytes  
62 81  Verwerking van waarschuwing. Deel van teruggezonden gege ­
vens kan beschadigd zijn  
63 00  Authenticatie mislukt (waarschuwing)  
63 CX  Foutieve CHV (pincode). „X” is waarde van teller voor reste ­
rende pogingen.  
64 00  Uitvoeringsfout — Toestand van niet-vluchtig geheugen ongewij ­
zigd. Integriteitsfout  
65 00  Uitvoeringsfout — Toestand van niet-vluchtig geheugen gewij ­
zigd 
65 81  Uitvoeringsfout — Toestand van niet-vluchtig geheugen gewij ­
zigd. Geheugenfout  
66 88  Beveiligingsfout: foutieve cryptografische controlesom (tijdens 
beveiligde berichtenuitwisseling) of 
ongeldig certificaat (tijdens certificaatverifica ­
tie) of 
ongeldig cryptogram (tijdens externe authenti ­
catie) of 
ongeldige handtekening (tijdens handtekening ­
verificatie)  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 197  
SW1  SW2  Betekenis  
67 00  Foutieve lengte (ongeldige Lc of Le)  
68 83  Laatste commando van de ketting verwacht  
69 00  Verboden commando (geen antwoord beschikbaar in T=0)  
69 82  Niet voldaan aan beveiligingsstatus  
69 83  Authenticatiemethode geblokkeerd  
69 85  Niet voldaan aan gebruiksvoorwaarden  
69 86  Commando niet toegestaan (geen geldig EF)  
69 87  Verwachte gegevensobjecten voor beveiligde berichtenuitwisse ­
ling ontbreken  
69 88  Onjuiste gegevensobjecten voor beveiligde berichtenuitwisseling  
6A 80  Onjuiste parameters in gegevensveld  
6A 82  Bestand niet gevonden  
6A 86  Foutieve parameters P1-P2  
6A 88  Referentiegegevens niet gevonden  
6B 00  Onjuiste parameters (offset buiten EF)  
6C XX  Foutieve lengte, SW2 geeft de exacte lengte aan. Er wordt geen 
gegevensveld teruggezonden  
6D 00  Instructiecode niet ondersteund of ongeldig  
6E 00  Categorie niet ondersteund  
6F 00  — Andere controlefouten  
Aanvullende statuswoorden zoals gedefinieerd in ISO/IEC 
7816-4 kunnen worden teruggezonden indien hun gedrag 
niet expliciet wordt genoemd in dit aanhangsel.  
Bijvoorbeeld de volgende statuswoorden kunnen facultatief 
worden teruggezonden:  
6881: Logical channel not supported  
6882: Secure messaging not supported  
▼B 
TCS_30 Indien in een APDU-commando meerdere foutcondities 
vervuld zijn, kan de kaart een van de toepasselijke status ­
woorden terugzenden.  
3.5. Beschrijving van commando's  
In dit hoofdstuk wordt een beschrijving gegeven van de verplichte 
commando's voor de tachograafkaarten.  
In aanhangsel 11 „Algemene beveiligingsmechanismen” worden na ­
dere bijzonderheden verstrekt over de betrokken cryptografische be ­
werkingen voor tachograaftoepassingen van de eerste en de tweede 
generatie.  
Alle commando's worden onafhankelijk van het gebruikte protocol (T 
= 0 of T = 1) beschreven. De APDU-bytes CLA, INS, P1, P2, Lc en 
Le worden altijd aangegeven. Indien Lc of Le niet nodig is voor het 
beschreven commando, zijn de daarmee samenhangende lengte, 
waarde en omschrijving leeg.  ▼M1
 02016R0799 — NL — 26.02.2020 — 002.001 — 198  
TCS_31 Indien beide lengtebytes (Lc en Le) vereist zijn, moet het 
beschreven commando in twee delen worden gesplitst wan ­
neer de IFD protocol T = 0 gebruikt: de IFD verzendt het 
commando zoals beschreven met P3 = Lc + gegevens, en 
verzendt vervolgens een GET RESPONSE-commando (zie 
punt 3.5.6) met P3 = Le.  
TCS_32 Indien beide lengtebytes vereist zijn en Le = 0 (beveiligde 
berichtenuitwisseling):  
— Bij gebruik van protocol T = 1 beantwoordt de kaart Le 
= 0 door alle beschikbare uitvoergegevens te verzenden.  
— Bij gebruik van protocol T = 0 verzendt de IFD het 
eerste commando met P3 = Lc + gegevens, en beant ­
woordt de kaart (deze impliciete Le = 0) met de status ­
bytes ‘ 61La ’, waarbij La het aantal beschikbare ant ­
woordbytes is. De IFD genereert vervolgens een GET 
RESPONSE-commando met P3 = La om de gegevens 
te kunnen lezen.  
TCS_33 Overeenkomstig ISO/IEC 7816-4 kan een tachograafkaart 
facultatief velden met uitgebreide lengte ondersteunen. Een 
tachograafkaart die velden met uitgebreide lengte onder ­
steunt:  
— geeft in het ATR aan dat velden met uitgebreide lengte 
worden ondersteund;  
— verstrekt de ondersteunde buffergrootte via de informa ­
tie over de uitgebreide lengte in EF ATR/INFO (zie 
TCS_146);  
— geeft in EF Extended_Length aan of velden met uit ­
gebreide lengte worden ondersteund voor T = 1 en/of 
T = 0 (zie TCS_147).  
— ondersteunt velden met uitgebreide lengte voor tacho ­
graaftoepassingen van de eerste en de tweede generatie.  
Opmerkingen:  
Alle commando's worden gespecificeerd voor velden met 
een korte lengte. Het gebruik van APDU's met uitgebreide 
lengte wordt verduidelijkt in ISO/IEC 7816-4.  
Doorgaans worden de commando's gespecificeerd voor de 
ongecodeerde modus, dat wil zeggen zonder beveiligde 
berichtenuitwisseling, aangezien de laag voor beveiligde 
berichtenuitwisseling wordt gespecificeerd in aanhangsel 
11. De toegangsregels voor een commando verduidelijken 
of het commando beveiligde berichtenuitwisseling al dan 
niet ondersteunt, en of het commando beveiligde berichte ­
nuitwisseling van de eerste en/of de tweede generatie on ­
dersteunt. Sommige varianten van commando's worden be ­
schreven met beveiligde berichtenuitwisseling om het ge ­
bruik daarvan te verduidelijken.  
TCS_34 De VU voert voor een sessie het volledige protocol voor 
wederzijdse authenticatie van VU-kaarten van de tweede 
generatie uit, met inbegrip van de certificaatverificatie (in ­
dien vereist) in DF Tachograaf, DF Tachograaf_G2 of in 
het MF.  
3.5.1  SELECT  
Dit commando voldoet aan ISO/IEC 7816-4, maar heeft een beperkt 
gebruik vergeleken met het in deze norm gedefinieerde commando.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 199  
Het SELECT-commando wordt gebruikt:  
— om een DF-toepassing te selecteren (er moet op naam worden 
geselecteerd);  
— om een hoofdbestand te selecteren dat overeenstemt met de opge ­
geven bestandsidentificator.  
3.5.1.1 S e l e c t i e o p n a a m ( A I D )  
Met dit commando wordt een DF-toepassing op de kaart geselecteerd.  
TCS_35 Dit commando kan overal in de bestandsstructuur worden 
uitgevoerd (na het ATR of wanneer dan ook).  
TCS_36 Indien een toepassing wordt geselecteerd, wordt de huidige 
beveiligingsomgeving teruggesteld. Na het selecteren van 
de toepassing wordt geen actuele openbare sleutel meer 
geselecteerd. De EXT-AUT-G1-toegangsconditie is ook 
verloren gegaan. Indien het commando zonder beveiligde 
berichtenuitwisseling (SM) werd uitgevoerd, zijn de vorige 
SM-sessiesleutels niet langer beschikbaar.  
TCS_37  Commandobericht  
Byte  Lengte  Waarde  Omschrijving  
CLA  1  ‘00h’  
INS 1  ‘A4h’  
P1 1  ‘04h’  Selectie op naam (AID)  
P2 1  ‘0Ch’  Geen antwoord verwacht  
Lc 1  ‘NNh’  Aantal naar de kaart verzonden bytes (lengte van AID): 
‘06h’ voor de tachograaftoepassing  
#6-#(5+NN)  NN  ‘XX..XXh’  AID: ‘FF 54 41 43 48 4F’ voor de tachograaftoepassing 
van de eerste generatie 
AID: ‘FF 53 4D 52 44 54’ voor de tachograaftoepassing 
van de tweede generatie  
Een antwoord op het SELECT-commando is niet nodig (Le 
afwezig in T = 1, of geen antwoord gevraagd in T = 0).  
TCS_38  Antwoordbericht (geen antwoord gevraagd)  
Byte  Lengte  Waarde  Omschrijving  
SW 2  ‘XXXXh’  Statuswoorden (SW1, SW2)  
— Indien het commando succesvol is, zendt de kaart 
‘9000 ’ terug.  
— Indien de met de AID corresponderende toepassing niet 
wordt gevonden, wordt de verwerkingsstatus ‘ 6A82 ’ 
teruggezonden.  
— In T = 1, indien byte Le aanwezig is, wordt de status 
‘6700 ’ teruggezonden.  
— In T= 0, indien na het SELECT-commando een ant ­
woord wordt gevraagd, wordt de status ‘ 6900 ’ terug­
gezonden.  
▼M1 
— Indien de geselecteerde toepassing beschadigd is (inte ­
griteitsfout vastgesteld in de bestandsattributen), wordt 
de verwerkingsstatus ‘ 6400 ’ of ‘ 6500 ’ teruggezonden.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 200  
3.5.1.2 S e l e c t i e v a n e e n h o o f d b e s t a n d ( E F ) o p b a s i s v a n 
d e b e s t a n d s i d e n t i f i c a t o r  
TCS_39  Commandobericht  
TCS_40 Voor deze commandovariant ondersteunt een tachograaf ­
kaart beveiligde berichtenuitwisseling van de tweede gene ­
ratie, zoals gespecificeerd in aanhangsel 11, deel B.  
Byte  Lengte  Waarde  Omschrijving  
CLA  1  ‘00h’  
INS 1  ‘A4h’  
P1 1  ‘02h’  Selectie van EF in de geldige DF  
P2 1  ‘0Ch’  Geen antwoord verwacht  
Lc 1  ‘02h’  Aantal naar de kaart verzonden bytes  
#6-#7  2  ‘XXXXh’  Bestandsidentificator  
Een antwoord op het SELECT-commando is niet nodig (Le 
afwezig in T = 1, of geen antwoord gevraagd in T = 0).  
TCS_41  Antwoordbericht (geen antwoord gevraagd)  
Byte  Lengte  Waarde  Omschrijving  
SW 2  ‘XXXXh’  Statuswoorden (SW1, SW2)  
— Indien het commando succesvol is, zendt de kaart 
‘9000 ’ terug.  
— Indien het met de bestandsidentificator corresponde ­
rende bestand niet wordt gevonden, wordt de verwer ­
kingsstatus ‘ 6A82 ’ teruggezonden.  
— In T = 1, indien byte Le aanwezig is, wordt de status 
‘6700 ’ teruggezonden.  
— In T = 0, indien na het SELECT-commando een ant ­
woord wordt gevraagd, wordt de status ‘ 6900 ’ terug­
gezonden.  
▼M1 
— Indien het geselecteerde bestand beschadigd is (integri ­
teitsfout vastgesteld in de bestandsattributen), wordt de 
verwerkingsstatus ‘ 6400 ’ of ‘ 6500 ’ teruggezonden.  
▼B 
3.5.2  READ BINARY  
Dit commando voldoet aan ISO/IEC 7816-4, maar heeft een beperkt 
gebruik vergeleken met het in deze norm gedefinieerde commando.  
Het READ BINARY-commando wordt gebruikt om gegevens van een 
transparant bestand te lezen.  
Het antwoord van de kaart bestaat uit het terugzenden van de gelezen 
gegevens, facultatief ingekapseld in een structuur van beveiligde be ­
richtenuitwisseling.  
3.5.2.1 C o m m a n d o m e t o f f s e t i n P 1 - P 2  
Met dit commando kan de IFD gegevens in het thans geselecteerde 
hoofdbestand (EF) lezen zonder beveiligde berichtenuitwisseling.  
Opmerking:  dit commando zonder beveiligde berichtenuitwisseling 
kan alleen worden gebruikt voor het lezen van een bestand dat de 
ALW-beveiligingsvoorwaarde voor de toegangsmodus van de Read- 
functie ondersteunt.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 201  
TCS_42  Commandobericht  
Byte  Lengte  Waarde  Omschrijving  
CLA  1  ‘00h’  
INS 1  ‘B0h’  READ BINARY (Lees binair getal)  
P1 1  ‘XXh’  Offset in bytes vanaf het begin van het bestand: meest 
significante byte  
P2 1  ‘XXh’  Offset in bytes vanaf het begin van het bestand: minst 
significante byte  
Le 1  ‘XXh’  Lengte van verwachte gegevens. Aantal te lezen bytes  
Opmerking:  bit 8 van P1 moet op ‘0’ worden gezet.  
TCS_43  Antwoordbericht  
Byte  Lengte  Waarde  Omschrijving  
#1-#X  X  ‘XX..XXh’  Gelezen gegevens  
SW 2  ‘XXXXh’  Statuswoorden (SW1, SW2)  
— Indien het commando succesvol is, zendt de kaart 
‘9000 ’ terug.  
— Indien geen EF is geselecteerd, wordt de verwerkings ­
status ‘ 6986 ’ teruggezonden.  
— Indien niet wordt voldaan aan de beveiligingsvoorwaar ­
den van het geselecteerde bestand, wordt het com ­
mando onderbroken met ‘ 6982 ’. 
— Indien de offset niet compatibel is met de grootte van 
het hoofdbestand (offset > grootte EF), wordt de ver ­
werkingsstatus ‘ 6B00 ’ teruggezonden.  
— Indien de grootte van de te lezen gegevens niet com ­
patibel is met de grootte van het hoofdbestand (Offset + 
Le > grootte EF), wordt de verwerkingsstatus ‘ 6700 ’ of 
‘6Cxx ’ teruggezonden, waarbij ‘xx’ de exacte lengte 
aangeeft.  
▼M1 
— Indien binnen de bestandsattributen een integriteitsfout 
wordt ontdekt, moet de kaart het bestand als beschadigd 
en verloren beschouwen; de teruggezonden verwer ­
kingsstatus is ‘ 6400 ’ of ‘ 6500 ’. 
▼B 
— Indien in de opgeslagen gegevens een integriteitsfout 
wordt vastgesteld, zendt de kaart de gevraagde gege ­
vens terug en wordt de verwerkingsstatus ‘ 6281 ’ terug­
gezonden.  
3.5.2.1.1 C o m m a n d o m e t b e v e i l i g d e b e r i c h t e n u i t w i s s e l i n g 
( v o o r b e e l d e n )  
Met dit commando kan de IFD gegevens van het thans geselecteerde 
hoofdbestand (EF) met beveiligde berichtenuitwisseling lezen om de 
integriteit van de ontvangen gegevens te verifiëren en de vertrouwe ­
lijkheid van de gegevens te beschermen in het geval dat de beveili ­
gingsvoorwaarde SM-R-ENC-MAC-G1 (eerste generatie) of SM-R- 
ENC-MAC-G2 (tweede generatie) wordt toegepast.  
TCS_44  Commandobericht  
Byte  Lengte  Waarde  Omschrijving  
CLA  1  ‘0Ch’  Beveiligde berichtenuitwisseling gevraagd  
INS 1  ‘B0h’  READ BINARY (Lees binair getal)  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 202  
Byte  Lengte  Waarde  Omschrijving  
P1 1  ‘XXh’  P1 (offset in bytes vanaf het begin van het bestand): 
meest significante byte  
P2 1  ‘XXh’  P2 (offset in bytes vanaf het begin van het bestand): 
minst significante byte  
Lc 1  ‘XXh’  Lengte van invoergegevens voor beveiligde berichtenuit ­
wisseling  
#6 1  ‘97h’  T  LE : label voor verwachte lengtespecificatie  
#7 1  ‘01h’  L  LE : lengte van verwachte lengte  
#8 1  ‘NNh’  Verwachte lengtespecificatie (originele Le): aantal te le ­
zen bytes  
#9 1  ‘8Eh’  T  CC : label voor cryptografische controlesom  
#10 1  ‘XXh’  L  CC : lengte van volgende cryptografische controlesom 
‘04h’ voor beveiligde berichtenuitwisseling van de eerste 
generatie (zie aanhangsel 11, deel A) 
‘08h’, ‘0Ch’ of ‘10h’ afhankelijk van de AES-sleutel ­
lengte voor beveiligde berichtenuitwisseling van de 
tweede generatie (zie aanhangsel 11, deel B)  
#11-#(10+L)  L  ‘XX..XXh’  Cryptografische controlesom  
Le 1  ‘00h’  Zoals gespecificeerd in ISO/IEC 7816-4  
TCS_45  Antwoordbericht indien SM-R-ENC-MAC-G1 (eerste 
generatie) / SM-R-ENC-MAC-G2 (tweede generatie) 
niet vereist is en indien het invoerformaat van de bevei ­
ligde berichtenuitwisseling correct is:  
▼M1 
Byte  Lengte  Waarde  Omschrijving  
#1 1  ‘81h’  T  PV : label voor gegevens met ongecodeerde 
waarde  
#2 L  ‘NNh’ of 
‘81 NNh’  L PV : lengte van teruggezonden gegevens (= 
originele Le) 
L is 2 bytes indien L  PV >127 bytes  
#(2+L) - #(1+L+NN)  NN  ‘XX..XXh’  Ongecodeerde gegevenswaarde  
#(2+L+NN)  1  ‘99h’  Label voor verwerkingsstatus (SW1-SW2) 
— facultatief voor beveiligde berichtenuit ­
wisseling van de eerste generatie  
#(3+L+NN)  1  ‘02h’  Lengte van verwerkingsstatus — facultatief 
voor beveiligde berichtenuitwisseling van de 
eerste generatie  
#(4+L+NN) - #(5+L+NN)  2  ‘XX XXh’  Verwerkingsstatus van het onbeveiligde AP ­
DU-antwoord — facultatief voor beveiligde 
berichtenuitwisseling van de eerste generatie  
#(6+L+NN)  1  ‘8Eh’  TCC: label voor cryptografische controlesom  
#(7+L+NN)  1  ‘XXh’  LCC: lengte van volgende cryptografische 
controlesom 
‘04h’ voor beveiligde berichtenuitwisseling 
van de eerste generatie (zie aanhangsel 11, 
deel A) 
‘08h’, ‘0Ch’ of ‘10h’ afhankelijk van de 
AES-sleutellengte voor beveiligde berichte ­
nuitwisseling van de tweede generatie (zie 
aanhangsel 11, deel B)  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 203  
Byte  Lengte  Waarde  Omschrijving  
#(8+L+NN) - 
#(7+M+L+NN)  M ‘XX..XXh’  Cryptografische controlesom  
SW 2  ‘XXXXh’  Statuswoorden (SW1, SW2)  
▼B 
TCS_46  Antwoordbericht indien SM-R-ENC-MAC-G1 (eerste 
generatie) / SM-R-ENC-MAC-G2 (tweede generatie) 
vereist is en indien het invoerformaat van de beveiligde 
berichtenuitwisseling correct is:  
▼M1 
Byte  Lengte  Waarde  Omschrijving  
#1 1  ‘87h’  T  PI CG  : label voor gecodeerde gegevens 
(cryptogram)  
#2 L  ‘MMh’ of 
‘81 MMh’  L PI CG  : lengte van teruggezonden geco ­
deerde gegevens (afwijkend van de originele 
Le van het commando wegens padding) 
L is 2 bytes indien LPI CG > 127 bytes.  
#(2+L)-#(1+L+MM)  MM  ‘01XX..XXh’  Gecodeerde gegevens: paddingindicator en 
cryptogram  
#(2+L+MM)  1  ‘99h’  Label voor verwerkingsstatus (SW1-SW2) 
— facultatief voor beveiligde berichtenuit ­
wisseling van de eerste generatie  
#(3+L+MM)  1  ‘02h’  Lengte van verwerkingsstatus — facultatief 
voor beveiligde berichtenuitwisseling van de 
eerste generatie  
#(4+L+MM) - #(5+L+MM)  2  ‘XX XXh’  Verwerkingsstatus van het onbeveiligde AP ­
DU-antwoord — facultatief voor beveiligde 
berichtenuitwisseling van de eerste generatie  
#(6+L+MM)  1  ‘8Eh’  TCC: label voor cryptografische controlesom  
#(7+L+MM)  1  ‘XXh’  LCC: lengte van volgende cryptografische 
controlesom 
‘04h’ voor beveiligde berichtenuitwisseling 
van de eerste generatie (zie aanhangsel 11, 
deel A) 
‘08h’, ‘0Ch’ of ‘10h’ afhankelijk van de 
AES-sleutellengte voor beveiligde berichte ­
nuitwisseling van de tweede generatie (zie 
aanhangsel 11, deel B)  
#(8+L+MM)- 
#(7+N+L+MM)  N ‘XX..XXh’  Cryptografische controlesom  
SW 2  ‘XXXXh’  Statuswoorden (SW1, SW2)  
▼B 
Het READ BINARY-commando kan gewone verwerkings ­
statussen terugzenden die worden opgesomd in TCS_43 
onder de label ‘99h’ (zie beschrijving in TCS_59), met 
gebruikmaking van beveiligde antwoordberichtstructuren.  
Bovendien kunnen bepaalde fouten optreden die meer in 
het bijzonder verband houden met de beveiligde berichte ­
nuitwisseling. In dit geval wordt de verwerkingsstatus ge ­
woon teruggezonden zonder beveiligde berichtenuitwisse ­
lingsstructuur.  ▼M1
 02016R0799 — NL — 26.02.2020 — 002.001 — 204  
TCS_47  Antwoordbericht indien het invoerformaat van de be ­
veiligde berichtenuitwisseling niet correct is:  
Byte  Lengte  Waarde  Omschrijving  
SW 2  ‘XXXXh’  Statuswoorden (SW1, SW2)  
— Indien geen lopende sessiesleutel beschikbaar is, wordt 
de verwerkingsstatus ‘ 6A88 ’ teruggezonden. Dit is het 
geval wanneer de sessiesleutel nog niet werd gegene ­
reerd of wanneer de geldigheid van de sessiesleutel 
verlopen is (in dit geval moet de IFD opnieuw een 
wederzijdse authenticatie uitvoeren om een nieuwe ses ­
siesleutel te genereren).  
— Indien een aantal verwachte gegevensobjecten (zoals 
hierboven gespecificeerd) ontbreekt in het formaat van 
de beveiligde berichtenuitwisseling, wordt de verwer ­
kingsstatus ‘ 6987 ’ teruggezonden: deze fout treedt op 
wanneer een verwacht label ontbreekt of wanneer het 
commandoveld niet correct samengesteld is.  
— Indien een aantal gegevensobjecten niet correct is, 
wordt de verwerkingsstatus ‘ 6988 ’ teruggezonden: 
deze fout treedt op wanneer alle vereiste labels aan ­
wezig zijn, maar een aantal lengtes afwijkt van de ver ­
wachte lengtes.  
— Indien de verificatie van de cryptografische controlesom 
mislukt, wordt de verwerkingsstatus ‘ 6688 ’ teruggezon ­
den. 
3.5.2.2 C o m m a n d o m e t k o r t e E F ( E l e m e n t a r y F i l e ) - i d e n ­
t i f i c a t o r  
Met deze commandovariant kan de IFD een hoofdbestand (EF) selec ­
teren met behulp van een korte EF-identificator, en gegevens van deze 
EF lezen.  
TCS_48 Een tachograafkaart ondersteunt deze commandovariant 
voor alle hoofdbestanden met een specifieke korte EF-iden ­
tificator. Deze korte EF-identificatoren worden gespecifi ­
ceerd in hoofdstuk 4.  
TCS_49  Commandobericht  
Byte  Lengte  Waarde  Omschrijving  
CLA  1  ‘00h’  
INS 1  ‘B0h’  READ BINARY (Lees binair getal)  
P1 1  ‘XXh’  Bit 8 wordt op ‘1’ gezet 
Bits 7 en 6 worden op ‘00’ gezet 
Bits 5 t/m 1 coderen de korte EF-identificator van de 
corresponderende EF  
P2 1  ‘XXh’  Codeert een offset van 0 t/m 255 bytes in de EF waar ­
naar P1 verwijst  
Le 1  ‘XXh’  Lengte van verwachte gegevens. Aantal te lezen bytes  
Opmerking:  de korte EF-identificatoren die voor tacho ­
graaftoepassingen van de tweede generatie worden ge ­
bruikt, worden gespecificeerd in hoofdstuk 4.  
Indien P1 een korte EF-identificator codeert en het com ­
mando succesvol is, wordt het geïdentificeerde hoofd ­
bestand (EF) de thans geselecteerde (geldige) EF.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 205  
TCS_50  Antwoordbericht  
Byte  Lengte  Waarde  Omschrijving  
#1-#L  L  ‘XX..XXh’  Gelezen gegevens  
SW 2  ‘XXXXh’  Statuswoorden (SW1, SW2)  
— Indien het commando succesvol is, zendt de kaart 
‘9000 ’ terug.  
— Indien het met de korte EF-identificator corresponde ­
rende bestand niet wordt gevonden, wordt de verwer ­
kingsstatus ‘ 6A82 ’ teruggezonden.  
— Indien niet wordt voldaan aan de beveiligingsvoorwaar ­
den van het geselecteerde bestand, wordt het com ­
mando onderbroken met ‘ 6982 ’. 
— Indien de offset niet compatibel is met de grootte van 
het hoofdbestand (offset > grootte EF), wordt de ver ­
werkingsstatus ‘ 6B00 ’ teruggezonden.  
— Indien de grootte van de te lezen gegevens niet com ­
patibel is met de grootte van het hoofdbestand (Offset + 
Le > grootte EF), wordt de verwerkingsstatus ‘ 6700 ’ of 
‘6Cxx ’ teruggezonden, waarbij ‘xx’ de exacte lengte 
aangeeft.  
▼M1 
— Indien binnen de bestandsattributen een integriteitsfout 
wordt ontdekt, moet de kaart het bestand als beschadigd 
en verloren beschouwen; de teruggezonden verwer ­
kingsstatus is ‘ 6400 ’ of ‘ 6500 ’. 
▼B 
— Indien in de opgeslagen gegevens een integriteitsfout 
wordt vastgesteld, zendt de kaart de gevraagde gege ­
vens terug en wordt de verwerkingsstatus ‘ 6281 ’ terug­
gezonden.  
3.5.2.3 C o m m a n d o m e t o n e v e n i n s t r u c t i e b y t e  
Met deze commandovariant kan de IFD gegevens lezen van een 
hoofdbestand (EF) dat 32 768 bytes of meer bevat.  
TCS_51 Een tachograafkaart die ondersteuning biedt aan EF's met 
32 768 bytes of meer, ondersteunt deze commandovariant 
voor die EF's. Voor andere EF's, met uitzondering van de 
EF Sensor_Installation_Data, kan een tachograafkaart deze 
commandovariant al dan niet ondersteunen (zie TCS_156 
en TCS_160).  
TCS_52  Commandobericht  
Byte  Lengte  Waarde  Omschrijving  
CLA  1  ‘00h’  
INS 1  ‘B1h’  READ BINARY (Lees binair getal)  
P1 1  ‘00h’  Geldige EF  
P2 1  ‘00h’  
Lc 1  ‘NNh’  Lc lengte van offset-gegevensobject  
#6-#(5+NN)  NN  ‘XX..XXh’  Offset-gegevensobject: 
Label ‘54h’ 
Lengte ‘01h’ of ‘02h’ 
Waarde offset  
▼M1 
Le 1  ‘XXh’  Zoals gespecificeerd in ISO/IEC 7816-4  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 206  
De IFD codeert de lengte van het offset-gegevensobject 
met zo weinig mogelijk bytes, en gebruikt met andere 
woorden de lengtebyte ‘01h’ om een offset te coderen 
van 0 tot en met 255 bytes, en de lengtebyte ‘02h’ om 
een offset te coderen van 256 tot en met 65 535 bytes.  
▼M1 
Als T=0 gaat de kaart ervan uit dat waarde Le = ‘00h’ 
wanneer geen beveiligde berichtenuitwisseling wordt toege ­
past. 
Als T = 1 is de teruggezonden verwerkingsstatus ‘6700’ als 
Le=‘01h’.  
▼B 
TCS_53  Antwoordbericht  
Byte  Lengte  Waarde  Omschrijving  
#1-#L  L  ‘XX..XXh’  Gelezen gegevens, ingekapseld in een discretionair gege ­
vensobject met label ‘53h’.  
SW 2  ‘XXXXh’  Statuswoorden (SW1, SW2)  
— Indien het commando succesvol is, zendt de kaart 
‘9000 ’ terug.  
— Indien geen EF is geselecteerd, wordt de verwerkings ­
status ‘ 6986 ’ teruggezonden.  
— Indien niet wordt voldaan aan de beveiligingsvoorwaar ­
den van het geselecteerde bestand, wordt het com ­
mando onderbroken met ‘ 6982 ’. 
— Indien de offset niet compatibel is met de grootte van 
het hoofdbestand (offset > grootte EF), wordt de ver ­
werkingsstatus ‘ 6B00 ’ teruggezonden.  
— Indien de grootte van de te lezen gegevens niet com ­
patibel is met de grootte van het hoofdbestand (offset + 
Le > grootte EF), wordt de verwerkingsstatus ‘ 6700 ’ of 
‘6Cxx ’ teruggezonden, waarbij ‘xx’ de exacte lengte 
aangeeft.  
▼M1 
— Indien binnen de bestandsattributen een integriteitsfout 
wordt ontdekt, moet de kaart het bestand als beschadigd 
en verloren beschouwen; de teruggezonden verwer ­
kingsstatus is ‘ 6400 ’ of ‘ 6500 ’. 
▼B 
— Indien in de opgeslagen gegevens een integriteitsfout 
wordt vastgesteld, zendt de kaart de gevraagde gege ­
vens terug en wordt de verwerkingsstatus ‘ 6281 ’ terug­
gezonden.  
3.5.2.3.1 C o m m a n d o m e t b e v e i l i g d e b e r i c h t e n u i t w i s s e l i n g 
( v o o r b e e l d )  
Het volgende voorbeeld verduidelijkt het gebruik van beveiligde be ­
richtenuitwisseling indien de beveiligingsvoorwaarde SM-MAC-G2 
van toepassing is.  
TCS_54 Commandobericht  
Byte  Lengte  Waarde  Omschrijving  
CLA  1  ‘0Ch’  Beveiligde berichtenuitwisseling gevraagd  
INS 1  ‘B1h’  READ BINARY (Lees binair getal)  
P1 1  ‘00h’  Geldige EF  
P2 1  ‘00h’  
Lc 1  ‘XXh’  Lengte van het beveiligde gegevensveld  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 207  
Byte  Lengte  Waarde  Omschrijving  
#6 1  ‘B3h’  Label voor ongecodeerde waarde van met BER-TLV 
gecodeerde gegevens  
#7 1  ‘NNh’  L  PV : lengte van overgebrachte gegevens  
#(8)-#(7+NN)  NN  ‘XX..XXh’  Ongecodeerde waarde van met BER-TLV gecodeerde 
gegevens, d.w.z. het offset-gegevensobject met label ‘54’  
#(8+NN)  1  ‘97h’  T  LE : label voor verwachte lengtespecificatie  
#(9+NN)  1  ‘01h’  L  LE : lengte van verwachte lengtespecificatie  
#(10+NN)  1  ‘XXh’  Verwachte lengtespecificatie (originele Le): aantal te le ­
zen bytes  
#(11+NN)  1  ‘8Eh’  T  CC : label voor cryptografische controlesom  
#(12+NN)  1  ‘XXh’  L  CC : lengte van volgende cryptografische controlesom 
‘08h’, ‘0Ch’ of ‘10h’ afhankelijk van de AES-sleutel ­
lengte voor beveiligde berichtenuitwisseling van de 
tweede generatie (zie aanhangsel 11, deel B)  
#(13+NN)- 
#(12+M+NN)  M ‘XX..XXh’  Cryptografische controlesom  
Le 1  ‘00h’  Zoals gespecificeerd in ISO/IEC 7816-4  
TCS_55 Antwoordbericht indien het commando succesvol is  
Byte  Lengte  Waarde  Omschrijving  
#1 1  ‘B3h’  Ongecodeerde waarde van met BER-TLV gecodeerde 
gegevens  
#2 L  ‘NNh’ of 
‘81 NNh’  L PV : lengte van teruggezonden gegevens (= originele Le) 
L is 2 bytes indien L  PV >127 bytes  
#(2+L)- 
#(1+L+NN)  NN ‘XX..XXh’  Ongecodeerde waarde van met BER-TLV gecodeerde 
gegevens, d.w.z. gelezen gegevens, ingekapseld in een 
discretionair gegevensobject met label ‘53h’  
#(2+L+NN)  1  ‘99h’  Verwerkingsstatus van het onbeveiligde APDU-antwoord  
#(3+L+NN)  1  ‘02h’  Lengte van verwerkingsstatus  
#(4+L+NN) — 
#(5+L+NN)  2 ‘XX XXh’  Verwerkingsstatus van het onbeveiligde APDU-antwoord  
#(6+L+NN)  1  ‘8Eh’  T  CC : label voor cryptografische controlesom  
#(7+L+NN)  1  ‘XXh’  L  CC : lengte van volgende cryptografische controlesom 
‘08h’, ‘0Ch’ of ‘10h’ afhankelijk van de AES-sleutel ­
lengte voor beveiligde berichtenuitwisseling van de 
tweede generatie (zie aanhangsel 11, deel B)  
#(8+L+NN)- 
#(7+M+L+N ­
N) M ‘XX..XXh’  Cryptografische controlesom  
SW 2  ‘XXXXh’  Statuswoorden (SW1, SW2)  
3.5.3  UPDATE BINARY  
Dit commando voldoet aan ISO/IEC 7816-4, maar heeft een beperkt 
gebruik vergeleken met het in die norm gedefinieerde commando.  
Het UPDATE BINARY-commandobericht start het bijwerken (wissen 
+ schrijven) van de bits die al in een binair getal van een EF aanwezig 
zijn met de in het APDU-commando gegeven bits.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 208  
3.5.3.1 C o m m a n d o m e t o f f s e t i n P 1 - P 2  
Met dit commando kan de IFD gegevens schrijven in de thans gese ­
lecteerde EF, zonder dat de kaart de integriteit van de ontvangen 
gegevens verifieert.  
Opmerking:  dit commando zonder beveiligde berichtenuitwisseling 
kan alleen worden gebruikt voor het bijwerken van een bestand dat 
de ALW-beveiligingsvoorwaarde van de toegangsmodus van de Up ­
date-functie ondersteunt.  
TCS_56  Commandobericht  
Byte  Lengte  Waarde  Omschrijving  
CLA  1  ‘00h’  
INS 1  ‘D6h’  Update Binary (Werk binair getal bij)  
P1 1  ‘XXh’  Offset in bytes vanaf het begin van het bestand: meest 
significante byte  
P2 1  ‘XXh’  Offset in bytes vanaf het begin van het bestand: minst 
significante byte  
Lc 1  ‘NNh’  Lc lengte van bij te werken gegevens. Aantal te schrijven 
bytes  
#6-#(5+NN)  NN  ‘XX..XXh’  Te schrijven gegevens  
Opmerking:  bit 8 van P1 moet op ‘0’ worden gezet.  
TCS_57  Antwoordbericht  
Byte  Lengte  Waarde  Omschrijving  
SW 2  ‘XXXXh’  Statuswoorden (SW1, SW2)  
— Indien het commando succesvol is, zendt de kaart 
‘9000 ’ terug.  
— Indien geen EF is geselecteerd, wordt de verwerkings ­
status ‘ 6986 ’ teruggezonden.  
— Indien niet wordt voldaan aan de beveiligingsvoorwaar ­
den van het geselecteerde bestand, wordt het com ­
mando onderbroken met ‘ 6982 ’. 
— Indien de offset niet compatibel is met de grootte van 
het hoofdbestand (offset > grootte EF), wordt de ver ­
werkingsstatus ‘ 6B00 ’ teruggezonden.  
— Indien de grootte van de te schrijven gegevens niet 
compatibel is met de grootte van het hoofdbestand (off ­
set + Lc > grootte EF), wordt de verwerkingsstatus 
‘6700 ’ teruggezonden.  
— Indien in de bestandsattributen een integriteitsfout 
wordt vastgesteld, beschouwt de kaart het bestand als 
beschadigd en definitief verloren en wordt de verwer ­
kingsstatus ‘ 6400 ’ of ‘ 6500 ’ teruggezonden.  
— Indien het schrijven mislukt, wordt de verwerkingssta ­
tus ‘ 6581 ’ teruggezonden.  
3.5.3.1.1 C o m m a n d o m e t b e v e i l i g d e b e r i c h t e n u i t w i s s e l i n g 
( v o o r b e e l d e n )  
Met dit commando kan de IFD gegevens schrijven in de thans gese ­
lecteerde EF, waarbij de kaart de integriteit van de ontvangen gege ­
vens verifieert. Aangezien geen vertrouwelijkheid vereist is, worden 
de gegevens niet gecodeerd.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 209  
TCS_58  Commandobericht  
Byte  Lengte  Waarde  Omschrijving  
CLA  1  ‘0Ch’  Beveiligde berichtenuitwisseling gevraagd  
INS 1  ‘D6h’  Update Binary (Werk binair getal bij)  
P1 1  ‘XXh’  Offset in bytes vanaf het begin van het bestand: 
meest significante byte  
P2 1  ‘XXh’  Offset in bytes vanaf het begin van het bestand: 
minst significante byte  
Lc 1  ‘XXh’  Lengte van het beveiligde gegevensveld  
#6 1  ‘81h’  T  PV : label voor gegevens met ongecodeerde waarde  
#7 L  ‘NNh’ of 
‘81 NNh’  L PV : lengte van overgebrachte gegevens 
L is 2 bytes indien L  PV > 127 bytes  
#(7+L)- 
#(6+L+NN)  NN ‘XX..XXh’  Ongecodeerde gegevenswaarde (te schrijven gegevens)  
#(7+L+NN)  1  ‘8Eh’  T  CC : label voor cryptografische controlesom  
#(8+L+NN)  1  ‘XXh’  L  CC : lengte van volgende cryptografische controlesom 
‘04h’ voor beveiligde berichtenuitwisseling van de eerste 
generatie (zie deel A van aanhangsel 11) 
‘08h’, ‘0Ch’ of ‘10h’ afhankelijk van de AES-sleutel ­
lengte voor beveiligde berichtenuitwisseling van de 
tweede generatie (zie aanhangsel 11, deel B)  
#(9+L+NN)- 
#(8+M+L+N ­
N) M ‘XX..XXh’  Cryptografische controlesom  
Le 1  ‘00h’  Zoals gespecificeerd in ISO/IEC 7816-4  
TCS_59  Antwoordbericht indien het invoerformaat van de be ­
veiligde berichtenuitwisseling correct is  
Byte  Lengte  Waarde  Omschrijving  
#1 1  ‘99h’  T  SW : label voor statuswoorden (te beveiligen door CC)  
#2 1  ‘02h’  L  SW : lengte van teruggezonden statuswoorden  
#3-#4  2  ‘XXXXh’  Verwerkingsstatus van het onbeveiligde APDU-antwoord  
#5 1  ‘8Eh’  T  CC : label voor cryptografische controlesom (CC)  
#6 1  ‘XXh’  L  CC : lengte van volgende cryptografische controlesom 
(CC) 
‘04h’ voor beveiligde berichtenuitwisseling van de eerste 
generatie (zie aanhangsel 11, deel A) 
‘08h’, ‘0Ch’ of ‘10h’ afhankelijk van de AES-sleutel ­
lengte voor beveiligde berichtenuitwisseling van de 
tweede generatie (zie aanhangsel 11, deel B)  
#7-#(6+L)  L  ‘XX..XXh’  Cryptografische controlesom (CC)  
SW 2  ‘XXXXh’  Statuswoorden (SW1, SW2)  
De „gewone” verwerkingsstatussen voor het UPDATE BI ­
NARY-commando zonder beveiligde berichtenuitwisseling 
(zie beschrijving in punt 3.5.3.1) kunnen met gebruikma ­
king van de hierboven omschreven antwoordberichtstruc ­
tuur worden teruggezonden.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 210  
Bovendien kunnen bepaalde fouten optreden die meer in 
het bijzonder verband houden met de beveiligde berichte ­
nuitwisseling. In dit geval wordt de verwerkingsstatus ge ­
woon teruggezonden zonder beveiligde berichtenuitwisse ­
lingsstructuur.  
TCS_60  Antwoordbericht bij een fout in de beveiligde berichte ­
nuitwisseling  
Byte  Lengte  Waarde  Omschrijving  
SW 2  ‘XXXXh’  Statuswoorden (SW1, SW2)  
— Indien geen lopende sessiesleutel beschikbaar is, wordt 
de verwerkingsstatus ‘ 6A88 ’ teruggezonden.  
— Indien een aantal verwachte gegevensobjecten (zoals 
hierboven gespecificeerd) ontbreekt in het formaat van 
de beveiligde berichtenuitwisseling, wordt de verwer ­
kingsstatus ‘ 6987 ’ teruggezonden: deze fout treedt op 
wanneer een verwacht label ontbreekt of wanneer het 
commandoveld niet correct samengesteld is.  
— Indien een aantal gegevensobjecten niet correct is, 
wordt de verwerkingsstatus ‘ 6988 ’ teruggezonden: 
deze fout treedt op wanneer alle vereiste labels aan ­
wezig zijn, maar een aantal lengtes afwijkt van de ver ­
wachte lengtes.  
— Indien de verificatie van de cryptografische controlesom 
mislukt, wordt de verwerkingsstatus ‘ 6688 ’ teruggezon ­
den. 
3.5.3.2 C o m m a n d o m e t k o r t e E F - i d e n t i f i c a t o r  
Met deze commandovariant kan de IFD een hoofdbestand (EF) selec ­
teren met behulp van een korte EF-identificator, en gegevens van deze 
EF schrijven.  
TCS_61 Een tachograafkaart ondersteunt deze commandovariant 
voor alle hoofdbestanden met een specifieke korte EF-iden ­
tificator. Deze korte EF-identificatoren worden gespecifi ­
ceerd in hoofdstuk 4.  
TCS_62  Commandobericht  
Byte  Lengte  Waarde  Omschrijving  
CLA  1  ‘00h’  
INS 1  ‘D6h’  Update Binary (Werk binair getal bij)  
P1 1  ‘XXh’  Bit 8 wordt op ‘1’ gezet 
Bits 7 en 6 worden op ‘00’ gezet 
Bits 5 t/m 1 coderen de korte EF-identificator van de 
corresponderende EF  
P2 1  ‘XXh’  Codeert een offset van 0 t/m 255 bytes in de EF waar ­
naar P1 verwijst  
Lc 1  ‘NNh’  Lc lengte van bij te werken gegevens. Aantal te schrijven 
bytes  
#6-#(5+NN)  NN  ‘XX..XXh’  Te schrijven gegevens  
TCS_63  Antwoordbericht  
Byte  Lengte  Waarde  Omschrijving  
SW 2  ‘XXXXh’  Statuswoorden (SW1, SW2)  
Opmerking:  de korte EF-identificatoren die voor tacho ­
graaftoepassingen van de tweede generatie worden ge ­
bruikt, worden gespecificeerd in hoofdstuk 4.  
Indien P1 een korte EF-identificator codeert en het com ­
mando succesvol is, wordt het geïdentificeerde hoofd ­
bestand (EF) de thans geselecteerde (geldige) EF.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 211  
— Indien het commando succesvol is, zendt de kaart 
‘9000 ’ terug.  
— Indien het met de korte EF-identificator corresponde ­
rende bestand niet wordt gevonden, wordt de verwer ­
kingsstatus ‘ 6A82 ’ teruggezonden.  
— Indien niet wordt voldaan aan de beveiligingsvoorwaar ­
den van het geselecteerde bestand, wordt het com ­
mando onderbroken met ‘ 6982 ’. 
— Indien de offset niet compatibel is met de grootte van 
het hoofdbestand (offset > grootte EF), wordt de ver ­
werkingsstatus ‘ 6B00 ’ teruggezonden.  
— Indien de grootte van de te schrijven gegevens niet 
compatibel is met de grootte van het hoofdbestand (off ­
set + Lc > grootte EF), wordt de verwerkingsstatus 
‘6700 ’ teruggezonden.  
▼M1 
— Indien binnen de bestandsattributen een integriteitsfout 
wordt ontdekt, moet de kaart het bestand als beschadigd 
en verloren beschouwen; de teruggezonden verwer ­
kingsstatus is ‘ 6400 ’ of ‘ 6500 ’. 
▼B 
— Indien het schrijven mislukt, wordt de verwerkingssta ­
tus ‘ 6581 ’ teruggezonden.  
3.5.3.3 C o m m a n d o m e t o n e v e n i n s t r u c t i e b y t e  
Met deze commandovariant kan de IFD gegevens schrijven in een 
hoofdbestand (EF) dat 32 768 bytes of meer bevat.  
TCS_64 Een tachograafkaart die ondersteuning biedt aan EF's met 
32 768 bytes of meer, ondersteunt deze commandovariant 
voor die EF's. Een tachograafkaart kan deze commandova ­
riant al dan niet ondersteunen voor andere EF's.  
TCS_65  Commandobericht  
Byte  Lengte  Waarde  Omschrijving  
CLA  1  ‘00h’  
INS 1  ‘D7h’  Update Binary (Werk binair getal bij)  
P1 1  ‘00h’  Geldige EF  
P2 1  ‘00h’  
Lc 1  ‘NNh’  Lc Lengte van gegevens in het gegevensveld van het 
commando  
#6-#(5+NN)  NN  ‘XX..XXh’  Offset-gegevensobject met label ‘54h’ || Discretionair ge ­
gevensobject met label ‘53h’, waarin de te schrijven ge ­
gevens zijn ingekapseld  
De IFD codeert de lengte van het offset-gegevensobject en 
het discretionair gegevensobject met zo weinig mogelijk 
bytes, en gebruikt met andere woorden de lengtebyte ‘01h’ 
om een offset/lengte te coderen van 0 tot en met 255 bytes, 
en de lengtebyte ‘02h’ om een offset/lengte te coderen van 
256 tot en met 65 535 bytes.  
TCS_66  Antwoordbericht  
Byte  Lengte  Waarde  Omschrijving  
SW 2  ‘XXXXh’  Statuswoorden (SW1, SW2)  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 212  
— Indien het commando succesvol is, zendt de kaart 
‘9000 ’ terug.  
— Indien geen EF is geselecteerd, wordt de verwerkings ­
status ‘ 6986 ’ teruggezonden.  
— Indien niet wordt voldaan aan de beveiligingsvoorwaar ­
den van het geselecteerde bestand, wordt het com ­
mando onderbroken met ‘ 6982 ’. 
— Indien de offset niet compatibel is met de grootte van 
het hoofdbestand (offset > grootte EF), wordt de ver ­
werkingsstatus ‘ 6B00 ’ teruggezonden.  
— Indien de grootte van de te schrijven gegevens niet 
compatibel is met de grootte van het hoofdbestand (off ­
set + Lc > grootte EF), wordt de verwerkingsstatus 
‘6700 ’ teruggezonden.  
— Indien in de bestandsattributen een integriteitsfout 
wordt vastgesteld, beschouwt de kaart het bestand als 
beschadigd en definitief verloren en wordt de verwer ­
kingsstatus ‘ 6400 ’ of ‘ 6500 ’ teruggezonden.  
— Indien het schrijven mislukt, wordt de verwerkingssta ­
tus ‘ 6581 ’ teruggezonden.  
3.5.3.3.1 C o m m a n d o m e t b e v e i l i g d e b e r i c h t e n u i t w i s s e l i n g 
( v o o r b e e l d )  
Het volgende voorbeeld verduidelijkt het gebruik van beveiligde be ­
richtenuitwisseling indien de beveiligingsvoorwaarde SM-MAC-G2 
van toepassing is.  
TCS_67 Commandobericht  
Byte  Lengte  Waarde  Omschrijving  
CLA  1  ‘0Ch’  Beveiligde berichtenuitwisseling gevraagd  
INS 1  ‘D7h’  Update Binary (Werk binair getal bij)  
P1 1  ‘00h’  Geldige EF  
P2 1  ‘00h’  
Lc 1  ‘XXh’  Lengte van het beveiligde gegevensveld  
#6 1  ‘B3h’  Label voor ongecodeerde waarde van met BER-TLV 
gecodeerde gegevens  
#7 L  ‘NNh’ of 
‘81 NNh’  L PV : lengte van overgebrachte gegevens 
L is 2 bytes indien L  PV > 127 bytes  
#(7+L)- 
#(6+L+NN)  NN ‘XX..XXh’  Ongecodeerde waarde van met BER-TLV gecodeerde 
gegevens, d.w.z. offset-gegevensobject met label ‘54h’ 
|| Discretionair gegevensobject met label ‘53h’, waarin 
de te schrijven gegevens zijn ingekapseld  
#(7+L+NN)  1  ‘8Eh’  T  CC : label voor cryptografische controlesom  
#(8+L+NN)  1  ‘XXh’  L  CC : lengte van volgende cryptografische controlesom 
‘08h’, ‘0Ch’ of ‘10h’ afhankelijk van de AES-sleutel ­
lengte voor beveiligde berichtenuitwisseling van de 
tweede generatie (zie aanhangsel 11, deel B)  
#(9+L+NN)- 
#(8+M+L+N ­
N) M ‘XX..XXh’  Cryptografische controlesom  
Le 1  ‘00h’  Zoals gespecificeerd in ISO/IEC 7816-4  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 213  
TCS_68 Antwoordbericht indien het commando succesvol is  
Byte  Lengte  Waarde  Omschrijving  
#1 1  ‘99h’  T  SW : label voor statuswoorden (te beveiligen door CC)  
#2 1  ‘02h’  L  SW : lengte van teruggezonden statuswoorden  
#3-#4  2  ‘XXXXh’  Verwerkingsstatus van het onbeveiligde APDU-antwoord  
#5 1  ‘8Eh’  T  CC : label voor cryptografische controlesom  
#6 1  ‘XXh’  L  CC : lengte van volgende cryptografische controlesom 
‘08h’, ‘0Ch’ of ‘10h’ afhankelijk van de AES-sleutel ­
lengte voor beveiligde berichtenuitwisseling van de 
tweede generatie (zie aanhangsel 11, deel B)  
#7-#(6+L)  L  ‘XX..XXh’  Cryptografische controlesom  
SW 2  ‘XXXXh’  Statuswoorden (SW1, SW2)  
3.5.4  GET CHALLENGE  
Dit commando voldoet aan ISO/IEC 7816-4, maar heeft een beperkt 
gebruik vergeleken met het in die norm gedefinieerde commando.  
Via het GET CHALLENGE-commando wordt de kaart gevraagd een 
identiteit af te geven voor gebruik in een beveiligingsprocedure waar ­
bij een cryptogram of een aantal gecodeerde gegevens naar de kaart 
wordt verzonden.  
TCS_69 De door de kaart afgegeven identiteit geldt alleen voor het 
volgende naar de kaart verzonden commando dat een iden ­
titeit gebruikt.  
TCS_70  Commandobericht  
Byte  Lengte  Waarde  Omschrijving  
CLA  1  ‘00h’  
INS 1  ‘84h’  INS  
P1 1  ‘00h’  P1  
P2 1  ‘00h’  P2  
Le 1  ‘08h’  Le (lengte van de verwachte identiteit)  
TCS_71  Antwoordbericht  
Byte  Lengte  Waarde  Omschrijving  
#1-#8  8  ‘XX..XXh’  Identiteit  
SW 2  ‘XXXXh’  Statuswoorden (SW1, SW2)  
— Indien het commando succesvol is, zendt de kaart 
‘9000 ’ terug.  
— Indien Le verschilt van ‘08h’, is de verwerkingsstatus 
‘6700 ’. 
— Indien de parameters P1-P2 niet correct zijn, is de ver ­
werkingsstatus ‘ 6A86 ’. ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 214  
3.5.5  VERIFY  
Dit commando voldoet aan ISO/IEC 7816-4, maar heeft een beperkt 
gebruik vergeleken met het in die norm gedefinieerde commando.  
Alleen de werkplaatskaart is vereist om dit commando te ondersteu ­
nen. 
Op andere soorten tachograafkaarten kan dit commando al dan niet 
worden geïmplementeerd. Voor deze kaarten wordt echter geen refe ­
rentie-CHV gepersonaliseerd. Bijgevolg kunnen deze kaarten dit com ­
mando niet met succes uitvoeren. Indien dit commando wordt ver ­
zonden voor andere tachograafkaarten dan werkplaatskaarten, valt de 
werking — dat wil zeggen de teruggezonden foutcode — buiten het 
toepassingsgebied van deze specificatie.  
Het VERIFY-commando start de vergelijking in de kaart van de door 
het commando verzonden CHV-gegevens (pincode) met de op de 
kaart opgeslagen referentie-CHV.  
▼M1 
TCS_72 De door de gebruiker ingevoerde pincode moet in ASCII 
gecodeerd zijn en rechts door de IFD worden opgevuld met 
„FFh”-bytes tot een lengte van 8 bytes (zie ook het gege ­
venstype WorkshopCardPIN in aanhangsel 1).  
▼B 
TCS_73 Tachograaftoepassingen van de eerste en de tweede gene ­
ratie gebruiken dezelfde referentie-CHV.  
TCS_74 De tachograafkaart controleert of het commando juist geco ­
deerd is. Indien het commando niet juist gecodeerd is, 
beëindigt de kaart het commando zonder de CHV-waarden 
te vergelijken, zonder de teller voor resterende CHV-pogin ­
gen te verlagen en zonder de beveiligingsstatus „PIN_Ve ­
rified” terug te stellen. Een commando geldt als juist geco ­
deerd indien de bytes CLA, INS, P1, P2 en Lc de voor ­
geschreven waarden bevatten, indien Le afwezig is en in ­
dien het gegevensveld van het commando de juiste lengte 
heeft.  
TCS_75 Indien het commando succesvol is, wordt de teller voor 
resterende CHV-pogingen opnieuw geïnitialiseerd. De be ­
ginwaarde van de teller voor resterende CHV-pogingen is 
5. Indien het commando succesvol is, stelt de kaart de 
interne beveiligingsstatus in op „PIN_Verified”. De kaart 
stelt deze beveiligingsstatus terug indien de kaart wordt 
teruggesteld of indien de in het commando overgebrachte 
CHV-code niet overeenstemt met de opgeslagen referentie- 
CHV.  
Opmerking:  door gebruik te maken van dezelfde referentie- 
CHV en van een algemene beveiligingsstatus, wordt ver ­
meden dat de werkplaatsmedewerker de pincode opnieuw 
moet invoeren na het selecteren van een andere DF van de 
tachograaftoepassing.  
TCS_76 Een niet-succesvolle vergelijking wordt op de kaart gere ­
gistreerd door de teller voor resterende CHV-pogingen met 
1 te verlagen ter beperking van het aantal latere pogingen 
om de referentie-CHV te gebruiken.  
TCS_77  Commandobericht  
Byte  Lengte  Waarde  Omschrijving  
CLA  1  ‘00h’  
INS 1  ‘20h’  INS  
P1 1  ‘00h’  P1  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 215  
Byte  Lengte  Waarde  Omschrijving  
P2 1  ‘00h’  P2 (de geverifieerde CHV is impliciet bekend)  
Lc 1  ‘08h’  Lengte van de overgebrachte CHV-code  
#6-#13  8  ‘XX..XXh’  CHV  
TCS_78  Antwoordbericht  
Byte  Lengte  Waarde  Omschrijving  
SW 2  ‘XXXXh’  Statuswoorden (SW1, SW2)  
— Indien het commando succesvol is, zendt de kaart 
‘9000 ’ terug.  
— Indien de referentie-CHV niet wordt gevonden, wordt 
de verwerkingsstatus ‘ 6A88 ’ teruggezonden.  
— Indien de CHV geblokkeerd is (de teller voor resterende 
CHV-pogingen staat op nul), wordt de verwerkingssta ­
tus ‘6983 ’ teruggezonden. Zodra die status actief is, kan 
de CHV niet meer met succes worden aangeboden.  
— Indien de vergelijking niet succesvol is, wordt de teller 
voor resterende pogingen verlaagd en wordt de status 
‘63CX ’ teruggezonden (waarbij ‘X’ groter is dan nul en 
gelijk aan de teller voor resterende CHV-pogingen).  
— Indien de referentie-CHV beschadigd is, wordt de ver ­
werkingsstatus ‘ 6400 ’ of ‘ 6581 ’ teruggezonden.  
— Indien Lc verschilt van ‘08h’, is de verwerkingsstatus 
‘6700 ’. 
3.5.6  GET RESPONSE  
Dit commando voldoet aan ISO/IEC 7816-4.  
Dit commando is alleen nodig en beschikbaar voor het protocol T = 0. 
Met dit commando worden de voorbereide gegevens van de kaart 
overgebracht naar de interface-inrichting (IFD) voor zover zowel Lc 
als Le in het commando was opgenomen.  
Het GET RESPONSE-commando moet worden gegeven onmiddellijk 
na het commando om de gegevens voor te bereiden. Zo niet, gaan de 
gegevens verloren. Na de uitvoering van het GET RESPONSE-com ­
mando (tenzij de fout ‘ 61xx ’ of ‘ 6Cxx ’ optreedt, zie hieronder) zijn 
de eerder voorbereide gegevens niet langer beschikbaar.  
TCS_79  Commandobericht  
Byte  Lengte  Waarde  Omschrijving  
CLA  1  ‘00h’  
INS 1  ‘C0h’  
P1 1  ‘00h’  
P2 1  ‘00h’  
Le 1  ‘XXh’  Aantal verwachte bytes  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 216  
TCS_80  Antwoordbericht  
Byte  Lengte  Waarde  Omschrijving  
#1-#X  X  ‘XX..XXh’  Gegevens  
SW 2  ‘XXXXh’  Statuswoorden (SW1, SW2)  
— Indien het commando succesvol is, zendt de kaart 
‘9000 ’ terug.  
— Indien de kaart geen gegevens heeft voorbereid, wordt 
de verwerkingsstatus ‘ 6900 ’ of ‘ 6F00 ’ teruggezonden.  
— Indien Le het aantal beschikbare bytes overschrijdt of 
gelijk is aan nul, wordt de verwerkingsstatus ‘ 6Cxx ’ 
teruggezonden, waarbij ‘xx’ het exacte aantal beschik ­
bare bytes aangeeft. In dit geval zijn de voorbereide 
gegevens nog beschikbaar voor een volgend GET RES ­
PONSE-commando.  
— Indien Le verschilt van nul en kleiner is dan het aantal 
beschikbare bytes, worden de vereiste gegevens ge ­
woon door de kaart verzonden en wordt de verwer ­
kingsstatus ‘ 61xx ’ teruggezonden, waarbij ‘xx’ een aan ­
tal extra bytes aangeeft dat nog beschikbaar is voor een 
volgend GET RESPONSE-commando.  
— Indien het commando niet wordt ondersteund (protocol 
T = 1), zendt de kaart ‘ 6D00 ’ terug.  
3.5.7  PSO: VERIFY CERTIFICATE  
Dit commando voldoet aan ISO/IEC 7816-8, maar heeft een beperkt 
gebruik vergeleken met het in deze norm gedefinieerde commando.  
De kaart gebruikt het VERIFY CERTIFICATE-commando om een 
externe openbare sleutel te verkrijgen en de geldigheid ervan te con ­
troleren.  
3.5.7.1 C o m m a n d o - a n t w o o r d p a a r v o o r d e e e r s t e g e n e r a t i e  
TCS_81 Deze commandovariant wordt alleen ondersteund door ta ­
chograaftoepassingen van de eerste generatie.  
TCS_82 Wanneer een VERIFY CERTIFICATE-commando succes ­
vol is, wordt de openbare sleutel in de beveiligingsomge ­
ving opgeslagen voor toekomstig gebruik. Deze sleutel 
wordt expliciet ingesteld voor gebruik in beveiligingsgere ­
lateerde commando's (INTERNAL AUTHENTICATE, EX ­
TERNAL AUTHENTICATE of VERIFY CERTIFICATE) 
door het MSE-commando (zie punt 3.5.11) met behulp van 
de bijbehorende sleutelidentificator.  
TCS_83 Het VERIFY CERTIFICATE-commando gebruikt hoe dan 
ook de openbare sleutel die het MSE-commando eerder 
heeft geselecteerd om het certificaat te openen. Deze open ­
bare sleutel moet die van een lidstaat of van Europa zijn.  
TCS_84  Commandobericht  
Byte  Lengte  Waarde  Omschrijving  
CLA  1  ‘00h’  
INS 1  ‘2Ah’  Voer beveiligingsoperatie uit (PSO)  
P1 1  ‘00h’  P1  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 217  
Byte  Lengte  Waarde  Omschrijving  
P2 1  ‘AEh’  P2: niet met BER-TLV gecodeerde gegevens (samenvoe ­
ging van gegevenselementen)  
Lc 1  ‘C2h’  Lc: lengte van het certificaat, 194 bytes  
#6-#199  194  ‘XX..XXh’  Certificaat: samenvoeging van gegevenselementen (zoals 
omschreven in aanhangsel 11)  
TCS_85  Antwoordbericht  
Byte  Lengte  Waarde  Omschrijving  
SW 2  ‘XXXXh’  Statuswoorden (SW1, SW2)  
— Indien het commando succesvol is, zendt de kaart 
‘9000 ’ terug.  
— Indien de certificaatverificatie mislukt, wordt de ver ­
werkingsstatus ‘ 6688 ’ teruggezonden. De procedure 
voor certificaatverificatie en openmaken van het certifi ­
caat wordt nader omschreven in aanhangsel 11 voor 
tachograaftoepassingen van de eerste en de tweede ge ­
neratie.  
— Indien geen openbare sleutel in de beveiligingsomge ­
ving aanwezig is, wordt ‘ 6A88 ’ teruggezonden.  
— Indien de geselecteerde openbare sleutel (waarmee het 
certificaat wordt opengemaakt) beschadigd is, wordt de 
verwerkingsstatus ‘ 6400 ’ of ‘ 6581 ’ teruggezonden.  
— Alleen voor tachograaftoepassingen van de eerste gene ­
ratie: Indien de geselecteerde openbare sleutel (waarmee 
het certificaat wordt opengemaakt) een andere 
CHA.LSB 
(
 ) 
heeft dan ‘00’ (dat wil zeggen niet die van een lidstaat 
of van Europa is), wordt de verwerkingsstatus ‘ 6985 ’ 
teruggezonden.  
3.5.7.2 C o m m a n d o - a n t w o o r d p a a r v o o r t a c h o g r a a f t o e p a s ­
s i n g e n v a n d e t w e e d e g e n e r a t i e  
In verband met de grootte van de elliptische kromme kunnen ECC- 
certificaten zo lang zijn dat het niet mogelijk is om ze in een enkele 
APDU te verzenden. In dit geval moeten de commando's aan elkaar 
worden gekoppeld (“geketend”) overeenkomstig ISO/IEC 7816-4, en 
wordt het certificaat verzonden in twee opeenvolgende APDU-com ­
mando's PSO: Verify Certificate.  
De certificaatstructuur en domeinparameters zijn gedefinieerd in aan ­
hangsel 11.  
TCS_86 Het commando kan worden uitgevoerd in MF, DF Tacho ­
graaf en DF Tachograaf_G2 (zie ook TCS_33).  
TCS_87  Commandobericht  
Byte  Lengte  Waarde  Omschrijving  
CLA  1  ‘X0h’  CLA-byte die aangeeft dat de commando's worden ge ­
ketend 
‘00h’ het enige of laatste commando van de keten 
‘10h’ niet het laatste commando van de keten  
INS 1  ‘2Ah’  Voer beveiligingsoperatie uit (PSO)  
P1 1  ‘00h’  
P2 1  ‘BEh’  Verifieer zelfbeschrijvend certificaat  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 218  
Byte  Lengte  Waarde  Omschrijving  
Lc 1  ‘XXh’  Lengte van het gegevensveld van het commando (zie 
TCS_88 en TCS_89).  
#6-#5+L  L  ‘XX..XXh’  Met DER-TLV gecodeerde gegevens: inhoud van het 
ECC-certificaat als eerste gegevensobject samengevoegd 
met de handtekening van het ECC-certificaat als tweede 
gegevensobject of met een deel van deze samenvoeging. 
Het label ‘7F21’ en de bijbehorende lengte worden niet 
verzonden. 
Deze gegevensobjecten hebben een vastgelegde volg ­
orde.  
TCS_88 Voor APDU's met korte lengte geldt het volgende: de IFD 
gebruikt het minimaal vereiste aantal APDU's om de pay ­
loadgegevens van het commando over te brengen en om 
het maximumaantal bytes in het eerste APDU-commando te 
verzenden volgens de waarde van de byte voor de grootte 
van het informatieveld (IFS), zie TCS_14. Indien de IFD 
anders reageert, valt de werking van de kaart buiten het 
toepassingsgebied van deze specificatie.  
TCS_89 Voor APDU's met uitgebreide lengte geldt het volgende: 
indien het certificaat niet in een enkele APDU past, onder ­
steunt de kaart het ketenen van commando's. De IFD ge ­
bruikt het minimaal vereiste aantal APDU's om de paylo ­
adgegevens van het commando over te brengen en om het 
maximumaantal bytes in het eerste APDU-commando te 
verzenden. Indien de IFD anders reageert, valt de werking 
van de kaart buiten het toepassingsgebied van deze speci ­
ficatie.  
Opmerking:  overeenkomstig aanhangsel 11 slaat de kaart 
het certificaat of de toepasselijke inhoud daarvan op, en 
werkt de kaart de currentAuthenticatedTime bij.  
De antwoordberichtstructuur en statuswoorden zijn vast ­
gelegd in TCS_85.  
TCS_90 Naast de in TCS_85 opgesomde foutcodes kan de kaart de 
volgende foutcodes terugzenden:  
— Indien de geselecteerde openbare sleutel (waarmee het 
certificaat wordt opengemaakt) een CHA.LSB (Certifi ­
cateHolderAuthorisation.equipmentType) heeft die niet 
geschikt is voor certificaatverificatie overeenkomstig 
aanhangsel 11, wordt de verwerkingsstatus ‘ 6985 ’ te­
ruggezonden.  
— Indien de currentAuthenticatedTime van de kaart valt 
na de datum waarop de geldigheid van het certificaat 
afloopt, wordt de verwerkingsstatus ‘ 6985 ’ teruggezon ­
den. 
— Indien het laatste commando van de keten wordt ver ­
wacht, zendt de kaart ‘ 6883 ’ terug.  
— Indien onjuiste parameters worden verzonden in het 
gegevensveld van het commando, zendt de kaart 
‘6A80 ’ terug (dat is ook het geval indien de gegevens ­
objecten niet in de voorgeschreven volgorde worden 
verzonden).  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 219  
3.5.8  INTERNAL AUTHENTICATE  
Dit commando voldoet aan ISO/IEC 7816-4.  
TCS_91 Alle tachograafkaarten ondersteunen dit commando in DF 
Tachograaf G1. Dit commando kan al dan niet toegankelijk 
zijn in MF en/of in DF Tachograaf_G2. Als dat het geval 
is, wordt het commando beëindigd met de toepasselijke 
foutcode aangezien de particuliere sleutel van de kaart 
(Card.SK) voor het authenticatieprotocol van de eerste ge ­
neratie alleen toegankelijk is in DF_Tachograaf van de 
eerste generatie.  
Met het INTERNAL AUTHENTICATE-commando kan de 
IFD de kaart authenticeren. De authenticatieprocedure 
wordt uiteengezet in aanhangsel 11. Hierbij worden de on ­
derstaande instructies toegepast.  
TCS_92 Het INTERNAL AUTHENTICATE-commando gebruikt de 
(impliciet geselecteerde) particuliere sleutel van de kaart ter 
ondertekening van de authenticatiegegevens met inbegrip 
van K1 (eerste element voor sleutelovereenstemming tij ­
dens de sessie) en RND1, en gebruikt de thans geselec ­
teerde openbare sleutel (via het laatste MSE-commando) 
om de handtekening te coderen en het authenticatieteken 
te genereren (zie aanhangsel 11 voor meer informatie).  
TCS_93  Commandobericht  
Byte  Lengte  Waarde  Omschrijving  
CLA  1  ‘00h’  CLA  
INS 1  ‘88h’  INS  
P1 1  ‘00h’  P1  
P2 1  ‘00h’  P2  
Lc 1  ‘10h’  Lengte van naar de kaart verzonden gegevens  
#6 — #13  8  ‘XX..XXh’  Identiteit gebruikt om de kaart te authenticeren  
#14 -#21  8  ‘XX..XXh’  VU.CHR (zie aanhangsel 11)  
Le 1  ‘80h’  Lengte van de gegevens die van de kaart worden ver ­
wacht  
TCS_94  Antwoordbericht  
Byte  Lengte  Waarde  Omschrijving  
#1-#128  128  ‘XX..XXh’  Kaartauthenticatieteken (zie aanhangsel 11)  
SW 2  ‘XXXXh’  Statuswoorden (SW1, SW2)  
— Indien het commando succesvol is, zendt de kaart 
‘9000 ’ terug.  
— Indien geen openbare sleutel in de beveiligingsomge ­
ving aanwezig is, wordt de verwerkingsstatus ‘ 6A88 ’ 
teruggezonden.  
— Indien geen particuliere sleutel in de beveiligingsomge ­
ving aanwezig is, wordt de verwerkingsstatus ‘ 6A88 ’ 
teruggezonden.  
— Indien VU.CHR niet overeenstemt met de identificator 
van de huidige openbare sleutel, wordt de verwerkings ­
status ‘ 6A88 ’ teruggezonden.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 220  
— Indien de geselecteerde particuliere sleutel beschadigd 
is, wordt de verwerkingsstatus ‘ 6400 ’ of ‘ 6581 ’ terug­
gezonden.  
▼M1 
TCS_95 Indien het INTERNAL AUTHENTICATE-commando suc ­
cesvol is, wordt de lopende sessiesleutel van de eerste ge ­
neratie (indien aanwezig) gewist en is die niet langer be ­
schikbaar. Om een nieuwe sessiesleutel van de eerste ge ­
neratie te krijgen, moet het EXTERNAL AUTHENTICA ­
TE-commando succesvol worden uitgevoerd voor het au ­
thenticatiemechanisme van de eerste generatie.  
Opmerking:  Voor sessiesleutels van de tweede generatie, 
zie aanhangsel 11, punten CSM_193 en CSM_195. Wan ­
neer sessiesleutels van de tweede generatie zijn vastgesteld 
en de tachograafkaart het ondubbelzinnige commando IN ­
TERNAL AUTHENTICATE APDU ontvangt, wordt de 
sessie voor beveiligde berichtenuitwisseling van de tweede 
generatie afgebroken en worden de sessiesleutels van gene ­
ratie 2 vernietigd.  
▼B 
3.5.9  EXTERNAL AUTHENTICATE  
Dit commando voldoet aan ISO/IEC 7816-4.  
Met het EXTERNAL AUTHENTICATE-commando kan de kaart de 
IFD authenticeren. De authenticatieprocedure wordt uiteengezet in 
aanhangsel 11 voor tachograaftoepassingen van de eerste en de 
tweede generatie (VU-authenticatie).  
TCS_96 Wat betreft het mechanisme voor wederzijdse authenticatie 
van de eerste generatie wordt deze commandovariant uit ­
sluitend ondersteund door tachograaftoepassingen van de 
eerste generatie.  
▼M1 
TCS_97 De commandovariant voor de wederzijdse authenticatie van 
VU-kaarten van de tweede generatie kan worden uitge ­
voerd in MF, DF Tachograaf en DF Tachograaf_G2 (zie 
ook TCS_34). Indien dit EXTERNAL AUTHENTICATE- 
commando van de tweede generatie succesvol is, wordt de 
lopende sessiesleutel van de eerste generatie (indien aan ­
wezig) gewist en is die niet langer beschikbaar.  
Opmerking:  Voor sessiesleutels van de tweede generatie, 
zie aanhangsel 11, punten CSM_193 en CSM_195. Wan ­
neer sessiesleutels van de tweede generatie zijn vastgesteld 
en de tachograafkaart het ondubbelzinnige commando EX ­
TERNAL AUTHENTICATE APDU ontvangt, wordt de 
sessie voor beveiligde berichtenuitwisseling van de tweede 
generatie afgebroken en worden de sessiesleutels van de 
tweede generatie vernietigd.  
▼B 
TCS_98  Commandobericht  
Byte  Lengte  Waarde  Omschrijving  
CLA  1  ‘00h’  CLA  
INS 1  ‘82h’  INS  
P1 1  ‘00h’  Sleutels en algoritmen impliciet bekend  
P2 1  ‘00h’  
Lc 1  ‘XXh’  Lc: lengte van de naar de kaart verzonden gegevens  
#6-#(5+L)  L  ‘XX..XXh’  Authenticatie van de eerste generatie: cryptogram (zie 
aanhangsel 11, deel A) 
Authenticatie van de tweede generatie: handtekening ge ­
genereerd door de IFD (zie aanhangsel 11, deel B)  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 221  
TCS_99  Antwoordbericht  
Byte  Lengte  Waarde  Omschrijving  
SW 2  ‘XXXXh’  Statuswoorden (SW1, SW2)  
— Indien het commando succesvol is, zendt de kaart 
‘9000 ’ terug.  
— Indien de CHA van de thans ingestelde openbare sleutel 
niet de samenvoeging is van de AID van de tachograaf ­
toepassing en van een model van VU-apparatuur, wordt 
de verwerkingsstatus ‘ 6F00 ’ teruggezonden.  
— Indien het commando niet onmiddellijk wordt voorafge ­
gaan door een GET CHALLENGE-commando, wordt 
de verwerkingsstatus ‘ 6985 ’teruggezonden.  
De tachograaftoepassing van de eerste generatie kan de 
volgende aanvullende foutcodes terugzenden:  
— Indien geen openbare sleutel in de beveiligingsomge ­
ving aanwezig is, wordt ‘ 6A88 ’ teruggezonden.  
— Indien geen particuliere sleutel in de beveiligingsomge ­
ving aanwezig is, wordt de verwerkingsstatus ‘ 6A88 ’ 
teruggezonden.  
— Indien de verificatie van het cryptogram mislukt, wordt 
de verwerkingsstatus ‘ 6688 ’ teruggezonden.  
— Indien de geselecteerde particuliere sleutel beschadigd 
is, wordt de verwerkingsstatus ‘ 6400 ’ of ‘ 6581 ’ terug­
gezonden.  
De commandovariant voor authenticatie van de tweede ge ­
neratie kan de volgende aanvullende foutcode terugzenden:  
— Indien de handtekeningverificatie mislukt is, zendt de 
kaart ‘ 6300 ’ terug.  
3.5.10  GENERAL AUTHENTICATE  
Dit commando wordt gebruikt voor het chipauthenticatieprotocol van 
de tweede generatie, zoals gespecificeerd in deel B van aanhangsel 11, 
en voldoet aan ISO/IEC 7816-4.  
TCS_100 Het commando kan worden uitgevoerd in MF, DF Tacho ­
graaf en DF Tachograaf_G2 (zie ook TCS_34).  
TCS_101  Commandobericht  
Byte  Lengte  Waarde  Omschrijving  
CLA  1  ‘00h’  
INS 1  ‘86h’  
P1 1  ‘00h’  Sleutels en protocol impliciet bekend  
P2 1  ‘00h’  
Lc 1  ‘NNh’  Lc: lengte van het volgende gegevensveld  
#6-#(5+L)  L  ‘7Ch’ + L  7C + 
‘80h’ + L  80 + 
‘XX..XXh’  Met DER-TLV gecodeerde waarde van de tijdelijke 
openbare sleutel (zie aanhangsel 11) 
De VU verzendt de gegevensobjecten in deze volg ­
orde. 
▼M1 
5 + L + 1  1  ‘00h’  Zoals gespecificeerd in ISO/IEC 7816-4  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 222  
TCS_102  Antwoordbericht  
Byte  Lengte  Waarde  Omschrijving  
#1-#L  L  ‘7Ch’ + L  7C + ‘81h’ 
+ ‘08h’ + ‘XX..XXh’ 
+ ‘82h’ + L  82 + 
‘XX..XXh’  Met DER-TLV gecodeerde dynamische authen ­
ticatiegegevens:  nonce  (willekeurig getal) en 
authenticatieteken (zie aanhangsel 11)  
SW 2  ‘XXXXh’  Statuswoorden (SW1, SW2)  
— Indien het commando succesvol is, zendt de kaart 
‘9000 ’ terug.  
— De kaart zendt ‘ 6A80 ’ terug om te wijzen op onjuiste 
parameters in het gegevensveld.  
— De kaart zendt ‘ 6982 ’ terug indien het External Authen ­
ticate-commando niet met succes werd uitgevoerd.  
Het antwoord van het gegevensobject voor dynamische 
authenticatie ‘7Ch’:  
— moet aanwezig zijn indien de bewerking succesvol is, 
dat wil zeggen wanneer de statuswoorden gelijk zijn 
aan ‘ 9000 ’, 
— moet afwezig zijn in geval van een uitvoerings- of con ­
trolefout, dat wil zeggen wanneer de statuswoorden lig ­
gen tussen ‘ 6400 ’ en ‘ 6FFF ’, en  
— kan afwezig zijn in geval van een waarschuwing, dat 
wil zeggen wanneer de statuswoorden liggen tussen 
‘6200 ’ en ‘ 63FF ’. 
3.5.11  MANAGE SECURITY ENVIRONMENT  
Het MSE-commando wordt gebruikt om een openbare sleutel voor 
authenticatiedoeleinden in te stellen.  
3.5.11.1 C o m m a n d o - a n t w o o r d p a a r v o o r t a c h o g r a a f t o e p a s ­
s i n g e n v a n d e e e r s t e g e n e r a t i e  
Dit commando voldoet aan ISO/IEC 7816-4. Het gebruik van dit 
commando is beperkt vergeleken met de toepasselijke norm.  
TCS_103 Dit commando wordt alleen ondersteund door tachograaf ­
toepassingen van de eerste generatie.  
TCS_104 De in het MSE-gegevensveld genoemde sleutel blijft de 
huidige openbare sleutel tot het volgende correcte MSE- 
commando, totdat een DF wordt geselecteerd of totdat de 
kaart wordt teruggesteld.  
TCS_105 Indien de genoemde sleutel (nog) niet in de kaart aanwezig 
is, blijft de beveiligingsomgeving ongewijzigd.  
TCS_106  Commandobericht  
Byte  Lengte  Waarde  Omschrijving  
CLA  1  ‘00h’  CLA  
INS 1  ‘22h’  INS  
P1 1  ‘C1h’  P1: genoemde sleutel, geldig voor alle cryptografische 
bewerkingen  
P2 1  ‘B6h’  P2: genoemde gegevens met betrekking tot de digitale 
handtekening  
Lc 1  ‘0Ah’  Lc: lengte van het volgende gegevensveld  
#6 1  ‘83h’  Label ter verwijzing naar een openbare sleutel in asym ­
metrische gevallen  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 223  
Byte  Lengte  Waarde  Omschrijving  
#7 1  ‘08h’  Lengte van de sleutelreferentie (sleutelidentificator)  
#8-#15  8  ‘XX..XXh’  Sleutelidentificator zoals gespecificeerd in aanhangsel 11  
TCS_107  Antwoordbericht  
Byte  Lengte  Waarde  Omschrijving  
SW 2  ‘XXXXh’  Statuswoorden (SW1, SW2)  
— Indien het commando succesvol is, zendt de kaart 
‘9000 ’ terug.  
— Indien de genoemde sleutel niet op de kaart aanwezig 
is, wordt de verwerkingsstatus‘ 6A88 ’ teruggezonden.  
— Indien een aantal verwachte gegevensobjecten in het 
beveiligde berichtenuitwisselingsformaat ontbreekt, 
wordt de verwerkingsstatus ‘ 6987 ’ teruggezonden. Dit 
kan gebeuren wanneer het label ‘83h’ ontbreekt.  
— Indien een aantal gegevensobjecten niet correct is, 
wordt de verwerkingsstatus ‘ 6988 ’ teruggezonden. Dit 
kan gebeuren wanneer de lengte van de sleutelidentifi ­
cator verschilt van ‘08h’.  
— Indien de geselecteerde sleutel beschadigd is, wordt de 
verwerkingsstatus ‘ 6400 ’ of ‘ 6581 ’ teruggezonden.  
3.5.11.2 C o m m a n d o - a n t w o o r d p a r e n v o o r t a c h o g r a a f t o e ­
p a s s i n g e n v a n d e t w e e d e g e n e r a t i e  
Voor de authenticatie van de tweede generatie ondersteunt de tacho ­
graafkaart de volgende MSE: Set-commandoversies die voldoen aan 
ISO/IEC 7816-4. Deze commandoversies worden niet ondersteund 
voor de authenticatie van de eerste generatie.  
3.5.11.2.1 M S E : S E T A T - c o m m a n d o v o o r c h i p a u t h e n t i c a t i e  
Het volgende MSE:SET AT-commando wordt gebruikt om de para ­
meters te selecteren voor de chipauthenticatie die wordt uitgevoerd 
door een volgend General Authenticate-commando.  
TCS_108 Het commando kan worden uitgevoerd in MF, DF Tacho ­
graaf en DF Tachograaf_G2 (zie ook TCS_34).  
TCS_109  MSE:SET AT-commandobericht voor chipauthenticatie  
Byte  Lengte  Waarde  Omschrijving  
CLA  1  ‘00h’  
INS 1  ‘22h’  
P1 1  ‘41h’  Ingesteld voor interne authenticatie  
P2 1  ‘A4h’  Authenticatie  
Lc 1  ‘NNh’  Lc: lengte van het volgende gegevensveld  
#6-#(5+L)  L  ‘80h’ + ‘0Ah’ 
+ ‘XX..XXh’  Met DER-TLV gecodeerde referentie voor het cryptogra ­
fisch mechanisme: objectidentificator van de chipauthen ­
ticatie (alleen waarde, label ‘06h’ wordt weggelaten). 
Zie aanhangsel 1 voor de waarden van de objectidenti ­
ficatoren; de notatie in byte wordt gebruikt. Zie aanhang ­
sel 11 voor meer uitleg over de wijze waarop een van 
deze objectidentificatoren wordt geselecteerd.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 224  
3.5.11.2.2 M S E : S E T A T - c o m m a n d o v o o r V U - a u t h e n t i c a t i e  
Het volgende MSE:SET AT-commando wordt gebruikt om de para ­
meters en sleutels te selecteren voor de VU-authenticatie die wordt 
uitgevoerd door een volgend External Authenticate-commando.  
TCS_110 Het commando kan worden uitgevoerd in MF, DF Tacho ­
graaf en DF Tachograaf_G2 (zie ook TCS_34).  
TCS_111  MSE:SET AT-commandobericht voor VU-authenticatie  
Byte  Lengte  Waarde  Omschrijving  
CLA  1  ‘00h’  
INS 1  ‘22h’  
P1 1  ‘81h’  Ingesteld voor externe authenticatie  
P2 1  ‘A4h’  Authenticatie  
Lc 1  ‘NNh’  Lc: lengte van het volgende gegevensveld  
#6-#(5+L)  L  ‘80h’ + ‘0Ah’ 
+ ‘XX..XXh’  Met DER-TLV gecodeerde referentie voor het cryptogra ­
fisch mechanisme: objectidentificator van de VU-authen ­
ticatie (alleen waarde, label ‘06h’ wordt weggelaten). 
Zie aanhangsel 1 voor de waarden van de objectidenti ­
ficatoren; de notatie in byte wordt gebruikt. Zie aanhang ­
sel 11 voor meer uitleg over de wijze waarop een van 
deze objectidentificatoren wordt geselecteerd.  
‘83h’ + ‘08h’ 
+ ‘XX..XXh’  Met DER-TLV gecodeerde referentie van de openbare 
VU-sleutel op basis van de referentie van de certificaat ­
houder die in zijn certificaat vermeld staat.  
‘91h’ + L  91 + 
‘XX..XXh’  Met DER-TLV gecodeerde gecomprimeerde voorstelling 
van de tijdelijke openbare sleutel van de VU die tijdens 
de chipauthenticatie wordt gebruikt (zie aanhangsel 11)  
3.5.11.2.3 M S E : S E T D S T  
Het volgende MSE:SET DST-commando wordt gebruikt om een 
openbare sleutel in te stellen:  
— ter verificatie van een handtekening die in een volgend PSO: 
Verify Digital Signature-commando wordt verstrekt, of  
— voor de handtekeningverificatie van een certificaat dat in een vol ­
gend PSO: Verify Certificate-commando wordt verstrekt.  
TCS_112 Het commando kan worden uitgevoerd in MF, DF Tacho ­
graaf en DF Tachograaf_G2 (zie ook TCS_33).  
TCS_113  MSE:SET DST-commandobericht  
Byte  Lengte  Waarde  Omschrijving  
CLA  1  ‘00h’  
INS 1  ‘22h’  
P1 1  ‘81h’  Ingesteld ter verificatie  
P2 1  ‘B6h’  Digitale handtekening  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 225  
Byte  Lengte  Waarde  Omschrijving  
Lc 1  ‘NNh’  Lc: lengte van het volgende gegevensveld  
#6-#(5+L)  L  ‘83h’ + ‘08h’ 
+ ‘XX...XXh’  Met DER-TLV gecodeerde referentie van een openbare 
sleutel, dat wil zeggen de referentie van de certificaat ­
houder in het openbare-sleutelcertificaat (zie aanhangsel 
11) 
Voor alle commandoversies worden de antwoordberichtstructuur en 
statuswoorden verstrekt door:  
TCS_114  Antwoordbericht  
Byte  Lengte  Waarde  Omschrijving  
SW 2  ‘XXXXh’  Statuswoorden (SW1, SW2)  
— Indien het commando succesvol is, zendt de kaart 
‘9000 ’ terug. Het protocol is geselecteerd en geïnitiali ­
seerd.  
— ‘6A80 ’ wijst op onjuiste parameters in het gegevens ­
veld van het commando.  
— ‘6A88 ’ geeft aan dat het genoemde gegeven (dat wil 
zeggen een genoemde sleutel) niet beschikbaar is.  
▼M1 
— Indien de currentAuthenticatedTime van de kaart valt 
na de datum waarop de geldigheid van geselecteerde 
openbare sleutel afloopt, wordt de verwerkingsstatus 
‘6A88 ’ teruggezonden.  
Opmerking:  In het geval van een commando MSE:SET AT 
for VU Authentication is de genoemde sleutel een openbare 
sleutel VU_MA. Voor zover beschikbaar in haar geheugen, 
stelt de kaart de openbare sleutel VU_MA die overeenstemt 
met de referentie van de certificaathouder (CHR) in het 
gegevensveld van het commando (de kaart kan openbare 
sleutels VU_MA identificeren aan de hand van het CHA- 
veld van het certificaat) in voor gebruik. Een kaart ant ­
woordt alleen met „6A 88” op dit commando wanneer de 
openbare sleutel VU_Sign niet beschikbaar is of geen en ­
kele openbare sleutel van de voertuigunit beschikbaar is. 
Zie aanhangsel 11 voor de definitie van het CHA-veld en 
aanhangsel 1 voor de definitie van het gegevenstype equip ­
mentType.  
In het geval een MSE:SET DST-commando dat verwijst 
naar een EQT (d.w.z. een VU of een kaart) wordt verzon ­
den naar een controlekaart, is de genoemde sleutel volgens 
CSM_234 altijd een EQT_Sign-sleutel die moet worden 
gebruikt voor de verificatie van een digitale handtekening. 
Volgens figuur 13 in aanhangsel 11 slaat de controlekaart 
altijd de relevante openbare sleutel EQT_Sign op. In som ­
mige gevallen is het mogelijk dat de controlekaart de over ­
eenkomstige openbare sleutel EQT_MA opslaat. De contro ­
lekaart stelt altijd de openbare sleutel EQT_Sign in voor 
gebruik wanneer zij een MSE:SET DST-commando ont ­
vangt.  
▼B 
3.5.12  PSO: HASH  
Dit commando wordt gebruikt om het resultaat van een hashbereke ­
ning van een aantal gegevens over te brengen op de kaart. Dit com ­
mando dient ter verificatie van digitale handtekeningen. De 
hashwaarde wordt tijdelijk opgeslagen voor het volgende PSO: Verify 
Digital Signature-commando.  
Dit commando voldoet aan ISO/IEC 7816-8. Het gebruik van dit 
commando is beperkt vergeleken met de toepasselijke norm.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 226  
Alleen de controlekaart is vereist om dit commando te ondersteunen 
in DF Tachograaf en DF Tachograaf_G2.  
Op andere soorten tachograafkaarten kan dit commando al dan niet 
worden geïmplementeerd. Dit commando kan al dan niet toegankelijk 
zijn in het stambestand (MF).  
Controlekaarten voor tachograaftoepassingen van de eerste generatie 
ondersteunen alleen SHA-1.  
TCS_115 De tijdelijk opgeslagen hashwaarde wordt verwijderd in ­
dien een nieuwe hashwaarde wordt berekend met behulp 
van het PSO: HASH-commando, indien een DF wordt ge ­
selecteerd, en indien de tachograafkaart wordt teruggesteld.  
TCS_116  Commandobericht  
Byte  Lengte  Waarde  Omschrijving  
CLA  1  ‘00h’  CLA  
INS 1  ‘2Ah’  Voer beveiligingsoperatie uit (PSO)  
P1 1  ‘90h’  Zend hashcode terug  
P2 1  ‘A0h’  Label: gegevensveld bevat voor hashfunctie relevante 
gegevensobjecten (DO's)  
Lc 1  ‘XXh’  Lengte Lc van het volgende gegevensveld  
#6 1  ‘90h’  Label voor de hashcode  
#7 1  ‘XXh’  Lengte L van de hashcode 
‘14h’ voor tachograaftoepassingen van de eerste genera ­
tie (zie aanhangsel 11, deel A) 
‘20h’, ‘30h’ of ‘40h’ voor tachograaftoepassingen van de 
tweede generatie (zie aanhangsel 11, deel B)  
#8-#(7+L)  L  ‘XX..XXh’  Hashcode  
TCS_117  Antwoordbericht  
Byte  Lengte  Waarde  Omschrijving  
SW 2  ‘XXXXh’  Statuswoorden (SW1, SW2)  
— Indien het commando succesvol is, zendt de kaart 
‘9000 ’ terug.  
— Indien een aantal verwachte gegevensobjecten (zoals 
hierboven gespecificeerd) ontbreekt, wordt de verwer ­
kingsstatus ‘ 6987 ’ teruggezonden. Dit kan gebeuren 
wanneer een van de labels ‘90h’ ontbreekt.  
— Indien een aantal gegevensobjecten niet correct is, 
wordt de verwerkingsstatus ‘ 6988 ’ teruggezonden. 
Deze fout treedt op wanneer het vereiste label aanwezig 
is, maar een lengte heeft die verschilt van: ‘14h’ voor 
SHA-1, ‘20h’ voor SHA-256, ‘30h’ voor SHA-384, 
‘40h’ voor SHA-512 (tachograaftoepassing van de 
tweede generatie).  
3.5.13  PERFORM HASH OF FILE  
Dit commando voldoet niet aan ISO/IEC 7816-8. De CLA-byte van 
dit commando geeft dus een particulier gebruik van PERFORM SE ­
CURITY OPERATION/HASH.  
Alleen de bestuurders- en werkplaatskaart zijn vereist om dit com ­
mando te ondersteunen in DF Tachograaf en DF Tachograaf_G2.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 227  
Op andere soorten tachograafkaarten kan dit commando al dan niet 
worden geïmplementeerd. Voor een bedrijfs- of controlekaart wordt 
dit commando geïmplementeerd op de in dit hoofdstuk vastgelegde 
wijze.  
Dit commando kan al dan niet toegankelijk zijn in het stambestand 
(MF). Als dat het geval is, wordt het commando geïmplementeerd op 
de in dit hoofdstuk vastgelegde wijze: er wordt met andere woorden 
geen hashwaarde berekend, maar het commando wordt beëindigd met 
een geschikte foutcode.  
TCS_118 Het PERFORM HASH of FILE-commando wordt gebruikt 
om het gegevensgebied van de thans geselecteerde trans ­
parante EF te hashen.  
TCS_119 Een tachograafkaart ondersteunt dit commando alleen voor 
de hoofdbestanden (EF's) die worden opgesomd in hoofd ­
stuk 4 onder DF Tachograaf en DF Tachograaf_G2, zij het 
met de volgende uitzondering: een tachograafkaart onder ­
steunt het commando niet voor de EF Sensor_Installati ­
on_Data van DF Tachograaf_G2.  
TCS_120 Het resultaat van de hashbewerking wordt tijdelijk in de 
kaart opgeslagen. Het kan vervolgens worden gebruikt om 
een digitale handtekening van het bestand te krijgen met 
gebruikmaking van het PSO: COMPUTE DIGITAL SIG ­
NATURE-commando.  
▼M1 
TCS_121 De tijdelijk opgeslagen hashwaarde wordt verwijderd in ­
dien een nieuwe hashwaarde wordt berekend met behulp 
van het PERFORM HASH of FILE-commando, indien een 
DF is geselecteerd en indien de tachograafkaart wordt te ­
ruggesteld.  
▼B 
TCS_122 Tachograaftoepassingen van de eerste generatie ondersteu ­
nen SHA-1.  
▼M1 
TCS_123 Tachograaftoepassingen van de tweede generatie ondersteu ­
nen het SHA-2-algoritme, SHA-256, SHA-384 of SHA- 
512, gespecificeerd aan de hand van de coderingssuite in 
aanhangsel 11, deel B, voor de handtekeningssleutel 
Card_Sign.  
▼B 
TCS_124  Commandobericht  
▼M1 
Byte  Lengte  Waarde  Omschrijving  
CLA  1  ‘80h’  CLA  
INS 1  ‘2Ah’  Voer beveiligingsoperatie uit  
P1 1  ‘90h’  Label: Hash  
P2 1  ‘00h’  Algoritme impliciet bekend 
Voor tachograaftoepassingen van de eerste generatie: 
SHA-1 
Voor tachograaftoepassingen van de tweede generatie: 
SHA-2-algorithme (SHA-256, SHA-384 of SHA-512), 
gedefinieerd aan de hand van de coderingssuite in aan ­
hangsel 11, deel B, voor de handtekeningssleutel 
Card_Sign  
▼B 
TCS_125  Antwoordbericht  
Byte  Lengte  Waarde  Omschrijving  
SW 2  ‘XXXXh’  Statuswoorden (SW1, SW2)  
— Indien het commando succesvol is, zendt de kaart 
‘9000 ’ terug.  
— Indien de geldige EF dit commando niet toestaat (EF 
Sensor_Installation_Data in DF Tachograaf_G2), wordt 
de verwerkingsstatus ‘ 6985 ’ teruggezonden.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 228  
— Indien de geselecteerde EF beschadigd is (integriteits ­
fouten in bestandsattributen of opgeslagen gegevens), 
wordt de verwerkingsstatus ‘ 6400 ’ of ‘ 6581 ’ terug­
gezonden.  
— Indien het geselecteerde bestand geen transparant be ­
stand is of indien er geen geldige EF is, wordt de ver ­
werkingsstatus ‘ 6986 ’ teruggezonden.  
3.5.14  PSO: COMPUTE DIGITAL SIGNATURE  
▼M1 
Dit commando wordt gebruikt om de digitale handtekening van een 
eerder berekende hashcode te berekenen (zie PERFORM HASH of 
FILE-commando in punt 3.5.13).  
Alleen de bestuurders- en werkplaatskaart zijn vereist om dit com ­
mando te ondersteunen in DF Tachograaf en DF Tachograaf_G2.  
Op andere soorten tachograafkaarten kan dit commando al dan niet 
worden geïmplementeerd. In het geval van tachograaftoepassingen 
van de tweede generatie hebben alleen de bestuurderskaart en de 
werkplaatskaart een handtekeningssleutel van de tweede generatie; 
andere kaarten kunnen het commando niet met succes uitvoeren en 
beëindigen het commando met een geschikte foutcode.  
Dit commando kan al dan niet toegankelijk zijn in het stambestand 
(MF). Als het commando niet toegankelijk is in het MF, eindigt het 
met een passende foutcode.  
Dit commando voldoet aan ISO/IEC 7816-8. Het gebruik van dit 
commando is beperkt vergeleken met de toepasselijke norm.  
▼B 
TCS_126 Dit commando berekent geen digitale handtekening van een 
eerder met het PSO: HASH-commando berekende hashco ­
de. 
TCS_127 De particuliere sleutel van de kaart wordt gebruikt om de 
digitale handtekening te berekenen en is impliciet bij de 
kaart bekend.  
TCS_128 Tachograaftoepassingen van de eerste generatie gebruiken 
voor de digitale handtekening een paddingmethode over ­
eenkomstig PKCS1 (zie aanhangsel 11 voor meer bijzon ­
derheden).  
TCS_129 Tachograaftoepassingen van de tweede generatie berekenen 
de digitale handtekening op basis van een elliptische 
kromme (zie aanhangsel 11 voor meer bijzonderheden).  
TCS_130  Commandobericht  
Byte  Lengte  Waarde  Omschrijving  
CLA  1  ‘00h’  CLA  
INS 1  ‘2Ah’  Voer beveiligingsoperatie uit (PSO)  
P1 1  ‘9Eh’  Terug te zenden digitale handtekening  
P2 1  ‘9Ah’  Label: gegevensveld bevat te ondertekenen gegevens. 
Als geen gegevensveld opgenomen is, wordt aange ­
nomen dat de gegevens al op de kaart aanwezig zijn 
(hashwaarde van bestand)  
Le 1  ‘NNh’  Lengte van de verwachte handtekening  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 229  
TCS_131  Antwoordbericht  
Byte  Lengte  Waarde  Omschrijving  
#1-#L  L  ‘XX..XXh’  Handtekening van de eerder berekende hashwaarde  
SW 2  ‘XXXXh’  Statuswoorden (SW1, SW2)  
— Indien het commando succesvol is, zendt de kaart 
‘9000 ’ terug.  
— Indien de impliciet geselecteerde particuliere sleutel be ­
schadigd is, wordt de verwerkingsstatus ‘ 6400 ’ of 
‘6581 ’ teruggezonden.  
— Indien de eerder met een Perform Hash of File-com ­
mando berekende hashwaarde niet beschikbaar is, wordt 
de verwerkingsstatus ‘ 6985 ’ teruggezonden.  
3.5.15  PSO: VERIFY DIGITAL SIGNATURE  
Dit commando wordt gebruikt ter verificatie van de digitale hand ­
tekening die als invoer is opgegeven en waarvan de hashwaarde bij 
de kaart bekend is. Het handtekeningalgoritme is impliciet bij de kaart 
bekend.  
Dit commando voldoet aan ISO/IEC 7816-8. Het gebruik van dit 
commando is beperkt vergeleken met de toepasselijke norm.  
Alleen de controlekaart is vereist om dit commando te ondersteunen 
in DF Tachograaf en DF Tachograaf_G2.  
Op andere soorten tachograafkaarten kan dit commando al dan niet 
worden geïmplementeerd. Dit commando kan al dan niet toegankelijk 
zijn in het stambestand (MF).  
TCS_132 Het VERIFY DIGITAL SIGNATURE-commando gebruikt 
altijd de door het voorafgaande MSE: SET DST-commando 
geselecteerde openbare sleutel en de voorafgaande, door 
een PSO: HASH-commando ingevoerde hashcode.  
TCS_133  Commandobericht  
▼M1 
Byte  Lengte  Waarde  Omschrijving  
CLA  1  ‘00h’  CLA  
INS 1  ‘2Ah’  Voer beveiligingsoperatie uit  
P1 1  ‘00h’  
P2 1  ‘A8h’  Label: gegevensveld bevat voor verificatie relevante 
DO's  
Lc 1  ‘XXh’  Lengte Lc van het volgende gegevensveld  
#6 1  „9Eh”  Label voor digitale handtekening  
# 7 of 
#7-#8  L ‘NNh’ of 
‘81 NNh’  Lengte van de digitale handtekening (L is 2 bytes als de 
digitale handtekening langer is dan 127 bytes): 
128 bytes, gecodeerd overeenkomstig deel A van aan ­
hangsel 11 voor tachograaftoepassingen van de eerste 
generatie. 
Afhankelijk van de geselecteerde elliptische kromme 
voor tachograaftoepassingen van de tweede generatie 
(zie deel B van aanhangsel 11).  
#(7+L)- 
#(6+L+NN)  NN ‘XX..XXh’  Inhoud van de digitale handtekening  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 230  
TCS_134  Antwoordbericht  
Byte  Lengte  Waarde  Omschrijving  
SW 2  ‘XXXXh’  Statuswoorden (SW1, SW2)  
— Indien het commando succesvol is, zendt de kaart 
‘9000 ’ terug.  
— Indien de handtekeningverificatie mislukt, wordt de ver ­
werkingsstatus ‘ 6688 ’ teruggezonden. De verificatiepro ­
cedure wordt uiteengezet in aanhangsel 11.  
— Indien geen openbare sleutel wordt geselecteerd, wordt 
de verwerkingsstatus ‘ 6A88 ’ teruggezonden.  
— Indien een aantal verwachte gegevensobjecten (zoals 
hierboven gespecificeerd) ontbreekt, wordt de verwer ­
kingsstatus ‘ 6987 ’ teruggezonden. Dit kan gebeuren 
wanneer een van de vereiste labels ontbreekt.  
— Indien geen hashcode beschikbaar is om het commando 
te verwerken (als gevolg van een voorafgaand PSO: 
Hash-commando), wordt de verwerkingsstatus ‘ 6985 ’ 
teruggezonden.  
— Indien een aantal gegevensobjecten niet correct is, 
wordt de verwerkingsstatus ‘ 6988 ’ teruggezonden. Dit 
kan gebeuren wanneer de lengte van een van vereiste 
gegevensobjecten niet correct is.  
— Indien de geselecteerde openbare sleutel beschadigd is, 
wordt de verwerkingsstatus ‘ 6400 ’ of ‘ 6581 ’ terug­
gezonden.  
▼M1 
— Indien de geselecteerde openbare sleutel (waarmee de 
digitale handtekening wordt geverifieerd) een 
CHA.LSB (CertificateHolderAuthorisation.equipment ­
Type) heeft die niet geschikt is voor de verificatie 
van digitale handtekeningen overeenkomstig aanhangsel 
11, wordt de verwerkingsstatus ‘ 6985 ’ teruggezonden.  
▼B 
3.5.16  PROCESS DSRC MESSAGE  
Dit commando wordt gebruikt om de integriteit en authenticiteit van 
het DSRC-bericht te verifiëren, alsook om de gegevens te decoderen 
die via de DSRC-verbinding worden overgebracht van een VU naar 
een controleautoriteit of een werkplaats. De kaart bepaalt de code ­
ringssleutel en de MAC-sleutel waarmee het DSRC-bericht is bevei ­
ligd (zie beschrijving in aanhangsel 11, deel B, hoofdstuk 13).  
Alleen de controle- en werkplaatskaart zijn vereist om dit commando 
te ondersteunen in DF Tachograaf_G2.  
Op andere soorten tachograafkaarten kan dit commando al dan niet 
worden geïmplementeerd. Deze kaarten hebben echter geen DSRC- 
hoofdsleutel („master key”). Bijgevolg wordt dit commando op deze 
kaarten niet met succes uitgevoerd, maar beëindigd met een geschikte 
foutcode.  
Dit commando kan al dan niet toegankelijk zijn in MF en/of in DF 
Tachograaf. Als dat het geval is, wordt het commando beëindigd met 
een geschikte foutcode.  
TCS_135 De DSRC-hoofdsleutel is alleen toegankelijk in DF Tacho ­
graaf G2; de controle- en werkplaatskaart ondersteunen met 
andere woorden alleen een succesvolle uitvoering van dit 
commando in DF Tachograaf G2.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 231  
TCS_136 Dit commando decodeert alleen de DSRC-gegevens en 
controleert de cryptografische controlesom, zij het zonder 
de invoergegevens te interpreteren.  
TCS_137 De volgorde van de gegevensobjecten (DO's) in het gege ­
vensveld van het commando wordt vastgelegd in deze spe ­
cificatie.  
TCS_138  Commandobericht  
Byte  Lengte  Waarde  Omschrijving  
CLA  1  ‘80h’  Particuliere CLA  
INS 1  ‘2Ah’  Voer beveiligingsoperatie uit (PSO)  
P1 1  ‘80h’  Antwoordgegevens: ongecodeerde waarde  
P2 1  ‘B0h’  Commandogegevens: ongecodeerde waarde van met 
BER-TLV gecodeerde gegevens, met inbegrip van SM 
DO's  
Lc 1  ‘NNh’  Lengte Lc van het volgende gegevensveld  
#6-#(5+L)  L  ‘87h’ + L  87 + 
‘XX..XXh’  Met DER-TLV gecodeerde padding-indicatorbyte ge ­
volgd door gecodeerde payloadgegevens van de tacho ­
graaf. Voor de padding-indicatorbyte wordt de waarde 
‘00h’ („geen nadere details” overeenkomstig ISO/IEC 
7816-4:2013, tabel 52) gebruikt. Zie aanhangsel 11, 
deel B, hoofdstuk 13 voor meer informatie over het co ­
deringsmechanisme. 
De toegestane waarden voor de lengte L  87 zijn veelvou ­
den van de AES-bloklengte + 1 voor de padding-indica ­
torbyte, dat wil zeggen van 17 bytes tot en met 193 
bytes.  
Opmerking:  zie ISO/IEC 7816-4:2013, tabel 49 voor het 
SM-gegevensobject met label ‘87h’.  
‘81h’ + ‘10h’  Met DER-TLV gecodeerd referentiemodel (template) 
voor vertrouwelijkheidscontrole, waarin de samenvoe ­
ging van de volgende gegevenselementen is ingesloten 
(zie DSRCSecurityData in aanhangsel 1 en zie aanhang ­
sel 11, deel B, hoofdstuk 13): 
— tijdaanduiding van 4 bytes 
— teller van 3 bytes 
— VU-serienummer van 8 bytes 
— versie van DSRC-hoofdsleutel van 1 byte  
Opmerking:  zie ISO/IEC 7816-4:2013, tabel 49 voor het 
SM-gegevensobject met label ‘81h’.  
‘8Eh’ + L  8E + 
‘XX..XXh’  Met DER-TLV gecodeerde MAC van het DSRC-bericht. 
Zie aanhangsel 11, deel B, hoofdstuk 13 voor meer in ­
formatie over het MAC-algoritme en de berekening van 
deze berichtauthenticatiecode.  
Opmerking:  zie ISO/IEC 7816-4:2013, tabel 49 voor het 
SM-gegevensobject met label ‘8Eh’.  
▼M1 
5 + L + 1  1  ‘00h’  Zoals gespecificeerd in ISO/IEC 7816-4  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 232  
TCS_139  Antwoordbericht  
Byte  Lengte  Waarde  Omschrijving  
#1-#L  L  ‘XX..XXh’  Afwezige gegevens (in geval van fout) of gedecodeerde 
gegevens (padding verwijderd)  
SW 2  ‘XXXXh’  Statuswoorden (SW1, SW2)  
— Indien het commando succesvol is, zendt de kaart 
‘9000 ’ terug.  
— ‘6A80 ’ wijst op onjuiste parameters in het gegevens ­
veld van het commando (ook gebruikt wanneer de ge ­
gevensobjecten niet in de voorgeschreven volgorde 
worden verzonden).  
— ‘6A88 ’ geeft aan dat het genoemde gegeven (dat wil 
zeggen de genoemde DSRC-hoofdsleutel) niet beschik ­
baar is.  
— ‘6900 ’ geeft aan dat de verificatie van de cryptografi ­
sche controlesom of de decodering van de gegevens is 
mislukt.  
▼M1 
— ‘6985 ’ geeft aan dat de tijdstempel van 4 byte in het 
gegevensveld van het commando vroeger is dan card ­
ValidityBegin of later dan cardExpiryDate.  
▼B 
4. STRUCTUUR VAN DE TACHOGRAAFKAARTEN  
In dit punt worden de bestandsstructuren van de tachograafkaarten 
gespecificeerd voor het opslaan van toegankelijke gegevens.  
De interne bestandsstructuren die specifiek zijn voor de fabrikant 
van de kaart, zoals de beginlabels (headers) van bestanden, 
worden niet gespecificeerd, evenmin als de opslag en verwerking 
van gegevenselementen voor intern gebruik zoals
  
,
 ,
  
of
 .  
TCS_140 Een tachograafkaart van de tweede generatie bevat het 
stambestand (MF) alsook een gelijksoortige tachograaftoe ­
passing van de eerste en de tweede generatie (bijvoorbeeld 
toepassingen voor de bestuurderskaart).  
TCS_141 Een tachograafkaart ondersteunt ten minste het minimum ­
aantal registraties dat voor de bijbehorende toepassingen is 
gespecificeerd, en ondersteunt niet meer registraties dan het 
maximumaantal dat voor de bijbehorende tachograaftoepas ­
singen is gespecificeerd.  
Het maximum- en minimumaantal registraties voor de ver ­
schillende tachograaftoepassingen worden in dit hoofdstuk 
gespecificeerd.  
Zie punt 3.3 voor meer informatie over de beveiligings ­
voorwaarden die in dit hoofdstuk worden toegepast op de 
toegangsregels. Doorgaans verwijst de toegangsmodus van 
de Read-functie naar het READ BINARY-commando met 
een even en — voor zover ondersteund — oneven instruc ­
tiebyte (INS), met uitzondering van de EF Sensor_Installa ­
tion_Data op de werkplaatskaart (zie TCS_156 en 
TCS_160). De toegangsmodus van de Update-functie ver ­
wijst naar het Update Binary-commando met een even en 
— voor zover ondersteund — oneven instructiebyte (INS). 
De toegangsmodus voor de Select-functie verwijst naar het 
SELECT-commando.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 233  
4.1. Stambestand (MF)  
TCS_142 Na personalisatie heeft het stambestand (MF) de onder ­
staande permanente bestandsstructuur en bestandstoegangs ­
regels:  
Opmerking:  de korte EF-identificator SFID wordt opge ­
geven als decimaal getal; zo komt de waarde ‘30’ overeen 
met ‘11110’ in binaire notatie.
  
In deze tabel wordt de volgende afkorting voor de beveili ­
gingsvoorwaarde gebruikt:  
SC1 ALW OR SM-MAC-G2  
TCS_143 Alle EF-structuren zijn transparant.  
TCS_144 Het stambestand (MF) heeft de onderstaande gegevens ­
structuur:
  
TCS_145 Het hoofdbestand EF DIR bevat de volgende toepassings ­
gerelateerde gegevensobjecten: ‘61 08 4F 06 FF 54 41 43 
48 4F 61 08 4F 06 FF 53 4D 52 44 54’  
TCS_146 Het hoofdbestand EF ATR/INFO is aanwezig indien de 
tachograafkaart in het ATR aangeeft dat velden met uit ­
gebreide lengte worden ondersteund. In dit geval bevat 
EF ATR/INFO het gegevensobject van informatie met uit ­
gebreide lengte (DO ‘7F66’), zoals gespecificeerd in ISO/ 
IEC 7816-4:2013 onder 12.7.1.  
TCS_147 Het hoofdbestand EF Extended_Length is aanwezig indien 
de tachograafkaart in het ATR aangeeft dat velden met 
uitgebreide lengte worden ondersteund. In dit geval bevat 
het hoofdbestand (EF) het volgende gegevensobject: ‘02 01 
xx’ waarbij ‘xx’ aangeeft of velden met uitgebreide lengte 
worden ondersteund voor het protocol T = 1 en/of T = 0.  
De waarde ‘01’ betekent dat velden met uitgebreide lengte 
worden ondersteund voor het protocol T = 1.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 234  
De waarde ‘10’ betekent dat velden met uitgebreide lengte 
worden ondersteund voor het protocol T = 0.  
De waarde ‘11’ betekent dat velden met uitgebreide lengte 
worden ondersteund voor het protocol T = 1 en T = 0.  
4.2. Toepassingen voor de bestuurderskaart  
4.2.1  Toepassing van de eerste generatie voor de bestuurderskaart  
TCS_148 Na personalisatie heeft de toepassing van de eerste genera ­
tie voor de bestuurderskaart de onderstaande permanente 
bestandsstructuur en bestandstoegangsregels:
  
In deze tabel worden de volgende afkortingen voor de 
beveiligingsvoorwaarden gebruikt:  
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 Alle EF-structuren zijn transparant.  
TCS_150 De tachograaftoepassing van de eerste generatie voor de 
bestuurderskaart heeft de onderstaande gegevensstructuur:  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 235
  
▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 236
  
▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 237  
TCS_151 De volgende waarden geven de grootte in de bovenstaande 
tabel aan en komen overeen met het minimum- en maxi ­
mumaantal registraties dat de gegevensstructuur van de be ­
stuurderskaart moet gebruiken voor een toepassing van de 
eerste generatie:
  
4.2.2  Toepassing van de tweede generatie voor de bestuurderskaart  
TCS_152 Na personalisatie heeft de toepassing van de tweede gene ­
ratie voor de bestuurderskaart de onderstaande permanente 
bestandsstructuur en bestandstoegangsregels:  
Opmerking:  de korte EF-identificator SFID wordt opge ­
geven als decimaal getal; zo komt de waarde ‘30’ overeen 
met ‘11110’ in binaire notatie.
  
In deze tabel wordt de volgende afkorting voor de beveili ­
gingsvoorwaarde gebruikt:  
SC1 ALW OR SM-MAC-G2  
TCS_153 Alle EF-structuren zijn transparant.  
TCS_154 De toepassing van de tweede generatie voor de bestuurders ­
kaart heeft de onderstaande gegevensstructuur:  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 238
  
► (1) M1 ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 239
  
▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 240
  
► (1) M1 
TCS_155 De volgende waarden geven de grootte in de bovenstaande 
tabel aan en komen overeen met het minimum- en maxi ­
mumaantal registraties dat de gegevensstructuur van de be ­
stuurderskaart moet gebruiken voor een toepassing van de 
tweede generatie:
  
► (1) M1 
4.3. Toepassingen voor de werkplaatskaart  
4.3.1  Toepassing van de eerste generatie voor de werkplaatskaart  
TCS_156 Na personalisatie heeft de toepassing van de eerste genera ­
tie voor de werkplaatskaart de onderstaande permanente 
bestandsstructuur en bestandstoegangsregels:  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 241
  
In deze tabel worden de volgende afkortingen voor de 
beveiligingsvoorwaarden gebruikt:  
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 Voor het READ BINARY-commando met even in ­
structiebyte (INS):  
(SM-C-MAC-G1 AND SM-R-ENC-MAC-G1) OR  
(SM-C-MAC-G2 AND SM-R-ENC-MAC-G2)  
Voor het READ BINARY-commando met oneven 
instructiebyte (indien ondersteund): NEV  
▼B 
TCS_157 Alle EF-structuren zijn transparant.  
TCS_158 De toepassing van de eerste generatie voor de werkplaats ­
kaart heeft de onderstaande gegevensstructuur:  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 242
  
▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 243
  
▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 244
  
TCS_159 De volgende waarden geven de grootte in de bovenstaande 
tabel aan en komen overeen met het minimum- en maxi ­
mumaantal registraties dat de gegevensstructuur van de 
werkplaatskaart moet gebruiken voor een toepassing van 
de eerste generatie:
  
4.3.2  Toepassing van de tweede generatie voor de werkplaatskaart  
TCS_160 Na personalisatie heeft de toepassing van de tweede gene ­
ratie voor de werkplaatskaart de onderstaande permanente 
bestandsstructuur en bestandstoegangsregels:  
Opmerking:  de korte EF-identificator SFID wordt opge ­
geven als decimaal getal; zo komt de waarde ‘30’ overeen 
met ‘11110’ in binaire notatie.
  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 245  
In deze tabel worden de volgende afkortingen voor de 
beveiligingsvoorwaarden gebruikt:  
SC1 ALW OR SM-MAC-G2  
SC5 Voor het READ BINARY-commando met even in ­
structiebyte (INS): SM-C-MAC-G2 AND SM-R- 
ENC-MAC-G2  
Voor het READ BINARY-commando met oneven 
instructiebyte (indien ondersteund): NEV  
TCS_161 Alle EF-structuren zijn transparant.  
TCS_162 De tachograaftoepassing van de tweede generatie voor de 
werkplaatskaart heeft de onderstaande gegevensstructuur:
  
► (1) (2) M1 ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 246
  
► (1) M1 ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 247
  
► (1) M1 ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 248  
TCS_163 De volgende waarden geven de grootte in de bovenstaande 
tabel aan en komen overeen met het minimum- en maxi ­
mumaantal registraties dat de gegevensstructuur van de 
werkplaatskaart moet gebruiken voor een toepassing van 
de tweede generatie:
  
► (1) M1 
4.4. Toepassingen voor de controlekaart  
4.4.1  Toepassing van de eerste generatie voor de controlekaart  
TCS_164 Na personalisatie heeft de toepassing van de eerste genera ­
tie voor de controlekaart de onderstaande permanente be ­
standsstructuur en bestandstoegangsregels:
  
In deze tabel worden de volgende afkortingen voor de 
beveiligingsvoorwaarden gebruikt:  
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 OR SM-MAC-G1 OR SM-MAC-G2  
TCS_165 Alle EF-structuren zijn transparant.  
TCS_166 De toepassing van de eerste generatie voor de controlekaart 
heeft de onderstaande gegevensstructuur:  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 249
  
TCS_167 De volgende waarden geven de grootte in de bovenstaande 
tabel aan en komen overeen met het minimum- en maxi ­
mumaantal registraties dat de gegevensstructuur van de 
controlekaart moet gebruiken voor een toepassing van de 
eerste generatie:
  
4.4.2  Toepassing van de tweede generatie voor de controlekaart  
TCS_168 Na personalisatie heeft de toepassing van de tweede gene ­
ratie voor de controlekaart de onderstaande permanente be ­
standsstructuur en bestandstoegangsregels:  
Opmerking:  de korte EF-identificator SFID wordt opge ­
geven als decimaal getal; zo komt de waarde ‘30’ overeen 
met ‘11110’ in binaire notatie.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 250
  
In deze tabel wordt de volgende afkorting voor de beveili ­
gingsvoorwaarde gebruikt:  
SC1 ALW OR SM-MAC-G2  
TCS_169 Alle EF-structuren zijn transparant.  
TCS_170 De toepassing van de tweede generatie voor de contro ­
lekaart heeft de onderstaande gegevensstructuur:
  
TCS_171 De volgende waarden geven de grootte in de bovenstaande 
tabel aan en komen overeen met het minimum- en maxi ­
mumaantal registraties dat de gegevensstructuur van de 
controlekaart moet gebruiken voor een toepassing van de 
tweede generatie:  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 251
  
4.5. Toepassingen voor de bedrijfskaart  
4.5.1  Toepassing van de eerste generatie voor de bedrijfskaart  
TCS_172 Na personalisatie heeft de toepassing van de eerste genera ­
tie voor de bedrijfskaart de onderstaande permanente be ­
standsstructuur en bestandstoegangsregels:
  
In deze tabel worden de volgende afkortingen voor de 
beveiligingsvoorwaarden gebruikt:  
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 OR SM-MAC-G1 OR SM-MAC-G2  
TCS_173 Alle EF-structuren zijn transparant.  
TCS_174 De toepassing van de eerste generatie voor de bedrijfskaart 
heeft de onderstaande gegevensstructuur:
  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 252  
TCS_175 De volgende waarden geven de grootte in de bovenstaande 
tabel aan en komen overeen met het minimum- en maxi ­
mumaantal registraties dat de gegevensstructuur van de be ­
drijfskaart moet gebruiken voor een toepassing van de eer ­
ste generatie:
  
4.5.2  Toepassing van de tweede generatie voor de bedrijfskaart  
TCS_176 Na personalisatie heeft de toepassing van de tweede gene ­
ratie voor de bedrijfskaart de onderstaande permanente be ­
standsstructuur en bestandstoegangsregels:  
Opmerking:  de korte EF-identificator SFID wordt opge ­
geven als decimaal getal; zo komt de waarde ‘30’ overeen 
met ‘11110’ in binaire notatie.
  
In deze tabel wordt de volgende afkorting voor de beveili ­
gingsvoorwaarde gebruikt:  
SC1 ALW OR SM-MAC-G2  
TCS_177 Alle EF-structuren zijn transparant.  
TCS_178 De toepassing van de tweede generatie voor de bedrijfs ­
kaart heeft de onderstaande gegevensstructuur:
  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 253  
TCS_179 De volgende waarden geven de grootte in de bovenstaande 
tabel aan en komen overeen met het minimum- en maxi ­
mumaantal registraties dat de gegevensstructuur van de be ­
drijfskaart moet gebruiken voor een toepassing van de 
tweede generatie:
  ▼B
02016R0799 — NL — 26.02.2020 — 002.001 — 254 
Aanhangsel 3  
PICTOGRAMMEN 
PIC_001 Het controleapparaat kan naar keuze gebruik maken van de volgende 
pictogrammen en combinaties van pictogrammen (of pictogrammen of 
combinaties daarvan die voldoende gelijkenis vertonen om ermee ver ­
eenzelvigd te worden):  
1. BASISPICTOGRAMMEN
Personen Activiteiten Werkingsmodi
  
Bedrijf Bedrijfsmodus
  
Controleur Controle Controlemodus
  
Bestuurder Rijden Operationele modus
  
Werkplaats/controlestation  Controle/kalibrering  Kalibreringsmodus
  
Fabrikant  
Activiteiten Duur
  
Beschikbaar Lopende periode van beschikbaarheid
  
Rijden Ononderbroken rijtijd
  
Rust Lopende rustperiode
  
Andere werkzaamheden Lopende werkperiode
  
Pauze Cumulatieve pauzetijd
  
Onbekend  
Apparatuur Functies
  
Lezer bestuurder
  
Lezer bijrijder
  
Kaart
  
Klok
  
Display Weergeven
  
Externe opslag Downloaden
  
Stroomvoorziening
  
Printer/afdruk Afdrukken
  
Sensor
  
Bandenmaat
  
Voertuig/voertuigunit
  
GNSS-module
  
Voorziening voor detectie op af ­
stand
  
ITS-interface  ▼B
Specifieke omstandigheden
  
Niet verplicht
  
Vervoer per veerboot/trein  
Diversen
  
Voorvallen
 Fouten
  
Begin van de dagelijkse werkperiode
 Einde van de dagelijkse werk­
periode
  
Plaats
  
Manuele invoer van werkzaamheden 
bestuurder
  
Beveiliging
  
Snelheid
  
Tijd
 
Totaal/overzicht  
Kwalificerende elementen  
24 h Dagelijks
  
Wekelijks
  
Om de twee weken
  
Van of tot  
2. PICTOGRAMCOMBINATIES
Diversen
  
Controleplaats
  
Plaats begin dagelijkse werkperiode
 Plaats einde dagelijkse werkperi­
ode 
▼M1
Positie na 3 uur cumulatieve rijtijd  
▼B
Van (tijd)
 Tot (tijd)
  
Van voertuig
  
Niet verplicht (begin)
 Niet verplicht (einde)  
Kaarten
  
Bestuurderskaart
  
Bedrijfskaart
  
Controlekaart
  
Werkplaatskaart
  
Geen kaart  ▼B02016R0799 — NL — 26.02.2020 — 002.001 — 255 
02016R0799 — NL — 26.02.2020 — 002.001 — 256 
Rijden
  
Rijden met een team
  
Rijtijd van een week
  
Rijtijd van twee weken  
Afdrukken
  
Dagelijkse afdruk van de kaart van de activiteiten van de bestuurder
  
Dagelijkse afdruk van de voertuigunit van de activiteiten van de bestuurder
  
Afdruk van de kaart van voorvallen en fouten
  
Afdruk van de voertuigunit van voorvallen en fouten
  
Afdruk van technische gegevens
  
Afdruk van snelheidsoverschrijding.  
Voorvallen
  
Inbrengen van een ongeldige kaart
  
Kaartconflict
  
Tijdsoverlapping
  
Rijden zonder een geschikte kaart
  
Inbrengen van de kaart tijdens het rijden
  
Laatste kaartsessie niet correct afgesloten
  
Snelheidsoverschrijding
  
Onderbreking in de stroomvoorziening
  
Fout in de bewegingsgegevens
  
Tegenstrijdige bewegingsgegevens
  
Inbreuk op de beveiliging  
▼M1
Tijdsconflict of tijdsafstelling (door werkplaats)  
▼B
Controle op snelheidsoverschrijding  
▼M1
Ontbreken van plaatsbepalingsinformatie van de GNSS-ontvanger of fout 
in de communicatie met de externe GNSS-module
  
Fout in de communicatie met het systeem voor communicatie op afstand  
▼B
Fouten
  
Kaartfout (lezer van de bestuurder)
  
Kaartfout (lezer van de bijrijder)
  
Displayfout  ▼B
02016R0799 — NL — 26.02.2020 — 002.001 — 257 
Downloadfout
  
Printerfout
  
Sensorfout
  
Interne fout in de VU
  
GNSS-fout
  
Fout in de detectie op afstand  
Procedure bij manuele invoer
  
Nog altijd dezelfde dagelijkse werkperiode?
  
Einde van de voorafgaande werkperiode?
  
Bevestig plaats van het einde van de werkperiode of voer deze in
  
Voer begintijd in
  
Voer plaats van het begin van de werkperiode in.  
Opmerking: Aanvullende pictogramcombinaties voor het vormen van 
een afdrukblok of recordidentificatiesymbolen worden in aanhangsel 4 
gedefinieerd.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 258  
Aanhangsel 4  
AFDRUKKEN  
INHOUDSOPGAVE  
1. ALGEMEEN  
2. SPECIFICATIE VAN GEGEVENSBLOKKEN  
3. AFDRUKSPECIFICATIES  
3.1. Dagelijkse afdruk van de kaart met de bestuurdersactiviteiten  
3.2. Dagelijkse afdruk van de VU met de bestuurdersactiviteiten  
3.3. Afdruk van de kaart van voorvallen en fouten  
3.4. Afdruk van de voertuigunit van voorvallen en fouten  
3.5. Afdruk van technische gegevens  
3.6. Afdruk van snelheidsoverschrijding  
3.7. Geschiedenis van ingebrachte kaarten  
1. ALGEMEEN  
Elke afdruk wordt opgebouwd door het achter elkaar plaatsen van di ­
verse gegevensblokken, mogelijk geïdentificeerd met een blokidentifi ­
catiesymbool.  
Een gegevensblok bevat een of meer records, mogelijk geïdentificeerd 
met een recordidentificatiesymbool.  
PRT_001 Wanneer een blokidentificatiesymbool onmiddellijk voor ­
afgaat aan een recordidentificatiesymbool, wordt het recordi ­
dentificatiesymbool niet afgedrukt.  
PRT_002 Als een gegevensbestanddeel onbekend is of niet afgedrukt 
mag worden wegens gegevenstoegangsrechten, worden in 
plaats daarvan spaties afgedrukt.  
PRT_003 Als de inhoud van een volledige regel onbekend is of niet 
afgedrukt hoeft te worden, wordt de volledige regel wegge ­
laten.  
PRT_004 Numerieke gegevensvelden worden rechts uitgelijnd afge ­
drukt, met een spatie voor duizendtallen en miljoenen en 
zonder voorafgaande nullen.  
PRT_005 Gegevensvelden met opeenvolgende tekens worden links uit ­
gelijnd afgedrukt en opgevuld met spaties tot de lengte van 
het gegevensbestanddeel of, indien nodig, afgekapt tot de 
lengte van het gegevensbestanddeel (namen en adressen).  
PRT_006 Als een regel wordt afgebroken als gevolg van een lange 
tekst, moet een bijzonder teken (een punt op halve regelhoog ­
te, ”•”) worden afgedrukt als eerste teken van de nieuwe 
regel.  
2. SPECIFICATIE VAN GEGEVENSBLOKKEN  
In dit hoofdstuk zijn de onderstaande opmaakcriteria gehanteerd:  
— vet gedrukte letters geven standaardtekst aan die afgedrukt moet 
worden (afdrukken gebeurt in gewone letters);  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 259  
— gewone letters geven variabelen aan (pictogrammen of gegevens) die 
door hun afdrukwaarden moeten worden vervangen;  
— namen van variabelen zijn onderstreept om de lengte van het gege ­
vensbestanddeel te tonen die voor de variabele ter beschikking is;  
— datums worden gespecificeerd in de vorm ”dd/mm/jjjj” (dag, maand, 
jaar). De vorm ”dd.mm.jjjj” mag ook worden gebruikt;  
— de term ”kaartidentificatie” verwijst naar: de kaartsoort door middel 
van een pictogramcombinatie van de kaart, de code van de lidstaat 
van afgifte, een schuine streep en het kaartnummer waarin de ver ­
vangingsindex en de vernieuwingsindex door een spatie gescheiden 
zijn: 
P
 x  x  x  / x  x  x  x  x  x  x  x  x  x  x  x  x  x  x  x
 Kaartpictogram- 
combinaties  
Code van de lidstaat 
van afgifte Eerste 14 tekens van het kaartnummer 
(bevat eventueel een opeenvolgende index)
 
Vervangingsindex  
Vernieuwingsindex ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 260  
PRT_007 Afdrukken maken gebruik van de volgende gegevensblokken en/of 
-records overeenkomstig de volgende betekenissen en opmaken:
  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 261
  
▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 262
  
► (1) (2) M1 ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 263
  
▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 264
  
▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 265
  
▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 266
  
3. AFDRUKSPECIFICATIES  
In dit hoofdstuk worden de onderstaande standaardtekens gebruikt: 
N Afdrukblok of record nummer N  
N Afdrukblok of record nummer N, zo vaak als nodig herhaald  
X/Y Afdrukblokken of records X en/of Y indien nodig, en zo vaak als 
nodig herhaald  
3.1. Dagelijkse afdruk van de kaart met de bestuurdersactiviteiten  
PRT_008 De dagelijkse afdruk van de kaart met de activiteiten van de 
bestuurder moet in overeenstemming zijn met onderstaande 
opmaak: 
1 Datum en tijdstip waarop het document is afgedrukt.  
2 Soort afdruk  
3 Identificatie van de controleur (indien een controlekaart in de VU is 
ingebracht)  
3 Bestuurdersidentificatie (van de kaart die wordt afgedrukt + GEN)  
4 Identificatie van het voertuig (voertuig waarvan de afdruk wordt ge ­
maakt)  
5 VU-identificatie (VU waarvan de afdruk wordt gemaakt + GEN)  
6 Laatste kalibrering van deze VU  
7 Laatste controle van de bestuurder  
8 Begrenzer van de bestuurdersactiviteiten  
8a ”Niet verplicht”-toestand aan het begin van deze dag  
8.1a / 8.1b / 8.1c / 8.2 / 
8.3 / 8.3a / 8.4  Activiteiten van de bestuurder in de volgorde waarin zij zich voor ­
deden  
11 Dagelijks overzicht begrenzer  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 267  
11.4 Ingevoerde plaatsen in chronologische volgorde  
▼M1 
11.5 Posities na 3 uur cumulatieve rijtijd, in chronologische volgorde  
▼B 
11.6 Totaal van activiteiten  
12.1 Begrenzer van voorvallen of fouten uit kaart  
12.4 Voorval/fout-records (laatste 5 op de kaart opgeslagen voorvallen of 
fouten)  
13.1 Begrenzer van voorvallen of fouten uit VU  
13.4 Voorval/fout-records (laatste 5 opgeslagen of lopende voorvallen of 
fouten in de VU)  
22.1 Controleplaats  
22.2 Handtekening van de controleur  
22.5 Handtekening van de bestuurder  
3.2. Dagelijkse afdruk van de VU met de bestuurdersactiviteiten  
PRT_009 De dagelijkse afdruk van de VU van de activiteiten van de 
bestuurder moet in overeenstemming zijn met onderstaande 
opmaak:  
▼M1 
1 Datum en tijdstip waarop het document is afgedrukt  
2 Soort afdruk  
3 Identificatie van de kaarthouder (voor alle in de VU in ­
gebrachte kaarten + GEN)  
4 Identificatie van het voertuig (voertuig waarvan de afdruk 
wordt gemaakt)  
5 VU-identificatie (VU waarvan de afdruk wordt gemaakt + 
GEN)  
6 Laatste kalibrering van deze VU  
7 Laatste controle van deze tachograaf  
9 Begrenzer van de bestuurdersactiviteiten  
10 Begrenzer van de lezer voor de bestuurder (lezer 1)  
10a „Niet verplicht”-toestand aan het begin van deze dag  
10.1 / 10.2 / 10.3 / 
10.3a / 10.4  Activiteiten in chronologische volgorde (lezer voor de be ­
stuurder)  
10 Begrenzer van de lezer voor de bijrijder (lezer 2)  
10a „Niet verplicht”-toestand aan het begin van deze dag  
10.1 / 10.2 / 10.3 / 
10.3a / 10.4  Activiteiten in chronologische volgorde (lezer voor de bij ­
rijder)  
11 Dagelijks overzicht begrenzer  
11.1 Overzicht van perioden zonder kaart in lezer voor bestuurder  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 268  
11.4 Ingevoerde plaatsen in chronologische volgorde  
11.5 Posities na 3 uur cumulatieve rijtijd, in chronologische volg ­
orde 
11.7 Totaal van activiteiten  
11.2 Overzicht van perioden zonder kaart in lezer voor bijrijder  
11.4 Ingevoerde plaatsen in chronologische volgorde  
11.5 Posities na 3 uur cumulatieve rijtijd, in chronologische volg ­
orde 
11.8 Totaal van activiteiten  
11.3 Overzicht van activiteiten van een bestuurder, beide lezers 
inbegrepen  
11.4 Door deze bestuurder ingevoerde plaatsen, in chronologische 
volgorde  
11.5 Posities na 3 uur cumulatieve rijtijd, in chronologische volg ­
orde 
11.9 Totaal van activiteiten voor deze bestuurder  
13.1 Begrenzer voorvallen/fouten  
13.4 Voorval/fout-records (laatste 5 opgeslagen of lopende voor ­
vallen of fouten in de VU)  
22.1 Controleplaats  
22.2 Handtekening van de controleur  
22.3 Van tijd (ruimte voor een bestuurder zonder een kaart om 
aan te geven  
22.4 Tot tijd ...… welke perioden voor hem relevant zijn)  
22.5 Handtekening van de bestuurder  
▼B 
3.3. Afdruk van de kaart van voorvallen en fouten  
PRT_010 De afdruk van de kaart met voorvallen en fouten moet in 
overeenstemming zijn met onderstaande opmaak: 
1 Datum en tijdstip waarop het document is afgedrukt.  
2 Soort afdruk  
3 Identificatie van de controleur (indien een controlekaart in de VU is 
ingebracht + GEN)  
3 Identificatie van de bestuurder (van de kaart waarvan de afdruk ge ­
maakt wordt)  
4 Identificatie van het voertuig (voertuig waarvan de afdruk wordt ge ­
maakt)  
12.2 Begrenzer van voorvallen  
12.4 Voorvalrecords (alle op de kaart opgeslagen voorvallen)  
12.3 Begrenzer van fouten  
12.4 Foutrecords (alle op de kaart opgeslagen fouten)  
22.1 Controleplaats  
22.2 Handtekening van de controleur  
22.5 Handtekening van de bestuurder  ▼M1
 02016R0799 — NL — 26.02.2020 — 002.001 — 269  
3.4. Afdruk van de voertuigunit van voorvallen en fouten  
PRT_011 De afdruk van de VU met voorvallen en fouten moet in 
overeenstemming zijn met onderstaande opmaak: 
1 Datum en tijdstip waarop het document is afgedrukt.  
2 Soort afdruk  
3 Identificatie van de kaarthouder (voor alle in de VU ingebrachte 
kaarten + GEN)  
4 Identificatie van het voertuig (voertuig waarvan de afdruk wordt ge ­
maakt)  
13.2 Begrenzer van voorvallen  
13.4 Voorvalrecords (alle in de VU opgeslagen of aanhoudende voorval ­
len) 
13.3 Begrenzer van fouten  
13.4 Foutrecords (alle in de VU opgeslagen of aanhoudende fouten)  
22.1 Controleplaats  
22.2 Handtekening van de controleur  
22.5 Handtekening van de bestuurder  
3.5. Afdruk van technische gegevens  
PRT_012 De afdruk van technische gegevens moet in overeenstemming 
zijn met onderstaande opmaak: 
1 Datum en tijdstip waarop het document is afgedrukt.  
2 Soort afdruk  
3 Identificatie van de kaarthouder (voor alle in de VU ingebrachte 
kaarten + GEN)  
4 Identificatie van het voertuig (voertuig waarvan de afdruk wordt ge ­
maakt)  
14 VU-identificatie  
15 Identificatie van de sensor  
15.1 Gegevens over sensorverbinding (alle gegevens in chronologische 
volgorde)  
16 GNSS-identificatie  
16.1 Gegevens over verbinding met de GNSS-module (alle gegevens in 
chronologische volgorde)  
17 Begrenzer van kalibreringsgegevens  
17.1 Kalibreringsrecords (alle records in chronologische volgorde)  
18 Begrenzer van de tijdafstelling  
18.1 Tijdafstellingsrecords (alle records van tijdafstelling en kalibrerings ­
gegevens)  
19 Meest recent(e) door de VU geregistreerd(e) voorval en fout  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 270  
3.6. Afdruk van snelheidsoverschrijding.  
PRT_013 De afdruk van snelheidsoverschrijding moet in overeenstem ­
ming zijn met onderstaande opmaak: 
1 Datum en tijdstip waarop het document is afgedrukt.  
2 Soort afdruk  
3 Identificatie van de kaarthouder (voor alle in de VU ingebrachte 
kaarten + GEN)  
4 Identificatie van het voertuig (voertuig waarvan de afdruk wordt ge ­
maakt)  
20 Informatie over snelheidsoverschrijdingscontrole  
21.1 Identificatiesymbool snelheidsoverschrijdingsgegevens  
21.4 / 21.5  Eerste snelheidsoverschrijding na de laatste kalibrering  
21.2 Identificatiesymbool snelheidsoverschrijdingsgegevens  
21.4 / 21.5  De 5 grootste snelheidsoverschrijdingen in de afgelopen 365 dagen  
21.3 Identificatiesymbool snelheidsoverschrijdingsgegevens  
21.4 / 21.5  De grootste snelheidsoverschrijding op elk van de laatste 10 dagen 
waarop snelheidsoverschrijdingen plaatsvonden  
22.1 Controleplaats  
22.2 Handtekening van de controleur  
22.5 Handtekening van de bestuurder  
3.7. Geschiedenis van ingebrachte kaarten  
▼M1 
PRT_014 De afdruk van de geschiedenis van ingebrachte kaarten moet 
in overeenstemming zijn met onderstaande opmaak: 
1 Datum en tijdstip waarop het document is afgedrukt  
2 Soort afdruk  
3 Identificatie van de kaarthouder (voor alle in de VU ingebrachte 
kaarten)  
23 Laatste in de VU ingebrachte kaart  
23.1 Ingebrachte kaarten (tot 88 records)  
12.3 Begrenzer van fouten  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 271  
Aanhangsel 5  
DISPLAY  
In dit aanhangsel worden de onderstaande opmaakcriteria gehanteerd:  
— vet gedrukte letters geven standaardtekst aan die getoond moet worden (weer ­
gave blijft in gewone letters);  
— gewone letters geven variabelen aan (pictogrammen of gegevens) die bij de 
weergave door hun waarden moeten worden vervangen:  
— dd mm yyyy: dag, maand, jaar,  
— hh: uren,  
— mm: minuten,  
— D: duurpictogram,  
— EF: pictogramcombinatie van voorvallen of fouten,  
— O: pictogram van de werkingsmodus.  
DIS_001 Het controleapparaat toont de gegevens met gebruikmaking van onder ­
staande opmaak:  
Gegevens  Format  
Standaarddisplay  
Plaatselijke tijd
  
Werkingsmodus
  
Informatie over de bestuurder
  
Informatie over de bijrijder
  
”Niet verplicht” -omstandigheid geopend
  
Waarschuwingsdisplay  
Overschrijden van de ononderbroken rijtijd
  
Voorval of fout
  
Overige displays  
UTC-datum
  
Tijd 
Ononderbroken rijtijd en cumulatieve rusttijd van de be ­
stuurder
  
Ononderbroken rijtijd en cumulatieve rusttijd van de bijrij ­
der
 
Cumulatieve rijtijd van de bestuurder in de voorafgaande en 
de lopende week
  
Cumulatieve rijtijd van de bijrijder in de voorafgaande en de 
lopende week
  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 272  
Aanhangsel 6  
FRONTCONNECTOR VOOR KALIBRERING EN DOWNLOADEN  
INHOUDSOPGAVE  
1. HARDWARE  
1.1. Connector  
1.2. Contacttoewijzing  
1.3. Blokschema  
2. DOWNLOADINTERFACE  
3. KALIBRERINGSINTERFACE  
1. HARDWARE  
1.1. Connector  
INT_001 De download-/kalibreringsconnector is een 6-pinsconnector die 
via het frontpaneel toegankelijk is zonder dat daarvoor delen van 
de tachograaf moeten worden losgekoppeld. De connector stemt 
overeen met de onderstaande tekening (alle maten in millime ­
ters):
 ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 273  
Het onderstaande schema toont een normale 6-pinscontrastekker:
  
1.2. Contacttoewijzing  
INT_002 Contacten moeten overeenkomstig de onderstaande tabel worden 
toegewezen:  
Pin Beschrijving  Opmerking  
1 Minpool  Verbonden met de minpool van het voertuig  
2 Gegevensoverdracht  K-lijn (ISO 14230-1)  
3 RxD — Download  Gegevensinvoer naar tachograaf  
4 Invoer-/uitvoersignaal  Kalibrering  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 274  
Pin Beschrijving  Opmerking  
5 Permanente vermogensafgifte  Het spanningsbereik wordt gespecificeerd als het vermogen 
van het voertuig minus 3 V met het oog op optredend span ­
ningsverlies in de veiligheidsschakelingen 
Output 40 mA  
6 TxD — Download  Gegevensuitvoer van tachograaf  
1.3. Blokschema  
INT_003 Het blokschema moet aan het onderstaande voldoen:
  
2. DOWNLOADINTERFACE  
INT_004 De downloadinterface moet voldoen aan RS232-specificaties.  
INT_005 De downloadinterface moet een startbit, 8 gegevensbits met LSB 
als eerste bit, een even pariteitsbit en 1 stopbit gebruiken.
  
Organisatie van gegevensbits  
Startbit: een bit met logisch niveau 0;  
Gegevensbits: verzonden met LSB als eerste bit;  
Pariteitsbit: even pariteit  
Stopbit: een bit met logisch niveau 1  
Wanneer numerieke gegevens verzonden worden die uit meer dan een byte 
bestaan, wordt de significantste byte het eerst verzonden en de minst 
significante byte het laatst.  
INT_006 Baudsnelheden van de transmissie moeten instelbaar zijn tussen 
9 600 bps en 115 200 bps. De transmissie moet met de hoogst 
mogelijke transmissiesnelheid worden uitgevoerd, waarbij de ini ­
tiële baudsnelheid na het begin van de overdracht op 9 600 bps 
moet worden gezet.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 275  
3. KALIBRERINGSINTERFACE  
INT_007 De gegevensoverdracht moet voldoen aan ISO 14230-1 Road 
vehicles — Diagnostic systems — Keyword protocol 2000 — 
Part 1: Physical layer, First edition: 1999.  
INT_008 Het invoer-/uitvoersignaal moet voldoen aan de onderstaande 
elektrische specificatie:  
Parameter  Minimum  Normaal  Maximum  Opmerking  
U low (in) 1,0 V  I = 750 μA 
U high (in) 4 V  I = 200 μA 
Frequentie  4 kHz  
U low (uit) 1,0 V  I = 1 mA  
U high (uit) 4 V  I = 1 mA  
INT_009 Het invoer-/uitvoersignaal moet voldoen aan de onderstaande 
tijdschema's:
  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 276  
Aanhangsel 7  
PROTOCOL VOOR GEGEVENSOVERDRACHT  
INHOUDSOPGAVE  
1. INLEIDING  
1.1. Toepassingsgebied  
1.2. Acroniemen en notaties  
2. GEGEVENSOVERDRACHT VAN DE VU  
2.1. Downloadprocedure  
2.2. Protocol voor gegevensoverdracht  
2.2.1 Berichtenstructuur  
2.2.2 Soorten berichten  
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 Berichtenstroom  
2.2.4 Tijdschema  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 277  
2.2.5 Behandeling van fouten  
2.2.5.1 Start communicatie-fase  
2.2.5.2 Overbrengingsfase  
2.2.6 Inhoud van het antwoordbericht  
2.2.6.1 Positive Response Transfer Data Overview  
2.2.6.2 Positive Response Transfer Data Activities  
2.2.6.3 Positive Response Transfer Data Events and Faults  
2.2.6.4 Positive Response Transfer Data Detailed Speed  
2.2.6.5 Positive Response Transfer Data Technical Data  
2.3. ESM bestandsopslag  
3. DOWNLOADPROTOCOL VAN TACHOGRAAFKAARTEN  
3.1. Toepassingsgebied  
3.2. Definities  
3.3. Kaartdownload  
3.3.1 Initialisatiesequentie  
3.3.2 Sequentie voor niet-getekende gegevensbestanden  
3.3.3 Sequentie voor getekende gegevensbestanden  
3.3.4 Sequentie voor het resetten van de kalibreringsteller  
3.4. Opmaak gegevensopslag  
3.4.1 Inleiding  
3.4.2 Bestandsopmaak  
4. DOWNLOADEN VAN EEN TACHOGRAAFKAART VIA EEN 
VOERTUIGUNIT  
1. INLEIDING  
In dit aanhangsel worden de te volgen procedures gespecificeerd voor 
het uitvoeren van de verschillende soorten gegevensoverdrachten naar 
een extern opslagmedium (ESM), alsmede de te implementeren proto ­
collen om de correcte gegevensoverdracht en de volledige compatibi ­
liteit van het overgebrachte gegevensformaat te waarborgen zodat een 
controleur deze gegevens kan inspecteren en de authenticiteit en inte ­
griteit ervan kan controleren voordat hij de gegevens analyseert.  
▼M1 
1.1. Toepassingsgebied  
Gegevens kunnen naar een ESM worden gedownload:  
— uit een voertuigeenheid (VU), door met de VU verbonden intelli ­
gente toepassingsgerichte apparatuur (IDE),  
— vanaf een tachograafkaart door een met een kaartinterface-inrichting 
(IFD) uitgeruste IDE,  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 278  
— vanaf een tachograafkaart via een voertuigunit door een met de VU 
verbonden IDE.  
Om de authenticiteit en integriteit van de overgedragen, op een ESM 
opgeslagen gegevens te kunnen verifiëren, worden gegevens ge ­
download met een toegevoegde handtekening overeenkomstig de alge ­
mene beveiligingsmechanismen van aanhangsel 11. De identificatie van 
het bronapparaat (VU of kaart) en de beveiligingscertificaten (lidstaat 
en apparaat) worden ook gedownload. De controleur van de gegevens 
moet zelf een betrouwbare Europese openbare sleutel in zijn bezit 
hebben.  
Gegevens die worden gedownload van een VU worden ondertekend 
overeenkomstig aanhangsel 11 (Algemene beveiligingsmechanismen), 
deel B (Tachograafsystemen van de tweede generatie), behalve wan ­
neer de controle op de bestuurder wordt uitgevoerd door een contro ­
leautoriteit van buiten de EU, waarbij gebruik wordt gemaakt van een 
controlekaart van de eerste generatie; in dat geval worden de gegevens 
ondertekend overeenkomstig aanhangsel 11 (Algemene beveiligings ­
mechanismen), deel A (Tachograafsystemen van de eerste generatie), 
zoals vereist uit hoofde van punt MIG_015 van aanhangsel 15 (Migra ­
tie). 
In dit aanhangsel worden dus twee types van gegevensdownload van 
de VU gespecificeerd:  
— gegevensdownloads van VU’s van de tweede generatie, met de 
gegevensstructuur van de tweede generatie, ondertekend overeen ­
komstig aanhangsel 11 (Algemene beveiligingsmechanismen), deel 
B, 
— gegevensdownloads van VU’s van de eerste generatie, met de ge ­
gevensstructuur van de eerste generatie, ondertekend overeenkom ­
stig aanhangsel 11 (Algemene beveiligingsmechanismen), deel A.  
Naar analogie hiermee bestaan er ook twee soorten gegevensdownload 
van bestuurderskaarten van de tweede generatie die in een VU worden 
ingebracht, zoals gespecificeerd in punten 3 en 4 van dit aanhangsel.  
▼B 
1.2. Acroniemen en notaties  
In dit aanhangsel worden de onderstaande acroniemen gebruikt:  
AID Applicatie-identificatie  
ATR  Antwoord op reset  
CS Controlesombyte  
DF Toepassingsgericht bestand  
DS_ Diagnostische sessie  
EF Hoofdbestand  
ESM  Extern opslagmedium  
FID Bestandsidentificatiesymbool (bestands-ID)  
FMT  Opmaakbyte (eerste byte van het beginlabel van het bericht)  
ICC Chipkaart  
IDE Intelligente toepassingsgerichte apparatuur: de apparatuur die 
wordt gebruikt voor het downloaden van gegevens naar het 
ESM (bijv. pc)  
IFD Interface-apparaat  
KWP  Sleutelwoordprotocol 2000  
LEN  Lengtebyte (laatste byte van het beginlabel van het bericht)  
PPS Protocol parameterselectie  
PSO  Voer beveiligingsoperatie uit  
SID Dienstidentificatiesymbool  
SRC  Bronbyte  
TGT  Doelbyte  ▼M1
 02016R0799 — NL — 26.02.2020 — 002.001 — 279  
TLV  Waarde van de labellengte  
TREP  Parameter overdracht antwoord  
TRTP  Parameter overdracht verzoek  
VU Voertuigunit  
2. GEGEVENSOVERDRACHT VAN DE VU  
2.1. Downloadprocedure  
Om gegevens van een VU te downloaden, moet de operator de onder ­
staande handelingen verrichten:  
— zijn tachograafkaart in een kaartlezer van de VU inbrengen (*);  
— de IDE met de downloadconnector van de VU verbinden;  
— de verbinding tussen de IDE en de VU tot stand brengen;  
— de over te brengen gegevens in de IDE selecteren en het verzoek 
naar de VU sturen;  
— de downloadsessie sluiten.  
2.2. Protocol voor gegevensoverdracht  
Het protocol is gestructureerd op een master-slavebasis, waarbij de IDE 
de rol van master speelt en de VU de rol van slave.  
De berichtenstructuur, berichtensoorten en berichtenstroom zijn hoofd ­
zakelijk gebaseerd op het Sleutelwoordprotocol 2000 (KWP) (ISO 
14230-2 Road vehicles — Diagnostic systems — Keyword protocol 
2000 — Part 2: Data link layer).  
De applicatielaag is hoofdzakelijk gebaseerd op het huidige ontwerp 
van ISO 14229-1 (Road vehicles — Diagnostic systems — Part 1: 
Diagnostic services, version 6 of 22 February 2001).  
2.2.1  Berichtenstructuur  
DDP_002 Alle tussen de IDE en de VU uitgewisselde berichten zijn 
opgemaakt volgens een uit drie delen bestaande structuur:  
— beginlabel bestaande uit een opmaakbyte (FMT), een 
doelbyte (TGT), een bronbyte (SRC) en eventueel een 
lengtebyte (LEN);  
— gegevensveld bestaande uit een identificatiebyte van de 
dienst (SID) en een variabel aantal gegevensbytes, die 
een facultatieve diagnosesessiebyte (DS_) dan wel een 
facultatieve overdrachtparameterbyte (TRTP of TREP) 
kunnen omvatten;  
— controlesom bestaande uit een controlesombyte (CS).  
Beginlabel  Gegevensveld  Controlesom  
FMT  TGT  SRC  LEN  SID  DATA  …  …  …  CS  
4 bytes  Max. 255 bytes  1 byte  
De TGT- en SRC-byte vertegenwoordigen het fysieke adres 
van de ontvanger en verzender van het bericht. Waarden 
zijn F0 Hex voor de IDE en EE Hex voor de VU.  
De LEN-byte is de lengte van het gegevensvelddeel.  ▼B 
(*) De ingebrachte kaart geeft de vereiste toegangsrechten voor het downloaden en tot de 
gegevens. Het is echter mogelijk gegevens over te brengen van een in één van de VU- 
lezers ingebrachte kaart als geen andere kaart in de andere lezer is ingebracht.
 02016R0799 — NL — 26.02.2020 — 002.001 — 280  
De controlesombyte is de 8-bits somserie module 256 van 
alle bytes van het bericht exclusief de CS zelf.  
FMT, SID, DS_, TRTP en TREP-bytes worden verderop in 
dit document gedefinieerd.  
DDP_003 Als de door het bericht over te dragen gegevens groter zijn 
dan de beschikbare ruimte in het gegevensvelddeel, wordt 
het bericht in een aantal subberichten verzonden. Elk sub ­
bericht heeft een beginlabel, hetzelfde SID en dezelfde 
TREP en een teller van 2 bytes voor de subberichten die 
het volgnummer van het subbericht binnen het totale bericht 
aangeeft. Met het oog op foutencontrole en voortijdige be ­
ëindiging bevestigt de IDE elk subbericht. De IDE kan het 
subbericht accepteren, vragen om het opnieuw te zenden, de 
VU verzoeken om opnieuw te beginnen of de overbrenging 
afbreken.  
DDP_004 Indien het laatste subbericht precies 255 bytes in het gege ­
vensveld bevat, moet een laatste subbericht met een leeg 
gegevensveld (met uitzondering van SID, TREP en teller 
van de subberichten) worden toegevoegd dat het einde van 
het bericht aangeeft.  
Voorbeeld:  
Beginlabel  SID  TREP  Bericht  CS  
4 bytes  Langer dan 255 bytes  
Wordt overgebracht als:  
Beginlabel  SID  TREP  00  01  Subbericht 1  CS  
4 bytes  255 bytes  
Beginlabel  SID  TREP  00  02  Subbericht 2  CS  
4 bytes  255 bytes  
… 
Beginlabel  SID  TREP  xx  yy  Subbericht n  CS  
4 bytes  Minder dan 255 bytes  
of als:  
Beginlabel  SID  TREP  00  01  Subbericht 1  CS  
4 bytes  255 bytes  
Beginlabel  SID  TREP  00  02  Subbericht 2  CS  
4 bytes  255 bytes  
… 
Beginlabel  SID  TREP  xx  yy  Subbericht n  CS  
4 bytes  255 bytes  
Beginlabel  SID  TREP  xx  yy + 1  CS  
4 bytes  4 bytes  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 281  
2.2.2  Soorten berichten  
Het communicatieprotocol voor de gegevensoverdracht tussen de VU 
en de IDE vereist de uitwisseling van 8 verschillende berichtensoorten.  
De onderstaande tabel vat deze berichten samen.  
▼M1 
Berichtstructuur  Max. 4 bytes Header  Max. 255 bytes Gegevens  1 byte 
Contro­
lesom  
IDE ->  <- VU  FMT  TGT  SRC  LEN  SID  DS_ / TRTP  GEGEVENS  CS  
Start Communication Request  81  EE  F0  81  E0  
Positive Response Start Com ­
munication  80 F0  EE  03  C1  EA, 8F  9B  
Start Diagnostic Session Re ­
quest  80 EE  F0  02  10  81  F1  
Positive Response Start Dia ­
gnostic  80 F0  EE  02  50  81  31  
Link Control Service  
Verify Baud Rate (stage 1)  
9 600 Bd  80  EE  F0  04  87  01,01,01  EC  
19 200 Bd  80  EE  F0  04  87  01,01,02  ED  
38 400 Bd  80  EE  F0  04  87  01,01,03  EE  
57 600 Bd  80  EE  F0  04  87  01,01,04  EF  
115 200 Bd  80  EE  F0  04  87  01,01,05  F0  
Positive Response Verify Baud 
Rate 80 F0  EE  02  C7  01  28  
Transition Baud Rate (stage 2)  80  EE  F0  03  87  02,03  ED  
Request Upload  80  EE  F0  0A  35  00,00,00, 
00,00,FF,FF, 
FF,FF  99 
Positive Response Request 
Upload  80 F0  EE  03  75  00,FF  D5  
Transfer Data Request  
Overview  80  EE  F0  02  36  01 or 21  97  
Activities  80  EE  F0  06  36  02 or 22  Date  CS  
Events & Faults  80  EE  F0  02  36  03 or 23  Date  99  
Detailed Speed  80  EE  F0  02  36  04 or 24  Date  9A  
Technical Data  80  EE  F0  02  36  05 or 25  Date  9B  
Card download  80  EE  F0  02  36  06  Slot  CS  
Positive Response Transfer 
Data  80 F0  EE  Len  76  TREP  Data  CS  
Request Transfer Exit  80  EE  F0  01  37  96  
Positive Response Request 
Transfer Exit  80 F0  EE  01  77  D6  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 282  
Berichtstructuur  Max. 4 bytes Header  Max. 255 bytes Gegevens  1 byte 
Contro­
lesom  
IDE ->  <- VU  FMT  TGT  SRC  LEN  SID  DS_ / TRTP  GEGEVENS  CS  
Stop Communication Request  80  EE  F0  01  82  E1  
Positive Response Stop Com ­
munication  80 F0  EE  01  C2  21  
Acknowledge sub message  80  EE  F0  Len  83  Data  CS  
Negative responses  
General reject  80  F0  EE  03  7F  Sid Req  10  CS  
Service not supported  80  F0  EE  03  7F  Sid Req  11  CS  
Sub function not supported  80  F0  EE  03  7F  Sid Req  12  CS  
Incorrect Message Length  80  F0  EE  03  7F  Sid Req  13  CS  
Conditions not correct or Re ­
quest sequence error  80 F0  EE  03  7F  Sid Req  22  CS  
Request out of range  80  F0  EE  03  7F  Sid Req  31  CS  
Upload not accepted  80  F0  EE  03  7F  Sid Req  50  CS  
Response pending  80  F0  EE  03  7F  Sid Req  78  CS  
Data not available  80  F0  EE  03  7F  Sid Req  FA  CS  
▼B 
Opmerkingen:  
▼M1 
— TRTP 21 tot en met 25 worden gebruikt voor gegevensdownload ­
verzoeken van VU’s van de tweede generatie, TRTP 01 tot en met 
05 worden gebruikt voor gegevensdownloadverzoeken van VU’s 
van de eerste generatie, die alleen door de VU kunnen worden 
aanvaard wanneer de bestuurderscontrole wordt uitgevoerd door 
een controleautoriteit van buiten de EU, waarbij gebruik wordt 
gemaakt van een controlekaart van de eerste generatie.  
— TRTP 11 tot en met 19 en 31 tot en met 39 zijn voorbehouden voor 
fabrikantspecifieke downloadverzoeken.  
▼B 
— Sid Req = het Sid van het corresponderende verzoek.  
— TREP = de TRTP van het corresponderende verzoek.  
— Zwarte cellen geven aan dat niets wordt overgebracht.  
— De term upload (vanaf de IDE) wordt gebruikt voor compatibiliteit 
met ISO 14229. Het betekent hetzelfde als download (vanaf de 
VU).  
— Potentiële tellers van 2 bytes voor het tellen van subberichten wor ­
den in deze tabel niet getoond.  
— Lezer is het lezernummer, ”1” (kaart in de lezer van de bestuurder) 
of ”2” (kaart in de lezer van de bijrijder).  
— Indien de lezer niet is gespecificeerd, kiest de VU lezer 1 indien 
een kaart in die lezer is ingebracht en kiest hij lezer 2 alleen als die 
specifiek door de gebruiker wordt geselecteerd.  
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 Dit bericht wordt door de IDE verstrekt om de overdrachts ­
verbinding met de VU tot stand te brengen. Aanvankelijk 
vindt overdracht steeds plaats bij 9 600 baud (tot de baud ­
snelheid uiteindelijk wordt gewijzigd met behulp van de 
passende Link Control Service).  ▼M1
 02016R0799 — NL — 26.02.2020 — 002.001 — 283  
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 Dit bericht wordt door de VU verstrekt om positief te ant ­
woorden op een verzoek om de start van de overdracht. Het 
bevat de 2 sleutelbytes ‘EA’ en ‘8F’, die aangeven dat de 
unit het protocol met beginlabel inclusief informatie over 
doel, bron en lengte ondersteunt.  
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 Het bericht Start Diagnostic Session Request wordt door de 
IDE verstrekt om een nieuwe diagnostische sessie met de 
VU aan te vragen. De subfunctie ‘defaultsessie’ (81 Hex) 
geeft aan dat een standaard diagnostische sessie wordt ge ­
opend.  
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 Het bericht Positive Response Start Diagnostic wordt door 
de VU gezonden om positief te antwoorden op Diagnostic 
Session Request.  
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 De Link Control Service wordt door de IDE gebruikt om 
een wijziging in de baudsnelheid te starten. Dat gebeurt in 
twee stappen. In stap een stelt de IDE voor de baudsnelheid 
te wijzigen, met vermelding van de nieuwe snelheid. Na 
ontvangst van een positief bericht van de VU zendt de 
IDE bevestiging van de wijziging van de baudsnelheid 
naar de VU (stap twee). De IDE gaat dan over op de nieuwe 
baudsnelheid. Na ontvangst van de bevestiging gaat de VU 
over op de nieuwe baudsnelheid.  
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 De Link Control Positive Response wordt door de VU ge ­
geven om positief te antwoorden op het verzoek van de 
Link Control Service (stap een). Merk op dat het bevesti ­
gingsbericht niet wordt beantwoord (stap twee).  
2.2.2.7 R e q u e s t U p l o a d ( S I D 3 5 )  
DDP_009 Het bericht Request Upload wordt door de IDE verstrekt om 
aan de VU te melden dat een downloadoperatie wordt ge ­
vraagd. Om aan het vereiste in ISO 14229 te voldoen, wor ­
den daarin gegevens opgenomen met betrekking tot het 
adres, de grootte en het formaat voor de gevraagde gege ­
vens. Aangezien de IDE deze vóór de overbrenging niet 
kent, wordt het geheugenadres op 0 ingesteld, wordt het 
formaat niet geëncrypteerd en gecomprimeerd en wordt de 
geheugengrootte op het maximum ingesteld.  
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 Het bericht Positive Response Request Upload wordt door 
de VU gezonden om de IDE te laten weten dat de VU 
gereed is om gegevens te downloaden. Om aan het vereiste 
in ISO 14229 te voldoen, worden in dit positieve antwoord ­
bericht gegevens opgenomen om de IDE te laten weten dat 
verdere Positive Response Transfer Data-berichten maxi ­
maal 00FF hex bytes zullen bevatten.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 284  
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 Het Transfer Data Request wordt door de IDE gezonden om 
de soort over te brengen gegevens mee te delen aan de VU. 
Een Transfer Request Parameter (TRTP) van één byte geeft 
de soort overdracht aan.  
Er zijn zes soorten gegevensoverdracht. Voor gegevens ­
downloads uit VU kunnen twee verschillende TRTP-waar ­
den worden gebruikt voor elk type overdracht.  
Type gegevensover ­
dracht  TRTP-waarden voor 
gegevensdownloads 
van VU’s van de 
eerste generatie  TRTP-waarden voor 
gegevensdownloads 
van VU’s van de 
eerste generatie  
Overview  01  21  
Activiteiten van 
een gespecifi ­
ceerde datum  02 22  
Voorvallen en 
fouten  03 23  
Gedetailleerde 
snelheid  04 24  
Technische gege ­
vens 05 25  
Type gegevens ­
overdracht  TRTP-waarde  
Card download  06  
DDP_054 De IDE is verplicht gedurende een overdrachtsessie de over ­
dracht van overzichtsgegevens (TRTP 01 of 21) aan te vra ­
gen, omdat alleen dit garandeert dat de VU-certificaten in 
het gedownloade bestand worden geregistreerd (en verifica ­
tie van de digitale handtekening mogelijk maakt).  
In het tweede geval (TRTP 02 of 22) bevat het bericht 
Transfer Data Request de aanwijzing van de te downloaden 
kalenderdag (
  opmaak).  
▼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 Het Positive Response Transfer Data wordt door de VU 
verzonden in antwoord op het Transfer Data Request. Het 
bericht bevat de gevraagde gegevens met een Transfer Res ­
ponse Parameter (TREP) die correspondeert met de TRTP 
van het verzoek.  
▼M1 
DDP_055 In het eerste geval (TREP 01 of 21) zendt de VU gegevens 
waarmee de operator van de IDE kan kiezen welke gege ­
vens hij verder wil overdragen. De in dit bericht opgenomen 
informatie bestaat uit:  
— veiligheidscertificaten,  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 285  
— identificatie van het voertuig,  
— huidige datum en tijd van de VU,  
— min. en max. opvraagbare datum (VU-gegevens),  
— indicatie van in de VU aanwezige kaarten,  
— vorige download naar een bedrijf,  
— bedrijfsvergrendelingen,  
— vorige controles.  
▼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 Het bericht Request Transfer Exit wordt door de IDE ge ­
zonden om de VU te melden dat de overdrachtssessie be ­
ëindigd is.  
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 Het bericht Positive Response Request Transfer Exit wordt 
door de VU gezonden om het Request Transfer Exit te 
bevestigen.  
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 Het bericht Stop Communication Request wordt door de 
IDE gezonden om de overdrachtsverbinding met de VU te 
verbreken.  
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 Het bericht Positive Response Stop Communication wordt 
door de VU gezonden om het Stop Communication Request 
te bevestigen.  
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 Het Acknowledge Sub Message wordt door de IDE gezon ­
den om de ontvangst te bevestigen van elk deel van een 
bericht dat in een aantal subberichten wordt overgebracht. 
Het gegevensveld bevat het van de VU ontvangen SID en 
een code van 2 bytes:  
— MsgC + 1 bevestigt de correcte ontvangst van het sub ­
bericht met de code MsgC.  
Verzoek van de IDE aan de VU om het volgende sub ­
bericht te zenden.  
— MsgC geeft een probleem met de ontvangst van het 
subbericht met de code MsgC aan.  
Verzoek van de IDE aan de VU om het volgende sub ­
bericht te zenden.  
— FFFF verzoekt om de beëindiging van het bericht.  
Dit kan door de IDE worden gebruikt om de overbren ­
ging van het bericht van de VU om welke reden dan 
ook te beëindigen.  
Het laatste subbericht van een bericht (LEN byte < 255) kan 
met gebruikmaking van een van deze codes bevestigd of 
niet bevestigd worden.  
De uit verschillende subberichten bestaande antwoorden van 
de VU zijn:  
— Positive Response Transfer Data (SID 76).  ▼M1
 02016R0799 — NL — 26.02.2020 — 002.001 — 286  
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 Het bericht Negative Response wordt door de VU gezonden 
in antwoord op de bovengenoemde verzoeken wanneer de 
VU niet aan het verzoek kan voldoen. De gegevensvelden 
van het bericht bevatten het SID van het antwoord (7F), het 
SID van het verzoek en een code die de reden van het 
negatieve antwoord specificeert. De onderstaande codes 
zijn beschikbaar:  
— 10 algemene verwerping  
De actie kan niet worden uitgevoerd om een reden die 
hieronder niet wordt genoemd.  
— 11 dienst niet ondersteund  
Het SID van het verzoek wordt niet herkend.  
— 12 subfunctie niet ondersteund  
Het DS_ of TRTP van het verzoek wordt niet herkend 
of er zijn geen over te brengen subberichten meer.  
— 13 onjuiste lengte van het bericht  
De lengte van het ontvangen bericht is fout.  
— 22 voorwaarden niet correct of verzoeksequentiefout  
De gevraagde dienst is niet actief of de sequentie van 
verzoekberichten is niet correct.  
— 31 verzoek buiten bereik  
De verzoek parameter record (gegevensveld) is niet gel ­
dig. 
— 50 upload niet geaccepteerd  
Het verzoek kan niet worden uitgevoerd (VU in een 
niet-geschikte werkingsmodus of interne fout van de 
VU).  
— 78 antwoord in behandeling  
De verzochte actie kan niet op tijd worden beëindigd en 
de VU is niet klaar om een ander verzoek te accepteren.  
▼M1 
— FA-gegevens niet beschikbaar  
Het gegevensobject van een verzoek om gegevensover ­
dracht is niet beschikbaar in de VU (omdat er bijv. geen 
kaart is ingebracht, verzoek om download van gegevens 
van een VU van de eerste generatie buiten het kader van 
een bestuurderscontrole door een controleautoriteit van 
buiten de EU).  
▼B 
2.2.3  Berichtenstroom  
Een typische berichtenstroom tijdens een normale gegevensdownloads ­
procedure ziet er als volgt uit:  
IDE VU  
Start Communication Request  ⇨ 
⇦  Positive Response  
Start Diagnostic Service Request  ⇨ 
⇦  Positive Response  
Request Upload  ⇨ 
⇦  Positive Response  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 287  
IDE VU  
Transfer Data Request Overview  ⇨ 
⇦  Positive Response  
Transfer Data Request #2  ⇨ 
⇦  Positive Response #1  
Acknowledge Sub Message #1  ⇨ 
⇦  Positive Response #2  
Acknowledge Sub Message #2  ⇨ 
⇦  Positive Response #m  
Acknowledge Sub Message #m  ⇨ 
⇦  Positive Response (Data Field < 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  Tijdschema  
DDP_019 Tijdens de normale werking zijn de in de onderstaande 
figuur getoonde timingparameters relevant:  
Figuur 1  
Berichtenstroom, timing
  
Waarbij:  
P1 = Interbytetijd voor antwoord van de VU.  
P2 = Tijd tussen het einde van het verzoek van de IDE en 
de start van het antwoord van de VU, of tussen het 
einde van de bevestiging van de IDE en de start van 
het volgende antwoord van de VU.  
P3 = Tijd tussen het einde van het antwoord van de VU en 
de start van een nieuw verzoek van de IDE, of tussen 
het einde van het antwoord van de VU en de start van 
de bevestiging van de IDE, of tussen het einde van 
het verzoek van de IDE en de start van een nieuw 
verzoek van de IDE, indien de VU niet antwoordt.  
P4 = Interbytetijd voor verzoek van de IDE.  
P5 = Toegevoegde waarde van P3 voor kaartdownload.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 288  
De toegestane waarden van de timingparameters worden in 
de onderstaande tabel aangegeven (toebedeelde reeks ti ­
mingparameters van het KWP, gebruikt in geval van fysieke 
adressering voor snellere overdracht).  
Tijdschemaparameter  Benedengrenswaarde 
(ms) Bovengrenswaarde 
(ms) 
P1 0  20  
P2 20  1 000 (*)  
P3 10  5 000  
P4 5  20  
P5 10  20 minuten  
(*) Indien de VU antwoordt met een Negative Response die een code met de betekenis ”verzoek correct 
ontvangen, antwoord in behandeling” bevat, wordt deze waarde toegevoegd aan dezelfde bovengrenswaarde 
van P3.  
2.2.5  Behandeling van fouten  
Indien tijdens de uitwisseling van berichten een fout optreedt, wordt het 
berichtenstroomschema gewijzigd volgens de apparatuur die de fout 
heeft opgespoord en het bericht dat de fout heeft veroorzaakt.  
In figuur 2 en figuur 3 worden de procedures voor de behandeling van 
fouten voor respectievelijk de VU en de IDE getoond.  
2.2.5.1 S t a r t c o m m u n i c a t i e - f a s e  
DDP_020 Indien de IDE tijdens de start communicatie-fase, door ti ­
ming of door de bitstroom, een fout opspoort, dan moet de 
IDE een P3min-periode wachten alvorens het verzoek op ­
nieuw te doen.  
DDP_021 Indien de VU in de door de IDE gezonden sequentie een 
fout opspoort, mag de VU geen antwoord zenden maar moet 
hij wachten op een ander Start Communication Request- 
bericht binnen een P3max-periode.  
2.2.5.2 O v e r b r e n g i n g s f a s e  
Er kunnen twee verschillende gebieden voor de behandeling van fouten 
worden gedefinieerd:  
1. De VU spoort een overbrengingsfout van de IDE op.  
DDP_022 Voor elk ontvangen bericht moet de VU timingfouten, 
byteopmaakfouten (bijv. foutieve start- en stopbits) en 
frame errors (verkeerd aantal bytes ontvangen, foutieve 
controlesombyte) opsporen.  
DDP_023 Indien de VU een van de bovengenoemde fouten op ­
spoort, dan zendt hij geen antwoord en negeert hij het 
ontvangen bericht.  
DDP_024 De VU kan andere fouten in de opmaak of inhoud van 
het ontvangen bericht opsporen (bijv. bericht niet onder ­
steund), zelfs indien het bericht voldoet aan de lengte- en 
controlesomeisen; in dat geval moet de VU aan de IDE 
met een Negative Response-bericht antwoorden waarin de 
aard van de fout wordt gespecificeerd.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 289  
Figuur 2  
VU-foutbehandeling
  
2. De IDE spoort een overbrengingsfout van de VU op.  
DDP_025 Voor elk ontvangen bericht moet de IDE timingfouten, 
fouten in de byteopmaak (bijv. foutieve start- en stopbits) 
en frame errors (verkeerd aantal bytes ontvangen, fou ­
tieve controlesombyte) opsporen.  
DDP_026 De IDE moet sequentiefouten opsporen, bijv. niet cor ­
recte standverhogingen bij de teller van de subberichten 
bij na elkaar ontvangen berichten.  
DDP_027 Indien de IDE een fout opspoort of indien er binnen een 
P2max-periode geen antwoord van de VU was, wordt het 
verzoekbericht opnieuw gezonden met een maximum van 
totaal drie overbrengingen. Voor het doel van deze fou ­
tenopsporing wordt de bevestiging van een subbericht 
beschouwd als een verzoek aan de VU.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 290  
DDP_028 De IDE moet ten minste een P3min-periode wachten voor 
de start van elke overbrenging; de wachttijd moet worden 
gemeten vanaf de laatst berekende optreding van een 
stopbit nadat de fout was opgespoord.  
Figuur 3  
IDE-foutbehandeling
  
2.2.6  Inhoud van het antwoordbericht  
Dit punt specificeert de inhoud van de gegevensvelden van de verschil ­
lende positieve antwoordberichten.  
Gegevenselementen worden gedefinieerd in de data dictionary in aan ­
hangsel 1.  
Opmerking: Voor downloads van de 2e generatie wordt elk gegevens ­
element op het hoogste niveau vertegenwoordigd door een reeks re ­
cords, zelfs als het maar één record bevat. Een reeks records begint met 
een beginlabel. Dat beginlabel bevat het soort record, de grootte van 
het record en het aantal records. Reeksen records worden in de vol ­
gende tabellen aangeduid door ”…RecordArray” (met beginlabel).  
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 O v e r v i e w  
DDP_029  ►M1 Het gegevensveld van het bericht „Positive Response 
Transfer Data Overview” moet de onderstaande gegevens in 
de onderstaande volgorde onder het SID 76 Hex, het TREP 
01 of 21 Hex en de passende splitsing en telling van de 
subberichten verstrekken: ◄ ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 291  
Gegevensstructuur 1e generatie (TREP 01 Hex)  
▼B 
Gegevenselement  Opmerking
  
VU-veiligheidscertificaten
  
Identificatie van het voertuig
  
Huidige datum en tijd van de VU
  
Downloadbare periode
  
Soorten in de VU ingebrachte kaarten
  
Vorige VU-download
  
Alle bedrijfsvergrendelingen opgeslagen. Indien 
dit segment leeg is, wordt alleen noOfLocks = 
0 verzonden.
  
Alle in de VU opgeslagen controlerecords. In ­
dien dit segment leeg is, wordt alleen noOfCon ­
trols = 0 verzonden.
  
RSA-handtekening van alle gegevens (behalve 
certificaten) vanaf VehicleIdentificationNumber 
tot de laatste byte van de laatste VuControlActi ­
vityData.  
▼M1 
Gegevensstructuur 2e generatie (TREP 21 Hex)  
▼B 
Gegevenselement  Opmerking
  
Lidstaatcertificaat
  
VU-certificaat
  
Identificatie van het voertuig
  
Voertuigregistratienummer
  
Huidige datum en tijd van de VU
  
Downloadbare periode
  
Soorten in de VU ingebrachte kaarten
  
Vorige VU-download
  
Alle bedrijfsvergrendelingen opgeslagen. Indien 
het segment leeg is, wordt alleen een beginlabel 
van een reeks met noOfRecords = 0 verzonden.
  
Alle in de VU opgeslagen controlerecords. In ­
dien het segment leeg is, wordt alleen een begin ­
label van een reeks met noOfRecords = 0 ver ­
zonden.
  
ECC-handtekening van alle voorgaande gege ­
vens behalve de certificaten.  
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 A c t i v i t i e s  
DDP_030  ►M1 Het gegevensveld van het bericht „Positive Response 
Transfer Data Activities” moet de onderstaande gegevens in 
de onderstaande volgorde onder het SID 76 Hex, het TREP 
02 of 22 Hex en de passende splitsing en telling van de 
subberichten verstrekken: ◄ ▼M1
 02016R0799 — NL — 26.02.2020 — 002.001 — 292  
Gegevensstructuur 1e generatie (TREP 02 Hex)  
▼B 
Gegevenselement  Opmerking
  
Datum van de gedownloade dag
  
Kilometerstand aan het einde van de gedownloade dag
  
Gegevens over de cycli van inbrengen en uitnemen van 
kaarten. 
— Indien deze passage geen beschikbare gegevens be ­
vat, wordt alleen noOfVuCardIWRecords = 0 ver ­
zonden. 
— Wanneer een VuCardIWRecord 00:00 (kaart in ­
gebracht op de vorige dag) of 24:00 (kaart uitgeno ­
men de volgende dag) overschrijdt, wordt het vol ­
ledig getoond op de twee betrokken dagen.
  
Status van de lezers op 00:00 en opgeslagen activiteits ­
wijzigingen op de gedownloade dag.
  
Opgeslagen plaatsgegevens op de gedownloade dag. In ­
dien dit segment leeg is, wordt alleen noOfPlaceRecords = 
0 verzonden.
  
Opgeslagen gegevens over specifieke omstandigheden op 
de gedownloade dag. Indien dit segment leeg is, wordt 
alleen noOfSpecificConditionRecords = 0 verzonden.
  
RSA-handtekening van alle gegevens vanaf TimeReal tot 
de laatste byte van de laatste specifieke omstandigheden- 
record  
▼M1 
Gegevensstructuur 2e generatie (TREP 22 Hex)  
▼B 
Gegevenselement  Opmerking
  
Datum van de gedownloade dag
  
Kilometerstand aan het einde van de gedownloade dag
  
Gegevens over de cycli van inbrengen en uitnemen van 
kaarten. 
— Indien dit segment geen beschikbare gegevens bevat, 
wordt een beginlabel van een reeks met noOf ­
Records = 0 verzonden. 
— Wanneer een VuCardIWRecord 00:00 (kaart in ­
gebracht op de vorige dag) of 24:00 (kaart uitgeno ­
men de volgende dag) overschrijdt, wordt het vol ­
ledig getoond op de twee betrokken dagen.
  
Status van de lezers op 00:00 en opgeslagen activiteits ­
wijzigingen op de gedownloade dag.
  
Opgeslagen plaatsgegevens op de gedownloade dag. In ­
dien het segment leeg is, wordt een beginlabel van een 
reeks met noOfRecords = 0 verzonden.  
▼M1
 
GNSS-posities van het voertuig wanneer de cumulatieve 
rijtijd van het voertuig een veelvoud van drie uur bereikt. 
Indien het segment leeg is, wordt alleen een beginlabel 
van een reeks met noOfRecords = 0 verzonden.  ▼M1
 02016R0799 — NL — 26.02.2020 — 002.001 — 293  
Gegevenselement  Opmerking
  
Opgeslagen gegevens over specifieke omstandigheden op 
de gedownloade dag. Indien het segment leeg is, wordt 
een beginlabel van een reeks met noOfRecords = 0 ver ­
zonden.
  
ECC-handtekening van alle voorgaande gegevens.  
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 E v e n t s a n d F a u l t s  
DDP_031  ►M1 Het gegevensveld van het bericht „Positive Response 
Transfer Data Events and Faults” moet de onderstaande 
gegevens in de onderstaande volgorde onder het SID 76 
Hex, het TREP 03 of 23 Hex en de passende splitsing en 
telling van de subberichten verstrekken: ◄ 
▼M1 
Gegevensstructuur 1e generatie (TREP 03 Hex)  
▼B 
Gegevenselement  Opmerking
  
Alle in de VU opgeslagen of lopende fouten. 
Indien dit segment leeg is, wordt alleen noOfVu ­
Faults = 0 verzonden.
  
Alle in de VU opgeslagen of lopende voorvallen 
(behalve snelheidsoverschrijding). 
Indien het segment leeg is, wordt alleen noOf ­
VuEvents = 0 verzonden.
  
Gegevens met betrekking tot de laatste snelheids ­
overschrijdingscontrole (standaardwaarde indien 
er geen gegevens zijn).
  
Alle in de VU opgeslagen snelheidsoverschrij ­
dingen. 
Indien het segment leeg is, wordt alleen noOf ­
VuOverSpeedingEvents = 0 verzonden.
  
Alle in de VU opgeslagen tijdafstellingen (buiten 
het kader van een volledige kalibrering). 
Indien het segment leeg is, wordt alleen noOf ­
VuTimeAdjrecords = 0 verzonden.
  
RSA-handtekening van alle gegevens vanaf 
noOfVuFaults tot de laatste byte van de laatste 
tijdafstellingsrecord.  
▼M1 
Gegevensstructuur 2e generatie (TREP 23 Hex)  
▼B 
Gegevenselement  Opmerking
  
Alle in de VU opgeslagen of lopende fouten. 
Indien het segment leeg is, wordt een beginlabel 
van een reeks met noOfRecords = 0 verzonden.
  
Alle in de VU opgeslagen of lopende voorvallen 
(behalve snelheidsoverschrijding). 
Indien het segment leeg is, wordt een beginlabel 
van een reeks met noOfRecords = 0 verzonden.
  
Gegevens met betrekking tot de laatste snelheids ­
overschrijdingscontrole (standaardwaarde indien 
er geen gegevens zijn).
  
Alle in de VU opgeslagen snelheidsoverschrij ­
dingen. 
Indien het segment leeg is, wordt een beginlabel 
van een reeks met noOfRecords = 0 verzonden.  ▼B
02016R0799 — NL — 26.02.2020 — 002.001 — 294 
Gegevenselement Opmerking
  
Alle in de VU opgeslagen tijdafstellingen (buiten 
het kader van een volledige kalibrering). 
Indien het segment leeg is, wordt een beginlabel 
van een reeks met noOfRecords = 0 verzonden.  
▼M1__________  
▼B
ECC-handtekening van alle voorgaande gege ­
vens. 
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 D e t a i l e d S p e e d  
DDP_032 ►M1 Het gegevensveld van het bericht „Positive Response 
Transfer Data Detailed Speed” moet de onderstaande gege ­
vens in de onderstaande volgorde onder het SID 76 Hex, het 
TREP 04 of 24 Hex en de passende splitsing en telling van 
de subberichten verstrekken: ◄ 
▼M1
Gegevensstructuur 1e generatie (TREP 04)  
▼B
Gegevenselement Opmerking
  
Alle in de VU opgeslagen gegevens over gede ­
tailleerde snelheid (één snelheidsblok per minuut 
waarin het voertuig rijdt). 
60 snelheidswaarden per minuut (één per secon ­
de).
 
RSA-handtekening van alle gegevens vanaf 
noOfSpeedBlocks tot de laatste byte van het laat ­
ste snelheidsblok.  
▼M1
Gegevensstructuur 2e generatie (TREP 24)  
▼B
Gegevenselement Opmerking
  
Alle in de VU opgeslagen gegevens over gede ­
tailleerde snelheid (één snelheidsblok per minuut 
waarin het voertuig rijdt). 
60 snelheidswaarden per minuut (één per secon ­
de).
 
ECC-handtekening van alle voorgaande gege ­
vens. 
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 T e c h n i c a l D a t a  
DDP_033 ►M1 Het gegevensveld van het bericht „Positive Response 
Transfer Data Technical Data” moet de onderstaande gege ­
vens in de onderstaande volgorde onder het SID 76 Hex, het 
TREP 05 of 25 Hex en de passende splitsing en telling van 
de subberichten verstrekken: ◄ ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 295  
Gegevensstructuur 1e generatie (TREP 05)  
▼B 
Gegevenselement  Opmerking
  
Alle in de VU opgeslagen kalibreringsrecords.
  
RSA-handtekening van alle gegevens vanaf vu ­
ManufacturerName tot de laatste byte van de 
laatste VuCalibrationRecord.  
▼M1 
Gegevensstructuur 2e generatie (TREP 25)  
▼B 
Gegevenselement  Opmerking
  
Alle in de VU opgeslagen sensorverbindingen.
  
Alle in de VU opgeslagen verbindingen met de 
externe GNSS-module.
  
Alle in de VU opgeslagen kalibreringsrecords.
  
Alle in de VU opgeslagen gegevens over kaart ­
inbrenging.
  
ECC-handtekening van alle voorgaande gege ­
vens.  
2.3. ESM bestandsopslag  
DDP_034 Wanneer tijdens een downloadsessie een gegevensover ­
dracht van een VU heeft plaatsgevonden, moet de IDE 
alle tijdens de downloadsessie van de VU in de berichten 
Positive Response Transfer Data ontvangen gegevens in één 
fysiek veld opslaan. Opgeslagen gegevens zijn exclusief 
beginlabels van berichten, tellers van subberichten, lege sub ­
berichten en controlesommen maar inclusief het SID en 
TREP (alleen van het eerste subbericht indien er verschei ­
dene subberichten zijn).  
3. DOWNLOADPROTOCOL VAN TACHOGRAAFKAARTEN  
3.1. Toepassingsgebied  
Dit punt beschrijft de directe gegevensoverdracht van een tachograaf ­
kaart naar een IDE. De IDE maakt geen deel uit van de beveiligde 
omgeving; daarom vindt er geen authenticatie tussen de kaart en de 
IDE plaats.  
3.2. Definities  
Downloadsessie : Elke keer dat er gegevens van de chip ­
kaart worden gedownload. De sessie 
omvat de volledige procedure vanaf 
het resetten van de chipkaart door een 
IFD tot de inactivering van de chip ­
kaart (uitnemen van de kaart of vol ­
gende reset).  ▼M1
 02016R0799 — NL — 26.02.2020 — 002.001 — 296  
Getekend gegevensbestand : Een bestand van de chipkaart. Het be ­
stand wordt ongecodeerd naar de IFD 
overgebracht. Op de chipkaart wordt 
het bestand gehashed en getekend; de 
handtekening wordt naar de IFD over ­
gebracht.  
3.3. Kaartdownload  
▼M1 
DDP_035 De download van een tachograafkaart omvat de onder ­
staande stappen:  
— Download van de algemene informatie van de kaart naar 
de
 en
  van het EF. Deze informatie is facul ­
tatief en wordt niet met een digitale handtekening bevei ­
ligd. 
— (voor tachograafkaarten van de eerste en tweede gene ­
ratie) Download EF’s in
  
— Download het
  en
  
van het EF. Deze informatie 
wordt niet met een digitale handtekening beveiligd.  
Het is verplicht om deze bestanden voor elke sessie 
te downloaden.  
— Download van de andere toepassingsgegevens van 
de EF’s (in
  ) met uitzondering 
van EF
  Deze informatie wordt 
beveiligd met een digitale handtekening, overeen ­
komstig aanhangsel 11 „Algemene beveiligings ­
mechanismen”, deel A.  
— Het is verplicht om ten minste de
  
en
 
van het EF voor elke sessie 
te downloaden.  
— Bij de download van een bestuurderskaart is het ook 
verplicht de onderstaande EF’s over te brengen:
  
— (alleen voor tachograafkaarten van de tweede gene ­
ratie) Download van de EF’s in
  
DF, behalve wanneer 
een in een VU ingebrachte bestuurderskaart wordt 
gedownload tijdens een bestuurderscontrole door 
een controleautoriteit van buiten de EU, waarbij ge ­
bruik wordt gemaakt van een controlekaart van de 
eerste generatie:  
— Download van het CardSignCertificate, CA_Cer ­
tificate and Link_Certificate (indien aanwezig) 
van de EF’s. Deze informatie wordt niet met 
een digitale handtekening beveiligd.  
Het is verplicht om deze bestanden voor elke 
sessie te downloaden.  
— Download van de andere toepassingsgegevens 
van de EF’s (in
  ) 
met uitzondering van
  van 
het EF. Deze informatie wordt beveiligd met een 
digitale handtekening, overeenkomstig aanhang ­
sel 11 „Algemene beveiligingsmechanismen”, 
deel B.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 297  
— Het is verplicht om ten minste de
  
en
 
van het EF voor elke 
sessie te downloaden.  
— Bij de download van een bestuurderskaart is het 
ook verplicht de onderstaande EF’s over te bren ­
gen:
 
— Bij de download van een bestuurderskaart moet 
de datum van
  worden 
aangepast in
  van het EF, 
in de
  en, voor zover van toe ­
passing, in de DF’s van
  
— Bij de download van een werkplaatskaart moet 
de kalibreringsteller worden gereset in
  
in de
  
en, voor zover van toepassing, in de DF's van
  
— Bij de download van een werkplaatskaart mag de
  
in de
  
en, voor zover van toepassing, 
de DF's van
  niet worden 
gedownload.  
▼B 
3.3.1  Initialisatiesequentie  
DDP_036 De IDE moet de sequentie als volgt initiëren:  
Kaart  Richting  IDE/IFD  Betekenis/Opmerkingen  
⇦ Hardware resetten  
ATR ⇨ 
Het gebruik van PPS om over te schakelen op een hogere 
baudsnelheid is facultatief zolang de chipkaart dit onder ­
steunt.  
3.3.2  Sequentie voor niet-getekende gegevensbestanden  
DDP_037  ►M1 De sequentie voor download van de chipkaart, IC, 
Card_Certificate (of CardSignCertificate voor DF Tacho ­
graph_G2), CA_Certificate en Link_Certificate (uitsluitend 
voor DF Tachograph_G2) van het EF is als volgt: ◄ 
Kaart  Richting  IDE/IFD  Betekenis/Opmerkingen  
⇦ Select file  Selecteer met bestandsidenti ­
ficatiesymbolen  
OK ⇨ ⇦ Read binary  Indien het bestand meer ge ­
gevens bevat dan de grootte 
van het buffergeheugen van 
de lezer of van de kaart, 
moet het commando worden 
herhaald totdat het volledige 
bestand gelezen is.  
Bestandsgegevens 
OK ⇨ Sla gegevens in ESM op  overeenkomstig  3.4 Opmaak 
gegevensopslag  ▼M1
 02016R0799 — NL — 26.02.2020 — 002.001 — 298  
Noot 1:  Voor het selecteren van het Card_Certificate (of 
CardSignCertificate) van het EF, moet de tachograaftoepas ­
sing worden geselecteerd (selectie met AID).  
Noot 2:  Een bestand lezen en selecteren kan ook in één stap 
worden uitgevoerd met het Read Binary-commando met een 
kort EF-identificatiesymbool.  
3.3.3  Sequentie voor getekende gegevensbestanden  
DDP_038 De onderstaande sequentie moet worden gebruikt voor elk 
van de volgende bestanden die met hun handtekening moe ­
ten worden overgebracht:  
▼M1 
Kaart  Richting  IDE / IFD  Betekenis/Opmerkingen
  
Select file  
OK
 
Perform Hash of File  — Berekent de hashwaarde 
van de inhoud van de ge ­
gevens van het geselec ­
teerde bestand met het 
voorgeschreven hashal ­
goritme overeenkomstig 
aanhangsel 11, deel A 
of B. Dit commando is 
geen ISO-commando.  
Bereken Hash of File en 
sla hashwaarde tijdelijk 
op 
OK
 
Read Binary  Indien het bestand meer ge ­
gevens bevat dan het buffer ­
geheugen van de lezer of van 
de kaart kan bewaren, moet 
het commando worden her ­
haald tot het volledige be ­
stand is gelezen.  
Bestandsgegevens 
OK
 Sla ontvangen gegevens in 
ESM op  Overeenkomstig  3.4 Data sto­
rage format
  
PSO: Compute Digital 
Signature  
Voer beveiligingsope ­
ratie „Bereken digitale 
handtekening” uit met 
de tijdelijk opgeslagen 
hashwaarde  
Handtekening 
OK
 Koppel gegevens aan de 
vorige in het ESM opgesla ­
gen gegevens  Overeenkomstig  3.4 Data sto­
rage format  
▼B 
Noot:  Een bestand selecteren en lezen kan ook in één stap 
worden uitgevoerd met het Read Binary-commando met een 
kort EF-identificatiesymbool. In dit geval kan het EF wor ­
den geselecteerd en gelezen vóór het commando ”perform 
hash of file” wordt toegepast.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 299  
3.3.4  Sequentie voor het resetten van de kalibreringsteller  
DDP_039 De sequentie voor het resetten van de
  
-teller in de
  
van het EF op een werkplaatskaart is 
de volgende:  
Kaart  Richting  IDE/IFD  Betekenis/Opmerkingen  
⇦ Select File  EF Card_Download  Selecteer met bestandsidenti ­
ficatiesymbolen  
OK ⇨ 
⇦ Update Binary  
NoOfCalibrationsSinceDownload 
= ‘00 00’  
Reset het volgnum ­
mer van kaart ­
download  
OK ⇨  
Noot:  Een bestand selecteren en lezen kan ook in één stap 
worden uitgevoerd met het Update Binary-commando met 
een kort EF-identificatiesymbool.  
3.4. Opmaak gegevensopslag  
3.4.1  Inleiding  
DDP_040 De gedownloade gegevens moeten overeenkomstig de on ­
derstaande voorwaarden worden opgeslagen:  
— De gegevens moeten transparant worden opgeslagen. 
Dat betekent dat de volgorde van de bytes en de volg ­
orde van de bits in de byte die vanaf de kaart worden 
overgebracht, tijdens de opslag gehandhaafd moeten blij ­
ven. 
— Alle tijdens een downloadsessie overgebrachte bestanden 
van de kaart worden in één bestand in het ESM opge ­
slagen.  
3.4.2  Bestandsopmaak  
DDP_041 De bestandsopmaak is een aaneenschakeling van diverse 
TLV-objecten.  
DDP_042 Het label voor een EF moet het FID plus de toevoeging 
”00” zijn.  
DDP_043 Het label van een handtekening van een EF moet het FID 
van het bestand plus de toevoeging ”01” zijn.  
DDP_044 De lengte is een waarde van twee bytes. De waarde defini ­
eert het aantal bytes in het waardeveld. De waarde ”FF FF” 
in het lengteveld wordt voor toekomstig gebruik gereser ­
veerd.  
DDP_045 Wanneer een bestand niet wordt gedownload, moeten geen 
gegevens met betrekking tot het bestand worden opgeslagen 
(geen label en geen nullengte).  
▼M1 
DDP_046 Een handtekening moet als het volgende TLV-object wor ­
den opgeslagen, onmiddellijk na het TLV-object dat de ge ­
gevens van het bestand bevat.  
Definitie  Betekenis  Lengte  
FID (2 Bytes) || „00”  Tag voor EF (FID) in de
  
of voor ge ­
meenschappelijke informa ­
tie van de kaart  3 bytes  
FID (2 Bytes) || „01”  Label voor handtekening 
van EF (FID) in de
  3 bytes  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 300  
Definitie  Betekenis  Lengte  
FID (2 Bytes) || „02”  Label voor EF (FID) in de
  
DF 3 bytes  
FID (2 Bytes) || „03”  Label voor handtekening 
van EF (FID) in de
  
DF 3 bytes  
xx xx  Lengte van waardeveld  2 bytes  
Voorbeeld van gegevens in een naar een ESM overgedragen 
bestand:  
Label  Lengte  Waarde
  
— Gegevens van EF ICC
  
— Gegevens van EF Card_Certificate  
— ...
  
Gegevens van EF
  
(in de
  DF)
  
Handtekening van EF
  
(in de
  
DF)
 
Gegevens van EF
  
in de
  DF
  
Handtekening van EF
  
in de
  
DF 
▼B 
4. DOWNLOADEN VAN EEN TACHOGRAAFKAART VIA EEN 
VOERTUIGUNIT  
DDP_047 De VU moet mogelijk maken de inhoud te downloaden van 
een bestuurderskaart die in een met de VU verbonden IDE 
is ingebracht  
DDP_048 De IDE moet een ”Transfer Data Request Card Download”- 
bericht naar de VU zenden om deze modus te initiëren (zie 
2.2.2.9).  
▼M1 
DDP_049 Bestuurderskaarten van de eerste generatie: de gegevens 
moeten worden gedownload door gebruik te maken van 
het downloadprotocol van de eerste generatie, en de ge ­
downloade gegevens moeten hetzelfde formaat hebben als 
gegevens die zijn gedownload van een voertuigunit van de 
eerste generatie.  
Bestuurderskaarten van de tweede generatie: de VU moet 
vervolgens overeenkomstig het in punt 3 gedefinieerde 
kaartdownloadprotocol de hele kaart downloaden, bestand 
voor bestand, en alle van de kaart ontvangen gegevens in 
de vereiste TLV-bestandsopmaak (zie 3.4.2) en ingekapseld 
in een „Positive Response Transfer Data”-bericht naar de 
IDE zenden.  
▼B 
DDP_050 De IDE moet de kaartgegevens van het ”Positive Response 
Transfer Data”-bericht lezen (alle beginlabels, SID's, 
TREP's, tellers van subberichten en controlesommen verwij ­
deren) en deze gegevens opslaan in een fysiek bestand zoals 
beschreven in punt 2.3.  
DDP_051 De VU moet vervolgens, naar gelang van het geval, het 
bestand
  of
  van 
de bestuurderskaart bijwerken.  ▼M1
 02016R0799 — NL — 26.02.2020 — 002.001 — 301  
Aanhangsel 8  
KALIBRERINGSPROTOCOL  
INHOUDSOPGAVE  
1. INLEIDING  
2. TERMEN, DEFINITIES EN REFERENTIES  
3. OVERZICHT VAN DIENSTEN  
3.1. Beschikbare diensten  
3.2. Antwoordcodes  
4. COMMUNICATIEDIENSTEN  
4.1. StartCommunication-dienst (Start overdracht)  
4.2. StopCommunication Service  
4.2.1 Omschrijving van het bericht  
4.2.2 Berichtformaat  
4.2.3 Parameterdefinitie  
4.3. TesterPresent-dienst (Testapparaat actief)  
4.3.1 Omschrijving van het bericht  
4.3.2 Berichtformaat  
5. BEHEERSDIENSTEN  
5.1. StartDiagnosticSession-dienst (Start diagnostische sessie)  
5.1.1 Omschrijving van het bericht  
5.1.2 Berichtformaat  
5.1.3 Parameterdefinitie  
5.2. SecurityAccess-dienst (Veiligheidstoegang)  
5.2.1 Omschrijving van het bericht  
5.2.2 Berichtformaat — SecurityAccess — requestSeed  
5.2.3 Berichtformaat — SecurityAccess — sendKey  
6. GEGEVENSOVERBRENGINGSDIENSTEN  
6.1. ReadDataByIdentifier-dienst (Lees gegevens met identificatiesymbool)  
6.1.1 Omschrijving van het bericht  
6.1.2 Berichtformaat  
6.1.3 Parameterdefinitie  
6.2. WriteDataByIdentifier service  
6.2.1 Omschrijving van het bericht  
6.2.2 Berichtformaat  
6.2.3 Parameterdefinitie  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 302  
7. CONTROLE VAN TESTIMPULSEN — INVOER-/UITVOERCON ­ 
TROLE FUNCTIONELE EENHEID  
7.1. InputOutputControlByIdentifier-dienst  
7.1.1 Omschrijving van het bericht  
7.1.2 Berichtformaat  
7.1.3 Parameterdefinitie  
8. FORMATEN VAN DATARECORDS  
8.1. Overgebrachte parameterreeksen  
8.2. Formaten van dataRecords  
1. INLEIDING  
In dit aanhangsel wordt beschreven hoe gegevens worden uitgewisseld 
tussen een voertuigunit en een testapparaat via de K-lijn die deel uit ­
maakt van de in aanhangsel 6 beschreven kalibreringsinterface. Voorts 
wordt ook de controle van de input/output-signaallijn op de kalibre ­
ringsconnector beschreven.  
Het tot stand brengen van communicatie via de K-lijn wordt beschre ­
ven in punt 4 ”Overdrachtsdiensten”.Communicatiediensten  
In dit aanhangsel wordt gebruik gemaakt van het idee van diagnosti ­
sche ”sessies” om het toepassingsgebied van K-lijncontrole onder ver ­
schillende omstandigheden vast te stellen. De standaardsessie is de 
”StandardDiagnosticSession”, waarin alle gegevens van een voertuig ­
unit kunnen worden gelezen maar waarin geen gegevens naar een 
voertuigunit kunnen worden geschreven.  
De selectie van de diagnostische sessie wordt beschreven in het punt 5 
”Beheerdiensten”.  
Dit aanhangsel moet worden beschouwd als relevant voor beide gene ­
raties VU's en werkplaatskaarten, overeenkomstig de in deze verorde ­
ning vastgestelde interoperabiliteitseisen.  
CPR_001 Met de ”ECUProgrammingSession” kunnen gegevens in de 
voertuigunit worden ingevoerd. Wanneer kalibreringsgege ­
vens worden ingevoerd, moet de voertuigunit bovendien in 
de werkingsmodus CALIBRATION staan.  
Gegevensoverdracht via K-lijn wordt beschreven in het punt 
6 ”Gegevensoverbrengingsdiensten”.Gegevensoverbren ­
gingsdiensten Formaten van overgebrachte gegevens worden 
nader beschreven in het punt 8 ”Formaten van gegevens ­
registraties”.Formaten van dataRecords  
CPR_002 Met de ”ECUAdjustmentSession” kan de I/O-modus van de 
I/O-signaallijn voor kalibrering via de K-lijninterface wor ­
den geselecteerd. De controle van de kalibrerings-I/O-sig ­
naallijn wordt beschreven in punt 7 ”Controle van testim ­
pulsen — Invoer-/uitvoercontrole functionele eenheid”.  
CPR_003 Overal in dit document wordt naar het testapparaat ver ­
wezen met het adres ‘tt’. Hoewel er mogelijk voorkeuradres ­
sen zijn voor testapparaten, moet de VU correct reageren op 
elk adres van een testapparaat. Het fysieke adres van de VU 
is 0xEE.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 303  
2. TERMEN, DEFINITIES EN REFERENTIES  
De protocollen, berichten en foutcodes zijn voornamelijk gebaseerd op 
een ontwerp van ISO 14229-1 (Road vehicles — Diagnostic systems 
— Part 1: Diagnostic services, versie 6 van 22 februari 2001).  
Bytecodering en hexadecimale waarden worden voor de dienstidentifi ­
catiesymbolen, de dienstverzoeken en dienstantwoorden en de stan ­
daardparameters gebruikt.  
De term „testapparaat” verwijst naar de inrichting die wordt gebruikt 
om programmeer-/kalibreringsgegevens in de VU in te voeren.  
De termen „cliënt” en „server” verwijzen respectievelijk naar het test ­
apparaat en de VU.  
De term ECU betekent ”elektronische controle-unit” en verwijst naar de 
VU. 
Referenties:  
▼M1 
ISO 14230-2: Road Vehicles — Diagnostic Systems — Keyword Pro ­
tocol 2000 — Part 2: Data Link Layer.  
Eerste editie: 1999.  
▼B 
3. OVERZICHT VAN DIENSTEN  
3.1. Beschikbare diensten  
De onderstaande tabel geeft een overzicht van de in de tachograaf 
beschikbare diensten; deze worden in dit document gedefinieerd.  
CPR_004 De tabel geeft de diensten aan die in een actieve diagnosti ­
sche sessie beschikbaar zijn.  
— De  1ste kolom  vermeldt de beschikbare diensten.  
— De  2de kolom  bevat het nummer van het punt in dit 
aanhangsel, waarin de dienst nader wordt gedefinieerd.  
— De  3de kolom  kent de waarden van het dienstidentifi ­
catiesymbool toe voor verzoekberichten.  
— De  4de kolom  specificeert de diensten van de  ”Stan­
dardDiagnosticSession” (SD)  (standaard diagnostische 
sessie) die in elke VU geïmplementeerd moeten worden.  
— De  5de kolom  specificeert de diensten van de  ”ECU­
AdjustmentSession” (ECUAS)  (ECU-afstellingssessie) 
die geïmplementeerd moeten worden om controle van 
de I/O-signaallijn in het frontpaneel van de kalibrerings ­
connector van de VU mogelijk te maken.  
— De  6de kolom  specificeert de diensten van de ECUPS 
(ECU-ProgrammingSession) die geïmplementeerd moe ­
ten worden om programmering van de parameters in de 
VU mogelijk te maken.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 304  
Tabel 1  
Verzameltabel 1waarden dienstidentificatiesymbolen  
Diagnostische sessies  
Naam van de diagnostische dienst  Sectie nr.  SId Vereiste 
waarde  SD ECUAS  ECUPS  
StartCommunication  4.1  81  ■ ■ ■ 
StopCommunication  4.2  82  ■ 
TesterPresent  4.3  3E  ■ ■ ■ 
StartDiagnosticSession  5.1  10  ■ ■ ■ 
SecurityAccess  5.2  27  ■ ■ ■ 
ReadDataByIdentifier  6.1  22  ■ ■ ■ 
WriteDataByIdentifier  6.2  2E  ■ 
InputOutputControlByIdentifier  7.1  2F  ■ 
■ Dit symbool geeft aan dat deze dienst verplicht is in deze diagnostische sessie. 
Geen symbool geeft aan dat deze dienst in deze diagnostische sessie niet is toegestaan.  
3.2. Antwoordcodes  
Voor elke dienst zijn antwoordcodes bepaald.  
4. COMMUNICATIEDIENSTEN  
Een aantal diensten zijn noodzakelijk voor het tot stand brengen en 
handhaven van de overdracht. Ze komen niet voor op de toepassings ­
laag. De beschikbare diensten worden in de onderstaande tabel beschre ­
ven: 
Tabel 2  
Communicatiediensten  
Naam van de dienst  Beschrijving  
StartCommunication  De cliënt verzoekt een overdrachtsessie 
met (een) server(s) te starten.  
StopCommunication  De cliënt verzoekt de huidige over ­
drachtsessie te beëindigen.  
TesterPresent  De cliënt wijst de server erop dat de 
verbinding nog actief is.  
CPR_005 De StartCommunication Service wordt gebruikt voor het 
starten van een overdracht. Om een dienst uit te kunnen 
voeren, moet de overdracht geïnitialiseerd worden en moe ­
ten de overdrachtparameters geschikt zijn voor de gewenste 
modus.  
4.1. StartCommunication-dienst (Start overdracht)  
CPR_006 Na ontvangst van een StartCommunication-indicatieprimitief 
moet de VU controleren of de gevraagde overdrachtverbin ­
ding onder de aanwezige voorwaarden geïnitialiseerd kan 
worden. Geldige voorwaarden voor de initialisatie van een 
overdrachtverbinding worden in document ISO 14230-2 be ­
schreven.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 305  
CPR_007 Vervolgens moet de VU alle noodzakelijke acties uitvoeren 
om de overdrachtverbinding te initialiseren en een Start ­
Communication-antwoordprimitief met de geselecteerde Po ­
sitive Response-parameters zenden.  
CPR_008 Indien een reeds geïnitialiseerde VU (die begonnen is aan 
een diagnostische sessie) een nieuw StartCommunication 
Request ontvangt (bijv. ten gevolge van het herstellen van 
fouten in het testapparaat), moet het verzoek geaccepteerd 
worden en moet de VU opnieuw geïnitialiseerd worden.  
CPR_009 Indien de overdrachtverbinding om de een of andere reden 
niet geïnitialiseerd kan worden, moet de VU blijven functi ­
oneren op de manier onmiddellijk voorafgaande aan de po ­
ging om de overdrachtverbinding te initialiseren.  
CPR_010 Het bericht StartCommunication Request moet fysiek ge ­
adresseerd worden.  
CPR_011 De VU wordt voor diensten geïnitialiseerd via een ”snelle 
initialisatie”-methode.  
— Aan elke activiteit gaat een bus-stilstandtijd vooraf.  
— Het testapparaat zendt vervolgens een initialisatiepa ­
troon.  
— Het antwoord van de VU bevat alle noodzakelijke in ­
formatie om de overdracht tot stand te brengen.  
CPR_012 Na voltooiing van de initialisatie:  
— Alle overdrachtparameters worden overeenkomstig de 
sleutelbytes op de in tabel 4 bepaalde waarden gezet.  
— De VU wacht op het eerste verzoek van het testapparaat.  
— De VU staat in de standaard diagnostische modus, d.w.z. 
StandardDiagnosticSession.  
— De kalibrerings-I/O-signaallijn staat in de standaard ­
instelling, d.w.z. geblokkeerde instelling.  
CPR_014 De snelheid van de gegevensoverdracht op de K-lijn be ­
draagt 10 400 baud.  
CPR_016 De snelle initialisatie wordt door het testapparaat gestart 
door het zenden van een Wake-up-patroon (Wup) op de 
K-lijn. Het patroon begint na de stilstandtijd op de K-lijn 
met een lage Tinil-tijd. Het testapparaat zendt de eerste bit 
van de StartCommunication-dienst na een Twup-tijd vol ­
gend op de eerste aflopende rand.
  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 306  
CPR_017 De timingwaarden voor snelle initialisatie en overdracht in 
het algemeen worden beschreven in de onderstaande tabel ­
len. Er zijn verschillende mogelijkheden voor de stilstand ­
tijd: 
— Eerste overbrenging na inschakeling, Tidle = 300 ms.  
— Na voltooiing van een StopCommunication-dienst, Tidle 
= P3 min.  
— Na beëindiging van de overdracht door time-out P3 
max, Tidle = 0.  
Tabel 3  
Timingwaarden voor snelle initialisatie  
Parameter  Minimumwaarde  Maximumwaarde  
Tinil  25 ± 1 ms  24 ms  26 ms  
Twup  50 ± 1 ms  49 ms  51 ms  
Tabel 4  
Timingwaarden voor overdracht  
Timing Pa ­
rameter  Parameteromschrijving  laagste waarden 
[ms] hoogste waarden 
[ms] 
min. max.  
P1 Interbytetijd voor antwoord 
van de VU  0 20  
P2 Tijd tussen verzoek van test ­
apparaat en antwoord van de 
VU of twee antwoorden van 
de VU  25 250  
P3 Tijd tussen einde van de ant ­
woorden van de VU en begin 
van een nieuw verzoek van het 
testapparaat  55 5 000  
P4 Interbytetijd voor verzoek van 
het testapparaat  5 20  
CPR_018 Het berichtenformaat voor snelle initialisatie wordt omschre ­
ven in de onderstaande tabellen. (N.B.: hex staat voor hexa ­
decimaal)  
Tabel 5  
StartCommunication Request-bericht  
Byte-#  Parameternaam  Hex-waarde  Mnemoniek  
# 1 Formaatbyte — fysieke adres ­
sering  81 FMT  
# 2 Byte van het doeladres  EE  TGT  
# 3 Byte van het bronadres  tt  SRC  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 307  
Byte-#  Parameternaam  Hex-waarde  Mnemoniek  
# 4 StartCommunication Request 
Service Id  81 SCR  
# 5 Controlesom  00-FF  CS  
Tabel 6  
StartCommunication Positive Response-bericht  
Byte-#  Parameternaam  Hex-waarde  Mnemoniek  
# 1 Formaatbyte — fysieke adres ­
sering  80 FMT  
# 2 Byte van het doeladres  tt  TGT  
# 3 Byte van het bronadres  EE  SRC  
# 4 Additionele lengtebyte  03  LEN  
# 5 StartCommunication Positive 
Response Service Id  C1 SCRPR  
# 6 Sleutelbyte 1  EA  KB1  
# 7 Sleutelbyte 2  8F  KB2  
# 8 Controlesom  00-FF  CS  
CPR_019 Er is geen negatief antwoord op het bericht StartCommuni ­
cation Request. Indien er geen positief antwoordbericht 
moet worden verzonden, dan wordt de VU niet geïnitiali ­
seerd. Er wordt niets verzonden en de VU blijft normaal 
functioneren.  
4.2. StopCommunication Service  
4.2.1  Omschrijving van het bericht  
Het doel van de dienst van deze overdrachtslaag is het afsluiten van 
een overdrachtssessie.  
CPR_020 Na ontvangst van een StopCommunication indicatieprimitief 
moet de VU controleren of de lopende condities een afslui ­
ting van deze overdracht toestaan. In dit geval moet de VU 
alle noodzakelijke handelingen uitvoeren om deze over ­
dracht af te sluiten.  
CPR_021 Indien het mogelijk is de overdracht af te sluiten, moet de 
VU een StopCommunication-antwoordprimitief met de ge ­
selecteerde Positive Response-parameters afgeven voordat 
de overdracht afgesloten wordt.  
CPR_022 Indien de overdracht om de een of andere reden niet kan 
worden afgesloten, moet de VU een StopCommunication- 
antwoordprimitief met de geselecteerde Negative Response- 
parameter afgeven.  
CPR_023 Indien een time-out van P3max door de VU opgespoord 
wordt, moet de overdracht zonder een afgegeven antwoord ­
primitief worden afgesloten.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 308  
4.2.2  Berichtformaat  
CPR_024 De berichtformaten voor de StopCommunication-primitieven 
worden omschreven in de onderstaande tabellen.  
Tabel 7  
StopCommunication Request-bericht  
Byte-#  Parameternaam  Hex-waarde  Mnemoniek  
# 1 Formaatbyte — fysieke adres ­
sering  80 FMT  
# 2 Byte van het doeladres  EE  TGT  
# 3 Byte van het bronadres  tt  SRC  
# 4 Additionele lengtebyte  01  LEN  
# 5 StopCommunication Request 
Service Id  82 SPR  
# 6 Controlesom  00-FF  CS  
Tabel 8  
StopCommunication Positive Response-bericht  
Byte-#  Parameternaam  Hex-waarde  Mnemoniek  
# 1 Formaatbyte — fysieke adres ­
sering  80 FMT  
# 2 Byte van het doeladres  tt  TGT  
# 3 Byte van het bronadres  EE  SRC  
# 4 Additionele lengtebyte  01  LEN  
# 5 StopCommunication Positive 
Response Service Id  C2 SPRPR  
# 6 Controlesom  00-FF  CS  
Tabel 9  
StopCommunication Negative Response-bericht  
Byte-#  Parameternaam  Hex-waarde  Mnemoniek  
# 1 Formaatbyte — fysieke adres ­
sering  80 FMT  
# 2 Byte van het doeladres  tt  TGT  
# 3 Byte van het bronadres  EE  SRC  
# 4 Additionele lengtebyte  03  LEN  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 309  
Byte-#  Parameternaam  Hex-waarde  Mnemoniek  
# 5 Negative Response Service Id  7F  NR  
# 6 StopCommunication Request 
Service Identification SPR  82 SPR  
# 7 ResponseCode = generalReject 
RC_GR  10 RC_GR  
# 8 Controlesom  00-FF  CS  
4.2.3  Parameterdefinitie  
Deze dienst vereist geen parameterdefinitie.  
4.3. TesterPresent-dienst (Testapparaat actief)  
4.3.1  Omschrijving van het bericht  
De TesterPresent-dienst wordt door het testapparaat gebruikt om de 
server erop te wijzen dat het nog steeds aanwezig is, teneinde te voor ­
komen dat de server automatisch naar normaal bedrijf terugkeert en 
mogelijk de verbinding verbreekt. Deze dienst, die periodiek wordt 
verzonden, houdt de diagnostische sessie/overdracht actief door, telkens 
als een verzoek voor deze dienst wordt ontvangen, de P3-timer op ­
nieuw in te stellen.  
4.3.2  Berichtformaat  
CPR_079 De berichtformaten voor de TesterPresent-primitieven wor ­
den omschreven in de onderstaande tabellen.  
Tabel 10  
TesterPresent Request-bericht  
Byte-#  Parameternaam  Hex-waarde  Mnemoniek  
# 1 Formaatbyte — fysieke adres ­
sering  80 FMT  
# 2 Byte van het doeladres  EE  TGT  
# 3 Byte van het bronadres  tt  SRC  
# 4 Additionele lengtebyte  02  LEN  
# 5 TesterPresent Request Ser ­
vice Id  3E TP  
# 6 Subfunctie = respon ­
seRequired (antwoord 
vereist) =  [ ja 01  RESPREQ_Y  
nee ]  02  RESPREQ_NO  
# 7 Controlesom  00-FF  CS  
CPR_080 Indien de responseRequired-parameter op ”ja” wordt in ­
gesteld, dan antwoordt de server met het volgende bericht 
van positief antwoord. Indien op „nee”, dan zendt de server 
geen antwoord.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 310  
Tabel 11  
TesterPresent Positive Response-bericht  
Byte-#  Parameternaam  Hex-waarde  Mnemoniek  
# 1 Formaatbyte — fysieke adres ­
sering  80 FMT  
# 2 Byte van het doeladres  tt  TGT  
# 3 Byte van het bronadres  EE  SRC  
# 4 Additionele lengtebyte  01  LEN  
# 5 TesterPresent Positive Res ­
ponse Service Id  7E TPPR  
# 6 Controlesom  00-FF  CS  
CPR_081 De dienst ondersteunt de volgende negatieve-antwoord ­
codes:  
Tabel 12  
TesterPresent Negative Response-bericht  
Byte-#  Parameternaam  Hex- 
waarde  Mnemoniek  
# 1 Formaatbyte — fysieke adressering  80  FMT  
# 2 Byte van het doeladres  tt  TGT  
# 3 Byte van het bronadres  EE  SRC  
# 4 Additionele lengtebyte  03  LEN  
# 5 Negative Response Service Id  7F  NR  
# 6 TesterPresent Request Service Identi ­
fication  3E TP  
#7 Response ­
Code =  [SubFunctionNotSup ­
ported-InvalidFormat  12 RC_SFNS_IF  
incorrectMessage ­
Length ]  13 RC_IML  
#8 Controlesom  00-FF  CS  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 311  
5. BEHEERSDIENSTEN  
De beschikbare diensten worden in de onderstaande tabel beschreven:  
Tabel 13  
Beheersdiensten  
Naam van de dienst  Beschrijving  
StartDiagnosticSession  De cliënt verzoekt een diagnostische sessie 
met een VU te starten.  
SecurityAccess  De cliënt verzoekt om toegang tot functies 
die alleen voor bevoegde gebruikers toegan ­
kelijk zijn.  
5.1. StartDiagnosticSession-dienst (Start diagnostische sessie)  
5.1.1  Omschrijving van het bericht  
CPR_025 De dienst StartDiagnosticSession wordt gebruikt om ver ­
schillende diagnostische sessies in de server mogelijk te 
maken. Een diagnostische sessie maakt een specifieke reeks 
diensten mogelijk volgens tabel 17. Een sessie kan speci ­
fieke diensten voor voertuigfabrikanten mogelijk maken die 
geen deel van dit document uitmaken. Implementatieregels 
moeten aan de volgende eisen voldoen:  
— In de VU moet altijd precies één diagnostische sessie 
actief zijn.  
— De VU moet bij het aanzetten altijd de StandardDia ­
gnosticSession starten. Indien geen andere diagnostische 
sessie wordt gestart, moet de StandardDiagnosticSession 
actief blijven zolang de VU wordt aangedreven.  
— Indien een diagnostische sessie die reeds actief is, door 
het testapparaat wordt aangevraagd, moet de VU een 
bericht van positief antwoord zenden.  
— Telkens als het testapparaat een nieuwe diagnostische 
sessie aanvraagt, moet de VU eerst een StartDiagnostic ­
Session positive response-bericht zenden voordat de 
nieuwe sessie in de VU actief wordt. Indien de VU de 
gevraagde nieuwe diagnostische sessie niet kan starten, 
moet deze antwoorden met een StartDiagnosticSession 
negative response-bericht en de lopende sessie wordt 
voortgezet.  
CPR_026 Een diagnostische sessie kan alleen worden gestart indien 
overdracht tussen de cliënt en de VU tot stand gebracht is.  
CPR_027 De timingparameters van tabel 4 moeten actief zijn na een 
succesvolle StartDiagnosticSession waarbij de diagnostic ­
Session-parameter in het verzoekbericht ingesteld is op 
”StandardDiagnosticSession” indien voorheen een andere 
diagnostische sessie actief was.  
5.1.2  Berichtformaat  
CPR_028 De berichtformaten voor de StartDiagnosticSession-primitie ­
ven worden omschreven in de onderstaande tabellen.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 312  
Tabel 14  
StartDiagnosticSession Request-bericht  
Byte-#  Parameternaam  Hex-waarde  Mnemoniek  
# 1 Formaatbyte — fysieke adres ­
sering  80 FMT  
# 2 Byte van het doeladres  EE  TGT  
# 3 Byte van het bronadres  tt  SRC  
# 4 Additionele lengtebyte  02  LEN  
# 5 StartDiagnosticSession Re ­
quest Service Id  10 STDS  
# 6 DiagnosticSession = [een 
waarde uit tabel 17]  xx DS_…  
# 7 Controlesom  00-FF  CS  
Tabel 15  
StartDiagnosticSession Positive Response-bericht  
Byte-#  Parameternaam  Hex-waarde  Mnemoniek  
# 1 Formaatbyte — fysieke adres ­
sering  80 FMT  
# 2 Byte van het doeladres  tt  TGT  
# 3 Byte van het bronadres  EE  SRC  
# 4 Additionele lengtebyte  02  LEN  
# 5 # 5 StartDiagnosticSession 
Positive Response Service Id  50 STDSPR  
# 6 DiagnosticSession = [zelfde 
waarde als in Byte-# 6 tabel 
14] xx DS_…  
# 7 Controlesom  00-FF  CS  
Tabel 16  
StartDiagnosticSession Negative Response-bericht  
Byte-#  Parameternaam  Hex- 
waarde  Mnemoniek  
# 1 Formaatbyte — fysieke adressering  80  FMT  
# 2 Byte van het doeladres  tt  TGT  
# 3 Byte van het bronadres  EE  SRC  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 313  
Byte-#  Parameternaam  Hex- 
waarde  Mnemoniek  
# 4 Additionele lengtebyte  03  LEN  
# 5 Negative Response Service Id  7F  NR  
# 6 StartDiagnosticSession Request Ser ­
vice Id  10 STDS  
# 7 Response ­
Code =  [subFunctionNotSup ­
ported (  a ) 12 RC_SFNS  
incorrectMessage ­
Length (  b ) 13 RC_IML  
conditionsNotCor ­
rect (  c ) 22 RC_CNC  
# 8 Controlesom  00-FF  CS  
( a ) — de waarde opgenomen in Byte-# 6 van het verzoekbericht wordt niet onder ­ 
steund, d.w.z. niet in tabel 17, 
( b ) — de lengte van het ontvangen bericht is fout, 
( c ) — er is niet voldaan aan de criteria voor het verzoek StartDiagnosticSession.  
5.1.3  Parameterdefinitie  
CPR_029 De parameter  diagnosticSession (DS_)  wordt gebruikt door 
de StartDiagnosticSession-dienst om de specifieke werking 
van de server(s) te selecteren. De onderstaande diagnosti ­
sche sessies worden in dit document gespecificeerd:  
Tabel 17  
Definitie van diagnosticSession-waarden  
Hex Beschrijving  Mnemoniek  
81 StandardDiagnosticSession  
Deze diagnostische sessie maakt alle in  tabel 1  
— Verzameltabel  1, kolom 4 ”SD”  gespecifi- 
ceerde diensten mogelijk. Met deze diensten 
kunnen gegevens van een server (VU) worden 
gelezen. Deze diagnostische sessie is actief nadat 
de initialisatie tussen cliënt (testapparaat) en 
server (VU) succesvol is afgesloten. Deze 
diagnostische sessie kan door andere in dit punt 
gespecificeerde diagnostische sessies overschre- 
ven worden  SD 
85 ECUProgrammingSession  
Deze diagnostische sessie maakt alle in  tabel 1  
— Verzameltabel 1 , kolom 6 ”ECUPS”  
gespecificeerde diensten mogelijk. Deze diensten 
ondersteunen het programmeren van het geheu- 
gen van een server (VU). Deze diagnostische 
sessie kan door andere in dit punt gespecificeerde 
diagnostische sessies overschreven worden.  ECUPS  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 314  
Hex Beschrijving  Mnemoniek  
87 ECUAdjustmentSession  
Deze diagnostische sessie maakt alle in  tabel 1  
— Verzameltabel 1 , kolom 5 ”ECUAS”  
gespecificeerde diensten mogelijk. Deze diensten 
ondersteunen de invoer-/uitvoercontrole van een 
server (VU). Deze diagnostische sessie kan door 
andere in dit punt gespecificeerde diagnostische 
sessies overschreven worden.  ECUAS  
5.2. SecurityAccess-dienst (Veiligheidstoegang)  
Het schrijven van kalibreringsgegevens is niet mogelijk tenzij de VU in 
de CALIBRATION-modus staat. Naast het inbrengen van een geldige 
werkplaatskaart moet de juiste PIN-code worden ingevoerd voordat 
toegang tot de CALIBRATION-modus wordt toegestaan.  
Als de VU in de CALIBRATION- of CONTROL-modus staat, is 
toegang tot de invoer-/uitvoerlijn van de kalibrering ook mogelijk.  
De SecurityAccess-dienst verschaft een middel om de PIN-code in te 
voeren en om aan het testapparaat aan te geven of de VU in de 
CALIBRATION-modus staat.  
De PIN-code kan ook door middel van alternatieve methoden worden 
ingevoerd.  
5.2.1  Omschrijving van het bericht  
De SecurityAccess-dienst bestaat uit een SecurityAccess ”requestSeed”- 
bericht (aanvraag van ”seed”), eventueel gevolgd door een Security ­
Access ”sendKey”-bericht (verzoek om sleutel te zenden). De Security ­
Access-dienst moet na de StartDiagnosticSession-dienst worden uitge ­
voerd.  
CPR_033 Het testapparaat moet het SecurityAccess ”requestSeed”-be ­
richt gebruiken om te controleren of de voertuigunit gereed 
is om een PIN-code te accepteren.  
CPR_034 Indien de voertuigunit reeds in CALIBRATION-modus is, 
moet de unit het verzoek beantwoorden door het zenden van 
een ”seed” van 0x0000 met gebruikmaking van de dienst 
SecurityAccess Positive Response.  
CPR_035 Indien de voertuigunit gereed is om een PIN-code voor 
verificatie door een werkplaatskaart te accepteren, moet de 
unit het verzoek beantwoorden door het zenden van een 
”seed” groter dan 0x0000 met gebruikmaking van de dienst 
SecurityAccess Positive Response.  
CPR_036 Indien de voertuigunit niet gereed is om een PIN-code van 
het testapparaat te accepteren, omdat de ingebrachte werk ­
plaatskaart niet geldig is of omdat er geen werkplaatskaart 
ingebracht is of omdat de voertuigunit de PIN-code via een 
andere methode verwacht, moet de unit het verzoek beant ­
woorden met een Negative Response met een op conditions ­
NotCorrectOrRequestSequenceError ingestelde antwoord ­
code.  
CPR_037 Het testapparaat moet dan het SecurityAccess ”sendKey”- 
bericht gebruiken om een PIN-code naar de voertuigunit te 
zenden. Om de uitvoering van het kaartauthenticatieproces 
voldoende tijd te geven, moet de VU de negatieve ant ­
woordcode requestCorrectlyReceived-ResponsePending 
(verzoek goed ontvangen — antwoord volgt) gebruiken  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 315  
om de tijd voor beantwoording te verlengen. De maximum ­
tijd voor beantwoording mag evenwel niet meer dan 5 mi ­
nuten bedragen. Zodra de gevraagde dienst is voltooid, moet 
de VU een bericht van positief antwoord zenden dan wel 
een bericht van negatief antwoord met een andere antwoord ­
code dan de eerste. De negatieve antwoordcode requestCor ­
rectlyReceived-ResponsePending mag door de VU worden 
herhaald totdat de gevraagde dienst is voltooid en het defi ­
nitieve antwoordbericht is gezonden.  
CPR_038 De voertuigunit mag dit verzoek alleen met gebruikmaking 
van de dienst SecurityAccess Positive Response beantwoor ­
den wanneer hij in CALIBRATION-modus staat.  
CPR_039 In de onderstaande gevallen moet de voertuigunit dit ver ­
zoek met een Negative Response beantwoorden met de ant ­
woordcode ingesteld op:  
— subFunctionNot supported: ongeldig formaat voor de 
subfunctieparameter (accessType);  
— conditionsNotCorrectOrRequestSequenceError: voertuig ­
unit niet gereed om de invoer van een PIN-code te 
accepteren;  
— invalidKey: PIN-code niet geldig en aantal controlepo ­
gingen van de PIN-code niet overschreden;  
— exceededNumberOfAttempts: PIN-code niet geldig en 
aantal controlepogingen van de PIN-code overschreden;  
— generalReject: correcte PIN-code maar wederzijdse au ­
thenticatie met werkplaatskaart mislukt.  
5.2.2  Berichtformaat — SecurityAccess — requestSeed  
CPR_040 De berichtformaten voor de SecurityAccess ”requestSeed”- 
primitieven worden omschreven in de onderstaande tabellen.  
Tabel 18  
SecurityAccess REQUEST- requestSeed-bericht  
Byte-#  Parameternaam  Hex-waarde  Mnemoniek  
# 1 Formaatbyte — fysieke adres ­
sering  80 FMT  
# 2 Byte van het doeladres  EE  TGT  
# 3 Byte van het bronadres  tt  SRC  
# 4 Additionele lengtebyte  02  LEN  
# 5 SecurityAccess Request Ser ­
vice Id  27 SA  
# 6 AccessType — requestSeed  7D  AT_RSD  
# 7 Controlesom  00-FF  CS  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 316  
Tabel 19  
SecurityAccess — requestSeed Positive Response-bericht  
Byte-#  Parameternaam  Hex-waarde  Mnemoniek  
# 1 Formaatbyte — fysieke adres ­
sering  80 FMT  
# 2 Byte van het doeladres  tt  TGT  
# 3 Byte van het bronadres  EE  SRC  
# 4 Additionele lengtebyte  04  LEN  
# 5 SecurityAccess Positive Res ­
ponse Service Id  67 SAPR  
# 6 AccessType — requestSeed  7D  AT_RSD  
# 7 Seed High  00-FF  SEEDH  
# 8 Seed Low  00-FF  SEEDL  
# 9 Controlesom  00-FF  CS  
Tabel 20  
SecurityAccess Negative Response-bericht  
Byte-#  Parameternaam  Hex- 
waarde  Mnemoniek  
# 1 Formaatbyte — fysieke adressering  80  FMT  
# 2 Byte van het doeladres  tt  TGT  
# 3 Byte van het bronadres  EE  SRC  
# 4 Additionele lengtebyte  03  LEN  
# 5 Negative Response Service Id  7F  NR  
# 6 SecurityAccess Request Service Id  27  SA  
# 7 Response ­
Code =  [conditionsNotCorrec ­
tOrRequestSequen ­
ceError  22 RC_CNC  
incorrectMessage ­
Length]  13 RC_IML  
# 8 Controlesom  00-FF  CS  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 317  
5.2.3  Berichtformaat — SecurityAccess — sendKey  
CPR_041 De berichtformaten voor de SecurityAccess ”sendKey”-pri ­
mitieven worden omschreven in de onderstaande tabellen.  
Tabel 21  
SecurityAccess Request — sendKey-bericht  
Byte-#  Parameternaam  Hex-waarde  Mnemoniek  
# 1 Formaatbyte — fysieke adres ­
sering  80 FMT  
# 2 Byte van het doeladres  EE  TGT  
# 3 Byte van het bronadres  tt  SRC  
# 4 Additionele lengtebyte  m + 2  LEN  
# 5 SecurityAccess Request Ser ­
vice Id  27 SA  
# 6 accessType — sendKey  7E  AT_SK  
# 7 tot # m 
+ 6 Key # 1 (High)  xx  KEY  
… …  
Key # m (low, m moet mini ­
maal 4 en maximaal 8 zijn)  xx 
# m + 7  Controlesom  00-FF  CS  
Tabel 22  
SecurityAccess — sendKey Positive Response-bericht  
Byte-#  Parameternaam  Hex-waarde  Mnemoniek  
# 1 Formaatbyte — fysieke adres ­
sering  80 FMT  
# 2 Byte van het doeladres  tt  TGT  
# 3 Byte van het bronadres  EE  SRC  
# 4 Additionele lengtebyte  02  LEN  
# 5 SecurityAccess Positive Res ­
ponse Service Id  67 SAPR  
# 6 accessType — sendKey  7E  AT_SK  
# 7 Controlesom  00-FF  CS  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 318  
Tabel 23  
SecurityAccess Negative Response-bericht  
Byte-#  Parameternaam  Hex- 
waarde  Mnemoniek  
# 1 Formaatbyte — fysieke adressering  80  FMT  
# 2 Byte van het doeladres  tt  TGT  
# 3 Byte van het bronadres  EE  SRC  
# 4 Additionele lengtebyte  03  LEN  
# 5 Negative Response Service Id  7F  NR  
# 6 SecurityAccess Request Service Id  27  SA  
# 7 Response ­
Code =  [generalReject  10  # 8  
subFunctionNotSup ­
ported  12 RC_SFNS  
incorrectMessage ­
Length  13 RC_IML  
conditionsNotCorrec ­
tOrRequestSequen ­
ceError  22 RC_CNC  
invalidKey  35  RC_IK  
exceededNumberO ­
fAttempts  36 RC_ENA  
requestCorrectlyRe ­
ceived-ResponsePen ­
ding]  78 RC_RCR_RP  
# 8 Controlesom  00-FF  CS  
6. GEGEVENSOVERBRENGINGSDIENSTEN  
De beschikbare diensten worden in de onderstaande tabel beschreven:  
Tabel 24  
Gegevensoverbrengingsdiensten  
Naam van de dienst  Beschrijving  
ReadDataByIdentifier  De cliënt verzoekt om overbrenging van de 
huidige waarde van een registratie met toe ­
gang door recordDataIdentifier.  
WriteDataByIdentifier  De cliënt verzoekt een voor recordDataIden ­
tifier toegankelijke registratie te schrijven.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 319  
6.1. ReadDataByIdentifier-dienst (Lees gegevens met identificatiesym ­
bool)  
6.1.1  Omschrijving van het bericht  
CPR_050 De ReadDataByIdentifier-dienst wordt door de cliënt ge ­
bruikt om van een server om gegevensregistratiewaarden 
te vragen. De gegevens worden geïdentificeerd door een 
recordDataIdentifier. Het is de verantwoordelijkheid van 
de VU-fabrikant dat bij het verrichten van de dienst aan 
de servervoorwaarden wordt voldaan.  
6.1.2  Berichtformaat  
CPR_051 De berichtformaten voor de ReadDataByLocalIdentifier-pri ­
mitieven worden omschreven in de onderstaande tabellen.  
Tabel 25  
ReadDataByIdentifier Request-bericht  
Byte-#  Parameternaam  Hex-waarde  Mnemoniek  
# 1 Formaatbyte — fysieke adres ­
sering  80 FMT  
# 2 Byte van het doeladres  EE  TGT  
# 3 Byte van het bronadres  tt  SRC  
# 4 Additionele lengtebyte  03  LEN  
# 5 ReadDataByIdentifier Re ­
quest Service Id  22 RDBI  
# 6 en # 7  RecordDataIdentifier = [een 
waarde uit tabel 28]  xxxx  RDI_…  
# 8 Controlesom  00-FF  CS  
Tabel 26  
ReadDataByIdentifier Positive Response-bericht  
Byte-#  Parameternaam  Hex- 
waarde  Mnemoniek  
# 1 Formaatbyte — fysieke adressering  80  FMT  
# 2 Byte van het doeladres  tt  TGT  
# 3 Byte van het bronadres  EE  SRC  
# 4 Additionele lengtebyte  m + 3  LEN  
# 5 ReadDataByIdentifier Positive Res ­
ponse Service Id  62 RDBIPR  
# 6 en # 7  recordDataIdentifier = [zelfde waarde 
als byte-nrs. 6 en 7 tabel 25 Tabel 
23] xxxx  RDI_ …  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 320  
Byte-#  Parameternaam  Hex- 
waarde  Mnemoniek  
# 8 tot # 
m+7 dataRecord[] =  [data # 1  xx  DREC_DA ­
TA1 
: :  :  
data # m]  xx  DREC_DA ­
TAm  
# m+8  Controlesom  00-FF  CS  
Tabel 27  
ReadDataByIdentifier Negative Response-bericht  
Byte-#  Parameternaam  Hex- 
waarde  Mnemoniek  
# 1 Formaatbyte — fysieke adressering  80  FMT  
# 2 Byte van het doeladres  tt  TGT  
# 3 Byte van het bronadres  EE  SRC  
# 4 Additionele lengtebyte  03  LEN  
# 5 Negative Response Service Id  7F  NR  
# 6 ReadDataByIdentifier Request Ser ­
vice Id  22 RDBI  
# 7 Response- 
Code =  [requestOutOfRan ­
ge 31 RC_ROOR  
incorrectMessage ­
Length  13 RC_IML  
conditionsNotCor ­
rect] 22 RC_CNC  
# 8 Controlesom  00-FF  CS  
6.1.3  Parameterdefinitie  
CPR_052 De parameter  recordDataIdentifier (RDI_)  in het verzoek ­
bericht ReadDataByIdentifier identificeert een gegevens ­
registratie.  
CPR_053 De in dit document gedefinieerde waarden van de record ­
DataIdentifier worden in de onderstaande tabel getoond.  
De tabel recordDataIdentifier bestaat uit vier kolommen en 
meerdere rijen.  
— De  1e kolom (Hex)  bevat de ”Hex-waarde” die aan de 
in de 3e kolom gespecificeerde recordDataIdentifier is 
toegekend.  
— De  2e kolom (Gegevenselement)  specificeert het gege ­
venselement van aanhangsel 1 waarop de recordDataI ­
dentifier is gebaseerd (soms is transcodering nodig).  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 321  
— De  3e kolom (Omschrijving)  specificeert de correspon ­
derende recordDataIdentifier-naam.  
— De  4e kolom (Mnemonisch)  specificeert de mnemo ­
nische notatie van deze recordDataIdentifier.  
Tabel 28  
Definitie van recordDataIdentifier-waarden  
Hex Gegevenselement  recordDataIdentifier-naam 
(zie formaat in punt 8.2)  Mnemoniek  
F90B
  TimeDate  RDI_TD  
F912
  HighResolutionTotal- 
VehicleDistance  RDI_HRTVD  
F918
  Kfactor  RDI_KF  
F91C
  LfactorTyreCircumference  RDI_LF  
F91D
  WvehicleCharacteristicFactor  RDI_WVCF  
F921
  Bandenmaat  RDI_TS  
F922
  NextCalibrationDate  RDI_NCD  
F92C
  SpeedAuthorised  RDI_SA  
F97D
  RegisteringMemberState  RDI_RMS  
F97E
  VehicleRegistrationNumber  RDI_ VRN  
F190
  VIN  RDI_ VIN  
CPR_054 De parameter  dataRecord (DREC_)  wordt gebruikt door het 
ReadDataByIdentifier positive response-bericht om de door 
de recordDataIdentifier geïdentificeerde gegevensregistratie ­
waarde aan de cliënt (testapparaat) te leveren. Gegevensfor ­
maten worden in punt 8 nader gespecificeerd. Aanvullende 
voor de gebruiker facultatieve dataRecords, met inbegrip 
van voor de VU specifieke invoergegevens, interne gege ­
vens en uitvoergegevens kunnen worden geïmplementeerd, 
maar zijn niet in dit document gedefinieerd.  
6.2. WriteDataByIdentifier service  
6.2.1  Omschrijving van het bericht  
CPR_056 De dienst WriteDataByIdentifier wordt door de cliënt ge ­
bruikt om gegevensregistratiewaarden naar een server te 
schrijven. De gegevens worden geïdentificeerd door een re ­
cordDataIdentifier. Het is de verantwoordelijkheid van de 
VU-fabrikant dat bij het verrichten van de dienst aan de 
servervoorwaarden wordt voldaan. Om de parameters van 
tabel 28 bij te werken moet de VU in CALIBRATION- 
modus staan.  
6.2.2  Berichtformaat  
CPR_057 De berichtformaten voor de WriteDataByIdentifier-primitie ­
ven worden omschreven in de onderstaande tabellen.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 322  
Tabel 29  
WriteDataByIdentifier Request-bericht  
Byte-#  Parameternaam  Hex- 
waarde  Mnemoniek  
# 1 Formaatbyte — fysieke adressering  80  FMT  
# 2 Byte van het doeladres  EE  TGT  
# 3 Byte van het bronadres  tt  SRC  
# 4 Additionele lengtebyte  m+3  LEN  
# 5 WriteDataByIdentifier Request 
Service Id  2E WDBI  
# 6 en # 7  RecordDataIdentifier = [een waarde 
uit tabel 28]  xxxx  RDI_ …  
# 8 tot # 
m+7 dataRecord[] =  [data # 1  xx  DREC_DA ­
TA1 
: :  :  
data # m]  xx  DREC_DA ­
TAm  
# m+8  Controlesom  00-FF  CS  
Tabel 30  
WriteDataByIdentifier Positive Response-bericht  
Byte-#  Parameternaam  Hex-waarde  Mnemoniek  
# 1 Formaatbyte — fysieke adres ­
sering  80 FMT  
# 2 Byte van het doeladres  tt  TGT  
# 3 Byte van het bronadres  EE  SRC  
# 4 Additionele lengtebyte  03  LEN  
# 5 WriteDataByIdentifier Posi ­
tive Response Service Id  6E WDBIPR  
# 6 en # 7  recordDataIdentifier = [zelfde 
waarde als byte-nrs. 6 en 7 ta ­
bel 29]  xxxx  RDI_ …  
# 8 Controlesom  00-FF  CS  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 323  
Tabel 31  
WriteDataByIdentifier Negative Response-bericht  
Byte-#  Parameternaam  Hex- 
waarde  Mnemoniek  
# 1 Formaatbyte — fysieke adressering  80  FMT  
# 2 Byte van het doeladres  tt  TGT  
# 3 Byte van het bronadres  EE  SRC  
# 4 Additionele lengtebyte  03  LEN  
# 5 Negative Response Service Id  7F  NR  
# 6 WriteDataByIdentifier Request Ser ­
vice Id  2E WDBI  
# 7 Response- 
Code =  [requestOutOfRan ­
ge 31 RC_ROOR  
incorrectMessage ­
Length  13 RC_IML  
conditionsNotCor ­
rect] 22 RC_CNC  
# 8 Controlesom  00-FF  CS  
6.2.3  Parameterdefinitie  
De parameter  recordDataIdentifier (RDI_)  wordt in tabel 28 gedefini ­
eerd.  
De parameter  dataRecord (DREC_)  wordt gebruikt door het WriteDa ­
taByIdentifier request-bericht om aan de server (VU) de gegevensregis ­
tratiewaarden te leveren die door de recordDataIdentifier zijn geïdenti ­
ficeerd. Gegevensformaten worden in punt 8 nader gespecificeerd.  
7. CONTROLE VAN TESTIMPULSEN — INVOER-/UITVOERCON ­
TROLE FUNCTIONELE EENHEID  
De beschikbare diensten worden in de onderstaande tabel beschreven:  
Tabel 32  
Invoer-/uitvoercontrole functionele eenheid  
Naam van de dienst  Beschrijving  
InputOutputControlBy ­
Identifier  De cliënt verzoekt om controle van een voor 
de server specifieke invoer/uitvoer.  
7.1. InputOutputControlByIdentifier-dienst  
7.1.1  Omschrijving van het bericht  
Er is een verbinding via de frontconnector waarmee testpulsen met 
gebruikmaking van een geschikt testapparaat gecontroleerd of gemoni ­
tord kunnen worden.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 324  
CPR_058 Deze kalibrerings-I/O-signaallijn kan door het K-lijncom ­
mando geconfigureerd worden met gebruikmaking van de 
dienst InputOutputControlByIdentifier om de vereiste in ­
voer- of uitvoerfunctie voor de lijn te selecteren. De be ­
schikbare instellingen van de lijn zijn:  
— geblokkeerd,  
— speedSignalInput, waarbij de kalibrerings-I/O-signaallijn 
wordt gebruikt om een snelheidssignaal (testsignaal) in 
te voeren dat het snelheidssignaal van de bewegingssen ­
sor vervangt, deze functie is niet beschikbaar in de 
CONTROL-modus,  
— realTimeSpeedSignalOutputSensor, waarbij de kalibre ­
rings-I/O-signaallijn wordt gebruikt om het snelheidssig ­
naal van de bewegingssensor uit te voeren,  
— RTCOutput, waarbij de kalibrerings-I/O-signaallijn 
wordt gebruikt om het UTC-kloksignaal uit te voeren, 
deze functie is niet beschikbaar in de CONTROL-mo ­
dus. 
CPR_059 De voertuigunit moet een afstellingssessie ingevoerd hebben 
en in CALIBRATION- of CONTROL-modus staan om de 
instelling van de lijn te configureren. Indien de VU in de 
CALIBRATION-modus staat, kunnen de vier statussen van 
de lijn worden geselecteerd (uitgeschakeld, speedSignalIn ­
put, realTimeSpeedSignalOutputSensor, RTCOutput). Indien 
de VU in de CONTROL-modus staat, kunnen slechts twee 
statussen van de lijn worden geselecteerd (uitgeschakeld, 
realTimeSpeedSignalOutputSensor). Bij het verlaten van de 
afstellingssessie of van de CALIBRATION- of CONTROL- 
modus moet de voertuigunit ervoor zorgen dat de kalibre ­
rings-I/O-signaallijn teruggebracht wordt in de ”geblokkeer ­
de” (standaard)instelling.  
CPR_060 Indien snelheidspulsen op de real-time-invoerlijn van het 
snelheidssignaal van de VU worden ontvangen terwijl de 
kalibrerings-I/O-signaallijn op invoer staat, moet de kalibre ­
rings-I/O-signaallijn op uitvoer worden gezet of worden te ­
ruggebracht naar de geblokkeerde instelling.  
CPR_061 De sequentie moet zijn:  
— breng met de StartCommunication-dienst de overdracht 
tot stand;  
— voer met de StartDiagnosticSession-dienst een afstel ­
lingssessie in en zet de VU in de CALIBRATION- of 
CONTROL-modus (de volgorde van deze twee opdrach ­
ten is niet belangrijk);  
— wijzig de instelling van de uitvoer met de InputOutput ­
ControlByIdentifier-dienst.  
7.1.2  Berichtformaat  
CPR_062 De berichtformaten voor de InputOutputControlByIdentifier- 
primitieven worden omschreven in de onderstaande tabellen.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 325  
Tabel 33  
InputOutputControlByIdentifier Request-bericht  
Byte-#  Parameternaam  Hex-waarde  Mnemoniek  
# 1 Formaatbyte — fysieke adres ­
sering  80 FMT  
# 2 Byte van het doeladres  EE  TGT  
# 3 Byte van het bronadres  tt  SRC  
# 4 Additionele lengtebyte  xx  LEN  
# 5 InputOutputControlByIden ­
tifier Request Sid  2F IOCBI  
# 6 en # 7  InputOutputIdentifier = [Cali ­
brationInputOutput]  F960  IOI_CIO  
# 8 of 
# 8 en # 9  ControlOptionRecord = [  COR_…  
InputOutputControlParameter 
— één waarde uit tabel 36  xx IOCP_…  
controlState — één waarde uit 
tabel 37 (zie onderstaande op ­
merking)]  xx CS_…  
# 9 of 
# 10  Controlesom  00-FF  CS  
Opmerking:  De parameter controlState is slechts in een paar 
gevallen aanwezig (zie 7.1.3).  
Tabel 34  
InputOutputControlByIdentifier Positive Response-bericht  
Byte-#  Parameternaam  Hex-waarde  Mnemoniek  
# 1 Formaatbyte — fysieke adres ­
sering  80 FMT  
# 2 Byte van het doeladres  tt  TGT  
# 3 Byte van het bronadres  EE  SRC  
# 4 Additionele lengtebyte  xx  LEN  
# 5 inputOutputControlByIdenti ­
fier Positive Response SId  6F IOCBIPR  
# 6 en # 7  inputOutputIdentifier = [Cali ­
brationInputOutput]  F960  IOI_CIO  
# 8 of 
# 8 en # 9  controlStatusRecord = [  CSR_  
inputOutputControlParameter 
(zelfde waarde als byte-# 8 ta ­
bel 33)  xx IOCP_…  
controlState (zelfde waarde als 
byte-# 9 tabel 33)] (indien van 
toepassing)  xx CS_…  
# 9 of 
# 10  Controlesom  00-FF  CS  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 326  
Tabel 35  
InputOutputControlByIdentifier Negative Response-bericht  
Byte-#  Parameternaam  Hex-waarde  Mnemoniek  
# 1 Formaatbyte — fysieke adres ­
sering  80 FMT  
# 2 Byte van het doeladres  tt  TGT  
# 3 Byte van het bronadres  EE  SRC  
# 4 Additionele lengtebyte  03  LEN  
# 5 Negative Response Service Id  7F  # 6  
# 6 inputOutputControlByIdentifier 
Request SId  2F IOCBI  
# 7 responseCode=[  
incorrectMessageLength  13  RC_IML  
conditionsNotCorrect  22  RC_CNC  
requestOutOfRange  31  conditionsNot ­
Correct]  
deviceControlLimitsExceeded]  7A  RC_DCLE  
# 8 Controlesom  00-FF  CS  
7.1.3  Parameterdefinitie  
CPR_064 De parameter  inputOutputControlParameter (IOCP_)  
wordt omschreven in de onderstaande tabel.  
Tabel 36  
Definitie van inputOutputControlParameter-waarden  
Hex Beschrijving  Mnemoniek  
00 ReturnControlToECU  
Deze waarde moet aan de server (VU) aangeven 
dat het testapparaat niet langer controle heeft 
over de kalibrerings-I/O-signaallijn.  RCTECU  
01 ResetToDefault  
Deze waarde moet aan de server (VU) aangeven 
dat gevraagd wordt de kalibrerings-I/O-signaal- 
lijn terug te stellen op de standaardinstelling.  RTD ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 327  
Hex Beschrijving  Mnemoniek  
03 ShortTermAdjustment  
Deze waarde moet aan de server (VU) aangeven 
dat gevraagd wordt de kalibrerings-I/O-signaal- 
lijn af te stellen op de waarde in de controlState 
parameter.  STA  
CPR_065 De parameter  controlState  is alleen aanwezig wanneer de 
inputOutputControlParameter op ShortTermAdjustment in ­
gesteld is en wordt in de onderstaande tabel omschreven:  
Tabel 37  
Definitie van controlState-waarden  
Modus  Hex-waarde  Beschrijving  
Uitschakelen  00  I/O-lijn is geblokkeerd (standaardinstelling)  
Inschakelen  01  Kalibrerings-I/O-lijn kan worden gebruikt 
als speedSignalInput  
Inschakelen  02  Kalibrerings-I/O-lijn kan worden gebruikt 
als realTimeSpeedSignalOutputSensor  
Inschakelen  03  Kalibrerings-I/O-lijn kan worden gebruikt 
als RTCOutput  
8. FORMATEN VAN DATARECORDS  
Dit punt bevat nadere bijzonderheden betreffende:  
— algemene regels die moeten worden toegepast op reeksen parame ­
ters die door de voertuigunit aan het testapparaat worden doorge ­
geven,  
— formaten die moeten worden gebruikt voor gegevens die via de in 
punt 6 beschreven diensten voor gegevensoverbrenging worden 
doorgegeven.  
CPR_067 Alle geïdentificeerde parameters moeten door de VU worden 
ondersteund.  
CPR_068 Gegevens die door de VU aan het testapparaat worden door ­
gegeven in antwoord op een verzoekbericht, moeten van het 
gemeten type zijn (d.w.z. huidige waarde van de gevraagde 
parameter zoals gemeten of waargenomen door de VU).  
8.1. Overgebrachte parameterreeksen  
CPR_069 Tabel 38 definieert de reeksen die worden gebruikt om de 
geldigheid van een overgebrachte parameter te bepalen.  
CPR_070 De waarden in de reeks ”foutindicator” vormen een middel 
voor de voertuigunit om onmiddellijk aan te geven dat gel ­
dige parametrische gegevens momenteel niet beschikbaar 
zijn wegens een of andere fout in de tachograaf.  
CPR_071 De waarden in de reeks ”niet beschikbaar” vormen een 
middel voor de voertuigunit om een bericht over te brengen 
dat een parameter bevat welke in die module niet beschik ­
baar is of niet wordt ondersteund. De waarden in de reeks 
”niet gevraagd” vormen een middel voor een apparaat om 
een commandobericht over te brengen en de parameters te 
identificeren waarvoor geen antwoord van het ontvangst ­
apparaat wordt verwacht.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 328  
CPR_072 Indien een storing in een onderdeel het onmogelijk maakt 
geldige gegevens voor een parameter over te brengen, moet 
de foutindicator, als beschreven in tabel 38, worden gebruikt 
in plaats van de gegevens van die parameter. Indien de 
gemeten of berekende gegevens echter een waarde opleveren 
die geldig is, maar de gedefinieerde parameterreeks over ­
schrijdt, mag de foutindicator niet worden gebruikt. De ge ­
gevens moeten worden overgebracht met gebruikmaking van 
de passende minimale of maximale parameterwaarde.  
Tabel 38  
bereik van dataRecords  
Reeksnaam  1 byte 
(Hex-waarde)  2 bytes 
(Hex-waarde)  4 bytes 
(Hex-waarde)  ASCII  
Geldig signaal  00 tot FA  0000 tot FAFF  00000000 tot FAFFFFFF  1 tot en met 
254 
Parameterspecifieke indicator  FB  FB00 tot FBFF  FB000000 tot FBFFFFFF  geen  
Gereserveerde reeks voor toe ­
komstige indicatorbits  FC tot FD  FC00 tot FDFF  FC000000 tot FDFFFFFF  geen  
Foutindicator  FE  FE00 tot FEFF  FE000000 tot FEFFFFFF  0  
Niet beschikbaar of niet ge ­
vraagd  FF FF00 tot FFFF  FF000000 tot FFFFFFFF  FF  
CPR_073 Voor in ASCII gecodeerde parameters is het ASCII-teken 
”*” gereserveerd als begrenzer.  
8.2. Formaten van dataRecords  
De tabellen 39 tot en met 42 bevatten bijzonderheden over de formaten 
die moeten worden gebruikt via de ReadDataByIdentifier- en WriteDa ­
taByIdentifier-diensten.  
CPR_074 Tabel 39 geeft de lengte, resolutie en bedrijfsreeks voor elke 
parameter die door zijn recordDataIdentifier is geïdentifi ­
ceerd:  
Tabel 39  
Formaat van dataRecords  
Parameternaam  Data lengte (bytes)  Resolutie  Bedrijfsreeks  
TimeDate  8  Zie nadere informatie in tabel 40  
HighResolutionTotalVehicle ­
Distance  4 5 m/bit, toename, 0 m offset  0 tot + 21 055 406 km  
Kfactor  2  0,001 pulse/m/bit, toename, 0 offset  0 tot 64,255 pulsen/m  
LfactorTyreCircumference  2  0,125 10  – 3 m /bit, toename, 0 offset  0 tot + 8,031 m  
WvehicleCharacteristicFactor  2  0,001 pulse/m/bit, toename, 0 offset  0 tot 64,255 pulsen/m  
Bandenmaat  15  ASCII  ASCII  
NextCalibrationDate  3  Zie nadere informatie in tabel 41  
SpeedAuthorised  2  1/256 km/h/bit, toename, 0 offset  0 tot 250,996 km/h  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 329  
Parameternaam  Data lengte (bytes)  Resolutie  Bedrijfsreeks  
RegisteringMemberState  3  ASCII  ASCII  
VehicleRegistrationNumber  14  Zie nadere informatie in tabel 42  
VIN 17  ASCII  ASCII  
CPR_075 Tabel 40 bevat bijzonderheden betreffende de formaten van 
de verschillende bytes van de TimeDate-parameter:  
Tabel 40  
Gedetailleerd formaat van TimeDate (recordDataIdentifier-waarde # 
F922)  
Byte  Parameterdefini ­
tie Resolutie  Bedrijfsreeks  
1 Seconden  0,25 s/bit, toename, 0 s comp.  0 tot 59,75  
2 Minuten  1 min/bit, toename, 0 min 
comp.  0 tot 59 min  
3 Uren  1 h/bit toename, 0 h comp.  0 tot 23 h  
4 Maand  1 maand/bit toename, 0 maand 
comp.  1 tot 12 
maand  
5 Dag  0,25 dag/bit toename, 0 dag 
comp. 
(zie NOOT onder tabel 41)  0,25 tot 31,75 
dagen  
6 Jaar  1 jaar/bit toename, + 1985 jaar 
comp. 
(zie NOOT onder tabel 41)  jaar 1985 tot 
2235  
7 Lokale mi ­
nuutcompen ­
satie 1 min/bit, toename, – 125 min 
comp.  – 59 tot + 59 
min 
8 Lokale uur ­
compensatie  1 h/bit toename, – 125 h comp.  – 23 tot + 
23 h  
CPR_076 Tabel 41 bevat bijzonderheden betreffende de formaten van de verschillende 
bytes van de NextCalibrationDate-parameter.  
Tabel 41  
Gedetailleerd formaat van NextCalibrationDate (recordDataIdentifier- 
waarde # F922)  
Byte  Parameterdefini ­
tie Resolutie  Bedrijfsreeks  
1 Maand  1 maand/bit toename, 0 maand 
comp.  1 tot 12 
maand  
2 Dag  0,25 dag/bit toename, 0 dag 
comp. 
(zie NOOT hieronder)  0,25 tot 31,75 
dagen  
3 Jaar  1 jaar/bit toename, + 1985 jaar 
comp. 
(zie NOOT hieronder)  jaar 1985 tot 
2235 ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 330  
NOOT betreffende het gebruik van de ”Dag”-parameter:  
1) Een waarde van 0 voor de datum is ongeldig. De waarden 1, 2, 3 en 
4 worden gebruikt om de eerste dag van de maand aan te geven; 5, 
6, 7 en 8 geven de tweede dag van de maand aan, enz. enz.  
2) Deze parameter beïnvloedt of wijzigt de bovenstaande uur-parame ­
ter niet.  
NOOT betreffende het gebruik van de ”Jaar”-parameter:  
Een waarde van 0 voor het jaar geeft het jaar 1985 aan; een waarde van 
1 geeft 1986 aan, enz.  
CPR_078 Tabel 42 bevat bijzonderheden betreffende de formaten van 
de verschillende bytes van de VehicleRegistrationNumber- 
parameter.  
Tabel 42  
Gedetailleerd formaat van VehicleRegistrationNumber 
(recordDataIdentifier-waarde # F97E)  
Byte  Parameterdefinitie  Resolutie  Bedrijfsreeks  
1 Code Page (zoals gedefinieerd 
in aanhangsel 1)  ASCII  01 tot 0 A  
2 – 14  Vehicle Registration Number 
(zoals gedefinieerd in aanhang ­
sel 1)  ASCII  ASCII  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 331  
Aanhangsel 9  
TYPEGOEDKEURING LIJST VAN MINIMAAL VEREISTE TESTS  
INHOUDSOPGAVE  
1. INLEIDING  
2. FUNCTIETESTS VAN DE VOERTUIGUNIT  
3. FUNCTIETESTS VAN DE BEWEGINGSSENSOR  
4. FUNCTIETESTS VAN TACHOGRAAFKAARTEN  
5. TESTS EXTERNE GNSS-MODULE  
▼M1 
6. TESTS VAN DE EXTERNE APPARATUUR VOOR COMMUNICATIE 
OP AFSTAND  
▼B 
7. FUNCTIETESTS VAN DOCUMENTATIE  
8. INTEROPERABILITEITSTESTS  
1. INLEIDING  
1.1. Typegoedkeuring  
De EG-typegoedkeuring van een controleapparaat (of een component daar ­
van) of van een tachograafkaart is gebaseerd op:  
▼M1 
— een  veiligheidscertificering  volgens de specificaties van de gemeen ­
schappelijke criteria en met een veiligheidsdoelstelling die volledig vol ­
doet aan aanhangsel 10 van deze bijlage;  
▼B 
— een  functiecertificering  uitgevoerd door een autoriteit van de lidstaat 
die certificeert dat het geteste apparaat voldoet aan de voorschriften van 
deze bijlage met betrekking tot uitgevoerde functies, meetnauwkeurig ­
heid en milieukenmerken;  
— een  interoperabiliteitscertificering  uitgevoerd door de bevoegde instan ­
tie die certificeert dat het controleapparaat (of de tachograafkaart) vol ­
ledig interoperabel is met de vereiste modellen tachograafkaarten (of 
controleapparaten) (zie hoofdstuk 8 van deze bijlage).  
Dit aanhangsel specificeert welke tests minimaal door een autoriteit van de 
lidstaat tijdens de functietests moeten worden uitgevoerd, en welke tests 
minimaal door de bevoegde instantie tijdens de interoperabiliteitstests moe ­
ten worden uitgevoerd. De voor het uitvoeren van de tests te volgen pro ­
cedures of de soort tests worden niet nader gespecificeerd.  
Aspecten in verband met de veiligheidscertificering worden niet behandeld 
in dit aanhangsel. Indien sommige voor de typegoedkeuring vereiste tests 
tijdens de veiligheidsevaluatie en het certificeringsproces uitgevoerd zijn, 
hoeven deze tests niet opnieuw te worden uitgevoerd. In dat geval moeten 
alleen de resultaten van deze veiligheidstests worden gecontroleerd. Ter 
informatie worden de voorschriften die naar verwachting tijdens de veilig ­
heidscertificering worden getest (of die nauw verband houden met de tests 
die naar verwachting worden uitgevoerd) in dit aanhangsel met een ”*” 
aangeduid.  
De genummerde voorschriften verwijzen naar het geheel van bijlagen; de 
overige voorschriften verwijzen naar de andere aanhangsels. Zo verwijst 
PIC_001 bijvoorbeeld naar het voorschrift PIC_001 van aanhangsel 3 ”Pic ­
togrammen”.  
Dit aanhangsel behandelt afzonderlijk de typegoedkeuring van de be ­
wegingssensor, de voertuigunit en de externe GNSS-module als samenstel ­
lende delen van het controleapparaat. Elk samenstellend deel krijgt een  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 332  
eigen typegoedkeuringscertificaat waarin de andere compatibele componen ­
ten zijn aangegeven. De functietest van de bewegingssensor (of van de 
externe GNSS-module) wordt uitgevoerd samen met de voertuigunit, en 
omgekeerd.  
Er is geen interoperabiliteit vereist tussen elk model bewegingssensor (of 
externe GNSS-module) en elk model voertuigunit. In dit geval kan de 
typegoedkeuring van een bewegingssensor (of externe GNSS-module) alleen 
in combinatie met de typegoedkeuring van de desbetreffende voertuigunit 
worden verleend, en omgeke erd.  
1.2. Referentienormen  
De onderstaande referentienormen worden in dit aanhangsel gebruikt:  
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: Vibra ­
tion. 
IEC 60068-2-14: Environmental testing — Part 2-14: Tests — Test N: 
Change of temperature.  
IEC 60068-2-27: Environmental testing — Part 2: Tests — Test Ea and 
guidance: Shock.  
IEC 60068-2-30: Environmental testing — Part 2-30: Tests — Test Db: 
Damp heat, cyclic (12 h + 12 h cycle).  
IEC 60068-2-64: Environmental testing — Part 2-64: Tests — Test Fh: 
Vibration, broadband random and guidance.  
IEC 60068-2-78 Environmental testing — Part 2-78: Tests — Test Cab: 
Damp heat, steady state.  
ISO 16750-3 — Mechanical loads (2012-12).  
ISO 16750-4 — Climatic loads (2010-04).  
ISO 20653: Road vehicles — Degree of protection (IP code) — Protection 
of electrical equipment against foreign objects, water and access.  
ISO 10605:2008 + Technical Corrigendum 1:2010 + AMD 1:2014 Road 
vehicles — Test methods for electrical disturbances from electrostatic disch ­
arge.  
ISO 7637-1: 2002 + AMD 1: 2008 Road vehicles — Electrical disturbances 
from conduction and coupling — Part 1: Definitions and general conside ­
rations.  
ISO 7637-2 Road vehicles — Electrical disturbances from conduction and 
coupling — Part 2: Electrical transient conduction along supply lines only.  
ISO 7637-3 Road vehicles — Electrical disturbances from conduction and 
coupling — Part 3: Electrical transient transmission by capacitive and in ­
ductive coupling via lines other than supply lines.  
ISO/IEC 7816-1 Identification cards — Integrated circuit(s) cards with con ­
tacts — Part 1: Physical characteristics.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 333  
ISO/IEC 7816-2 Information technology — Identification cards — Integra ­
ted circuit(s) cards with contacts — Part 2: Dimensions and location of the 
contacts.  
ISO/IEC 7816-3 Information technology — Identification cards — Integra ­
ted circuit(s) cards with contacts — Part 3: Electronic signals and trans ­
mission protocol.  
ISO/IEC 10373-1:2006 + AMD 1:2012 Identification cards — Test methods 
— Part 1: General characteristics.  
ISO/IEC 10373-3:2010 + Technical Corrigendum 1:2013 Identification 
cards — Test methods — Part 3: Integrated circuit cards with contacts 
and related interface devices.  
ISO 16844-3:2004, Cor 1:2006 Road vehicles — Tachograph systems — 
Part 3: Motion sensor interface (with vehicle units).  
ISO 16844-4 Road vehicles — Tachograph systems — Part 4: CAN inter ­
face.  
ISO 16844-6 Road vehicles — Tachograph systems — Part 6: Diagnostics  
ISO 16844-7 Road vehicles — Tachograph systems — Part 7: Parameters.  
ISO 534 Paper and board — Determination of thickness, density and spe ­
cific volume.  
UN ECE R10 Uniform provisions concerning the approval of vehicles with 
regard to electromagnetic compatibility (United Nation Economic Commis ­
sion for Europe)  
2. FUNCTIETESTS VAN DE VOERTUIGUNIT  
▼M1 
Nr. Test  Omschrijving  Gerelateerde voorschriften  
1. Administratieve controle  
1.1 Documentatie  Juistheid van de documentatie  
1.2 Testresultaten van de 
fabrikant  Resultaten van de tijdens integratie door de 
fabrikant uitgevoerde test. 
Papierdemonstraties.  88, 89, 91  
2. Visuele inspectie  
2.1 Naleving van de documentatie  
2.2 Identificatie/opschriften  224 t.e.m. 226  
2.3 Materiaal  219 t.e.m. 223  
2.4 Verzegeling  398, 401 t.e.m. 405  
2.5 Externe interfaces  
3. Functietests  
3.1 Aanwezige functies  02, 03, 04, 05, 07, 382  
3.2 Werkingsmodi  09 t.e.m. 11*, 134, 135  
3.3 Functies en gegevenstoegangsrechten  12* 13*, 382, 383, 386 t.e.m. 
389 
3.4 Controle op het inbrengen en uitnemen van kaarten  15, 16, 17, 18, 19*, 20*, 134  
3.5 Meting van snelheid en afgelegde afstand  21 t.e.m. 31  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 334  
Nr. Test  Omschrijving  Gerelateerde voorschriften  
3.6 Tijdmeting (test uitgevoerd bij 20 °C)  38 t.e.m. 43  
3.7 Controle op activiteiten van de bestuurder  44 t.e.m. 53, 134  
3.8 Controle op de status van de bestuurders  54, 55, 134  
3.9 Handmatige invoer  56 t.e.m. 62  
3.10 Beheer van bedrijfsvergrendelingen  63 t.e.m. 68  
3.11 Bewaking van controleactiviteiten  69, 70  
3.12 Detectie van voorvallen en/of fouten  71 t.e.m. 88, 134  
3.13 Identificatiegegevens van de uitrusting  93*, 94*, 97, 100  
3.14 Gegevens over inbrengen en uitnemen van de bestuurderskaart  102* t.e.m. 104*  
3.15 Gegevens over activiteiten van de bestuurder  105* t.e.m. 107*  
3.16 Plaats- en positiegegevens  108* t.e.m. 112*  
3.17 Gegevens over de kilometerstand  113* t.e.m. 115*  
3.18 Gedetailleerde snelheidsgegevens  116*  
3.19 Gegevens over voorvallen  117*  
3.20 Foutgegevens  118*  
3.21 Kalibreringsgegevens  119* t.e.m. 121*  
3.22 Tijdafstellingsgegevens  124*, 125*  
3.23 Gegevens over controleactiviteiten  126*, 127*  
3.24 Gegevens over bedrijfsvergrendelingen  128*  
3.25 Gegevens over downloadactiviteiten  129*  
3.26 Gegevens over specifieke omstandigheden  130*, 131*  
3.27 Registreren en opslaan op tachograafkaarten  136, 137, 138*, 139*, 141*, 
142, 143 
144, 145, 146*, 147*, 148*, 
149, 150  
3.28 Weergeven  90, 134, 
151 t.e.m. 168 
PIC_001, DIS_001  
3.29 Afdrukken  90, 134, 
169 t.e.m. 181, PIC_001, 
PRT_001 t.e.m. PRT_014  
3.30 Waarschuwingssignalen  134, 182 t.e.m. 191, 
PIC_001  ▼M1
 02016R0799 — NL — 26.02.2020 — 002.001 — 335  
Nr. Test  Omschrijving  Gerelateerde voorschriften  
3.31 Doorsturen van gegevens naar externe media  90, 134, 192 t.e.m. 196  
3.32 Communicatie op afstand voor gerichte wegcontroles  197 tot en met 199  
3.33 Uitvoergegevens naar aanvullende externe apparaten  200, 201  
3.34 Kalibrering  202 t.e.m. 206*, 383, 384, 
386 t.e.m. 391  
3.35 Kalibreringscontrole langs de weg  207 tot en met 209  
3.36 Tijdafstelling  210 t.e.m. 212*  
3.37 Geen interferentie van aanvullende functies  06, 425  
3.38 Motion sensor interface  02, 122  
3.39 Externe GNSS-module  03, 123  
3.40 Verifieer of de voertuigunit (VU) de door de VU-fabrikant bepaalde 
voorvallen en/of fouten detecteert, registreert en opslaat, wanneer een 
gekoppelde bewegingssensor reageert op een magnetisch veld dat de 
bewegingsdetectie van het voertuig stoort  217 
3.41 Codereeks en gestandaardiseerde domeinparameters  CSM_48, CSM_50  
4. Milieutests  
4.1 Temperatuur  Controleer de functionaliteit aan de hand van: 
ISO 16750-4, punt 5.1.1.2: test bij lage tem ­
peratuur in ingeschakelde toestand (72 uur bij 
– 20 °C) 
Deze test berust op IEC 60068-2-1: Environ ­
mental testing — Part 2-1: Tests — Test A: 
Cold. 
Test overeenkomstig ISO 16750-4: punt 
5.1.2.2: test bij hoge temperatuur in ingescha ­
kelde toestand (72 uur bij + 70 °C) 
Deze test berust op IEC 60068-2-2: Basic 
environmental testing procedures Deel 2: tes ­
ten; Tests B: Dry heat 
Test overeenkomstig ISO 16750-4: punt 
5.3.2: snelle temperatuurwisselingen binnen 
de voorgeschreven overgangsduur (20 wisse ­
lingen met een temperatuur variërend van 
– 20 °C tot + 70 °C, bij een verblijf gedu ­
rende 2 uur bij de laagste en de hoogste tem ­
peratuur) 
Een kleiner aantal tests (zoals gedefinieerd in 
punt 3 van deze tabel) kan worden uitgevoerd 
bij de laagste temperatuur, bij de hoogste 
temperatuur en tijdens de temperatuurwisse ­
lingen  213 
4.2 Vochtigheid  Controleer de bestandheid van de voertuigunit 
tegen cyclische vochtigheid (warmteproef) 
aan de hand van IEC 60068-2-30, test Db, 
zes cycli van 24 uur, elke temperatuur varië ­
rend van + 25 °C tot + 55 °C en een relatieve 
vochtigheid van 97 % bij + 25 °C en gelijk 
aan 93 % bij + 55 °C  214 ▼M1
 02016R0799 — NL — 26.02.2020 — 002.001 — 336  
Nr. Test  Omschrijving  Gerelateerde voorschriften  
4.3 Vibratie en mecha ­
nische schokken  1. Sinusoïdale vibraties 
Controleer of de voertuigunit bestand is 
tegen sinusoïdale vibraties met de onder ­
staande kenmerken: 
constante verplaatsing tussen 5 en 11 Hz: 
10 mm piek 
constante acceleratie tussen 11 en 300 Hz: 
5 g 
Dit voorschrift wordt gecontroleerd aan de 
hand van IEC 60068-2-6, test Fc, met een 
minimale testduur van drie keer 12 uur 
(12 uur per as) 
Apparatuur die zich in de aparte bestuur ­
derscabine bevindt, moet volgens ISO 
16750-3 niet op sinusoïdale vibraties wor ­
den getest 
2. Willekeurige vibraties 
Test overeenkomstig ISO 16750-3: punt 
4.1.2.8: test VIII: bedrijfsvoertuigen met 
aparte bestuurderscabine 
Test op willekeurige vibraties, 
10...2 000 Hz, effectieve waarde in ver ­
ticale richting 21,3 m/s  2 , effectieve waarde 
in lengterichting 11,8 m/s  2 , effectieve 
waarde in zijwaartse richting 13,1 m/s  2 , 
drie assen, 32 uur per as, inclusief tempe ­
ratuurwisseling tussen – 20 °C en + 70 °C 
Deze test berust op IEC 60068-2-64: En ­
vironmental testing - Part 2-64: Tests - 
Test Fh: Vibration, broadband random 
and guidance. 
3. Schokken 
Mechanische schok met halve-sinuspuls 
van 3 g overeenkomstig ISO 16750 
De bovengenoemde tests worden op twee ver ­
schillende modellen van de te testen appara ­
tuur uitgevoerd  219 
4.4 Bescherming tegen wa ­
ter en vreemde licha ­
men Test overeenkomstig ISO 20653: Road vehi ­
cles – Degree of protection (IP code) – Pro ­
tection of electrical equipment against foreign 
objects, water and access (gelijkblijvende pa ­
rameters); beveiligingsindex ten minste IP 40  220, 221  
4.5 Overspanningsbeveili ­
ging Controleer of de voertuigunit bestand is tegen 
een stroomvoorziening van: 
24V-uitvoeringen: 34 V bij + 40 °C 1 uur 
12 V-uitvoeringen: 17 V bij + 40 °C 
1 uur(ISO 16750-2)  216 ▼M1
 02016R0799 — NL — 26.02.2020 — 002.001 — 337  
Nr. Test  Omschrijving  Gerelateerde voorschriften  
4.6 Beveiliging tegen om ­
polen  Controleer of de voertuigunit bestand is tegen 
een omkering in de stroomvoorziening 
(ISO 16750-2)  216 
4.7 Kortsluitbeveiliging  Controleer of de invoer-/uitvoersignalen be ­
veiligd zijn tegen kortsluiting in de stroom ­
voorziening en tegen aardsluiting 
(ISO 16750-2)  216 
5. EMC-tests  
5.1 Stralingsemissies en 
gevoeligheid  Overeenkomstig VN/ECE-reglement nr. 10  218  
5.2 Elektrostatische ontla ­
dingen  Overeenkomstig ISO 10605:2008 + 
technische rectificatie 1:2010 + 
AMD 1:2014: ± 4 kV contactontlading en 
± 8 kV luchtontlading  218 
5.3 Transiënte geleidings ­
verschijnselen in de 
stroomvoorziening  Voor 24V-uitvoeringen: overeenkomstig ISO 
7637-2 + VN/ECE-reglement nr. 10, herz. 3: 
puls 1a: Vs= – 450V Ri=50 ohms 
puls 2 a: Vs = + 37 V, Ri = 2 ohm 
puls 2b: Vs = + 20 V, Ri = 0,05 ohm 
puls 3a: Vs = – 150 V, Ri = 50 ohm 
puls 3b: Vs = + 150 V, Ri = 50 ohm 
puls 4: Vs = – 16 V, Va = – 12 V, t6 = 
100 ms 
puls 5: Vs = + 120 V, Ri = 2,2 ohm, td = 
250 ms 
Voor 12 V-uitvoeringen: overeenkomstig ISO 
7637-1 + VN/ECE-reglement nr. 10, herz. 3: 
puls 1: Vs = – 75 V, Ri = 10 ohm 
puls 2 a: Vs = + 37 V, Ri = 2 ohm 
puls 2b: Vs = + 10 V, Ri = 0,05 ohm 
puls 3a: Vs = – 112 V, Ri = 50 ohm 
puls 3b: Vs = + 75 V, Ri = 50 ohm 
puls 4: Vs = – 6 V, Va = – 5 V, t6 = 15 ms 
puls 5: Vs = + 65 V, Ri = 3 ohm, td = 
100 ms 
Puls 5 moet alleen worden getest bij voertuig ­
units die in voertuigen worden geïnstalleerd 
waarvoor geen externe gewone beveiliging 
tegen een plotselinge spanningsverlaging 
geïmplementeerd is 
Wat betreft de voorstelwaarde voor span ­
ningsverlaging: zie ISO 16750-2, vierde uit ­
gave, punt 4.6.4  218 ▼M1
 02016R0799 — NL — 26.02.2020 — 002.001 — 338  
3. FUNCTIETESTS VAN DE BEWEGINGSSENSOR  
Nr. Test  Omschrijving  Gerelateerde voorschriften  
1. Administratieve controle  
1.1 Documentatie  Juistheid van de documentatie  
2 Visuele inspectie  
2.1 Naleving van de documentatie  
2.2 Identificatie/opschriften  225, 226  
2.3 Materiaal  219 t.e.m. 223  
2.4 Verzegeling  398, 401 t.e.m. 405  
3 Functietests  
3.1 Identificatiegegevens van de sensor  95 t.e.m. 97  
3.2 Koppeling bewegingssensor — voertuigunit  122*, 204  
3.3 Bewegingsdetectie 
Juistheid van bewegingsmeting  30 t.e.m. 35  
3.4 Interface van de voertuigunit  02  
3.5 Controleer of de bewegingssensor bestand is tegen een constant magnetisch 
veld. Verifieer, als alternatief, of de bewegingssensor reageert op een constant 
magnetisch veld dat de bewegingsdetectie van het voertuig stoort, zodat een 
aangesloten VU sensorfouten kan detecteren, registreren en opslaan  217 
4 Milieutests  
4.1 Bedrijfstemperatuur  Controleer de functionaliteit (zoals gedefinieerd 
in test nr. 3.3) in het temperatuurbereik 
[– 40 °C; + 135 °C] aan de hand van: 
IEC 60068-2-1, test Ad, met een testduur van 96 
uur bij de laagste temperatuur To  min , 
IEC 60068-2-2, test Bd, met een testduur van 96 
uur bij de hoogste temperatuur To  max 
Test overeenkomstig ISO 16750-4, punt 5.1.1.2: 
test bij lage temperatuur in ingeschakelde toe ­
stand (24 uur bij – 40 °C) 
Deze test berust op IEC 60068-2-1: Environ ­
mental testing — Part 2-1: Tests — Test A: 
Cold; IEC 68-2-2, test Bd, met een testduur 
van 96 uur bij de laagste temperatuur van – 
40 °C 
Test overeenkomstig ISO 16750-4, punt 5.1.2.2: 
test bij hoge temperatuur in ingeschakelde toe ­
stand (96 uur bij + 135 °C) 
Deze test berust op IEC 60068-2-2: Basic envi ­
ronmental testing procedures — Part 2: tests — 
Tests B: Dry heat  213 ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 339  
Nr. Test  Omschrijving  Gerelateerde voorschriften  
4.2 Temperatuur-wisseltest  Test overeenkomstig ISO 16750-4, punt 5.3.2: 
snelle temperatuurwisselingen binnen de voor ­
geschreven overgangsduur (20 wisselingen met 
een temperatuur variërend van – 40 °C tot + 
135 °C, bij een verblijf gedurende 30 minuten 
bij de laagste en de hoogste temperatuur) 
IEC 60068-2-14: Environmental testing — Part 
2-14: Tests — Test N: Change of temperature.  213 
4.3 Vochtigheidscycli  Controleer de functionaliteit (als gedefinieerd in 
test nr. 3.3) aan de hand van IEC 60068-2-30, 
test Db, zes cycli van 24 uur, elke temperatuur 
variërend van + 25 °C tot + 55 °C en een rela ­
tieve vochtigheid van 97 % bij + 25 °C en gelijk 
aan 93 % bij + 55 °C  214 
4.4 Vibratie  ISO 16750-3: punt 4.1.2.6: test VI: bedrijfsvoer ­
tuigen, motor — versnellingsbak, 
vibratietest in gemengde modus, met inbegrip 
van 
a) test sinusoïdale vibraties, 20…520 Hz, 11,4 
… 120 m/s  2 , ≤ 0,5 octaaf per minuut 
b) test willekeurige vibraties, 10…2 000 Hz, ef ­
fectieve waarde 177 m/s  2 
94 uur per as, inclusief temperatuurwisselingen 
tussen – 20 °C en + 70 °C?) 
Deze test berust op IEC 60068-2-80: Environ ­
mental testing — Part 2-80: Tests — Test Fi: 
Vibration — Mixed mode  219 
4.5 Mechanische schokken  ISO 16750-3: punt 4.2.3: test VI: test van ap ­
paratuur in of op de versnellingsbak; 
half-sinusoïdale schok, acceleratie overeen te 
komen binnen een bereik van 
3 000…15 000 m/s  2 , pulsduur overeen te ko ­
men, maar kleiner dan 1 ms, aantal schokken 
overeen te komen 
Deze test berust op IEC 60068-2-27: Environ ­
mental testing — Part 2: Tests — Test Ea and 
guidance: Shock  219 
4.6 Bescherming tegen water en 
vreemde lichamen  Test overeenkomstig ISO 20653: Road vehicles 
— Degree of protection (IP code) — Protection 
of electrical equipment against foreign objects, 
water and access 
(beveiligingsindex ten minste IP 64)  220, 221  
4.7 Beveiliging tegen ompolen  Controleer of de bewegingssensor bestand is te ­
gen een omkering in de stroomvoorziening  216 
4.8 Kortsluitbeveiliging  Controleer of de invoer-/uitvoersignalen bevei ­
ligd zijn tegen kortsluiting in de stroomvoorzie ­
ning en tegen aardsluiting  216 ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 340  
Nr. Test  Omschrijving  Gerelateerde voorschriften  
5 Elektromagnetische compatibiliteit (EMC)  
5.1 Stralingsemissies en gevoe ­
ligheid  Controleer de overeenstemming met VN/ECE- 
reglement nr. 10  218 
5.2 Elektrostatische ontlading  Overeenkomstig ISO 10605:2008 + Technical 
corrigendum: 2010 + AMD 1:2014: ± 4 kV con ­
tactontlading en ± 8 kV luchtontlading  218 
5.3 Transiënte geleidings-ver ­
schijnselen in datatransmis ­
sielijnen  Voor 24V-uitvoeringen: overeenkomstig ISO 
7637-2 + VN/ECE-reglement nr. 10, herz. 3: 
puls 1a: Vs = – 450 V, Ri = 50 ohm 
puls 2a: Vs = + 37 V, Ri = 2 ohm 
puls 2b: Vs = + 20 V, Ri = 0,05 ohm 
puls 3a: Vs = – 150 V, Ri = 50 ohm 
puls 3b: Vs = + 150 V, Ri = 50 ohm 
puls 4: Vs = – 16 V, Va = – 12 V, t6 = 100 ms 
puls 5: Vs = + 120 V, Ri = 2,2 ohm, td = 
250 ms 
Voor 12V-uitvoeringen: overeenkomstig ISO 
7637-1 + VN/ECE-reglement nr. 10, herz. 3: 
puls 1: Vs = – 75 V, Ri = 10 ohm 
puls 2a: Vs = + 37 V, Ri = 2 ohm 
puls 2b: Vs = + 10 V, Ri = 0,05 ohm 
puls 3a: Vs = – 112 V, Ri = 50 ohm 
puls 3b: Vs = + 75 V, Ri = 50 ohm 
puls 4: Vs = – 6 V, Va = – 5 V, t6 = 15 ms 
puls 5: Vs = + 65 V, Ri = 3 ohm, td = 100 ms 
Puls 5 moet alleen worden getest bij voertuig ­
units die in voertuigen worden geïnstalleerd 
waarvoor geen externe gewone beveiliging te ­
gen een plotselinge spanningsverlaging geïmple ­
menteerd is 
Wat betreft de voorstelwaarde voor spannings ­
verlaging: zie ISO 16750-2, vierde uitgave, punt 
4.6.4  218 
4. FUNCTIETESTS VAN TACHOGRAAFKAARTEN  
Tests overeenkomstig dit punt 4,  
nr. 5 „Protocoltests”,  
nr. 6 „Kaartstructuur” en  
nr. 7 „Functietests”  
kunnen worden uitgevoerd door de beoordelings- of certificeringsinstantie 
tijdens de veiligheidscertificering van voor de chipmodule op basis van 
gemeenschappelijke criteria (CC).  
Tests nr. 2.3 en 4.2 zijn identiek. Dit zijn de mechanische tests van de 
combinatie voertuigcarrosserie en chipmodule. Bij vervanging van een van 
deze samenstellende delen (voertuigcarrosserie, chipmodule) moeten deze 
tests worden uitgevoerd.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 341  
Nr. Test  Omschrijving  Gerelateerde voorschriften  
1 Administratieve controle  
1.1 Documentatie  Juistheid van de documentatie  
2 Kaart  
2.1 Opdruk  Controleer of alle beveiligingskenmerken en zicht ­
bare gegevens naar behoren en conform de regels 
op de kaart zijn afgedrukt 
[Code] 
Bijlage 1 C, punt 4.1 „Zichtbare gegevens”, 227 
De voorkant bevat: 
naar gelang van de kaartsoort de vermelding „Be ­
stuurderskaart” of „Controlekaart” of „Werkplaats ­
kaart” of „Bedrijfskaart” in hoofdletters, gedrukt in 
de officiële taal/talen van de lidstaat die de kaart 
afgeeft. 
[Naam van de lidstaat] 
Bijlage 1 C, punt 4.1 „Zichtbare gegevens”, 229 
De voorkant bevat: 
de vermelding van de naam van de lidstaat die de 
kaart afgeeft (facultatief). 
[Teken] 
Bijlage 1 C, punt 4.1 „Zichtbare gegevens”, 229 
De voorkant bevat: 
het onderscheidingsteken van de lidstaat die de kaart 
afgeeft, negatief afgedrukt in een door twaalf gele 
sterren omringde blauwe rechthoek. 
[Enumeratie] 
Bijlage 1 C, punt 4.1 „Zichtbare gegevens”, 232 
De achterkant bevat: 
een toelichting bij de genummerde rubrieken op de 
voorkant van de kaart; 
[Kleur] 
Bijlage 1 C, punt 4.1 „Zichtbare gegevens”, 234 
Tachograafkaarten moeten worden gedrukt met de 
volgende achtergrondkleuren: 
— bestuurderskaart: wit, 
— werkplaatskaart: rood, 
— controlekaart: blauw, 
— bedrijfskaart: geel.  227 t.e.m. 229, 232, 
234 t.e.m. 236  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 342  
Nr. Test  Omschrijving  Gerelateerde voorschriften  
[Beveiliging] 
Bijlage 1 C, punt 4.1 „Zichtbare gegevens”, 235 
Tachograafkaarten moeten ten minste de volgende 
eigenschappen hebben om de kaart te beschermen 
tegen vervalsing en misbruik/manipulatie: 
— een beveiligde achtergrond met fijne guillochepa- 
tronen en regenboogdruk, 
— ten minste één tweekleurige microzeefdrukregel. 
[Opschriften] 
Bijlage 1 C, punt 4.1 „Zichtbare gegevens”, 236 
De lidstaten mogen kleuren of aanduidingen, zoals 
nationale symbolen of beveiligingstekens, toevoegen. 
[Goedkeuringsmerk] 
Tachograafkaarten bevatten een goedkeuringsmerk. 
Het goedkeuringsmerk bestaat uit: 
— een rechthoek waarbinnen een kleine letter „e” is 
aangebracht, gevolgd door een onderscheidings- 
nummer of een onderscheidingsletter van het land 
waar de goedkeuring werd afgegeven, 
— een goedkeuringsnummer, overeenkomend met 
het nummer op het goedkeuringscertificaat dat is 
opgesteld voor de tachograafkaart, en aangebracht 
op een willekeurige positie vlak bij de rechthoek.  
2.2 Mechanische tests  
[Kaartformaat] 
Tachograafkaarten moeten voldoen aan: 
ISO/IEC 7810, Identification cards — Physical cha ­
racteristics, 
[5] Dimension of card, 
[5.1] Card size, 
[5.1.1] Card dimensions and tolerances, 
card type ID-1 Unused card 
[Kaartranden] 
Tachograafkaarten moeten aan de volgende norm 
voldoen: 
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 — NL — 26.02.2020 — 002.001 — 343  
Nr. Test  Omschrijving  Gerelateerde voorschriften  
[Kaartvorm] 
Tachograafkaarten moeten voldoen aan: 
ISO/IEC 7810, Identification cards — Physical 
characteristics, 
[6] Card construction 
[Kaartmateriaal] 
Tachograafkaarten moeten voldoen aan: 
ISO/IEC 7810, Identification cards — Physical 
characteristics, 
[7] Card materials 
[Buigstijfheid] 
Tachograafkaarten moeten voldoen aan: 
ISO/IEC 7810, Identification cards — Physical 
characteristics, 
[8] Card characteristics, 
[8.1] Bending stiffness 
[Toxiciteit] 
Tachograafkaarten moeten voldoen aan: 
ISO/IEC 7810, Identification cards — Physical 
characteristics, 
[8] Card characteristics, 
[8.3] Toxicity 
[Chemicaliënbestendigheid] 
Tachograafkaarten moeten voldoen aan: 
ISO/IEC 7810, Identification cards — Physical 
characteristics, 
[8] Card characteristics, 
[8.4] Resistance to chemicals 
[Maatvastheid] 
Tachograafkaarten moeten voldoen aan: 
ISO/IEC 7810, Identification cards — Physical 
characteristics, 
[8] Card characteristics, 
[8.5] Card dimensional stability and warpage with 
temperature and humidity  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 344  
Nr. Test  Omschrijving  Gerelateerde voorschriften  
[Lichtechtheid] 
Tachograafkaarten moeten voldoen aan: 
ISO/IEC 7810, Identification cards — Physical 
characteristics, 
[8] Card characteristics, 
[8.6] Light 
[Duurzaamheid] 
Bijlage 1 C, punt 4.4 „Milieu- en elektrotechnische 
specificaties”, 241 
De tachograafkaarten moeten vijf jaar lang naar 
behoren kunnen functioneren indien de vastgestelde 
milieu- en elektrotechnische grenswaarden niet wor- 
den overschreden. 
[Afpelsterkte] 
Tachograafkaarten moeten voldoen aan: 
ISO/IEC 7810, Identification cards — Physical 
characteristics, 
[8] Card characteristics, 
[8.8] Peel strength 
[Hechting of contactadhesie] 
De tachograafkaarten moeten voldoen aan: 
ISO/IEC 7810, Identification cards — Physical 
characteristics, 
[8] Card characteristics, 
[8.9] Adhesion or blocking 
[Kromtrekking] 
Tachograafkaarten moeten voldoen aan: 
ISO/IEC 7810, Identification cards — Physical 
characteristics, 
[8] Card characteristics, 
[8.11] Overall card warpage 
[Hittevastheid] 
Tachograafkaarten moeten voldoen aan: 
ISO/IEC 7810, Identification cards — Physical 
characteristics, 
[8] Card characteristics, 
[8.12] Resistance to heat  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 345  
Nr. Test  Omschrijving  Gerelateerde voorschriften  
[Oppervlaktevervormingen] 
Tachograafkaarten moeten voldoen aan: 
ISO/IEC 7810, Identification cards — Physical 
characteristics, 
[8] Card characteristics, 
[8.13] Surface distortions 
[Verontreiniging] 
Tachograafkaarten moeten voldoen aan: 
ISO/IEC 7810, Identification cards — Physical 
characteristics, 
[8] Card characteristics, 
[8.14] Contamination and interaction of card 
components  
2.3 Mechanische tests met 
ingebouwde chipmo ­
dule [Buigvastheid] 
Tachograafkaarten moeten voldoen aan: 
ISO/IEC 7810:2003/AMD 1:2009, Identification 
cards — Physical characteristics, Amendment 1: 
Criteria for cards containing integrated circuits 
[9.2] Dynamic bending stress 
Totaal aantal buigcycli 4 000 
[Torsiesterkte] 
Tachograafkaarten moeten voldoen aan: 
ISO/IEC 7810:2003/AMD 1:2009, Identification 
cards — Physical characteristics, Amendment 1: 
Criteria for cards containing integrated circuits 
[9.3] Dynamic torsional stress 
Totaal aantal torsiecycli 4 000  ISO/IEC 7810  
3 Module  
3.1 Module  Module is te verstaan als de ingekapselde chip en het 
contactplaatje 
[Oppervlakteprofiel] 
Tachograafkaarten moeten voldoen aan: 
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 — NL — 26.02.2020 — 002.001 — 346  
Nr. Test  Omschrijving  Gerelateerde voorschriften  
[Mechanische sterkte] 
Tachograafkaarten moeten voldoen aan: 
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) 
[Elektrische weerstand:] 
Tachograafkaarten moeten voldoen aan: 
ISO/IEC 7816-1:2011, Identification cards — Inte- 
grated circuit cards — Part 1: Cards with contacts — 
Physical characteristics 
[4.4] Electrical resistance (of contacts) 
[Afmeting] 
Tachograafkaarten moeten voldoen aan: 
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 
[Plaats] 
Tachograafkaarten moeten voldoen aanmoeten vol- 
doen aan: 
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 
Voor modules met zes contacten vallen contacten 
„C4” en „C8” niet onder dit testvoorschrift.  
4 Chip  
4.1 Chip  
[Bedrijfstemperatuur] 
De chip van de tachograafkaart werkt bij een omge ­
vingstemperatuur tussen – 25 °C en + 85 °C.  241 t.e.m. 244 
VN/ECE-reglement 
nr. 10 
ISO/IEC 7810 
ISO/IEC 10373  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 347  
Nr. Test  Omschrijving  Gerelateerde voorschriften  
[Temperatuur en vochtigheid] 
Bijlage 1 C, punt 4.4 „Milieu- en elektrotechnische 
specificaties”, 241 
Tachograafkaarten moeten naar behoren kunnen 
functioneren onder alle klimatologische omstandighe ­
den die zich normaliter op het grondgebied van de 
Unie voordoen, en ten minste binnen het tempera ­
tuurbereik van – 25 °C tot + 70 °C met incidentele 
pieken tot + 85 °C; „incidenteel” betekent niet meer 
dan 4 uur per keer en niet meer dan 100 keer tijdens 
de levensduur van de kaart. 
Tachograafkaarten worden achtereenvolgens bloot ­
gesteld aan de volgende temperatuur en relatieve 
vochtigheid (RV) binnen de opgegeven tijdsduur. 
Na elke stap worden de tachograafkaarten getest op 
goede werking van de elektrische onderdelen. 
1 Temperatuur van – 20 °C gedurende 2 uur 
2 Temperatuur van ± 0 °C gedurende 2 uur 
3 Temperatuur van + 20 °C en RV van 50 % gedu ­
rende 2 uur 
4 Temperatuur van + 50 °C en RV van 50 % gedu ­
rende 2 uur 
5 Temperatuur van + 70 °C en RV van 50 % gedu ­
rende 2 uur 
De temperatuur wordt intermitterend verhoogd tot 
+ 85 °C, bij een RV van 50 %, gedurende 60 min. 
6 Temperatuur van + 70 °C en RV van 85 % gedu ­
rende 2 uur 
De temperatuur wordt intermitterend verhoogd tot 
+ 85 °C, bij een RV van 85 %, gedurende 30 min. 
[Vochtigheid] 
Bijlage 1 C, punt 4.4 „Milieu- en elektrotechnische 
specificaties”, 242 
Tachograafkaarten moeten naar behoren kunnen 
functioneren binnen het vochtigheidsbereik van 
10 % tot 90 % 
[Elektromagnetische compatibiliteit (EMC)] 
Bijlage 1 C, punt 4.4 „Milieu- en elektrotechnische 
specificaties”, 244 
Tijdens de werking moeten de tachograafkaarten 
voldoen aan VN/ECE-reglement nr. 10 wat hun 
elektromagnetische compatibiliteit betreft  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 348  
Nr. Test  Omschrijving  Gerelateerde voorschriften  
[Statische elektriciteit] 
Bijlage 1 C, punt 4.4 „Milieu- en elektrotechnische 
specificaties”, 244 
Tijdens de werking moeten de tachograafkaarten 
beveiligd zijn tegen elektrostatische ontladingen 
De tachograafkaarten moeten voldoen aan: 
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 
Testspanning: 4 000 V 
[Röntgenstralen] 
Tachograafkaarten moeten voldoen aan: 
ISO/IEC 7810:2003/AMD 1:2009, Identification 
cards — Physical characteristics, Amendment 1: 
Criteria for cards containing integrated circuits 
[9.1] X-rays 
[Ultraviolet licht] 
ISO/IEC 10373-1:2006 Identification cards — Test 
methods — Part 1: General characteristics 
[5.11] Ultraviolet light 
[Driewieler] 
Tachograafkaarten moeten voldoen aan: 
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 
[Omhulsel] 
Tachograafkaarten moeten voldoen aan: 
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 — NL — 26.02.2020 — 002.001 — 349  
Nr. Test  Omschrijving  Gerelateerde voorschriften  
4.2 Mechanische tests van 
in de kaart ingebedde 
chipmodule -> als on ­
der 2.3  [Buigvastheid] 
Tachograafkaarten moeten voldoen aan: 
ISO/IEC 7810:2003/AMD 1:2009, Identification 
cards — Physical characteristics, Amendment 1: 
Criteria for cards containing integrated circuits 
[9.2] Dynamic bending stress 
Totaal aantal buigcycli 4 000 
[Torsiesterkte] 
Tachograafkaarten moeten voldoen aan: 
ISO/IEC 7810:2003/AMD 1:2009, Identification 
cards — Physical characteristics, Amendment 1: 
Criteria for cards containing integrated circuits 
[9.3] Dynamic torsional stress 
Totaal aantal torsiecycli 4 000  ISO/IEC 7810  
5 Protocoltests  
5.1 ATR  Controleer of het antwoord op terugstellen (ATR) vol ­
doet ISO/IEC 7816-3 
TCS_14, TCS_17, 
TCS_18  
5.2 T=0  Controleer of het protocol T=0 voldoet  ISO/IEC 7816-3 
TCS_11, TCS_12, 
TCS_13, TCS_15  
5.3 PTS  Controleer of het PTS-commando (protocol voor trans ­
missieselectie) voldoet door T=0 op T=1 te zetten  ISO/IEC 7816-3 
TCS_12, TCS_19, 
TCS_20, TCS_21  
5.4 T=1  Controleer of het protocol T=1 voldoet  ISO/IEC 7816-3 
TCS_11, TCS_13, 
TCS_16  
6 Kaartstructuur  
6.1 Ga na of de bestandsstructuur van de kaart voldoet 
door de kaart te controleren op de aanwezigheid van 
verplichte bestanden en bijbehorende toegangscon ­
dities (AC)  TCS 22 t.e.m. TCS 28 
TCS_140 to TCS_179  
7 Functietests  
7.1 Normale verwerking  Test ten minste een keer het toegestane gebruik van 
elk commando (test bijvoorbeeld het Update Binary- 
commando met CLA = ‘00’, CLA = ‘0C’ en met 
verschillende P1-, P2- en Lc-parameters) 
Controleer of de bewerkingen daadwerkelijk op de 
kaart werden uitgevoerd (bijvoorbeeld door het be ­
stand te lezen waarop het commando werd uitgevoerd)  TCS 29 t.e.m. TCS 
139 ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 350  
Nr. Test  Omschrijving  Gerelateerde voorschriften  
7.2 Foutmeldingen  Test voor elk commando ten minste een keer elke 
foutmelding (zoals gespecificeerd in aanhangsel 2) 
Test ten minste een keer elke algemene fout (met uit ­
zondering van de tijdens de veiligheidscertificering ge ­
controleerde integriteitsfouten ‘ 6400 ’) 
7.3 Codereeks en gestandaardiseerde domeinparameters  CSM_48, CSM_50  
8 Personalisatie  
8.1 Optische personalisatie  Bijlage 1 C, punt 4.1 „Zichtbare gegevens”, 230 
De voorkant bevat: 
de gegevens die specifiek zijn voor de afgegeven 
kaart. 
Bijlage 1 C, punt 4.1 „Zichtbare gegevens”, 231 
De voorkant bevat: 
datums in de notatie „dd/mm/jjjj” of „dd.mm.jjjj” 
(dag, maand, jaar). 
Bijlage 1 C, punt 4.1 „Zichtbare gegevens”, 235 
Tachograafkaarten moeten ten minste de volgende 
eigenschappen hebben om de kaart te beschermen 
tegen vervalsing en misbruik/manipulatie: 
— bij de foto moeten de beveiligde achtergrond en de 
foto elkaar overlappen.  230, 231, 235  
5. TESTS EXTERNE GNSS-MODULE  
Nr. Test  Omschrijving  Gerelateerde voorschrif ­
ten 
1 Administratieve controle  
1.1 Documentatie  Juistheid van de documentatie  
2 Visuele inspectie externe GNSS-module  
2.1 Naleving van de documentatie  
2.2 Identificatie/opschriften  224 t.e.m. 226  
2.3 Materiaal  219 t.e.m. 223  
3 Functietests  
3.1 Identificatiegegevens van de sensor  98, 99  
3.2 Koppeling tussen externe GNSS-module — voertuigunit  123,205  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 351  
Nr. Test  Omschrijving  Gerelateerde voorschrif ­
ten 
3.3 GNSS-positie  36, 37  
3.4 Interface van de voertuigunit wanneer de GNSS-ontvanger niet in de voertuigunit 
zit 03 
3.5 Codereeks en gestandaardiseerde domeinparameters  CSM_48, CSM_50  
4 Milieutests  
4.1 Temperatuur  Controleer de functionaliteit aan de hand van: 
ISO 16750-4, punt 5.1.1.2: test bij lage temperatuur in in ­
geschakelde toestand (72 uur bij – 20 °C) 
Deze test berust op IEC 60068-2-1: Environmental testing — 
Part 2-1: Tests — Test A: Cold 
Test overeenkomstig ISO 16750-4, punt 5.1.2.2: test bij hoge 
temperatuur in ingeschakelde toestand (72 uur bij + 70 °C) 
Deze test berust op IEC 60068-2-2: Basic environmental tes ­
ting procedures — Part 2: tests — Tests B: Dry heat 
Test overeenkomstig ISO 16750-4, punt 5.3.2: snelle tempe ­
ratuurwisselingen binnen de voorgeschreven overgangsduur 
(20 wisselingen met een temperatuur variërend van – 20 °C 
tot + 70 °C, bij een verblijf gedurende 1 uur bij de laagste en 
de hoogste temperatuur) 
Een kleiner aantal tests (zoals gedefinieerd in punt 3 van deze 
tabel) kan worden uitgevoerd bij de laagste temperatuur, bij 
de hoogste temperatuur en tijdens de temperatuurwisselingen  213 
4.2 Vochtigheid  Controleer of de voertuigunit bestand is tegen een cyclische 
vochtigheid (warmtetest) aan de hand van IEC 60068-2-30, 
test Db, zes cycli van 24 uur, elke temperatuur variërend van 
+ 25 °C tot + 55 °C en een relatieve vochtigheid van 97 % bij 
+ 25 °C en gelijk aan 93 % bij + 55 °C  214 
4.3 Vibratie en me ­
chanische schok ­
ken 1. Sinusoïdale vibraties 
Controleer of de voertuigunit bestand is tegen sinusoïdale 
vibraties met de onderstaande kenmerken: 
constante verplaatsing tussen 5 en 11 Hz: 10 mm piek 
constante acceleratie tussen 11 en 300 Hz: 5 g 
Dit voorschrift wordt gecontroleerd aan de hand van IEC 
60068-2-6, test Fc, met een minimale testduur van drie 
keer 12 uur (12 uur per as) 
Apparatuur die zich in de aparte bestuurderscabine be ­
vindt, moet volgens ISO 16750-3 niet op sinusoïdale vi ­
braties worden getest  219 ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 352  
Nr. Test  Omschrijving  Gerelateerde voorschrif ­
ten 
2. Willekeurige vibraties 
Test overeenkomstig ISO 16750-3, punt 4.1.2.8: test VIII: 
bedrijfsvoertuigen met aparte bestuurderscabine 
Test op willekeurige vibraties, 10…2 000 Hz, effectieve 
waarde in verticale richting 21,3 m/s  2 , effectieve waarde in 
lengterichting 11,8 m/s  2 , effectieve waarde in zijwaartse 
richting 13,1 m/s  2 , drie assen, 32 uur per as, inclusief 
temperatuurwisseling tussen – 20 °C en + 70 °C 
Deze test berust op IEC 60068-2-64: Environmental testing 
— Part 2-64: Tests — Test Fh: Vibration, broadband 
random and guidance. 
3. Schokken 
Mechanische schok met halve-sinuspuls van 3 g over- 
eenkomstig ISO 16750 
De bovengenoemde tests worden op twee verschillende 
modellen van de te testen apparatuur uitgevoerd  
4.4 Bescherming te ­
gen water en 
vreemde licha ­
men Test overeenkomstig ISO 20653: Road vehicles — Degree of 
protection (IP code) — Protection of electrical equipment 
against foreign objects, water and access (gelijkblijvende pa ­
rameters)  220, 221  
4.5 Overspannings- 
beveiliging  Controleer of de voertuigunit bestand is tegen een stroom ­
voorziening van:  216 
24V-uitvoeringen:  34 V bij + 40 °C 1 uur  
12V-uitvoeringen:  17 V bij + 40 °C 1 uur  
(ISO 16750-2, punt 4.3)  
4.6 Beveiliging te ­
gen ompolen  Controleer of de voertuigunit bestand is tegen een omkering 
in de stroomvoorziening 
(ISO 16750-2, punt 4.7)  216 
4.7 Kortsluit-beveili ­
ging Controleer of de invoer-/uitvoersignalen beveiligd zijn tegen 
kortsluiting in de stroomvoorziening en tegen aardsluiting 
(ISO 16750-2, punt 4.10)  216 
5 EMC-tests  
5.1 Stralingsemissies 
en gevoeligheid  Overeenkomstig VN/ECE-reglement nr. 10  218  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 353  
Nr. Test  Omschrijving  Gerelateerde voorschrif ­
ten 
5.2 Elektrostatische 
ontlading  Overeenkomstig ISO 10605:2008 + Technical Corrigen ­
dum:2010 + AMD 1:2014: ± 4 kV contactontlading en ± 
8 kV luchtontlading  218 
5.3 Transiënte gelei ­
dings-verschijn ­
selen in de 
stroomvoorzie ­
ning Voor 24V-uitvoeringen: overeenkomstig ISO 7637-2 + VN/ 
ECE-reglement nr. 10, herz. 3: 
puls 1a: Vs = – 450 V, Ri = 50 ohm 
puls 2a: Vs = + 37 V, Ri = 2 ohm 
puls 2b: Vs = + 20 V, Ri = 0,05 ohm 
puls 3a: Vs = – 150 V, Ri = 50 ohm 
puls 3b: Vs = + 150 V, Ri = 50 ohm 
puls 4: Vs = – 16 V, Va = – 12 V, t6 = 100 ms 
puls 5: Vs = + 120 V, Ri = 2,2 ohm, td = 250 ms 
Voor 12V-uitvoeringen: overeenkomstig ISO 7637-1 + VN/ 
ECE-reglement nr. 10, herz. 3: 
puls 1: Vs = – 75 V, Ri = 10 ohm 
puls 2a: Vs = + 37 V, Ri = 2 ohm 
puls 2b: Vs = + 10 V, Ri = 0,05 ohm 
puls 3a: Vs = – 112 V, Ri = 50 ohm 
puls 3b: Vs = + 75 V, Ri = 50 ohm 
puls 4: Vs = – 6 V, Va = – 5 V, t6 = 15 ms 
puls 5: Vs = + 65 V, Ri = 3 ohm, td = 100 ms 
Puls 5 moet alleen worden getest bij voertuigunits die in 
voertuigen worden geïnstalleerd waarvoor geen externe ge ­
wone beveiliging tegen een plotselinge spanningsverlaging 
geïmplementeerd is 
Wat betreft de voorstelwaarde voor spanningsverlaging: zie 
ISO 16750-2, vierde uitgave, punt 4.6.4  218 
▼M1 
6. TEST VAN DE EXTERNE APPARATUUR VOOR COMMUNICATIE 
OP AFSTAND  
Nr. Test  Omschrijving  Gerelateerde voorschriften  
1. Administratieve controle  
1.1 Documentatie  Juistheid van de do ­
cumentatie  
2. Visuele inspectie  
2.1 Naleving van de documentatie  
2.2 Identificatie/opschriften  225, 226  
2.3 Materiaal  219 t.e.m. 223  
3. Functietests  
3.1 Communicatie op afstand voor gerichte wegcontroles  4, 197 tot en met 199  
3.2 Registreren en opslaan in het geheugen  91  
3.3 Communicatie met de voertuigunit  Aanhangsel 14 
DSC_66 tot en met 
DSC_70, DSC_71 tot 
en met DSC_76  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 354  
Nr. Test  Omschrijving  Gerelateerde voorschriften  
4. Milieutests  
4.1 Temperatuur  Controleer de functionaliteit aan de hand van: 
ISO 16750-4, punt 5.1.1.2: test bij lage temperatuur in 
ingeschakelde toestand (72 uur bij – 20 °C) 
Deze test berust op IEC 60068-2-1: Environmental tes ­
ting — Part 2-1: Tests — Test A: Cold. 
Test overeenkomstig ISO 16750-4: punt 5.1.2.2: test bij 
hoge temperatuur in ingeschakelde toestand (72 uur bij 
+ 70 °C) 
Deze test berust op IEC 60068-2-2: Basic environmental 
testing procedures Deel 2: testen; Tests B: Dry heat 
Test overeenkomstig ISO 16750-4: punt 5.3.2: snelle 
temperatuurwisselingen binnen de voorgeschreven over ­
gangsduur (20 wisselingen met een temperatuur varië ­
rend van – -20 °C tot + 70 °C, bij een verblijf gedurende 
1 uur bij de laagste en de hoogste temperatuur) 
Een kleiner aantal tests (zoals gedefinieerd in punt 3 van 
deze tabel) kan worden uitgevoerd bij de laagste tempe ­
ratuur, bij de hoogste temperatuur en tijdens de tempe ­
ratuurwisselingen  213 
4.2 Bescherming tegen 
water en vreemde 
lichamen  Test overeenkomstig ISO 20653: Road vehicles – Degree 
of protection (IP code) – Protection of electrical equip ­
ment against foreign objects, water and access (beveili ­
gingsindex ten minste IP 40)  220, 221  
5 EMC-tests  
5.1 Stralingsemissies en 
gevoeligheid  Overeenkomstig VN/ECE-reglement nr. 10  218  
5.2 Elektrostatische ont ­
ladingen  Overeenkomstig ISO 10605:2008 + technische rectifica ­
tie 1:2010 + AMD 1:2014: +/– 4 kV contactontlading en 
+/– 8 kV luchtontlading  218 
5.3 Transiënte gelei ­
dingsverschijnselen 
in de stroomvoor ­
ziening  Voor 24V-uitvoeringen: overeenkomstig ISO 7637-2 + 
VN/ECE-reglement nr. 10, herz. 3: 
puls 1a: Vs=– 450V Ri=50 ohms 
puls 2a: Vs = + 37 V, Ri = 2 ohm 
puls 2b: Vs = + 20 V, Ri = 0,05 ohm 
puls 3a: Vs = – 150 V, Ri = 50 ohm 
puls 3b: Vs = + 150 V, Ri = 50 ohm 
puls 4: Vs = – 16 V, Va = – 12 V, t6 = 100 ms 
puls 5: Vs = + 120 V, Ri = 2,2 ohm, td = 250 ms 
Voor 12 V-uitvoeringen: overeenkomstig ISO 7637-1 + 
VN/ECE-reglement nr. 10, herz. 3: 
puls 1: Vs = – 75 V, Ri = 10 ohm 
puls 2a: Vs = + 37 V, Ri = 2 ohm 
puls 2b: Vs = + 10 V, Ri = 0,05 ohm 
puls 3a: Vs = – 112 V, Ri = 50 ohm  218 ▼M1
 02016R0799 — NL — 26.02.2020 — 002.001 — 355  
Nr. Test  Omschrijving  Gerelateerde voorschriften  
puls 3b: Vs = + 75 V, Ri = 50 ohm 
puls 4: Vs = – 6 V, Va = – 5 V, t6 = 15 ms 
puls 5: Vs = + 65 V, Ri = 3 ohm, td = 100 ms 
Puls 5 moet alleen worden getest bij voertuigunits die in 
voertuigen worden geïnstalleerd waarvoor geen externe 
gewone beveiliging tegen een plotselinge spanningsver ­
laging geïmplementeerd is 
Wat betreft de voorstelwaarde voor spanningsverlaging: 
zie ISO 16750-2, vierde uitgave, punt 4.6.4  
▼B 
7. FUNCTIETESTS VAN DOCUMENTATIE  
Nr. Test  Omschrijving  Gerelateerde voorschriften  
1 Administratieve controle  
1.1 Documentatie  Juistheid van de documentatie  
2 Algemene tests  
2.1 Aantal tekens per re ­
gel Visuele inspectie van afdrukken  172  
2.2 Minimale teken ­
grootte  Visuele inspectie van afdrukken en tekens  173  
2.3 Ondersteunde teken ­
sets De printer ondersteunt de tekens zoals gespecificeerd in 
aanhangsel 1, hoofdstuk 4 „Tekensets”  174 
2.4 Afdrukscherpte  Controle van de typekeuring van de tachograaf en visu ­
ele inspectie van afdrukken  174 
2.5 Leesbaarheid en 
identificatie van af ­
drukken  Inspectie van afdrukken 
Aangetoond aan de hand van door de fabrikant ver ­
strekte testverslagen en testprotocollen 
Het printpapier is bedrukt met alle homologatienummers 
van tachografen waarmee dit wordt gebruikt  175, 177, 178  
2.6 Toevoeging van 
handgeschreven aan ­
tekeningen  Visuele inspectie: er is ruimte beschikbaar voor de 
handtekening van de bestuurder. 
Er is ruimte beschikbaar voor andere handgeschreven 
vermeldingen  180 
2.7 Aanvullende details 
over papierbladen  Op de voor- en achterzijde van het blad kunnen aan ­
vullende details en gegevens worden vermeld 
Dit mag geen afbreuk doen aan de leesbaarheid van de 
afdrukken 
Visuele inspectie  177, 178  ▼M1
 02016R0799 — NL — 26.02.2020 — 002.001 — 356  
Nr. Test  Omschrijving  Gerelateerde voorschriften  
3 Opslagtests  
3.1 Droge hitte  Voorbehandeling: 16 uur bij + 23 °C ± 2 °C en 55 % ± 
3 % RV 
Testomgeving: 72 uur bij + 70 °C ± 2 °C 
Hersteltijd: 16 uur bij + 23 °C ± 2 °C en 55 % ± 3 % 
RV 176, 178 
IEC 60068-2-2-Bb  
2.2 Vochtige hitte  Voorbehandeling: 16 uur bij + 23 °C ± 2 °C en 55 % ± 
3 % RV 
Testomgeving: 144 uur bij + 55 °C ± 2 °C en 93 % ± 
3 % RV 
Hersteltijd: 16 uur bij + 23 °C ± 2 °C en 55 % ± 3 % 
RV 176, 178 
IEC 60068-2-78-Cab  
4 Tests van documentatie tijdens het gebruik  
4.1 Vochtbestendig-heid 
ondergrond (onbe ­
drukt papier)  Voorbehandeling: 16 uur bij + 23 °C ± 2 °C en 55 % ± 
3 % RV 
Testomgeving: 144 uur bij + 55 °C ± 2 °C en 93 % ± 
3 % RV 
Hersteltijd: 16 uur bij + 23 °C ± 2 °C en 55 % ± 3 % 
RV 176, 178 
IEC 60068-2-78-Cab  
4.2 Bedrukbaarheid  Voorbehandeling: 24 uur bij + 40 °C ± 2 °C en 93 % ± 
3 % RV 
Testomgeving: afdruk gemaakt bij + 23 °C ± 2 °C 
Hersteltijd: 16 uur bij + 23 °C ± 2 °C en 55 % ± 3 % 
RV 176, 178  
4.3 Hittevastheid  Voorbehandeling: 16 uur bij + 23 °C ± 2 °C en 55 % ± 
3 % RV 
Testomgeving: 2 uur bij + 70 °C ± 2 °C, droge hitte 
Hersteltijd: 16 uur bij + 23 °C ± 2 °C en 55 % ± 3 % 
RV 176, 178 
IEC 60068-2-2-Bb  
4.4 Bestendigheid tegen 
lage temperaturen  Voorbehandeling: 16 uur bij + 23 °C ± 2 °C en 55 % ± 
3 % RV 
Testomgeving: 24 uur bij – 20 °C ± 3 °C, droge koude 
Hersteltijd: 16 uur bij + 23 °C ± 2 °C en 55 % ± 3 % 
RV 176, 178 
ISO 60068-2-1-Ab  
4.5 Lichtechtheid  Voorbehandeling: 16 uur bij + 23 °C ± 2 °C en 55 % ± 
3 % RV 
Testomgeving: 100 uur onder een verlichtingssterkte 
van 5 000 lux bij + 23 °C ± 2 °C en 55 % ± 3 % RV 
Hersteltijd: 16 uur bij + 23 °C ± 2 °C en 55 % ± 3 % 
RV 176, 178  
Leesbaarheidscriteria voor tests 3.x en 4.x:  
Ee afdruk moet leesbaar zijn indien de optische dichtheid binnen de vol ­
gende grenswaarden ligt:  
gedrukte tekens: min. 1,0  
ondergrond (onbedrukt papier): max. 0,2  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 357  
De optische dichtheid van de gemaakte afdrukken wordt gemeten overeen ­
komstig DIN EN ISO 534.  
De afdrukken moeten maatvast en goed leesbaar blijven  
8. INTEROPERABILITEITSTESTS  
▼M1 
Nr. Test  Omschrijving  
8.1 Tests van de interoperabiliteit tussen voertuigunits en tachograafkaarten  
1 Wederzijdse authenticatie  Controleer of de wederzijdse authenticatie tussen de voertuigunit en 
de tachograafkaart normaal functioneert.  
2 Lees-/schrijftests  Voer een typisch functiescenario in de voertuigunit uit. Het scenario 
moet aan de te testen kaartsoort worden aangepast en schrijfopdrach ­
ten in zoveel mogelijk hoofdbestanden (EF’s) op de kaart bevatten. 
Controleer of alle corresponderende registraties correct zijn inge ­
voerd door gegevens van de voertuigunit over te brengen. 
Controleer of alle corresponderende registraties correct zijn inge ­
voerd door gegevens van de kaart over te brengen. 
Controleer of alle corresponderende registraties correct kunnen wor ­
den gelezen door middel van een dagelijkse afdruk.  
8.2 Tests van de interoperabiliteit tussen voertuigunits en bewegingssensoren  
1 Koppeling  Controleer of de koppelingsprocedure tussen de voertuigunit en de 
bewegingssensoren foutloos wordt uitgevoerd.  
2 Activiteitstests  Voer een typisch activiteitsscenario op de bewegingssensor uit. Het 
scenario heeft betrekking op een normale activiteit waarbij zoveel 
mogelijk voorvallen en fouten worden gegenereerd. 
Controleer of alle corresponderende registraties correct zijn inge ­
voerd door gegevens van de voertuigunit over te brengen. 
Controleer of alle corresponderende registraties correct zijn inge ­
voerd door gegevens van de kaart over te brengen. 
Controleer of alle corresponderende registraties correct kunnen wor ­
den gelezen door middel van een dagelijkse afdruk.  
8.3 Interoperabiliteitstests tussen voertuigunits en externe GNSS-modules (indien van toepassing)  
1 Wederzijdse authenticatie  Controleer of de wederzijdse authenticatie (verbindingsopbouw) tus ­
sen de voertuigunit en de externe GNSS-module normaal functio ­
neert.  
2 Activiteitstests  Voer een typisch activiteitsscenario uit op de externe GNSS-module. 
Het scenario heeft betrekking op een normale activiteit waarbij zo ­
veel mogelijk voorvallen en fouten worden gegenereerd. 
Controleer of alle corresponderende registraties correct zijn inge ­
voerd door gegevens van de voertuigunit over te brengen. 
Controleer of alle corresponderende registraties correct zijn inge ­
voerd door gegevens van de kaart over te brengen. 
Controleer of alle corresponderende registraties correct kunnen wor ­
den gelezen door middel van een dagelijkse afdruk.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 358  
Aanhangsel 10  
BEVEILIGINGSVOORSCHRIFTEN  
Dit aanhangsel beschrijft de voorschriften inzake de IT-beveiliging van de onder ­
delen van slimme tachografen (tachografen van de tweede generatie).  
SEC_001 De volgende onderdelen van slimme tachografen worden gecertifi ­
ceerd op basis van de gemeenschappelijke criteria:  
— voertuigunit  
— tachograafkaart  
— bewegingssensor  
— externe GNSS-module  
SEC_002 In een overeenkomstig de gemeenschappelijke criteria opgesteld on ­
derdeelbeveiligingsprofiel wordt voor elk onderdeel waarvoor een 
veiligheidscertificering vereist is, bepaald aan welke minimumeisen 
dat onderdeel moet voldoen op het gebied van IT-beveiliging.  
SEC_003 De Europese Commissie zorgt ervoor dat de vier beveiligingsprofielen 
die aan deze bijlage voldoen, worden gesponsord, ontwikkeld en 
gevalideerd door de met IT-beveiligingscertificering belaste autoritei ­
ten die deel uitmaken van de Joint Interpretation Working Group 
(JIWG), die de wederzijdse erkenning van certificaten ondersteunt 
onder de auspiciën van de Europese SOGIS-MRA-overeenkomst 
(Agreement on Mutual Recognition of Information Technology Secu ­
rity Evaluation Certificates), en dat deze worden geregistreerd:  
— beveiligingsprofiel voertuigunit  
— beveiligingsprofiel tachograafkaart  
— beveiligingsprofiel bewegingssensor  
— beveiligingsprofiel externe GNSS-module  
Het beveiligingsprofiel voor voertuigunits regelt de gevallen waarin de VU al dan 
niet is ontworpen voor gebruik met een externe GNSS-module. In het laatste 
geval worden de beveiligingseisen voor de externe GNSS-module opgenomen in 
het specifieke beveiligingsprofiel.  
SEC_004 Fabrikanten van onderdelen verfijnen en vervolledigen waar nodig het 
passende onderdeelbeveiligingsprofiel, zonder de bestaande bedreigin ­
gen, doelstellingen, procedurele middelen en specificaties van veilig ­
heidsversterkende functies te wijzigen of te schrappen, teneinde een 
beveiligingsdoelstelling te ontwikkelen die als toetssteen voor de vei ­
ligheidscertificering van het onderdeel zal fungeren.  
SEC_005 Tijdens het beoordelingsproces moet worden bevestigd dat de bevei ­
ligingsdoelstelling volledig conform is met het overeenkomstige be ­
veiligingsprofiel.  
SEC_006 Voor elk beveiligingsprofiel geldt betrouwbaarheidsniveau EAL4, 
versterkt door de betrouwbaarheidsonderdelen ATE_DPT.2 en 
AVA_VAN.5.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 359  
Aanhangsel 11  
ALGEMENE BEVEILIGINGSMECHANISMEN  
INHOUD  
PREAMBULE  
DEEL A TACHOGRAAFSYSTEEM VAN DE EERSTE GENERATIE  
1. INLEIDING  
1.1. Referentienormen  
1.2. Begrippen en afkortingen  
2. CRYPTOGRAFISCHE SYSTEMEN EN ALGORITMEN  
2.1. Cryptografische systemen  
2.2. Cryptografische algoritmen  
2.2.1 RSA-algoritme  
2.2.2 Hashalgoritme  
2.2.3 Algoritme voor gegevenscodering  
3. SLEUTELS EN CERTIFICATEN  
3.1. Generering en verspreiding van sleutels  
3.1.1 Generering en verspreiding van RSA-sleutels  
3.1.2 RSA-testsleutels  
3.1.3 Sleutels voor de bewegingssensor  
3.1.4 Generering en verspreiding van TDES-sessiesleutels  
3.2. Sleutels  
3.3. Certificaten  
3.3.1 Inhoud van de certificaten  
3.3.2 Afgegeven certificaten  
3.3.3 Certificaatverificatie en uitpakken  
4. MECHANISME VOOR WEDERZIJDSE AUTHENTICATIE  
5. VERTROUWELIJKHEIDS-, INTEGRITEITS- EN AUTHENTI ­ 
CATIEMECHANISMEN VOOR GEGEVENSOVERDRACHT 
VIA VU-KAARTEN  
5.1. Beveiligde berichtenuitwisseling  
5.2. Behandeling van fouten bij beveiligde berichtenuitwisseling (SM)  
5.3. Algoritme voor het berekenen van cryptografische controlesommen  
5.4. Algoritme voor het berekenen van cryptogrammen voor vertrouwe ­ 
lijkheids-DO's  
6. DIGITALE HANDTEKENINGMECHANISMEN OM GEGE ­ 
VENS TE DOWNLOADEN  
6.1. Generering van de handtekening  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 360  
6.2. Handtekeningverificatie  
DEEL B DIGITAAL TACHOGRAAFSYSTEEM VAN DE TWEEDE GE ­ 
NERATIE  
7. INLEIDING  
7.1. Referentienormen  
7.2. Notaties en afkortingen  
7.3. Definities  
8. CRYPTOGRAFISCHE SYSTEMEN EN ALGORITMEN  
8.1. Cryptografische systemen  
8.2. Cryptografische algoritmen  
8.2.1 Symmetrische algoritmen  
8.2.2 Asymmetrische algoritmen en gestandaardiseerde domeinparame ­ 
ters 
8.2.3 Hashalgoritmen  
8.2.4 Coderingssuites  
9. SLEUTELS EN CERTIFICATEN  
9.1. Asymmetrische sleutelparen en openbare-sleutelcertificaten  
9.1.1 Algemeen  
9.1.2 Europees niveau  
9.1.3 Lidstaatniveau  
9.1.4 Apparatuurniveau Voertuigunits  
9.1.5 Apparatuurniveau: tachograafkaarten  
9.1.6 Apparatuurniveau: externe GNSS-modules  
9.1.7 Overzicht: vervanging van het certificaat  
9.2. Symmetrische sleutels  
9.2.1 Sleutels ter beveiliging van de communicatie tussen VU en be ­ 
wegingssensor  
9.2.2 Sleutels ter beveiliging van de DSRC-communicatie  
9.3. Certificaten  
9.3.1 Algemeen  
9.3.2 Inhoud van het certificaat  
9.3.3 Certificaataanvragen  
10. WEDERZIJDSE AUTHENTICATIE TUSSEN VU EN KAART, 
EN BEVEILIGDE BERICHTENUITWISSELING  
10.1. Algemeen  
10.2. Wederzijdse verificatie van de certificaatketen  
10.2.1 Verificatie van de certificaatketen op kaartniveau door de VU  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 361  
10.2.2 Verificatie van de certificaatketen op VU-niveau door de kaart  
10.3. VU-authenticatie  
10.4. Chipauthenticatie en sleutelovereenstemming tijdens de sessie  
10.5. Beveiligde berichtenuitwisseling  
10.5.1 Algemeen  
10.5.2 Structuur van het beveiligde bericht  
10.5.3 Afbreken van een sessie voor beveiligde berichtenuitwisseling  
11. KOPPELING, WEDERZIJDSE AUTHENTICATIE EN BEVEI ­ 
LIGDE BERICHTENUITWISSELING TUSSEN VU EN EX ­ 
TERNE GNSS-MODULE  
11.1. Algemeen  
11.2. Koppeling tussen VU en externe GNSS-module  
11.3. Wederzijdse verificatie van de certificaatketen  
11.3.1 Algemeen  
11.3.2 Tijdens de koppeling tussen VU en externe GNSS-module  
11.3.3 Tijdens normaal bedrijf  
11.4. VU-authenticatie, chipauthenticatie en sleutelovereenstemming tij ­ 
dens de sessie  
11.5. Beveiligde berichtenuitwisseling  
12. KOPPELING EN COMMUNICATIE TUSSEN VU EN BE ­ 
WEGINGSSENSOR  
12.1. Algemeen  
12.2. Koppeling tussen VU en bewegingssensor met gebruikmaking van 
sleutels van verschillende generaties  
12.3. Koppeling en communicatie tussen VU en bewegingssensor via 
AES  
12.4. Koppeling tussen VU en bewegingssensor voor apparatuur van 
verschillende generaties  
13. BEVEILIGING VOOR COMMUNICATIE OP AFSTAND VIA 
DE DSRC-INTERFACE  
13.1. Algemeen  
13.2. Codering van de payloadgegevens van de tachograaf en MAC-ge ­ 
nerering  
13.3. Verificatie en decodering van de payloadgegevens van de tacho ­ 
graaf  
14. ONDERTEKENING VAN GEDOWNLOADE GEGEVENS EN 
HANDTEKENINGVERIFICATIE  
14.1. Algemeen  
14.2. Generering van de handtekening  
14.3. Handtekeningverificatie  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 362  
PREAMBULE  
Dit aanhangsel specificeert de beveiligingsmechanismen die het volgende waar ­
borgen:  
— de wederzijdse authenticatie tussen de verschillende onderdelen van het ta ­
chograafsysteem;  
— de vertrouwelijkheid, integriteit, authenticiteit en/of onweerlegbaarheid van de 
gegevens die tussen verschillende onderdelen van het tachograafsysteem wor ­
den uitgewisseld of die op externe opslagmedia worden gedownload.  
Dit aanhangsel bestaat uit twee delen: deel A specificeert de beveiligingsmecha ­
nismen voor het tachograafsysteem van de eerste generatie (digitale tachograaf); 
deel B specificeert de beveiligingsmechanismen voor het tachograafsysteem van 
de tweede generatie (slimme tachograaf).  
De in deel A van dit aanhangsel gespecificeerde mechanismen zijn van toepas ­
sing indien minstens een van de bij de wederzijdse authenticatie en/of gegevens ­
overdracht betrokken onderdelen van het tachograafsysteem van de eerste gene ­
ratie is.  
De in deel B van dit aanhangsel gespecificeerde mechanismen zijn van toepas ­
sing indien de bij de wederzijdse authenticatie en/of gegevensoverdracht betrok ­
ken onderdelen van het tachograafsysteem allebei van de tweede generatie zijn.  
In aanhangsel 15 wordt meer informatie verstrekt over het gebruik van onder ­
delen van de eerste generatie in combinatie met onderdelen van de tweede 
generatie.  
DEEL A  
TACHOGRAAFSYSTEEM VAN DE EERSTE GENERATIE  
1. INLEIDING  
1.1. Referentienormen  
De onderstaande referentienormen worden in dit aanhangsel gebruikt:  
SHA-1 National Institute of Standards and Technology 
(NIST).  FIPS Publication 180-1 : Secure Hash Stan ­
dard. April 1995.  
PKCS1 RSA Laboratories. PKCS 1: RSA Encryption Stan ­
dard. Versie 2.0. Oktober 1998.  
TDES National Institute of Standards and Technology 
(NIST).  FIPS Publication 46-3 : Data Encryption Stan ­
dard. Ontwerp 1999.  
TDES-OP ANSI X9.52, Triple Data Encryption Algorithm Mo ­
des of Operation. 1998.  
ISO/IEC 7816-4 Information Technology — Identification cards — In ­
tegrated circuit(s) cards with contacts — Part 4: Inter ­
industry 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: Inter ­
industry 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 — NL — 26.02.2020 — 002.001 — 363  
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. Begrippen en afkortingen  
De onderstaande begrippen en afkortingen worden in dit aanhangsel 
gebruikt:  
(K a , K  b , K  c ) Reeks sleutels voor gebruik door het algoritme voor 
drievoudige gegevenscodering  
CA Certificeringsautoriteit  
CAR Referentie van de certificeringsautoriteit  
CC Cryptografische controlesom  
CG Cryptogram  
CH Koplabel (header) van het commando  
CHA Autorisatie van de certificaathouder  
CHR Referentie van de certificaathouder  
D() Decodering op basis van DES ( Data Encryption Stan ­
dard ) 
DE Gegevenselement  
DO Gegevensobject  
d Particuliere RSA-sleutel, particuliere exponent  
e Openbare RSA-sleutel, openbare exponent  
E() Codering op basis van DES ( Data Encryption Stan ­
dard ) 
EQT Apparatuur  
Hash()  Hashwaarde als resultaat van  Hash  
Hash  Hashfunctie  
KID Sleutelidentificator  
Km TDES-sleutel. Master Key (hoofdsleutel), gedefinieerd 
in ISO 16844-3  
Km  VU TDES-sleutel ingebracht in voertuigunits  
Km  WC TDES-sleutel ingebracht in werkplaatskaarten  
m Berichtsymbool, een geheel getal tussen 0 en  n-1 
n RSA-sleutels, modulus  
PB Opvulbytes (padding)  
PI Padding-indicatorbyte (voor gebruik in cryptogram ter 
waarborging van vertrouwelijkheid DO)  
PV Ongecodeerde waarde  
s Handtekeningsymbool, een geheel getal tussen 0 en  
n-1 
SSC Zendsequentieteller  
SM Beveiligde berichtenuitwisseling  
TCBC TDEA Cipher Block Chaining-werkingsmodus  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 364  
TDEA Algoritme voor drievoudige gegevenscodering  
TLV Waarde van de labellengte  
VU Voertuigunit  
X.C Door de certificeringsautoriteit afgegeven certificaat 
van gebruiker X  
X.CA Certificeringsautoriteit van gebruiker X  
X.CA.PK  o X.C Handeling van uitpakken van een certificaat om een 
openbare sleutel op te halen. Het is een infix-operator; 
de linker operand is de openbare sleutel van de certi ­
ficeringsautoriteit en de rechter operand is het door 
die certificeringsautoriteit afgegeven certificaat. Het 
resultaat is de openbare sleutel van gebruiker X wiens 
certificaat de rechter operand is  
X.PK Openbare RSA-sleutel van gebruiker X  
X.PK[I] RSA-codering van informatie I, met gebruikmaking 
van de openbare sleutel van gebruiker X  
X.SK Particuliere RSA-sleutel van gebruiker X  
X.SK[I] RSA-codering van informatie I, met gebruikmaking 
van de particuliere sleutel van gebruiker X  
‘xx’ Hexadecimale waarde  
|| Samenvoegingsoperator  
2. CRYPTOGRAFISCHE SYSTEMEN EN ALGORITMEN  
2.1. Cryptografische systemen  
CSM_001 Voertuigunits en tachograafkaarten gebruiken een standaard 
cryptografisch systeem van openbare RSA-sleutels om de 
onderstaande beveiligingsmechanismen te bieden:  
— authenticatie tussen voertuigunits en kaarten,  
— overbrenging van drievoudige DES-sessiesleutels tussen 
voertuigunits en tachograafkaarten,  
— digitale handtekening van de gegevens die van voertuig ­
units of tachograafkaarten worden gedownload op externe 
media.  
CSM_002 Voertuigunits en tachograafkaarten gebruiken een sym ­
metrisch cryptografisch systeem van TDES-sleutels, enerzijds 
om een mechanisme te bieden dat de integriteit waarborgt 
van de tussen voertuigunits en de tachograafkaarten uitgewis ­
selde gebruikersgegevens en anderzijds om waar nodig de 
vertrouwelijkheid te garanderen van de tussen voertuigunits 
en tachograafkaarten uitgewisselde gegevens.  
2.2. Cryptografische algoritmen  
2.2.1  RSA-algoritme  
CSM_003 Het RSA-algoritme wordt door de onderstaande vergelijkin ­
gen volledig gedefinieerd:  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 365  
X.SK[ m] = s = m d mod n 
X.PK[ s] = m = s e mod n 
Een uitgebreidere beschrijving van de RSA-functie is te vin ­
den in de referentienorm [PKCS1]. De in het RSA-algoritme 
gebruikte openbare exponent  e is een geheel getal tussen 3 en 
n-1 dat voldoet aan gcd(e, lcm(p-1, q-1))=1.  
2.2.2  Hashalgoritme  
CSM_004 De digitale handtekeningmechanismen gebruiken het in refe ­
rentienorm [SHA-1] gedefinieerde hashalgoritme SHA-1.  
2.2.3  Algoritme voor gegevenscodering  
CSM_005 Op DES gebaseerde algoritmen worden in de Cipher Block 
Chaining-werkingsmodus gebruikt.  
3. SLEUTELS EN CERTIFICATEN  
3.1. Generering en verspreiding van sleutels  
3.1.1  Generering en verspreiding van RSA-sleutels  
CSM_006 RSA-sleutels worden op drie functionele hiërarchieniveaus 
gegenereerd:  
— Europees niveau,  
— lidstaatniveau,  
— apparatuurniveau.  
CSM_007 Op Europees niveau wordt een enkel Europees sleutelpaar 
(EUR.SK en EUR.PK) gegenereerd. De Europese particuliere 
sleutel wordt gebruikt om de openbare sleutels van de lid ­
staten te certificeren. Van alle gecertificeerde sleutels worden 
registraties bijgehouden. Deze taken worden uitgevoerd door 
de Europese certificeringsautoriteit in opdracht en onder ver ­
antwoordelijkheid van de Europese Commissie.  
CSM_008 Op lidstaatniveau wordt een lidstaat-sleutelpaar (MS.SK en 
MS.PK) gegenereerd. Openbare sleutels van lidstaten worden 
door de Europese certificeringsautoriteit gecertificeerd. De 
particuliere sleutel van de lidstaat wordt gebruikt ter certifi ­
cering van de openbare sleutels die in apparatuur (voertuig ­
unit of tachograafkaart) worden ingebracht. Van alle gecerti ­
ficeerde openbare sleutels worden registraties bijgehouden 
met de identificatie van de apparatuur waarvoor zij bedoeld 
zijn. Deze taken worden door de certificeringsautoriteit van 
de lidstaat uitgevoerd. Een lidstaat kan zijn sleutelpaar regel ­
matig wijzigen.  
CSM_009 Op apparatuurniveau wordt een enkel sleutelpaar (EQT.SK 
en EQT.PK) gegenereerd en in elke apparatuur ingebracht. 
Openbare sleutels voor apparatuur worden door de certifice ­
ringsautoriteit van de lidstaat gecertificeerd. Deze taken kun ­
nen door de fabrikanten en installateurs van de apparatuur of 
door de autoriteiten van de lidstaat worden uitgevoerd. Dit 
sleutelpaar dient voor de authenticatie, digitale handtekening 
en codering.  
CSM_010 De vertrouwelijkheid van de particuliere sleutels blijft ge ­
waarborgd tijdens de generering, eventuele overbrenging en 
opslag.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 366  
De gegevensstroom van dit proces wordt samengevat in het 
onderstaande schema:
  
3.1.2  RSA-testsleutels  
CSM_011 Voor testdoeleinden van de apparatuur (inclusief interope ­
rabiliteitstests) genereert de Europese certificeringsautoriteit 
een afzonderlijk Europees testsleutelpaar en ten minste 
twee testsleutelparen voor de lidstaten. De openbare sleutels 
van deze testsleutelparen worden op basis van de Europese 
particuliere testsleutel gecertificeerd. Voor typegoedkeurings ­
tests van apparatuur brengen de fabrikanten testsleutels in die 
door een van deze testsleutels van de lidstaten gecertificeerd 
zijn. 
3.1.3  Sleutels voor de bewegingssensor  
Tijdens de generering, eventuele overbrenging en opslag wordt de ver ­
trouwelijkheid van de drie hieronder beschreven drievoudige DES-sleu ­
tels op adequate wijze gewaarborgd.  
Ter ondersteuning van ISO 16844-conforme tachograafonderdelen zorgen 
de Europese certificeringsautoriteit en de certificeringsautoriteiten van de 
lidstaten bovendien voor het volgende:  
CSM_036 De Europese certificeringsautoriteit genereert KmVU en 
KmWC, twee onafhankelijke en unieke drievoudige 
DES-sleutels, en genereert Km als:  Km = Km  VU XOR Km  WC . 
De Europesecertificeringsautoriteit geeft deze sleutels des ­
gevraagd door aan de certificeringsautoriteiten van de lidsta ­
ten, via adequaat beveiligde procedures.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 367  
CSM_037 De certificeringsautoriteiten van de lidstaten:  
— gebruiken Km om door de fabrikanten van bewegings ­
sensoren gevraagde gegevens van de bewegingssensor te 
coderen (de met Km te coderen gegevens worden gede ­
finieerd in ISO 16844-3);  
— geven Km  VU via adequaat beveiligde procedures door 
aan de fabrikanten van voertuigunits voor gebruik in 
voertuigunits;  
— zorgen ervoor dat Km  WC wordt ingebracht in alle werk ­
plaatskaarten (
  in het 
hoofdbestand
  ) bij de per ­
sonalisering van de kaart.  
3.1.4  Generering en verspreiding van TDES-sessiesleutels  
CSM_012 Voertuigunits en tachograafkaarten moeten als onderdeel van 
de wederzijdse authenticatie de vereiste gegevens genereren 
en uitwisselen teneinde een gemeenschappelijke drievoudige 
DES-sessiesleutel te ontwikkelen. Met het oog op de ver ­
trouwelijkheid wordt deze gegevensuitwisseling beveiligd 
door een RSA-coderingsmechanisme.  
CSM_013 Deze sleutel wordt gebruikt bij alle navolgende cryptografi ­
sche bewerkingen met beveiligde berichtenuitwisseling. De 
geldigheid van de sleutel vervalt aan het einde van de sessie 
(kaartuitneming of kaartterugstelling) en/of na 240 toepassin ­
gen (een toepassing van de sleutel = een via beveiligde be ­
richtenuitwisseling naar de kaart verzonden commando en 
bijbehorend antwoord).  
3.2. Sleutels  
CSM_014 RSA-sleutels hebben (ongeacht het niveau) de volgende leng ­
te: modulus  n 1 024 bits, openbare exponent  e maximaal 64 
bits, particuliere exponent  d 1 024 bits.  
CSM_015 Drievoudige DES-sleutels hebben de vorm (K  a , K  b , K  a ), 
waarbij K  a en K  b onafhankelijke sleutels van 64 bits zijn. 
Er worden geen bits ingesteld om pariteitsfouten op te spo ­
ren. 
3.3. Certificaten  
CSM_016 Certificaten van openbare RSA-sleutels zijn van het „niet- 
zelfbeschrijvende” en „kaartverifieerbare” type (zie ISO/IEC 
7816-8).  
3.3.1  Inhoud van de certificaten  
CSM_017 Certificaten van openbare RSA-sleutels bevatten de volgende 
gegevens in de onderstaande volgorde:  
Gegevens  Formaat  Bytes  Toelichting  
CPI INTEGER  1  Identificator van het certifi ­
caatprofiel (‘01’ voor deze 
versie)  
CAR  OCTET 
STRING  8 Referentie van de certifice ­
ringsautoriteit  
CHA  OCTET 
STRING  7 Autorisatie van de certifi ­
caathouder  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 368  
Gegevens  Formaat  Bytes  Toelichting  
EOV  TimeReal  4  Vervaldatum van het certi ­
ficaat. Facultatief, ‘FF’ op ­
gevuld indien niet gebruikt  
CHR  OCTET 
STRING  8 Referentie van de certifi ­
caathouder  
n OCTET 
STRING  128 Openbare sleutel (modu ­
lus) 
e OCTET 
STRING  8 Openbare sleutel (openbare 
exponent)  
164 
Opmerkingen:  
1. De „identificator van het certificaatprofiel” (CPI) geeft de exacte 
structuur van een authenticatiecertificaat aan. Dit gegeven kan worden 
gebruikt als interne identificator van apparatuur in een toepasselijke 
lijst van koplabels (headers), waarin de samenvoeging van gegevens ­
elementen in het certificaat wordt omschreven.  
De volgende koplabels (headers) hebben betrekking op de inhoud van 
dit certificaat: 
‘4D’  ‘16’  ‘5F 
29’ ‘01’ ‘42’  ‘08’  ‘5F 
4B’ ‘07’ ‘5F 
24’ ‘04’ ‘5F 
20’ ‘08’ ‘7F 
49’ ‘05’ ‘81’  ‘81 
80’ ‘82’ ‘08’
 Toegevoegd label lijst van headers  
Lengte lijst van headers  
CPI-label  
CPI-lengte  
CAR-label  
CAR-lengte  
CHA-label  
CHA-lengte  
EOV-label  
EOV-lengte  
CHR-label  
CHR-lengte  
Label openbare sleutel (geconstrueerd)  
Lengte opeenvolgende DO's  
Label modulus  
Lengte modulus  
Label openbare exponent  
Lengte openbare exponent 
2. Het doel van de „referentie van de certificeringsautoriteit” (CAR) is 
het identificeren van de certificeringsautoriteit die het certificaat af ­
geeft, zodat het gegevenselement tegelijkertijd met een sleutelidenti ­
ficator van de autoriteit kan worden gebruikt ter verwijzing naar de 
openbare sleutel van de certificeringsautoriteit (zie onderstaande sleu ­
telidentificator voor de codering).  
3. De „autorisatie van de certificaathouder” (CHA) wordt gebruikt om de 
rechten van de certificaathouder te identificeren. Dit gegeven bestaat 
uit de toepassingsidentificator van de tachograaf en het model van de 
apparatuur waarvoor het certificaat bedoeld is (overeenkomstig het 
gegevenselement
  , ‘00’ voor een lidstaat).  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 369  
4. Het doel van de „referentie van de certificaathouder” (CHR) is het 
eenduidig identificeren van de certificaathouder, zodat het gegevens ­
element tegelijkertijd met een sleutelidentificator van het onderwerp 
kan worden gebruikt ter verwijzing naar de openbare sleutel van de 
certificaathouder.  
5. De certificaathouder of certificeringsautoriteiten worden eenduidig ge ­
ïdentificeerd op basis van sleutelidentificatoren. Ze worden als volgt 
gecodeerd:  
5.1 Apparatuur (VU of kaart): 
Gegevens  Serienum ­
mer van 
de appara­
tuur Datum  Type  Fabrikant  
Lengte  4 bytes  2 bytes  1 byte  1 byte  
Waarde  Geheel 
getal  mm yy BCD-code ­
ring Specifiek ken ­
merk fabrikant  Fabrikantcode  
In het geval van een VU is het mogelijk dat de fabrikant bij het 
aanvragen van certificaten de identificatie van de apparatuur 
waarin de sleutels worden ingebracht, soms wel en soms niet 
kent.  
In het eerste geval verzendt de fabrikant de identificatie van de 
apparatuur met de openbare sleutel ter certificering naar de au ­
toriteit van zijn lidstaat. Het certificaat bevat dan de identificatie 
van de apparatuur. De fabrikant moet garanderen dat sleutels en 
certificaat in de daartoe bestemde apparatuur worden ingebracht. 
De sleutelidentificator heeft de hierboven omschreven vorm.  
In het tweede geval moet de fabrikant elke certificaataanvraag 
eenduidig identificeren en deze identificatie met de openbare 
sleutel ter certificering naar de autoriteit van zijn lidstaat ver ­
zenden. Het certificaat bevat de identificatie van de certificaat ­
aanvraag. Nadat de sleutel in de apparatuur is ingebracht, moet 
de fabrikant de autoriteit van zijn lidstaat op de hoogte brengen 
van de aan de apparatuur toegewezen sleutel (dat wil zeggen 
identificatie van de certificaataanvraag en identificatie van de 
apparatuur). De sleutelidentificator heeft de volgende vorm: 
Gegevens  Serienum ­
mer certi­
ficaataan­
vraag  Datum  Type  Fabrikant  
Lengte  4 bytes  2 bytes  1 byte  1 byte  
Waarde  Geheel 
getal  mm yy BCD-code ­
ring ‘FF’ Fabrikantcode  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 370  
5.2. Certificeringsautoriteit: 
Gegevens  Identificatie certi ­
ficeringsautoriteit  Serienummer 
van de sleutel  Additionele 
info Identificator  
Lengte  4 bytes  1 byte  2 bytes  1 byte  
Waarde  1 byte numerieke 
nationale code 
3 bytes alfanume ­
rieke nationale co ­
de Geheel getal  Additionele 
codering 
(specifiek 
voor de certi ­
ficeringsauto ­
riteit) 
‘FF FF’ in ­
dien niet ge ­
bruikt  ‘01’ 
Het serienummer van de sleutel dient om de verschillende sleu ­
tels van een lidstaat te onderscheiden in het geval dat de sleutel 
wordt gewijzigd.  
6. Certificaatverificateurs weten impliciet dat de gecertificeerde openbare 
sleutel als RSA-sleutel van belang is voor de authenticatie, verificatie 
van de digitale handtekening en codering voor vertrouwelijke diensten 
(het certificaat bevat geen objectidentificator ter specificatie).  
3.3.2  Afgegeven certificaten  
CSM_018 Het afgegeven certificaat is een digitale handtekening met 
gedeeltelijke recovery van de inhoud van het certificaat over ­
eenkomstig ISO/IEC 9796-2, uitgezonderd bijlage A.4 daar ­
van, waaraan de „referentie van de certificeringsautoriteit” is 
toegevoegd.  
X.C = X.CA.SK[‘6A’ || C  r || Hash (Cc) || ‘BC’] || C  n || X.CAR 
Met inhoud van het 
certificaat = Cc =  C r || C  n 
106 bytes  58 bytes  
Opmerkingen:  
1. Dit certificaat is 194 bytes lang.  
2. De door de handtekening verborgen CAR wordt ook aan de hand ­
tekening toegevoegd, zodat de openbare sleutel van de certificerings ­
autoriteit ter verificatie van het certificaat kan worden geselecteerd.  
3. De certificaatverificateur kent impliciet het door de certificeringsauto ­
riteit gebruikte algoritme ter ondertekening van het certificaat.  
4. De volgende koplabels (headers) hebben betrekking op dit afgegeven 
certificaat: 
‘7F 21’  ‘09’  ‘5F 37’  ‘81 80’  ‘5F 38’  ‘3A’  ‘42’  ‘08’
 Label zelfbeschrijvend 
certificaat (geconstrueerd)  
Lengte opeenvolgende DO's  
Label handtekening  
Lengte handtekening  
Label restant  
Lengte restant  
CAR-label  
CAR-lengte ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 371  
3.3.3  Certificaatverificatie en uitpakken  
Certificaatverificatie en uitpakken bestaan uit het verifiëren van de hand ­
tekening overeenkomstig ISO/IEC 9796-2, het lezen van de inhoud van 
het certificaat en de opgenomen openbare sleutel: X.PK = X.CA.PK  o 
X.C, en het verifiëren van de geldigheid van het certificaat.  
CSM_019 Hierbij worden de volgende stappen ondernomen:  
Verifieer handtekening en zoek inhoud: 
— van X.C zoek Teken, C  n ' en CAR':  X.C =  Teken  ||  C  n ' ||  CAR'  
128 bytes  58 bytes  8 bytes  
— van CAR' selecteer de vereiste openbare sleutel van de 
certificeringsautoriteit (indien dit nog niet met andere 
middelen is gedaan)  
— open Teken met openbare sleutel CA: Sr' = X.CA.PK 
[Teken],  
— controleer of Sr' begint met ‘6A’ en of eindigt met ‘BC’ 
— bereken C  r ' en H' van: Sr' =  ‘6A’  || C  r ' ||  H'  ||  ‘BC’  
106 bytes  20 bytes  
— vind inhoud van het certificaat C' = C  r ' || C  n ', 
— controleer of  Hash (C') = H'  
Indien de controles in orde zijn, is het certificaat authentiek; 
de inhoud ervan is C'.  
Verifieer geldigheid. Van C':  
— controleer in voorkomend geval einddatum van geldig ­
heidsduur.  
Zoek en bewaar openbare sleutel, sleutelidentificator, autori ­
satie van de certificaathouder en vervaldatum van het certi ­
ficaat van C':  
— X.PK =  n || e 
— X.KID = CHR  
— X.CHA = CHA  
— X.EOV = EOV  
4. MECHANISME VOOR WEDERZIJDSE AUTHENTICATIE  
De wederzijdse authenticatie tussen kaarten en VU's is gebaseerd op het 
volgende principe:  
Elke partij bewijst aan de andere partij in het bezit te zijn van een geldig 
sleutelpaar waarvan de openbare sleutel is gecertificeerd door een certi ­
ficeringsautoriteit van een lidstaat, die zelf weer is gecertificeerd door de 
Europese certificeringsautoriteit.  
Het bewijs wordt geleverd door ondertekening met de particuliere sleutel 
van een willekeurig (aselect), door de andere partij gezonden nummer; de 
andere partij moet het verzonden willekeurige nummer bij de verificatie 
van deze handtekening terugvinden.  
Het mechanisme wordt door de VU gestart bij kaartinbrenging. Het 
begint met de uitwisseling van certificaten en het uitpakken van openbare 
sleutels en eindigt met de instelling van een sessiesleutel.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 372  
CSM_020 Het volgende protocol wordt gebruikt (de pijlen geven com ­
mando's en uitgewisselde gegevens aan (zie aanhangsel 2)):
  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 373
  
▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 374  
5. VERTROUWELIJKHEIDS-, INTEGRITEITS- EN AUTHENTICATIE ­
MECHANISMEN VOOR GEGEVENSOVERDRACHT VIA VU- 
KAARTEN  
5.1. Beveiligde berichtenuitwisseling  
CSM_021 De integriteit van de gegevensoverdracht via VU-kaarten 
wordt beschermd door beveiligde berichtenuitwisseling over ­
eenkomstig de referentienormen [ISO/IEC 7816-4] en [ISO/ 
IEC 7816-8].  
CSM_022 Indien gegevens tijdens de overdracht moeten worden bevei ­
ligd, wordt het gegevensobject in de vorm van een crypto ­
grafische controlesom toegevoegd aan de in het commando 
of antwoord verzonden gegevensobjecten. De cryptografische 
controlesom wordt geverifieerd door de ontvanger.  
CSM_023 De cryptografische controlesom van in een commando ver ­
zonden gegevens bevat de header van het commando en alle 
verzonden gegevensobjecten (=> CLA = ‘0C’; alle gegevens ­
objecten worden ingekapseld met labels waarin b1 = 1).  
CSM_024 Indien het antwoord geen gegevensveld bevat, worden de 
bytes van de statusinformatie in het antwoord beveiligd 
door een cryptografische controlesom.  
CSM_025 Cryptografische controlesommen zijn 4 bytes lang.  
Bij gebruik van beveiligde berichtenuitwisseling hebben de 
commando's en antwoorden derhalve de volgende structuur:  
De gebruikte gegevensobjecten (DO's) zijn een deelverzame ­
ling van de in ISO/IEC 7816-4 beschreven DO's voor bevei ­
ligde berichtenuitwisseling:  
Label  Mnemoniek  Betekenis  
‘81’ T  PV Ongecodeerde waarde van niet met BER-TLV geco ­
deerde gegevens (te beschermen door CC)  
‘97’ T  LE Waarde van Le in het onbeveiligde commando (te 
beschermen door CC)  
‘99’ T  SW Statusinformatie (te beschermen door CC)  
‘8E’ T  CC Cryptografische controlesom  
‘87’ T  PI CG  Padding-indicatorbyte || Cryptogram (Ongecodeerde 
waarde, niet met BER-TLV gecodeerd)  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 375  
Gegeven een onbeveiligd commando-antwoordpaar:  
Koplabel (header) commando  Inhoud commando  
CLA  INS  P1  P2  [Veld L  c ] [Gegevensveld]  [Veld L  e ] 
4 bytes  L bytes, aangeduid als B  1 t/m B  L 
Inhoud antwoord  Staartlabel (trailer) antwoord  
[Gegevensveld]  SW1  SW2  
L r gegevensbytes  2 bytes  
Het corresponderende beveiligde commando-antwoordpaar 
is: 
Beveiligd commando:  
Header commando (CH)  Inhoud commando  
CLA  INS  P1  P2  [Nieuw veld L  c ] [Nieuw gegevensveld]  [Nieuw 
veld L  e ] 
‘OC’  Lengte van 
nieuw 
gegevensveld  T PV L PV PV T  LE L LE L e T CC L CC CC ‘00’  
‘81’ L  c Gegevens­
veld ‘97’ ‘01’  L  e ‘8E’ ‘04’  CC  
In de controlesom te integreren gegevens = CH || PB || T  PV || 
L PV || PV || T  LE || L  LE || L  e || PB  
PB = opvulbytes (80 .. 00) overeenkomstig ISO-IEC 7816-4 
en ISO 9797, methode 2.  
De gegevensobjecten PV en LE zijn alleen aanwezig wan ­
neer het onbeveiligde commando corresponderende gegevens 
bevat.  
Beveiligd antwoord:  
1. Geval waarin het gegevensveld van het antwoord niet leeg 
is en niet hoeft te worden beveiligd ter waarborging van 
de vertrouwelijkheid:  
Inhoud antwoord  Staartlabel (trailer) ant ­
woord  
[Nieuw gegevensveld]  Nieuwe SW1, SW2  
T PV L PV PV T  CC L CC CC 
‘81’ L  r Gegevensveld  ‘8E’  ‘04’  CC  
In de controlesom te integreren gegevens = T  PV 
|| L  PV || PV || PB  
2. Geval waarin het gegevensveld van het antwoord niet leeg 
is en moet worden beveiligd ter waarborging van de ver ­
trouwelijkheid:  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 376  
Inhoud antwoord  Staartlabel (trailer) ant ­
woord  
[Nieuw gegevensveld]  Nieuwe SW1, SW2  
T PI CG  L PI 
CG PI CG  T  CC L CC CC 
‘87’ PI || CG  ‘8E’  ‘04’  CC  
Door CG over te dragen gegevens: niet met BER-TLV 
gecodeerde gegevens en opvulbytes (padding).  
In de controlesom te integreren gegevens = T  PI CG  || L  PI 
CG || PI CG || PB  
3. Geval waarin het gegevensveld van het antwoord leeg is:  
Inhoud antwoord  Staartlabel (trailer) ant ­
woord  
[Nieuw gegevensveld]  Nieuwe SW1, SW2  
T SW L SW SW T  CC L CC CC 
‘99’ ‘02’  Nieuwe SW1, SW2  ‘8E’  ‘04’  CC  
In de controlesom te integreren gegevens = T  SW || L  SW || 
SW || PB  
5.2. Behandeling van fouten bij beveiligde berichtenuitwisseling (SM)  
CSM_026 Indien de tachograafkaart tijdens het vertalen van een com ­
mando een SM-fout ontdekt, dan moeten de statusbytes zon ­
der SM worden teruggezonden. Overeenkomstig ISO/IEC 
7816-4 worden de onderstaande statusbytes gedefinieerd 
om SM-fouten te melden:  
‘66 88’: verificatie van cryptografische controlesom mislukt;  
‘69 87’: verwachte SM-gegevensobjecten ontbreken;  
‘69 88’: SM-gegevensobjecten onjuist.  
CSM_027 Indien de tachograafkaart statusbytes zonder SM-gegevens ­
objecten of met een foutief SM-gegevensobject terugzendt, 
moet de sessie door de VU worden afgebroken.  
5.3. Algoritme voor het berekenen van cryptografische controlesommen  
CSM_028 Cryptografische controlesommen worden opgebouwd door 
middel van een  retail  berichtauthenticatiecode (MAC) over ­
eenkomstig ANSI X9.19 op basis van DES ( Data Encryption 
Standard ): 
— beginfase: het eerste checkblok y0 is E(Ka, SSC);  
— volgende fase: de checkblokken y1, .., yn worden met Ka 
berekend;  
— eindfase: de cryptografische controlesom wordt als volgt 
vanaf het laatste checkblok yn berekend: E(Ka, D(Kb, 
yn)),  
waarbij E() codering met DES en D() decodering met DES 
betekent.  
De vier meest significante bytes van de cryptografische con ­
trolesom worden overgedragen.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 377  
CSM_029 De zendsequentieteller (SSC) wordt tijdens de goedkeurings ­
procedure van de sleutel (sleutelovereenstemming) geïnitieerd 
op: 
begin SSC: Rnd3 (4 minst significante bytes) || Rnd1 (4 
minst significante bytes).  
CSM_030 Elke keer voordat een MAC wordt berekend, wordt de zend ­
sequentieteller met 1 verhoogd (met andere woorden de SSC 
voor het eerste commando = begin SSC + 1, de SSC voor 
het eerste antwoord = begin SSC + 2).  
De onderstaande figuur verduidelijkt de berekening van de  
retail  MAC:
  
5.4. Algoritme voor het berekenen van cryptogrammen voor vertrouwe ­
lijkheids-DO's  
CSM_031 Cryptogrammen worden met TDEA in TCBC-werkings ­
modus berekend overeenkomstig referentienorm [TDES] en 
[TDES-OP] en met de lege vector als beginwaardeblok.  
De onderstaande figuur verduidelijkt de toepassing van sleu ­
tels in TDES:
  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 378  
6. DIGITALE HANDTEKENINGMECHANISMEN OM GEGEVENS TE 
DOWNLOADEN  
CSM_032 De intelligente toepassingsgerichte apparatuur (IDE) slaat de 
van een apparaat (VU of kaart) tijdens een downloadsessie 
ontvangen gegevens op in een fysiek gegevensbestand. Dit 
bestand moet de certificaten MS  i .C en EQT.C bevatten. Het 
bestand bevat digitale handtekeningen van gegevensblokken, 
zoals gespecificeerd in aanhangsel 7 „Protocollen voor gege ­
vensoverdracht”.  
CSM_033 Digitale handtekeningen van gedownloade gegevens gebrui ­
ken een digitaal handtekeningschema met aanhangsel zodat 
gedownloade gegevens desgewenst zonder decodering kun ­
nen worden gelezen.  
6.1. Generering van de handtekening  
CSM_034 De gegevenshandtekening wordt door de apparatuur gegene ­
reerd volgens het handtekeningschema met aanhangsel, zoals 
vastgelegd in referentienorm [PKCS1], op basis van de SHA- 
1-hashfunctie:  
Handtekening = EQT.SK[‘00’ || ‘01’ ||  PS  || ‘00’ || 
DER(SHA-1(Gegevens))]  
PS = Reeks opvulbytes (padding string) met waarde ‘FF’ 
zodat de lengte gelijk is aan 128.  
DER(SHA-1( M)) is de codering van de identificatie van het 
algoritme voor de hashfunctie en de hashwaarde in een 
ASN.1-waarde van het type DigestInfo (kenmerkende code ­
ringsregels):  
‘30’||‘21’||‘30’||‘09’||‘06’||‘05’|| ‘2B’||‘0E’||‘03’||‘02’||‘1A’||‘05 ­ 
’||‘00’||‘04’||‘14’||Hashwaarde.  
6.2. Handtekeningverificatie  
CSM_035 De gegevenshandtekening op gedownloade gegevens wordt 
geverifieerd volgens het handtekeningschema met aanhang ­
sel, zoals vastgelegd in referentienorm [PKCS1], op basis 
van de SHA-1-hashfunctie.  
De verificateur moet de Europese openbare sleutel EUR.PK 
zelf kennen (en vertrouwen).  
De onderstaande tabel verduidelijkt het protocol dat een IDE 
met ingebrachte controlekaart kan volgen om de integriteit te 
verifiëren van gedownloade en op externe opslagmedia 
(ESM) opgeslagen gegevens. De controlekaart wordt gebruikt 
om digitale handtekeningen te decoderen. Deze functie mag 
in dit geval niet in de IDE worden geïmplementeerd.  
De apparatuur die de te analyseren gegevens heeft ge ­
download en ondertekend, wordt aangeduid met EQT.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 379
  
DEEL B  
TACHOGRAAFSYSTEEM VAN DE TWEEDE GENERATIE  
7. INLEIDING  
7.1. Referentienormen  
De onderstaande referentienormen worden in dit aanhangsel gebruikt:  
AES National Institute of Standards and Technology (NIST), 
FIPS PUB 197: Advanced Encryption Standard (AES), 
November 26, 2001  
DSS National Institute of Standards and Technology (NIST), 
FIPS PUB 186-4: Digital Signature Standard (DSS), July 
2013  
ISO 7816-4 ISO/IEC 7816-4, Identification cards — Integrated circuit 
cards — Part 4: Organization, security and commands for 
interchange. Third edition 2013-04-15  
ISO 7816-8 ISO/IEC 7816-8, Identification cards — Integrated circuit 
cards — Part 8: Commands for security operations. Se ­
cond edition 2004-06-01  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 380  
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 Distinguis ­
hed 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 Func ­
tion (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 Au ­
thentication, 2005.  
TR-03111 BSI Technical Guideline TR-03111, Elliptic Curve Cryp ­
tography, version 2.00, 2012-06-28  
7.2. Begrippen en afkortingen  
De onderstaande begrippen en afkortingen worden in dit aanhangsel 
gebruikt:  
AES Advanced Encryption Standard  
CA Certificeringsautoriteit  
CAR Referentie van de certificeringsautoriteit  
CBC Cipher Block Chaining (werkingsmodus)  
CH Koplabel (header) van het commando  
CHA Autorisatie van de certificaathouder  
CHR Referentie van de certificaathouder  
CV Constante vector  
DER Kenmerkende coderingsregels  
DO Gegevensobject  
DSRC Speciale korteafstandscommunicatie  
ECC Elliptische-krommecryptografie  
ECDSA Elliptische kromme-algoritme voor digitale handtekening  
ECDH Elliptische kromme Diffie-Hellman-sleuteluitwisselingspro ­
tocol (algoritme voor sleutelovereenstemming)  
EGF Externe GNSS-module  
EQT Apparatuur  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 381  
IDE Intelligente toepassingsgerichte apparatuur  
K M Master Key (hoofdsleutel) van de bewegingssensor om een 
VU te koppelen aan een bewegingssensor  
K M-VU  In voertuigunits ingebrachte sleutel waarmee de VU de 
hoofdsleutel (Master Key) van de bewegingssensor kan 
afleiden indien een werkplaatskaart in de VU is ingebracht  
K M-WC  In werkplaatskaarten ingebrachte sleutel waarmee de VU 
de hoofdsleutel (Master Key) van de bewegingssensor kan 
afleiden indien een werkplaatskaart in de VU is ingebracht  
MAC Berichtauthenticatiecode  
MoS Bewegingssensor  
MSB Meest significante bit  
PKI Openbare-sleutelinfrastructuur  
RCF Inrichting voor communicatie op afstand  
SSC Zendsequentieteller  
SM Beveiligde berichtenuitwisseling  
TDES Standaard voor drievoudige gegevenscodering  
TLV Waarde van de labellengte  
VU Voertuigunit  
X.C Openbare-sleutelcertificaat van gebruiker X  
X.CA Certificeringsautoriteit die het certificaat van gebruiker X 
heeft afgegeven  
X.CAR Referentie van de certificeringsautoriteit die vermeld staat 
in het certificaat van gebruiker X  
X.CHR Referentie van de certificaathouder die vermeld staat in het 
certificaat van gebruiker X  
X.PK Openbare sleutel van gebruiker X  
X.SK Particuliere sleutel van gebruiker X  
X.PK  eph Tijdelijke openbare sleutel van gebruiker X  
X.SK  eph Tijdelijke particuliere sleutel van gebruiker X  
‘xx’ Hexadecimale waarde  
|| Samenvoegingsoperator  
7.3. Definities  
De in dit aanhangsel gebruikte begrippen worden gedefinieerd in deel I 
van bijlage 1 C.  
8. CRYPTOGRAFISCHE SYSTEMEN EN ALGORITMEN  
8.1. Cryptografische systemen  
CSM_38 Voertuigunits en tachograafkaarten gebruiken een op ellip ­
tische-krommecryptografie gebaseerd systeem van open ­
bare sleutels om de volgende beveiligingsdiensten te le ­
veren:  
— wederzijdse authenticatie tussen voertuigunit en kaart;  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 382  
— overeenstemming van AES-sessiesleutels tussen voer ­
tuigunit en kaart;  
— waarborgen van de authenticiteit, integriteit en onweer ­
legbaarheid van de gegevens die van voertuigunits of 
tachograafkaarten worden gedownload op externe me ­
dia. 
CSM_39 Voertuigunits en externe GNSS-modules gebruiken een op 
elliptische-krommecryptografie gebaseerd systeem van 
openbare sleutels om de volgende beveiligingsdiensten te 
leveren:  
— koppeling tussen voertuigunit en externe GNSS-modu ­
le; 
— wederzijdse authenticatie tussen voertuigunit en externe 
GNSS-module;  
— overeenstemming van AES-sessiesleutels tussen voer ­
tuigunit en externe GNSS-module.  
CSM_40 Voertuigunits en tachograafkaarten gebruiken een op AES 
gebaseerd symmetrisch cryptografisch systeem om de vol ­
gende beveiligingsdiensten te leveren:  
— waarborgen van de authenticiteit en integriteit van de 
tussen voertuigunit en tachograafkaart uitgewisselde 
gegevens;  
— waarborgen (waar nodig) van de vertrouwelijkheid van 
de tussen voertuigunit en tachograafkaart uitgewisselde 
gegevens.  
CSM_41 Voertuigunits en externe GNSS-modules gebruiken een op 
AES gebaseerd symmetrisch cryptografisch systeem om de 
volgende beveiligingsdiensten te leveren:  
— waarborgen van de authenticiteit en integriteit van de 
tussen voertuigunit en externe GNSS-module uitgewis ­
selde gegevens.  
CSM_42 Voertuigunits en bewegingssensoren gebruiken een op 
AES gebaseerd symmetrisch cryptografisch systeem om 
de volgende beveiligingsdiensten te leveren:  
— koppeling tussen voertuigunit en bewegingssensor,  
— wederzijdse authenticatie tussen voertuigunit en be ­
wegingssensor;  
— waarborgen van de vertrouwelijkheid van de tussen 
voertuigunit en bewegingssensor uitgewisselde gege ­
vens.  
CSM_43 Voertuigunits en controlekaarten gebruiken een op AES 
gebaseerd symmetrisch cryptografisch systeem om de vol ­
gende beveiligingsdiensten te leveren via de interface voor 
communicatie op afstand:  
— waarborgen van de vertrouwelijkheid, authenticiteit en 
integriteit van de gegevens die van een voertuigunit 
worden overgebracht naar een controlekaart.  
Opmerkingen:  
— Strikt genomen worden de VU-gegevens via een in ­
richting voor communicatie op afstand binnen of bui ­
ten de VU overgebracht naar een door de controleamb ­
tenaar bediend systeem voor ondervraging op afstand 
(zie aanhangsel 14). Het systeem voor ondervraging op  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 383  
afstand brengt de ontvangen gegevens echter over op 
een controlekaart om ze te decoderen en te authentice ­
ren. De inrichting voor communicatie op afstand en het 
systeem voor ondervraging op afstand zijn volledig 
transparant vanuit beveiligingsoogpunt.  
— Voor de DSRC-interface biedt een werkplaatskaart de ­
zelfde beveiligingsdiensten als een controlekaart. Zo 
kan in de werkplaats worden gecontroleerd of de 
VU-interface voor communicatie op afstand goed func ­
tioneert, ook wat de beveiliging betreft. Zie punt 9.2.2 
voor meer informatie.  
8.2. Cryptografische algoritmen  
8.2.1  Symmetrische algoritmen  
CSM_44 Voertuigunits, tachograafkaarten, bewegingssensoren en 
externe GNSS-modules ondersteunen het AES-algoritme, 
zoals vastgelegd in [AES], met een sleutellengte van 
128, 192 en 256 bits.  
8.2.2  Asymmetrische algoritmen en gestandaardiseerde domeinparameters  
CSM_45 Voertuigunits, tachograafkaarten en externe GNSS-modu ­
les ondersteunen elliptische-krommecryptografie met een 
sleutelgrootte van 256, 384 en 512/521 bits.  
CSM_46 Voertuigunits, tachograafkaarten en externe GNSS-modu ­
les ondersteunen het ECDSA-ondertekeningsalgoritme, zo ­
als gespecificeerd in [DSS].  
CSM_47 Voertuigunits, tachograafkaarten en externe GNSS-modu ­
les ondersteunen het ECKA-EG-algoritme voor sleutel ­
overeenstemming, zoals gespecificeerd in [TR 03111].  
CSM_48 Voertuigunits, tachograafkaarten en externe GNSS-modu ­
les ondersteunen alle gestandaardiseerde domeinparameters 
die hieronder in Tabel 1 worden gespecificeerd voor de 
elliptische-krommecryptografie.  
Tabel 1  
Gestandaardiseerde domeinparameters  
Naam  Grootte (bits)  Referentie  Objectidentificator  
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 — NL — 26.02.2020 — 002.001 — 384  
Opmerking:  de objectidentificatoren in de laatste kolom 
van Tabel 1 worden gespecificeerd in [RFC 5639] wat 
de Brainpool-krommen betreft, en in [RFC 5480] wat de 
NIST-krommen betreft.
  
8.2.3  Hashalgoritmen  
▼M1 
CSM_49 Voertuigunits, tachograafkaarten en externe GNSS-modu ­
les ondersteunen de in [SHS] gespecificeerde algoritmen 
SHA-256, SHA-384 en SHA-512.  
▼B 
8.2.4  Coderingssuites  
CSM_50 Indien een symmetrisch algoritme, asymmetrisch algoritme 
en/of hashalgoritme worden gecombineerd om een bevei ­
ligingsprotocol te vormen, zijn de respectieve sleutellengte 
en hashgrootte (ongeveer) van gelijke cryptografische 
sterkte. De toegestane coderingssuites worden weergege ­
ven in Tabel 2:  
Tabel 2  
Toegestane coderingssuites  
ID coderingssuite  ECC-sleutelgrootte 
(bits)  AES-sleutellengte (bits)  Hashalgoritme  MAC-lengte (by ­
tes) 
CS#1  256  128  SHA-256  8  
CS#2  384  192  SHA-384  12  
CS#3  512/521  256  SHA-512  16  
Opmerking:  in dit aanhangsel worden ECC-sleutels met een grootte van 512 bits en 521 bits in 
elk opzicht als van gelijke cryptografische sterkte beschouwd.  
9. SLEUTELS EN CERTIFICATEN  
9.1. Asymmetrische sleutelparen en openbare-sleutelcertificaten  
9.1.1  Algemeen  
Opmerking: de hier beschreven sleutels worden gebruikt voor de weder ­
zijdse authenticatie en beveiligde berichtenuitwisseling tussen voertuig ­
units en tachograafkaarten en tussen voertuigunits en externe GNSS-mo ­
dules. De desbetreffende procedures worden uitvoerig toegelicht in 
hoofdstukken 10 en 11 van dit aanhangsel.  
CSM_51 In het Europese slimme tachograafsysteem worden de 
ECC-sleutelparen en bijbehorende certificaten op drie 
functionele hiërarchieniveaus gegenereerd en beheerd:  
— Europees niveau,  
— lidstaatniveau,  
— apparatuurniveau.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 385  
CSM_52 In het volledige Europese slimme tachograafsysteem wor ­
den openbare en particuliere sleutels en certificaten gege ­
nereerd, beheerd en uitgewisseld met gebruikmaking van 
gestandaardiseerde en beveiligde methoden.  
9.1.2  Europees niveau  
CSM_53 Op Europees niveau wordt een enkel Europees ECC-sleu ­
telpaar gegenereerd, aangeduid als EUR en bestaande uit 
een particuliere sleutel (EUR.SK) en een openbare sleutel 
(EUR.PK). Dit sleutelpaar vormt de basis van de openba ­
re-sleutelinfrastructuur (PKI) van het volledige Europese 
slimme tachograafsysteem. Deze taak wordt uitgevoerd 
door de Europese basiscertificeringsautoriteit (ERCA) in 
opdracht en onder verantwoordelijkheid van de Europese 
Commissie.  
CSM_54 De ERCA gebruikt de Europese particuliere sleutel om een 
(zelfondertekend) basiscertificaat van de Europese open ­
bare sleutel te ondertekenen, en deelt dit Europese basis ­
certificaat mee aan alle lidstaten.  
CSM_55 De ERCA gebruikt de Europese particuliere sleutel om 
desgevraagd de openbare-sleutelcertificaten van de lidsta ­
ten te ondertekenen. De ERCA houdt registraties bij van 
alle ondertekende openbare-sleutelcertificaten van de lid ­
staten.  
CSM_56 Zoals aangegeven in Figuur 1 onder 9.1.7, genereert de 
ERCA om de 17 jaar een nieuw Europees basissleutelpaar. 
Telkens wanneer de ERCA een nieuw Europees basissleu ­
telpaar genereert, maakt zij een nieuw, zelfondertekend 
basiscertificaat voor de nieuwe Europese openbare sleutel. 
Het Europese basiscertificaat is 34 jaar en 3 maanden 
geldig.  
Opmerking:  op het ogenblik dat een nieuw basissleutelpaar 
wordt geïntroduceerd, genereert de ERCA ook een nieuwe 
hoofdsleutel voor de bewegingssensor en een nieuwe 
DSRC-hoofdsleutel (zie punten 9.2.1.2 en 9.2.2.2).  
CSM_57 Alvorens een nieuw Europees basissleutelpaar te genere ­
ren, onderzoekt de ERCA welke cryptografische sterkte 
het nieuwe sleutelpaar moet hebben om gedurende de ko ­
mende 34 jaar bescherming te bieden tegen inbreuken op 
de beveiliging. Zoals gespecificeerd in CSM_50, schakelt 
de ERCA indien nodig over op een coderingssuite die een 
grotere cryptografische sterkte heeft dan de huidige.  
▼M1 
CSM_58 Telkens wanneer de ERCA een nieuw Europees basissleu ­
telpaar genereert, maakt zij een verbindingscertificaat voor 
de nieuwe Europese openbare sleutel en ondertekent die 
met de vorige Europese particuliere sleutel. Het verbin ­
dingscertificaat is 17 jaar en 3 maand geldig. Dit wordt 
eveneens verduidelijkt in Figuur 1 onder 9.1.7.  
▼B 
Opmerking:  aangezien een verbindingscertificaat de door 
de ERCA gegenereerde openbare sleutel van generatie  X 
bevat en wordt ondertekend met de door de ERCA gege ­
nereerde particuliere sleutel van generatie  X-1, kan appara ­
tuur waarvoor een sleutel van generatie  X-1  is verstrekt, 
vertrouwen op apparatuur die beschikt over een sleutel van 
generatie  X. 
CSM_59 Zodra een nieuw basissleutelcertificaat van kracht wordt, 
staakt de ERCA het gebruik van de particuliere sleutel van 
het basissleutelpaar.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 386  
CSM_60 De ERCA beschikt te allen tijde over de volgende crypto ­
grafische sleutels en certificaten:  
— het huidige EUR-sleutelpaar en bijbehorend certificaat;  
— alle vorige EUR-certificaten ter verificatie van de nog 
geldende certificaten van de certificeringsautoriteiten 
van de lidstaten;  
— verbindingscertificaten voor EUR-certificaten van alle 
generaties, met uitzondering van het eerste certificaat.  
9.1.3  Lidstaatniveau  
CSM_61 Alle lidstaten die certificaten voor tachograafkaarten moe ­
ten ondertekenen, genereren een of meerdere unieke ECC- 
sleutelparen, aangeduid als MSCA_Card. Alle lidstaten die 
certificaten voor voertuigunits of externe GNSS-modules 
moeten ondertekenen, genereren daarnaast ook een of 
meerdere unieke ECC-sleutelparen, aangeduid als 
MSCA_VU-EGF.  
CSM_62 De taak om sleutelparen op lidstaatniveau te genereren, 
wordt opgedragen aan de certificeringsautoriteit van de 
lidstaat (MSCA). Telkens wanneer de MSCA een lid ­
staat-sleutelpaar genereert, geeft zij de openbare sleutel 
door aan de ERCA om het desbetreffende, door de 
ERCA ondertekende lidstaatcertificaat te verkrijgen.  
CSM_63 De MSCA kiest voor het lidstaat-sleutelpaar dezelfde cryp ­
tografische sterkte als die van het Europese basissleutel ­
paar waarmee het corresponderende lidstaatcertificaat 
wordt ondertekend.  
CSM_64 Het sleutelpaar MSCA_VU-EGF bestaat in voorkomend 
geval uit een particuliere sleutel MSCA_VU-EGF.SK en 
een openbare sleutel MSCA_VU-EGF.PK. De MSCA ge ­
bruikt de particuliere sleutel MSCA_VU-EGF.SK uitslui ­
tend om de openbare-sleutelcertificaten van voertuigunits 
en externe GNSS-modules te ondertekenen.  
CSM_65 Het sleutelpaar MSCA_Card bestaat uit een particuliere 
sleutel (MSCA_Card.SK) en een openbare sleutel 
(MSCA_Card.PK). De MSCA gebruikt de particuliere 
sleutel MSCA_Card.SK uitsluitend om de openbare-sleu ­
telcertificaten van tachograafkaarten te ondertekenen.  
CSM_66 De MSCA houdt registraties bij van alle ondertekende 
certificaten van voertuigunits, externe GNSS-modules en 
tachograafkaarten, samen met de identificatie van de ap ­
paratuur waarvoor elk certificaat bedoeld is.  
CSM_67 Het certificaat MSCA_VU-EGF is 17 jaar en 3 maanden 
geldig. Het certificaat MSCA_Card is 7 jaar en 1 maand 
geldig.  
CSM_68 Zoals aangegeven in Figuur 1 onder 9.1.7, kunnen de 
particuliere sleutel van een sleutelpaar MSCA_VU-EGF 
en de particuliere sleutel van een sleutelpaar MSCA_Card 
gedurende twee jaar worden gebruikt.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 387  
CSM_69 De MSCA staakt het gebruik van de particuliere sleutel 
van het sleutelpaar MSCA_VU-EGF zodra de gebruikster ­
mijn is verstreken. De MSCA staakt eveneens het gebruik 
van de particuliere sleutel van het sleutelpaar MSCA_Card 
zodra de gebruikstermijn is verstreken.  
CSM_70 De MSCA beschikt te allen tijde over de volgende cryp ­
tografische sleutels en certificaten:  
— het huidige sleutelpaar MSCA_Card en bijbehorend 
certificaat;  
— alle vorige certificaten MSCA_Card ter verificatie van 
de nog geldende certificaten voor tachograafkaarten;  
— het huidige EUR-certificaat ter verificatie van het hui ­
dige MSCA-certificaat;  
— alle vorige EUR-certificaten ter verificatie van alle nog 
geldende MSCA-certificaten.  
CSM_71 Voorts beschikt de MSCA, indien zij certificaten voor 
voertuigunits of externe GNSS-modules moet onderteke ­
nen, over de volgende sleutels en certificaten:  
— het huidige sleutelpaar MSCA_VU-EGF en bijbeho ­
rend certificaat;  
— alle vorige openbare sleutels MSCA_VU-EGF ter ve ­
rificatie van de nog geldende certificaten voor VU's of 
externe GNSS-modules.  
9.1.4  Apparatuurniveau: voertuigunits  
▼M1 
CSM_72 Voor elke voertuigunit worden twee unieke ECC-sleutel ­
paren gegenereerd, aangeduid als VU_MA en VU_Sign. 
Deze taak wordt uitgevoerd door de VU-fabrikanten. De 
partij die een VU-sleutelpaar genereert, verzendt de open ­
bare sleutel naar haar MSCA om het desbetreffende, door 
de MSCA ondertekende VU-certificaat te verkrijgen. De 
particuliere sleutel wordt uitsluitend door de voertuigunit 
gebruikt.  
▼B 
CSM_73 De certificaten VU_MA en VU_Sign van de voertuigunit 
hebben dezelfde ingangsdatum.  
CSM_74 De VU-fabrikant kiest voor het VU-sleutelpaar dezelfde 
cryptografische sterkte als die van het MSCA-sleutelpaar 
waarmee het corresponderende VU-certificaat wordt onder ­
tekend.  
CSM_75 De voertuigunit gebruikt het sleutelpaar VU_MA, be ­
staande uit de particuliere sleutel VU_MA.SK en de open ­
bare sleutel VU_MA.PK, uitsluitend om zich te authenti ­
ceren bij de tachograafkaarten en externe GNSS-modules, 
zoals gespecificeerd in punten 10.3 en 11.4 van dit aan ­
hangsel.  
CSM_76 De voertuigunit kan tijdelijke ECC-sleutelparen genereren 
die uitsluitend dienen voor de sleutelovereenstemming tij ­
dens de sessie met een tachograafkaart of externe GNSS- 
module, zoals gespecificeerd in punten 10.4 en 11.4 van 
dit aanhangsel.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 388  
CSM_77 De voertuigunit gebruikt de particuliere sleutel 
VU_Sign.SK van het sleutelpaar VU_Sign uitsluitend om 
gedownloade gegevensbestanden te ondertekenen, zoals 
gespecificeerd in hoofdstuk 14 van dit aanhangsel. De cor ­
responderende openbare sleutel VU_Sign.PK wordt uitslui ­
tend gebruikt ter verificatie van de door de voertuigunit 
aangemaakte handtekeningen.  
CSM_78 Zoals aangegeven in Figuur 1 onder 9.1.7, is het certificaat 
VU_MA 15 jaar en 3 maanden geldig. Het certificaat 
VU_Sign is eveneens 15 jaar en 3 maanden geldig.  
Opmerkingen:  
— Dankzij de verlengde geldigheidsduur van het certifi ­
caat VU_Sign kan de voertuigunit gedurende de eerste 
drie maanden na de vervaldatum van het certificaat 
geldige handtekeningen voor gedownloade gegevens 
aanmaken, zoals voorgeschreven in Verordening (EU) 
nr. 581/2010 van de Commissie.  
— De verlengde geldigheidsduur van het certificaat 
VU_MA is noodzakelijk om de VU in staat te stellen 
zich gedurende de eerste drie maanden na de verval ­
datum van het certificaat te authenticeren bij een con ­
trolekaart of bedrijfskaart en zodoende gegevens te 
downloaden.  
CSM_79 Nadat de geldigheidsduur van het desbetreffende certificaat 
is verstreken, staakt de voertuigunit het gebruik van de 
particuliere sleutel van het VU-sleutelpaar.  
CSM_80 De VU-sleutelparen (met uitzondering van tijdelijke sleu ­
telparen) en bijbehorende VU-certificaten worden niet ter 
plaatse vervangen of vernieuwd nadat de voertuigunit in 
gebruik is genomen.  
Opmerkingen:  
— De tijdelijke sleutelparen vallen niet onder dit voor ­
schrift aangezien de VU een nieuw tijdelijk sleutelpaar 
genereert bij elke chipauthenticatie en sleutelovereen ­
stemming tijdens de sessie (zie punt 10.4). Tijdelijke 
sleutelparen hebben geen corresponderende certificaten.  
— Dit voorschrift doet geen afbreuk aan de mogelijkheid 
om statische VU-sleutelparen te vervangen tijdens de 
ombouw of reparatie in een beveiligde omgeving onder 
het toezicht van de VU-fabrikant.  
CSM_81 Bij ingebruikname bevatten voertuigunits de volgende 
cryptografische sleutels en certificaten:  
— de particuliere sleutel VU_MA en bijbehorend certifi ­
caat;  
— de particuliere sleutel VU_Sign en bijbehorend certifi ­
caat;  
— het certificaat MSCA_VU-EGF met de openbare sleu ­
tel MSCA_VU-EGF.PK ter verificatie van het certifi ­
caat VU_MA en het certificaat VU_Sign;  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 389  
— het EUR-certificaat met de openbare sleutel EUR.PK 
ter verificatie van het certificaat MSCA_VU-EGF;  
— het EUR-certificaat waarvan de geldigheidsduur on ­
middellijk voorafgaat aan die van het EUR-certificaat 
ter verificatie van het certificaat MSCA_VU-EGF (in ­
dien bestaand);  
— het verbindingscertificaat tussen beide EUR-certificaten 
(indien bestaand).  
CSM_82 Naast de in CSM_81 genoemde cryptografische sleutels en 
certificaten beschikken voertuigunits ook over de in deel A 
van dit aanhangsel gespecificeerde sleutels en certificaten 
ten behoeve van de interactie met tachograafkaarten van de 
eerste generatie.  
9.1.5  Apparatuurniveau: tachograafkaarten  
▼M1 
CSM_83 Voor elke tachograafkaart wordt een uniek ECC-sleutel ­
paar gegenereerd, aangeduid als Card_MA. Daarnaast 
wordt voor elke bestuurders- en werkplaatskaart een 
tweede uniek ECC-sleutelpaar gegenereerd, aangeduid als 
Card_Sign. Deze taak kan worden uitgevoerd door kaart ­
fabrikanten of -personalisatoren. De partij die een sleutel ­
paar voor een kaart genereert, verzendt de openbare sleutel 
naar haar MSCA om het desbetreffende, door de MSCA 
ondertekende kaartcertificaat te verkrijgen. De particuliere 
sleutel wordt uitsluitend door de tachograafkaart gebruikt.  
▼B 
CSM_84 De certificaten Card_MA en Card_Sign van de bestuur ­
ders- of werkplaatskaart hebben dezelfde ingangsdatum.  
CSM_85 De kaartfabrikant of -personalisator kiest voor het kaart ­
sleutelpaar dezelfde cryptografische sterkte als die van het 
MSCA-sleutelpaar waarmee het corresponderende kaartcer ­
tificaat wordt ondertekend.  
CSM_86 De tachograafkaart gebruikt het sleutelpaar Card_MA, be ­
staande uit de particuliere sleutel Card_MA.SK en de 
openbare sleutel Card_MA.PK, uitsluitend met het oog 
op de wederzijdse authenticatie en sleutelovereenstemming 
tijdens de sessie met voertuigunits, zoals gespecificeerd in 
punten 10.3 en 10.4 van dit aanhangsel.  
CSM_87 De bestuurders- of werkplaatskaart gebruikt de particuliere 
sleutel Card_Sign.SK van het sleutelpaar Card_Sign uit ­
sluitend om gedownloade gegevensbestanden te onderteke ­
nen, zoals gespecificeerd in hoofdstuk 14 van dit aanhang ­
sel. De corresponderende openbare sleutel Card_Sign.PK 
wordt uitsluitend gebruikt ter verificatie van de door de 
kaart aangemaakte handtekeningen.  
▼M1 
CSM_88 Het certificaat Card_MA heeft de volgende geldigheids ­
duur:  
— voor bestuurderskaarten: 5 jaar;  
— voor bedrijfskaarten: 5 jaar;  
— voor controlekaarten: 2 jaar;  
— voor werkplaatskaarten: 1 jaar.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 390  
CSM_89 Het certificaat Card_Sign heeft de volgende geldigheids ­
duur: 
— voor bestuurderskaarten:  5 jaar en 1 maand;  
— voor werkplaatskaarten:  1 jaar en 1 maand.  
Opmerking:  dankzij de verlengde geldigheidsduur van het 
certificaat Card_Sign kan de bestuurderskaart gedurende de 
eerste maand na de vervaldatum van het certificaat geldige 
handtekeningen voor gedownloade gegevens aanmaken. 
Dit is noodzakelijk in het licht van Verordening (EU) nr. 
581/2010 van de Commissie, op grond waarvan de maxi ­
mumtermijn binnen dewelke gegevens van een bestuur ­
derskaart moeten worden gedownload, niet langer mag 
zijn dan 28 dagen nadat de laatste gegevens zijn geregis ­
treerd.  
CSM_90 De sleutelparen en bijbehorende certificaten van de tacho ­
graafkaart worden niet vervangen of vernieuwd na afgifte 
van de kaart.  
CSM_91 Bij afgifte bevatten de tachograafkaarten de volgende cryp ­
tografische sleutels en certificaten:  
— de particuliere sleutel Card_MA en bijbehorend certi ­
ficaat;  
— voor bestuurders- en werkplaatskaarten daarnaast ook 
de particuliere sleutel Card_Sign en bijbehorend certi ­
ficaat;  
— het certificaat MSCA_Card met de openbare sleutel 
MSCA_Card.PK ter verificatie van het certificaat 
Card_MA en het certificaat Card_Sign;  
— het EUR-certificaat met de openbare sleutel EUR.PK 
ter verificatie van het certificaat MSCA_Card;  
— het EUR-certificaat waarvan de geldigheidsduur on ­
middellijk voorafgaat aan die van het EUR-certificaat 
ter verificatie van het certificaat MSCA_Card (indien 
bestaand);  
— het verbindingscertificaat tussen beide EUR-certificaten 
(indien bestaand).  
▼M1 
— Bovendien uitsluitend voor controlekaarten, bedrijfs ­
kaarten en werkplaatskaarten, en alleen als deze kaar ­
ten zijn afgegeven tijdens de eerste drie maanden van 
de geldigheidsduur van een nieuw EUR-certificaat: het 
EUR-certificaat dat twee generaties ouder is, indien 
aanwezig.  
Opmerking bij het laatste streepje:  In de eerste drie maan ­
den van het ERCA(3)-certificaat (zie figuur 1) moeten de 
genoemde kaarten bijvoorbeeld het ERCA(1)-certificaat 
bevatten om te garanderen dat deze kaarten kunnen wor ­
den gebruikt om gegevens te downloaden van ERCA(1)- 
voertuigunits waarvan de normale levensduur van 15 jaar 
plus de periode van 3 maanden voor het downloaden van 
gegevens gedurende deze maanden verstrijkt; zie het laat ­
ste streepje van voorschrift 13 van bijlage IC.  
▼B 
CSM_92 Naast de in CSM_91 genoemde cryptografische sleutels en 
certificaten beschikken tachograafkaarten ook over de in 
deel A van dit aanhangsel gespecificeerde sleutels en cer ­
tificaten ten behoeve van de interactie met voertuigunits 
van de eerste generatie.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 391  
9.1.6  Apparatuurniveau: externe GNSS-modules  
▼M1 
CSM_93 Voor elke externe GNSS-module wordt een uniek ECC- 
sleutelpaar gegenereerd, aangeduid als EGF_MA. Deze 
taak wordt uitgevoerd door de fabrikanten van externe 
GNSS-modules. De partij die een EGF_MA-sleutelpaar 
voor een kaart genereert, verzendt de openbare sleutel 
naar haar MSCA om het desbetreffende, door de MSCA 
ondertekende EGF_MA-certificaat te verkrijgen. De parti ­
culiere sleutel wordt uitsluitend door de externe GNSS- 
module gebruikt.  
▼B 
CSM_94 De fabrikant van de externe GNSS-module kiest voor het 
sleutelpaar EGF_MA dezelfde cryptografische sterkte als 
die van het MSCA-sleutelpaar waarmee het corresponde ­
rende certificaat EGF_MA wordt ondertekend.  
▼M1 
CSM_95 De externe GNSS-module gebruikt het sleutelpaar 
EGF_MA, bestaande uit de particuliere sleutel 
EGF_MA.SK en de openbare sleutel EGF_MA.PK, uitslui ­
tend met het oog op de wederzijdse authenticatie en sleu ­
telovereenstemming tijdens de sessie met voertuigunits, 
zoals gespecificeerd in punt 11.4 van dit aanhangsel.  
▼B 
CSM_96 Het certificaat EGF_MA is 15 jaar geldig.  
CSM_97 Nadat de geldigheidsduur van het desbetreffende certificaat 
is verstreken, staakt de externe GNSS-module het gebruik 
van de particuliere sleutel van het sleutelpaar EGF_MA.  
Opmerking: zoals uiteengezet in punt 11.3.3, kan de ex ­
terne GNSS-module de particuliere sleutel gebruiken voor 
de wederzijdse authenticatie met de VU waaraan hij al 
gekoppeld is, zelfs wanneer de geldigheidsduur van het 
desbetreffende certificaat is verstreken.  
CSM_98 Het sleutelpaar EGF_MA en het bijbehorende EGF-certi ­
ficaat worden niet ter plaatse vervangen of vernieuwd na ­
dat de externe GNSS-module in gebruik is genomen.  
Opmerking: dit voorschrift doet geen afbreuk aan de mo ­
gelijkheid om EGF-sleutelparen te vervangen tijdens de 
ombouw of reparatie in een beveiligde omgeving onder 
het toezicht van de fabrikant van de externe GNSS-modu ­
le. 
CSM_99 Bij ingebruikname bevat de externe GNSS-module de vol ­
gende cryptografische sleutels en certificaten:  
— de particuliere sleutel EGF_MA en bijbehorend certifi ­
caat;  
— het certificaat MSCA_VU-EGF met de openbare sleu ­
tel MSCA_VU-EGF.PK ter verificatie van het certifi ­
caat EGF_MA;  
— het EUR-certificaat met de openbare sleutel EUR.PK 
ter verificatie van het certificaat MSCA_VU-EGF;  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 392  
— het EUR-certificaat waarvan de geldigheidsduur on ­
middellijk voorafgaat aan die van het EUR-certificaat 
ter verificatie van het certificaat MSCA_VU-EGF (in ­
dien bestaand);  
— het verbindingscertificaat tussen beide EUR-certificaten 
(indien bestaand).  
9.1.7  Overzicht: vervanging van het certificaat  
In Figuur 1 hieronder wordt een overzicht gegeven van de afgifte- en 
gebruikstermijnen voor de verschillende generaties ERCA-basiscertifica ­
ten, ERCA-verbindingscertificaten, MSCA-certificaten en apparatuurcer ­
tificaten (VU- en kaartcertificaten):  
▼M1 
Figuur 1  
Afgifte- en gebruikstermijnen voor de verschillende generaties ERCA-basiscertificaten, ERCA- 
verbindingscertificaten, MSCA-certificaten en apparatuurcertificaten
  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 393  
Toelichtingen bij Figuur 1:  
1. De verschillende generaties van het basiscertificaat worden aangeduid 
door een cijfer tussen haakjes. ERCA (1) bijvoorbeeld verwijst naar 
het ERCA-basiscertificaat van de eerste generatie; ERCA (2) verwijst 
naar het ERCA-basiscertificaat van de tweede generatie enz.  
2. Andere certificaten worden aangeduid door twee cijfers tussen haak ­
jes: het eerste cijfer geeft aan in het kader van welke generatie van het 
basiscertificaat het desbetreffende certificaat is afgegeven; het tweede 
cijfer verwijst naar de generatie van het certificaat zelf. MSCA_Card 
(1-1) verwijst bijvoorbeeld naar het eerste certificaat MSCA_Card dat 
is afgegeven in het kader van het basiscertificaat ERCA (1); 
MSCA_Card (2-1) verwijst naar het eerste certificaat MSCA_Card 
dat is afgegeven in het kader van het basiscertificaat ERCA (2); 
MSCA_Card (2-laatste) is het laatste certificaat MSCA_Card dat is 
afgegeven in het kader van het basiscertificaat ERCA (2); Card_MA 
(2-1) is het eerste kaartcertificaat dat met het oog op de wederzijdse 
authenticatie is afgegeven in het kader van het basiscertificaat ERCA 
(2) enz.  
3. De certificaten MSCA_Card (2-1) en MSCA_Card (1-laatste) zijn 
bijna, maar niet exact op dezelfde datum afgegeven. MSCA_Card 
(2-1) is het eerste certificaat MSCA_Card in het kader van het basis ­
certificaat ERCA (2) en wordt iets later afgegeven dan het certificaat 
MSCA_Card (1-laatste), zijnde het laatste certificaat MSCA_Card dat 
is afgegeven in het kader van het basiscertificaat ERCA (1).  
4. Uit de figuur blijkt dat de eerste VU- en kaartcertificaten die zijn 
afgegeven in het kader van het basiscertificaat ERCA (2), bijna 
twee jaar vroeger voorkomen dan de laatste VU- en kaartcertificaten 
die zijn afgegeven in het kader van het basiscertificaat ERCA (1). De 
reden hiervoor is dat de VU- en kaartcertificaten niet rechtstreeks in 
het kader van het ERCA-certificaat worden afgegeven, maar veeleer 
als onderdeel van een MSCA-certificaat. Het certificaat MSCA (2-1) 
wordt afgegeven direct nadat het basiscertificaat ERCA (2) geldig 
wordt, terwijl het certificaat MSCA (1-laatste) iets vroeger wordt 
afgegeven, net vóór de vervaldatum van het basiscertificaat ERCA 
(1). Bijgevolg hebben beide MSCA-certificaten vrijwel dezelfde gel ­
digheidsduur, ook al behoren ze tot een verschillende generatie.  
5. De aangegeven geldigheidsduur is van toepassing op bestuurderskaar ­
ten (5 jaar).  
▼M1 
6. Om ruimte te besparen, wordt het verschil in geldigheidsduur tussen 
de certificaten Card_MA en Card_Sign alleen voor de eerste generatie 
aangegeven.  
▼B 
9.2. Symmetrische sleutels  
9.2.1  Sleutels ter beveiliging van de communicatie tussen VU en bewegings ­
sensor  
9.2.1.1  Algemeen  
Opmerking: de lezer wordt bekend verondersteld met de inhoud van [ISO 
16844-3], waarin een beschrijving wordt gegeven van de interface tussen 
een voertuigunit en een bewegingssensor. De koppelingsprocedure tussen 
een VU en een bewegingssensor wordt nader toegelicht in hoofdstuk 12 
van dit aanhangsel.  
CSM_100 Zoals wordt verduidelijkt in Tabel 3, is een aantal symmetri ­
sche sleutels vereist, niet alleen om voertuigunits en be ­
wegingssensoren te koppelen en wederzijds te authenticeren, 
maar ook om de communicatie tussen voertuigunits en be ­
wegingssensoren te coderen. Het gaat daarbij altijd om AES- 
sleutels waarvan de lengte gelijk is aan die van de hoofd ­
sleutel van de bewegingssensor, welke gerelateerd is aan de 
lengte van het (geplande) Europese basissleutelpaar, zoals 
beschreven in CSM_50.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 394  
Tabel 3  
Sleutels ter beveiliging van de communicatie tussen voertuigunit en bewegingssensor  
Sleutel  Symbool  Afkomstig van  Methode van genereren  Opgeslagen door  
Hoofdsleutel bewegings- 
sensor — VU-gedeelte  K M-VU  ERCA  Aselect  ERCA, MSCA's die VU-certifi ­
caten afgeven, VU-fabrikanten, 
voertuigunits  
Hoofdsleutel bewegings- 
sensor — Werkplaats ­
gedeelte  K M-WC  ERCA  Aselect  ERCA, MSCA's, kaartfabrikan ­
ten, werkplaatskaarten  
Hoofdsleutel bewegings- 
sensor  K M Niet afzonderlijk 
gegenereerd  Berekend als K  M = K  M- 
VU XOR K  M-WC  ERCA, MSCA's die sleutels 
verstrekken voor bewegings ­
sensoren (facultatief) (*)  
Identificatie-sleutel  K  ID Niet afzonderlijk 
gegenereerd  Berekend als K  ID = K M 
XOR CV, waarbij CV 
(constante vector) is ge ­
specificeerd in 
CSM_106  ERCA, MSCA's die sleutels 
verstrekken voor bewegings ­
sensoren (facultatief) (*)  
Koppelings-sleutel  K  P Fabrikanten van 
bewegingssenso ­
ren Aselect  De betrokken bewegingssensor  
Sessiesleutel  K  S VU (tijdens kop ­
peling tussen VU 
en bewegingssen ­
sor) Aselect  De betrokken VU en be ­
wegingssensor  
(*) De sleutels K  M en K  ID worden facultatief opgeslagen aangezien ze kunnen worden afgeleid van K  M-VU  , K  M-WC  en CV.  
CSM_101 De Europese basiscertificeringsautoriteit (ERCA) genereert 
K M-VU  en K  M-WC  , twee aselecte en unieke AES-sleutels 
waarmee de hoofdsleutel van de bewegingssensor K  M kan 
worden berekend als K  M-VU  XOR K  M-WC  . De ERCA deelt 
de sleutels K  M , K  M-VU  en K  M-WC  mee aan de certificerings ­
autoriteiten van de lidstaten (MSCA's) die daarom verzoe ­
ken. 
CSM_102 De ERCA wijst aan elke hoofdsleutel van de bewegings ­
sensor K  M een uniek versienummer toe, dat ook geldt 
voor de samenstellende sleutels K  M-VU  en K  M-WC  en voor 
de bijbehorende identificatiesleutel K  ID . Op het ogenblik dat 
de ERCA de sleutels K  M-VU  en K  M-WC  naar de MSCA's 
verzendt, deelt zij ook het versienummer mee.  
Opmerking:  het versienummer dient om onderscheid te ma ­
ken tussen de verschillende generaties van deze sleutels, 
zoals uiteengezet in punt 9.2.1.2.  
CSM_103 De MSCA geeft de sleutel K  M-VU  , met het bijbehorende 
versienummer door aan de VU-fabrikanten die daarom ver ­
zoeken. De sleutel K  M-VU  wordt met het bijbehorende ver ­
sienummer in alle geproduceerde voertuigunits ingebracht 
door de VU-fabrikanten.  
CSM_104 De MSCA zorgt ervoor dat de sleutel K  M-WC  met het bij ­
behorende versienummer wordt ingebracht in elke werk ­
plaatskaart die onder haar verantwoordelijkheid wordt afge ­
geven.  
Opmerkingen:  
— Zie de beschrijving van het gegevenstype
  
in aanhangsel 2.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 395  
— Zoals uiteengezet in punt 9.2.1.2, kan het nodig zijn in 
een en dezelfde werkplaatskaart sleutels K  M-WC  van 
meerdere generaties in te brengen.  
CSM_105 Naast de in CSM_104 genoemde AES-sleutel zorgt de 
MSCA ervoor dat de TDES-sleutel Km  WC , zoals gespecifi ­
ceerd in voorschrift CSM_037 in deel A van dit aanhangsel, 
wordt ingebracht in elke werkplaatskaart die onder haar ver ­
antwoordelijkheid wordt afgegeven.  
Opmerkingen:  
— Op die manier kan een werkplaatskaart van de tweede 
generatie worden gebruikt om verbinding te maken met 
een VU van de eerste generatie.  
— Een werkplaatskaart van de tweede generatie bevat 
twee verschillende toepassingen: de eerste voldoet 
aan deel B van dit aanhangsel en de tweede aan deel 
A. Deze laatste toepassing bevat de TDES-sleutel 
Km  WC . 
CSM_106 De MSCA die sleutels voor bewegingssensoren verstrekt, 
leidt de identificatiesleutel af van de hoofdsleutel van de 
bewegingssensor door een exclusieve OF-bewerking 
(„XOR”) daarop uit te voeren met een constante vector 
(CV). De CV heeft de volgende waarde:  
▼M1 
— Voor 128-bits hoofdsleutels van de bewegingssensor: 
CV = ‘B6 44 2C 45 0E F8 D3 62 0B 7A 8A 97 91 
E4 5D 83’  
▼B 
— Voor 192-bits hoofdsleutels van de bewegingssensor: 
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’  
— Voor 256-bits hoofdsleutels van de bewegingssensor: 
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’  
Opmerking:  de constante vectoren werden als volgt gegene ­
reerd:  
Pi_10 = eerste 10 bytes van het decimale gedeelte van de 
wiskundige constante π = ‘24 3F 6A 88 85 A3 08 D3 13 
19’ 
CV_128-bits = eerste 16 bytes van SHA-256(Pi_10)  
CV_192-bits = eerste 24 bytes van SHA-384(Pi_10)  
CV_256-bits = eerste 32 bytes van SHA-512(Pi_10)  
CSM_107  ►M1 Elke fabrikant van bewegingssensoren genereert voor 
elke bewegingssensor een aselecte en unieke koppelingssleu ­
tel K  P , en verzendt elke koppelingssleutel naar zijn MSCA. 
De MSCA codeert elke koppelingssleutel afzonderlijk met 
de hoofdsleutel van de bewegingssensor K  M en zendt de 
gecodeerde sleutel terug naar de fabrikant van bewegings ­
sensoren. Voor elke gecodeerde sleutel deelt de MSCA het 
versienummer van de bijbehorende sleutel K  M mee aan de 
fabrikant van bewegingssensoren. ◄ 
Opmerking:  zoals uiteengezet in punt 9.2.1.2, kan het zijn 
dat de fabrikant van bewegingssensoren voor een en de ­
zelfde bewegingssensor meerdere unieke koppelingssleutels 
moet genereren.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 396  
CSM_108 Elke fabrikant van bewegingssensoren genereert een uniek 
serienummer voor elke bewegingssensor en verzendt alle 
serienummers naar zijn MSCA. De MSCA codeert elk serie ­
nummer afzonderlijk met de identificatiesleutel K  ID en zendt 
het gecodeerde serienummer terug naar de fabrikant van 
bewegingssensoren. Voor elk gecodeerd serienummer deelt 
de MSCA het versienummer van de bijbehorende sleutel 
K ID mee aan de fabrikant van bewegingssensoren.  
▼B 
CSM_109 Om te voldoen aan de voorschriften CSM_107 en 
CSM_108, gebruikt de MSCA het AES-algoritme in 
CBS(Cipher Block Chaining)-werkingsmodus, zoals vast ­
gelegd in [ISO 10116], met een interleave-parameter  m = 
1 en een initialisatievector IV = ‘00’ {16}, dat wil zeggen 
16 bytes met een binaire nul. Zo nodig past de MSCA de in 
[ISO 9797-1] vastgelegde paddingmethode 2 toe om de ge ­
gevens op te vullen.  
CSM_110 De fabrikant van bewegingssensoren slaat de gecodeerde 
koppelingssleutel en het gecodeerde serienummer op in de 
desbetreffende bewegingssensor, samen met de corresponde ­
rende ongecodeerde tekstwaarden en het versienummer van 
de voor de codering gebruikte sleutels K  M en K  ID . 
Opmerking:  zoals uiteengezet in punt 9.2.1.2, kan het zijn 
dat de fabrikant van bewegingssensoren in een en dezelfde 
bewegingssensor meerdere gecodeerde koppelingssleutels en 
serienummers moet inbrengen.  
CSM_111 Naast het op AES gebaseerde cryptografisch materiaal, zoals 
gespecificeerd in CSM_110, kan een fabrikant van be ­
wegingssensoren ook in elke bewegingssensor het op 
TDES gebaseerde cryptografisch materiaal opslaan dat nader 
wordt omschreven in voorschrift CSM_037 in deel A van 
dit aanhangsel.  
Opmerking:  deze werkwijze maakt het mogelijk een verbin ­
ding tot stand te brengen tussen een bewegingssensor van de 
tweede generatie en een VU van de eerste generatie.  
CSM_112 De lengte van de sessiesleutel K  S die door een VU wordt 
gegenereerd tijdens de koppeling met een bewegingssensor, 
is gerelateerd aan de lengte van de bijbehorende sleutel K  M- 
VU , zoals beschreven in CSM_50.  
9.2.1.2  Vervanging van de hoofdsleutel van de bewegingssensor in apparatuur 
van de tweede generatie  
CSM_113 Elke hoofdsleutel van de bewegingssensor is samen met alle 
bijbehorende sleutels (zie Tabel 3) gerelateerd aan het ER ­
CA-basissleutelpaar van een specifieke generatie. Bijgevolg 
worden deze sleutels om de 17 jaar vervangen. De geldig ­
heidsduur van elke generatie hoofdsleutels van bewegings ­
sensoren gaat in één jaar voordat het bijbehorende ERCA- 
basissleutelpaar van kracht wordt, en eindigt op het ogenblik 
dat dit ERCA-basissleutelpaar vervalt. Dit wordt verduide ­
lijkt in Figuur 2.  ▼M1
 02016R0799 — NL — 26.02.2020 — 002.001 — 397  
Figuur 2  
Afgifte en gebruik van verschillende generaties hoofdsleutels van bewegingssensoren in voertuigunits, 
bewegingssensoren en werkplaatskaarten
  
CSM_114 Ten minste één jaar voordat een nieuw Europees basissleu ­
telpaar wordt gegenereerd, zoals beschreven in CSM_56, 
genereert de ERCA een nieuwe hoofdsleutel van de be ­
wegingssensor K  M door nieuwe sleutels K  M-VU  en K  M-WC  
aan te maken. Overeenkomstig CSM_50 is de lengte van de 
hoofdsleutel van de bewegingssensor gerelateerd aan de ver ­
wachte cryptografische sterkte van het nieuwe Europese ba ­
sissleutelpaar. De ERCA deelt de nieuwe sleutels K  M , K  M- 
VU en K  M-WC  met het bijbehorende versienummer mee aan 
de MSCA's die daarom verzoeken.  
CSM_115 Zoals verduidelijkt in Figuur 2, zorgt de MSCA ervoor dat 
alle geldige generaties van de sleutels K  M-WC  samen met de 
bijbehorende versienummers worden opgeslagen in elke 
werkplaatskaart die onder haar verantwoordelijkheid wordt 
afgegeven.  
Opmerking: dit betekent dat in het laatste jaar van de gel ­
digheidsduur van een ERCA-certificaat werkplaatskaarten 
worden afgegeven met sleutels K  M-WC  van drie verschil ­
lende generaties, zoals verduidelijkt in Figuur 2.  
CSM_116 Voor de in CSM_107 en CSM_108 hierboven toegelichte 
procedure geldt het volgende: Elke koppelingssleutel K  P die 
de MSCA van een fabrikant van bewegingssensoren ont ­
vangt, wordt afzonderlijk gecodeerd voor elke geldige gene ­
ratie hoofdsleutel van de bewegingssensor K  M . Elk serie ­
nummer dat de MSCA van een fabrikant van bewegings ­
sensoren ontvangt, wordt eveneens afzonderlijk gecodeerd 
voor elke geldige generatie identificatiesleutel K  ID . De fa­
brikant van bewegingssensoren slaat alle gecodeerde kop ­
pelingssleutels en serienummers op in de desbetreffende be ­
wegingssensor, samen met de corresponderende ongeco ­
deerde tekstwaarden en het (de) versienummer(s) van de 
voor de codering gebruikte sleutels K  M en K  ID . ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 398  
Opmerking:  dit betekent dat in het laatste jaar van de gel ­
digheidsduur van een ERCA-certificaat bewegingssensoren 
worden afgegeven met gecodeerde gegevens die berusten op 
sleutels K  M van drie verschillende generaties, zoals verdui ­
delijkt in Figuur 2.  
CSM_117 Voor de in CSM_107 hierboven toegelichte procedure geldt 
het volgende: Aangezien de lengte van de koppelingssleutel 
K P gerelateerd is aan de lengte van de sleutel K  M (zie 
CSM_100), kan het zijn dat de fabrikant van bewegings ­
sensoren voor een en dezelfde bewegingssensor tot drie ver ­
schillende koppelingssleutels (van uiteenlopende lengte) 
moet genereren in het geval dat de sleutels K  M van opeen ­
volgende generaties een verschillende lengte hebben. In dit 
geval verzendt de fabrikant elke koppelingssleutel naar de 
MSCA. De MSCA zorgt ervoor dat elke koppelingssleutel 
wordt gecodeerd met de hoofdsleutel van de bewegingssen ­
sor van de juiste generatie, dat wil zeggen die welke de ­
zelfde lengte heeft.  
Opmerking:  indien de fabrikant van bewegingssensoren er ­
voor kiest een op TDES gebaseerde koppelingssleutel te 
gebruiken voor een bewegingssensor van de tweede genera ­
tie (zie CSM_111), meldt hij de MSCA dat deze koppelings ­
sleutel moet worden gecodeerd met de op TDES gebaseerde 
hoofdsleutel van de bewegingssensor. Een TDES-sleutel kan 
immers dezelfde lengte hebben als een AES-sleutel, zodat de 
MSCA niet alleen op de sleutellengte kan afgaan.  
CSM_118 VU-fabrikanten brengen in elke voertuigunit de sleutel K  M- 
VU van een enkele generatie in, samen met het bijbehorende 
versienummer. De sleutel K  M-VU  van deze generatie is ge ­
relateerd aan het ERCA-certificaat waarop de VU-certifica ­
ten gebaseerd zijn.  
Opmerkingen:  
— Een voertuigunit die berust op een ERCA-certificaat van 
generatie  X, bevat alleen de sleutel K  M-VU  van de gene ­
ratie X, zelfs indien deze wordt verstrekt nadat de gel ­
digheidsduur van het ERCA-certificaat van de generatie  
X + 1  is ingegaan. Dit wordt verduidelijkt in Figuur 2.  
— Een VU van generatie  X kan niet worden gekoppeld aan 
een bewegingssensor van generatie  X-1. 
— Aangezien werkplaatskaarten één jaar geldig zijn, heb ­
ben de voorschriften CSM_113 tot en met CSM_118 tot 
gevolg dat alle werkplaatskaarten de nieuwe sleutel K  M- 
WC bevatten op het ogenblik dat de eerste VU met de 
nieuwe sleutel K  M-VU  in gebruik wordt genomen. Bij ­
gevolg kan deze VU altijd de nieuwe sleutel K  M bere­
kenen. Bovendien bevatten de meeste nieuwe be ­
wegingssensoren tegen dan ook gecodeerde gegevens 
die gebaseerd zijn op de nieuwe sleutel K  M . 
9.2.2  Sleutels ter beveiliging van de DSRC-communicatie  
9.2.2.1  Algemeen  
CSM_119 De authenticiteit en vertrouwelijkheid van gegevens die via 
een DSRC-interface voor communicatie op afstand worden 
overgebracht van een voertuigunit naar een controleautori ­
teit, worden gewaarborgd door een reeks VU-specifieke 
AES-sleutels die zijn afgeleid van een enkele DSRC-hoofd ­
sleutel, KM  DSRC  . ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 399  
CSM_120 De DSRC-hoofdsleutel KM  DSRC  is een AES-sleutel die op 
beveiligde wijze wordt gegenereerd, opgeslagen en verspreid 
door de ERCA. De sleutellengte bedraagt 128, 192 of 256 
bits en is gerelateerd aan de lengte van het Europese basis ­
sleutelpaar, zoals beschreven in CSM_50.  
CSM_121 De ERCA geeft de DSRC-hoofdsleutel op beveiligde wijze 
door aan de MSCA's die daarom verzoeken, zodat zij VU- 
specifieke DSRC-sleutels daarvan kunnen afleiden, alsook 
om ervoor te zorgen dat de DSRC-hoofdsleutel wordt in ­
gebracht in alle controle- en werkplaatskaarten die onder 
hun verantwoordelijkheid worden afgegeven.  
CSM_122 De ERCA wijst aan elke DSRC-hoofdsleutel een uniek ver ­
sienummer toe. Op het ogenblik dat de ERCA de DSRC- 
hoofdsleutel verzendt naar de MSCA's, deelt zij ook het 
versienummer mee.  
Opmerking:  het versienummer dient om onderscheid te ma ­
ken tussen de verschillende generaties van de DSRC-hoofd ­
sleutel, zoals uiteengezet in punt 9.2.2.2.  
▼M1 
CSM_123 De VU-fabrikant genereert voor elke voertuigunit een uniek 
VU-serienummer en verzendt dit naar de MSCA met het 
verzoek twee VU-specifieke DSRC-sleutels te krijgen. Het 
VU-serienummer heeft het gegevenstype VuSerialNumber.  
Opmerking:  
— Dit VU-serienummer is identiek aan het element vuSe ­
rialNumber element van VuIdentification (zie aanhangsel 
1) en aan de referentie van de certificaathouder op de 
certificaten van de voertuigunit.  
— Het is mogelijk dat het VU-serienummer niet bekend is 
op het ogenblik dat een fabrikant van voertuigunits de 
VU-specifieke DSRC-sleutels aanvraagt. In dat geval 
verstuurt de VU-fabrikant in plaats daarvan de unieke 
identificator van de certificaataanvraag die hij heeft ge ­
bruikt voor het aanvragen van de certificaten van de VU; 
zie CSM_153. Deze identificator van de certificaataan ­
vraag moet bijgevolg gelijk zijn aan de referentie van de 
certificaathouder in de certificaten van de VU.  
▼B 
CSM_124 Bij ontvangst van een verzoek om VU-specifieke DSRC- 
sleutels, leidt de MSCA twee AES-sleutels voor de voertuig ­
unit af, K_VU  DSRC  _ENC en K_VU  DSRC  _MAC genoemd. 
Deze VU-specifieke sleutels hebben dezelfde lengte als de 
DSRC-hoofdsleutel. De MSCA gebruikt de in [RFC 5869] 
vastgelegde sleutelafleidingsfunctie (KDF). De hashfunctie 
die nodig is om de HMAC-hashfunctie te concretiseren, is 
gerelateerd aan de lengte van de DSRC-hoofdsleutel, zoals 
uiteengezet in CSM_50. De in [RFC 5869] vastgelegde sleu ­
telafleidingsfunctie (KDF) wordt als volgt gebruikt:  
Stap 1 (Extractie):  
— PRK  = HMAC-Hash ( salt, IKM ), waarbij  salt  een lege 
string ‘’ is en  IKM  gelijk is aan KM  DSRC  . ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 400  
Stap 2 (Expansie):  
— OKM  = T(1) , waarbij  
T(1) = HMAC-Hash ( PRK , T(0)  || info  || ‘01’) met  
— T(0)  = een lege string (‘’)  
— ►M1 info  = VU-serienummer of identificator van 
de certificaataanvraag, zoals gespecificeerd in 
CSM_123 ◄ 
— K_VU  DSRC  _ENC = eerste  L bytes van  OKM  en 
K_VU  DSRC  _MAC = laatste  L bytes van  OKM  
waarbij  L de vereiste lengte is van K_VU  DSRC  _ENC en 
K_VU  DSRC  _MAC in bytes.  
CSM_125 De MSCA geeft de sleutels K_VU  DSRC  _ENC en 
K_VU  DSRC  _MAC op beveiligde wijze door aan de VU-fa ­
brikant, zodat die ze kan inbrengen in de voertuigunit waar ­
voor ze bedoeld zijn.  
CSM_126 Bij afgifte zijn de sleutels K_VU  DSRC  _ENC en 
K_VU  DSRC  _MAC opgeslagen in het beveiligde geheugen 
van de voertuigunit ter waarborging van de integriteit, au ­
thenticiteit en vertrouwelijkheid van de gegevens die worden 
verzonden via de interface voor communicatie op afstand. 
De voertuigunit slaat ook het versienummer op van de 
DSRC-hoofdsleutel waarmee deze VU-specifieke sleutels 
worden afgeleid.  
CSM_127 Bij afgifte is de DSRC-hoofdsleutel KM  DSRC  opgeslagen in 
het beveiligde geheugen van de controle- en werkplaatskaar ­
ten ter verificatie van de integriteit en authenticiteit van de 
gegevens die de VU via de interface voor communicatie op 
afstand verzendt, alsook om deze gegevens te decoderen. 
Ook het versienummer van de DSRC-hoofdsleutel wordt 
in controle- en werkplaatskaarten opgeslagen.  
Opmerking:  zoals uiteengezet in punt 9.2.2.2, kan het nodig 
zijn in een en dezelfde controle- of werkplaatskaart een 
DSRC-hoofdsleutel KM  DSRC  van verschillende generaties 
in te brengen.  
▼M1 
CSM_128 De MSCA houdt registraties bij van alle door haar gegene ­
reerde VU-specifieke DSRC-sleutels, van het bijbehorende 
versienummer en van het VU-serienummer of de identifica ­
tor van de certificaataanvraag die voor het afleiden van deze 
sleutels werden gebruikt.  
▼B 
9.2.2.2  Vervanging van de DSRC-hoofdsleutel  
CSM_129 Elke DSRC-hoofdsleutel is verbonden aan het ERCA-basis ­
sleutelpaar van een specifieke generatie. Bijgevolg wordt de 
DSRC-hoofdsleutel om de 17 jaar vervangen door de ER ­
CA. De geldigheidsduur van de DSRC-hoofdsleutel van elke 
generatie gaat in twee jaar voordat het bijbehorende ERCA- 
basissleutelpaar van kracht wordt, en eindigt op het ogenblik 
dat dit ERCA-basissleutelpaar vervalt. Dit wordt verduide ­
lijkt in Figuur 3.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 401  
Figuur 3  
Afgifte en gebruik van de DSRC-hoofdsleutel van verschillende generaties in voertuigunits, controle- en 
werkplaatskaarten
  
CSM_130 Ten minste twee jaar voordat een nieuw Europees basissleu ­
telpaar wordt gegenereerd, zoals beschreven in CSM_56, 
genereert de ERCA een nieuwe DSRC-hoofdsleutel. Over ­
eenkomstig CSM_50 is de lengte van de DSRC-hoofdsleutel 
gerelateerd aan de verwachte cryptografische sterkte van het 
nieuwe Europese basissleutelpaar. De ERCA deelt de 
nieuwe DSRC-hoofdsleutel met het bijbehorende versienum ­
mer mee aan de MSCA's die daarom verzoeken.  
CSM_131 Zoals wordt verduidelijkt in Figuur 3, zorgt de MSCA er ­
voor dat alle geldige generaties van de sleutel KM  DSRC  
samen met de bijbehorende versienummers worden opgesla ­
gen in elke controlekaart die onder haar verantwoordelijk ­
heid wordt afgegeven.  
Opmerking: dit betekent dat in de laatste twee jaar van de 
geldigheidsduur van een ERCA-certificaat controlekaarten 
worden afgegeven met een sleutel KM  DSRC  van drie ver ­
schillende generaties, zoals aangegeven in Figuur 3.  
CSM_132 Zoals verduidelijkt in Figuur 3, zorgt de MSCA ervoor dat 
alle generaties van de sleutel KM  DSRC  die ten minste één 
jaar geldig zijn geweest en nog steeds geldig zijn, samen 
met de bijbehorende versienummers worden opgeslagen in 
elke werkplaatskaart die onder haar verantwoordelijkheid 
wordt afgegeven.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 402  
Opmerking:  dit betekent dat in het laatste jaar van de gel ­
digheidsduur van een ERCA-certificaat werkplaatskaarten 
worden afgegeven met een sleutel KM  DSRC  van drie ver ­
schillende generaties, zoals verduidelijkt in Figuur 3.  
CSM_133 VU-fabrikanten brengen in elke voertuigunit een enkele 
reeks VU-specifieke DSRC-sleutels in, samen met het bij ­
behorende versienummer. Deze sleutelreeks wordt afgeleid 
van de sleutel KM  DSRC  van de generatie van het ERCA- 
certificaat waarop de VU-certificaten gebaseerd zijn.  
Opmerkingen:  
— een voertuigunit die gebaseerd is op een ERCA-certifi ­
caat van generatie  X, bevat bijgevolg alleen de sleutels 
K_VU  DSRC  _ENC en K_VU  DSRC  _MAC van de generatie  
X, zelfs indien deze wordt verstrekt nadat de geldig ­
heidsduur van het ERCA-certificaat van de generatie  X 
+ 1 is ingegaan. Dit wordt verduidelijkt in Figuur 3.  
— Aangezien werkplaatskaarten één jaar en controlekaarten 
twee jaar geldig zijn, hebben de voorschriften CSM_131 
tot en met CSM_133 tot gevolg dat alle werkplaats- en 
controlekaarten de nieuwe DSRC-hoofdsleutel bevatten 
op het ogenblik dat de eerste VU met op die hoofdsleu ­
tel gebaseerde VU-specifieke sleutels in gebruik wordt 
genomen.  
9.3. Certificaten  
9.3.1  Algemeen  
CSM_134 Alle certificaten in het Europese slimme tachograafsysteem 
zijn zelfbeschrijvend en kaartverifieerbaar overeenkomstig 
[ISO 7816-4] en [ISO 7816-8].  
CSM_135  ►M1 De kenmerkende coderingsregels (DER) overeen ­
komstig [ISO 8825-1] worden toegepast om de gegevens ­
objecten in certificaten te coderen. Tabel 4 bevat de vol ­
ledige codering van het certificaat, met inbegrip van alle 
tags en lengtebytes. ◄ 
Opmerking:  door deze codering wordt de waarde van de 
labellengte (TLV) als volgt gestructureerd:  
Label: het label wordt ingevoerd in 1 of 2 bytes en geeft 
de inhoud aan.  
Lengte: de lengte wordt ingevoerd als niet-getekend geheel 
getal in 1, 2 of 3 bytes, wat een maximumlengte 
van 65 535 bytes geeft. Er worden zo weinig mo ­
gelijk bytes gebruikt.  
Waarde: de waarde wordt ingevoerd in nul of meer bytes.  
9.3.2  Inhoud van het certificaat  
CSM_136 Alle certificaten zijn opgebouwd volgens de in Tabel 4 aan ­
gegeven structuur van het certificaatprofiel.  
Tabel 4  
Certificaatprofiel versie 1  
Veld  Veld-ID  Label  Lengte (bytes)  ASN.1-gegevenstype 
(zie aanhangsel 1)  
ECC-certificaat  C  ‘7F 21’  var  
ECC-certificerings ­
instantie  B ‘7F 4E’  var  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 403  
Veld  Veld-ID  Label  Lengte (bytes)  ASN.1-gegevenstype 
(zie aanhangsel 1)  
Identificator van het 
certificaatprofiel  CPI ‘5F 29’  ‘01’
  
Referentie van de 
certificeringsautoriteit  CAR  ‘42’  ‘08’
  
Autorisatie van de 
certificaathouder  CHA  ‘5F 4C’  ‘07’
  
Openbare sleutel  PK  ‘7F 49’  var  
Domeinparameters  DP  ‘06’  var
  
Openbaar punt  PP  ‘86’  var
  
Referentie van de 
certificaathouder  CHR  ‘5F 20’  ‘08’
  
Ingangsdatum van het 
certificaat  CEfD  ‘5F 25’  ‘04’
  
Vervaldatum van het 
certificaat  CExD  ‘5F 24’  ‘04’
  
Handtekening van het 
ECC-certificaat  S ‘5F 37’  var
  
Opmerking:  verderop in dit aanhangsel wordt de veld-ID 
gebruikt om te verwijzen naar afzonderlijke velden van 
een certificaat; zo is X.CAR bijvoorbeeld de referentie van 
de certificeringsautoriteit (CAR) die vermeld staat in het 
certificaat van gebruiker X.  
9.3.2.1 Identificator van het certificaatprofiel (CPI)  
CSM_137 Deze identificator geeft aan welk certificaatprofiel wordt 
gebruikt. Versie 1, zoals gespecificeerd in Tabel 4, wordt 
geïdentificeerd door de waarde ‘00’.  
9.3.2.2 Referentie van de certificeringsautoriteit (CAR)  
CSM_138 Deze referentie bepaalt welke openbare sleutel wordt ge ­
bruikt ter verificatie van de handtekening van het certificaat. 
De referentie van de certificeringsautoriteit is bijgevolg ge ­
lijk aan de referentie van de certificaathouder in het certifi ­
caat van de betrokken certificeringsautoriteit.  
CSM_139 Het ERCA-basiscertificaat is zelfondertekend, wat betekent 
dat de referentie van de certificeringsautoriteit gelijk is aan 
de referentie van de certificaathouder in het certificaat.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 404  
CSM_140 Voor een ERCA-verbindingscertificaat is de referentie van 
de certificaathouder (CHR) gelijk aan die van het nieuwe 
ERCA-basiscertificaat. Voor een verbindingscertificaat is de 
referentie van de certificeringsautoriteit gelijk aan de CHR 
van het vorige ERCA-basiscertificaat.  
9.3.2.3 Autorisatie van de certificaathouder (CHA)  
▼M1 
CSM_141 De autorisatie van de certificaathouder (CHA) dient om het 
certificaattype te identificeren. De CHA bestaat uit de zes 
meest significante bytes van de toepassingsidentificator 
(AID) van de tachograaf, samengevoegd met het type ap ­
paratuur, dat aangeeft voor welk type van apparatuur het 
certificaat bedoeld is. In het geval van een certificaat van 
een voertuigunit, een bestuurderskaart of een werkplaats ­
kaart, wordt het type apparatuur ook gebruikt om een onder ­
scheid te maken tussen een certificaat voor wederzijdse au ­
thenticatie en een certificaat voor het opstellen van digitale 
handtekeningen (zie punt 9.1 en aanhangsel 1, gegevenstype 
EquipmentType).  
▼B 
9.3.2.4 Openbare sleutel (PK)  
De openbare sleutel bevat twee gegevenselementen: de gestandaardi ­
seerde domeinparameters (DP) die men moet gebruiken met de openbare 
sleutel van het certificaat, en de waarde van het openbare punt (PP).  
CSM_142 Het gegevenselement „DP” bevat een van de in Tabel 1 
gespecificeerde objectidentificatoren als verwijzing naar 
een reeks gestandaardiseerde domeinparameters.  
CSM_143 Het gegevenselement „PP” bevat het openbare punt. Zoals 
gespecificeerd in [TR-03111], worden openbare punten op 
elliptische krommen omgezet in bytereeksen (octet strings). 
Het niet-gecomprimeerde coderingsformaat wordt gebruikt. 
Om een punt van de elliptische kromme te herstellen uit het 
gecodeerde formaat, worden altijd de in [TR-03111] om ­
schreven validaties uitgevoerd.  
9.3.2.5 Referentie van de certificaathouder (CHR)  
CSM_144 Dit is een identificator van de openbare sleutel in het certi ­
ficaat. De CHR dient om in andere certificaten naar deze 
openbare sleutel te verwijzen.  
CSM_145 Voor certificaten van tachograafkaarten en externe 
GNSS-modules heeft de referentie van de certificaathou ­
der het in aanhangsel 1 gespecificeerde gegevenstype
  
. 
CSM_146 In het geval van een certificaataanvraag voor voertuigunits 
is het mogelijk dat de fabrikant het fabrikantspecifieke 
serienummer van de VU waarvoor dit certificaat en de 
bijbehorende particuliere sleutel bedoeld zijn, soms wel 
en soms niet kent. In het eerste geval heeft de referentie 
van de certificaathouder het in aanhangsel 1 gespecifi ­
ceerde gegevenstype
  . In het 
tweede geval heeft de referentie van de certificaathouder 
het in aanhangsel 1 gespecificeerde gegevenstype
  
. ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 405  
Opmerking:  voor een kaartcertificaat is de waarde van de 
CHR gelijk aan de waarde van het cardExtendedSerialNum ­
ber in EF_ICC; zie aanhangsel 2. voor een EGF-certificaat is 
de waarde van de CHR gelijk aan de waarde van het sen ­
sorGNSSSerialNumber in EF_ICC; zie aanhangsel 14. Voor 
een VU-certificaat is de waarde van de CHR gelijk aan het 
vuSerialNumber element van VuIdentification (zie aanhang ­
sel 1), tenzij de fabrikant het fabrikantspecifieke serienum ­
mer niet kent op het ogenblik dat het certificaat wordt aan ­
gevraagd.  
▼B 
CSM_147 Voor de ERCA- en MSCA-certificaten heeft de referentie 
van de certificaathouder het in aanhangsel 1 gespecificeerde 
gegevenstype
  .  
9.3.2.6 Ingangsdatum van het certificaat (CEfD)  
▼M1 
CSM_148 Dit veld bevat de begindatum en -tijd van de geldigheids ­
duur van het certificaat.  
▼B 
9.3.2.7 Vervaldatum van het certificaat (CExD)  
CSM_149 Dit veld bevat de einddatum en -tijd van de geldigheidsduur 
van het certificaat.  
9.3.2.8 Handtekening van het certificaat (S)  
CSM_150 De handtekening van het certificaat wordt in  overlay  ge­
plaatst op het inhoudelijk gecodeerde deel van het certifi ­
caat, en bevat het label en de lengte daarvan. Het onder ­
tekeningsalgoritme is ECDSA, zoals gespecificeerd in 
[DSS]. Daarbij wordt het hashalgoritme toegepast dat gere ­
lateerd is aan het sleutelgrootte van de ondertekeningsauto ­
riteit, zoals gespecificeerd in CSM_50. Het handtekeningfor ­
maat is ongecodeerd, zoals gespecificeerd in [TR-03111].  
9.3.3  Certificaataanvragen  
CSM_151  ►M1 Wanneer een MSCA een certificaat aanvraagt, stuurt 
zij de volgende gegevens naar de ERCA: ◄ 
— de identificator van het certificaatprofiel (CPI) voor het 
gewenste certificaat;  
— de referentie van de certificeringsautoriteit (CAR) waar ­
mee het certificaat naar verwachting wordt ondertekend;  
— de te ondertekenen openbare sleutel (PK).  
CSM_152 Naast de in CSM_151 vermelde gegevens stuurt de MSCA 
in een certificaataanvraag de volgende gegevens naar de 
ERCA zodat die de referentie van de certificaathouder van 
het nieuwe MSCA-certificaat kan aanmaken:  
— de numerieke nationale code van de certificeringsautori ­
teit (gegevenstype
  , zoals vastgelegd 
in aanhangsel 1);  
— de alfanumerieke nationale code van de certificerings ­
autoriteit (gegevenstype
  , zoals vast ­
gelegd in aanhangsel 1);  
— het serienummer van 1 byte om de verschillende sleutels 
van de certificeringsautoriteit te onderscheiden in het 
geval dat sleutels worden gewijzigd;  
— het veld van 2 bytes met aanvullende codering (specifiek 
voor de certificeringsautoriteit).  ▼M1
 02016R0799 — NL — 26.02.2020 — 002.001 — 406  
CSM_153 De apparatuurfabrikant verstuurt in een certificaataanvraag 
de volgende gegevens naar de MSCA zodat die de referentie 
van de certificaathouder van het nieuwe apparatuurcertificaat 
kan aanmaken:  
— voor zover bekend (zie CSM_154), een fabrikantspeci ­
fiek serienummer voor de apparatuur, het model van de 
apparatuur en de maand van fabricage; zo niet, een 
unieke identificator van de certificaataanvraag;  
— de maand en het jaar van fabricage of van de certificaat ­
aanvraag.  
De fabrikant zorgt ervoor dat deze gegevens juist zijn en dat het door de 
MSCA teruggezonden certificaat wordt ingebracht in de apparatuur waar ­
voor dit bedoeld is.  
▼B 
CSM_154 In het geval van een certificaataanvraag voor een VU is het 
mogelijk dat de fabrikant het fabrikantspecifieke serienum ­
mer van de VU waarvoor dit certificaat en de bijbehorende 
particuliere sleutel bedoeld zijn, soms wel en soms niet kent. 
In het eerste geval verzendt de VU-fabrikant het serienum ­
mer naar de MSCA. In het tweede geval moet de fabrikant 
elke certificaataanvraag eenduidig identificeren en het serie ­
nummer daarvan verzenden naar de MSCA. Het resulterende 
certificaat bevat dan het serienummer van de certificaataan ­
vraag. Na het inbrengen van het certificaat in een specifieke 
VU brengt de fabrikant de MSCA op de hoogte van de link 
tussen het serienummer van de certificaataanvraag en de 
VU-identificatie.  
10. WEDERZIJDSE AUTHENTICATIE TUSSEN VU EN KAART, EN 
BEVEILIGDE BERICHTENUITWISSELING  
10.1.  Algemeen  
CSM_155 De beveiligde communicatie op hoog niveau tussen een 
voertuigunit en tachograaf verloopt in de volgende stappen:  
— Stap 1: elke partij bewijst aan de andere partij in het 
bezit te zijn van een geldig openbare-sleutelcertificaat 
dat is ondertekend door de certificeringsautoriteit van 
de lidstaat (MSCA). Het openbare-sleutelcertificaat van 
de MSCA moet op zijn beurt zijn ondertekend door de 
Europese basiscertificeringsautoriteit (ERCA). Deze stap 
wordt verificatie van de certificaatketen genoemd en 
wordt uitvoerig toegelicht in punt 10.2.  
— Stap 2: de voertuigunit (VU) bewijst aan de kaart in het 
bezit te zijn van de particuliere sleutel die overeenstemt 
met de openbare sleutel in het aangeboden certificaat. 
Het bewijs wordt geleverd door ondertekening met een 
willekeurig, door de kaart verzonden nummer. De kaart 
moet dit nummer bij de verificatie van de handtekening 
terugvinden. Bij een succesvolle verificatie wordt de VU 
geauthenticeerd. Deze stap wordt VU-authenticatie ge ­
noemd en wordt uitvoerig toegelicht in punt 10.3.  ▼M1
 02016R0799 — NL — 26.02.2020 — 002.001 — 407  
— Stap 3: beide partijen berekenen zelfstandig twee AES- 
sessiesleutels met behulp van een asymmetrisch algo ­
ritme voor sleutelovereenstemming. Met een van beide 
sessiesleutels maakt de kaart een berichtauthenticatie ­
code (MAC) aan voor sommige door de VU verzonden 
gegevens. De VU verifieert de MAC. Bij een succes ­
volle verificatie wordt de kaart geauthenticeerd. Deze 
stap wordt kaartauthenticatie genoemd en wordt uitvoe ­
rig toegelicht in punt 10.4.  
— Stap 4: de VU en de kaart gebruiken de overeengeko ­
men sessiesleutels om de vertrouwelijkheid, integriteit en 
authenticiteit van alle uitgewisselde berichten te waar ­
borgen. Deze stap wordt beveiligde berichtenuitwisseling 
(SM) genoemd en wordt uitvoerig toegelicht in punt 
10.5.  
CSM_156 Het in CSM_155 beschreven mechanisme wordt door de 
VU gestart bij kaartinbrenging in een van de lezers.  
10.2.  Wederzijdse verificatie van de certificaatketen  
10.2.1  Verificatie van de certificaatketen op kaartniveau door de VU  
CSM_157  ►M1 Voertuigunits verifiëren de certificaatketen van een 
tachograafkaart volgens het stroomschema in Figuur 4. 
Voor elk certificaat dat de VU van de kaart leest, gaat hij 
na of het veld Certificate Holder Authorisation (CHA) cor ­
rect is:  
— In het veld CHA van het kaartcertificaat moet een kaart ­
certificaat voor wederzijdse authenticatie zijn vermeld 
(zie aanhangsel 1, gegevenstype EquipmentType).  
— In de CHA van het certificaat Card.CA moet een MSCA 
vermeld zijn.  
— In de CHA van het certificaat Card.Link moet een 
ERCA vermeld zijn. ◄ 
Toelichtingen bij Figuur 4:  
— De kaartcertificaten en openbare sleutels in deze figuur 
dienen voor de wederzijdse authenticatie. In punt 9.1.5 
worden deze aangeduid als Card_MA.  
— De openbare sleutels en certificaten Card.CA in deze 
figuur dienen om kaartcertificaten te ondertekenen en 
worden aangegeven in de CAR van het kaartcertificaat. 
In punt 9.1.3 worden deze aangeduid als MSCA_Card.  
— Het certificaat Card.CA.EUR in deze figuur is het Euro ­
pese basiscertificaat dat vermeld staat in de referentie 
van de certificeringsautoriteit (CAR) van het certificaat 
Card.CA.  
— Het certificaat Card.Link in deze figuur is het verbin ­
dingscertificaat van de kaart (indien aanwezig). Zoals 
verduidelijkt in punt 9.1.2, is dit een verbindingscertifi ­
caat voor een nieuw Europees basissleutelpaar dat door 
de ERCA is aangemaakt en dat met de vorige Europese 
particuliere sleutel is ondertekend.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 408  
— Het certificaat Card.Link.EUR is het Europese basiscer ­
tificaat dat vermeld staat in de referentie van de certifi ­
ceringsautoriteit (CAR) van het certificaat Card.Link.  
CSM_158 Zoals blijkt uit Figuur 4, begint de verificatie van 
de certificaatketen op kaartniveau bij kaartinbrenging. 
De VU leest de referentie van de kaarthouder 
(
 ) in het hoofdbestand 
van de chipkaart (EF ICC). De VU controleert of de kaart 
bekend is, met andere woorden of de certificaatketen van de 
kaart in het verleden met succes is geverifieerd en voor 
toekomstig gebruik werd opgeslagen. Indien dat het geval 
is en het kaartcertificaat nog geldig is, wordt de procedure 
voortgezet met de verificatie van de certificaatketen op VU- 
niveau. Zo niet, leest de VU achtereenvolgens op de kaart 
het certificaat MSCA_Card ter verificatie van het kaartcerti ­
ficaat, het Card.CA.EUR-certificaat ter verificatie van het 
certificaat MSCA_Card, en in voorkomend geval het ver ­
bindingscertificaat, totdat een bekend of verifieerbaar certi ­
ficaat wordt gevonden. Indien een bekend certificaat wordt 
gevonden, gebruikt de VU dit ter verificatie van de onder ­
liggende kaartcertificaten die op de kaart werden gelezen. 
Bij een succesvolle verificatie wordt de procedure voortgezet 
met de verificatie van de certificaatketen op VU-niveau. Zo 
niet, wordt de kaart genegeerd door de VU.  
Opmerking:  de VU kan het certificaat Card.CA.EUR op drie 
manieren kennen:  
— het certificaat Card.CA.EUR is hetzelfde certificaat als 
het EUR-certificaat van de VU zelf;  
— het certificaat Card.CA.EUR gaat het EUR-certificaat 
van de VU zelf vooraf en is bij afgifte al in de VU 
opgeslagen (zie CSM_81);  
— het certificaat Card.CA.EUR volgt op het EUR-certifi ­
caat van de VU zelf en de VU heeft in het verleden een 
verbindingscertificaat van een andere tachograafkaart 
ontvangen, geverifieerd en voor toekomstig gebruik op ­
geslagen.  
CSM_159 Zoals aangegeven in Figuur 4, kan de VU na verificatie van 
de authenticiteit en geldigheid van een tot dan toe niet be ­
kend certificaat, dit certificaat voor toekomstig gebruik op ­
slaan. Op die manier hoeft de VU de authenticiteit van dit 
certificaat niet opnieuw te verifiëren wanneer het nogmaals 
wordt aangeboden. Zoals gespecificeerd in punt 9.3.2, kan 
de VU in plaats van het volledige certificaat alleen het in ­
houdelijk deel van het certificaat opslaan.  ►M1 Een nieuw 
verbindingscertificaat dat door een kaart wordt gepresen ­
teerd, moet verplicht in de VU worden opgeslagen; de op ­
slag van alle andere types certificaten is facultatief. ◄ 
CSM_160 De VU verifieert de temporele geldigheid van elk certificaat 
dat op de kaart wordt gelezen of dat in het VU-geheugen is 
opgeslagen. Vervallen certificaten worden verworpen. Om 
de temporele geldigheid van een door de kaart aangeboden 
certificaat te verifiëren, gebruikt de VU zijn interne klok.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 409  
Figuur 4  
Stroomschema ter verificatie van de certificaatketen op kaartniveau door de VU
  
10.2.2  Verificatie van de certificaatketen op VU-niveau door de kaart  
CSM_161  ►M1 Tachograafkaarten verifiëren de certificaatketen van 
een voertuigunit (VU) volgens het stroomschema in Figuur 
5. Voor elk certificaat dat door de VU wordt gepresenteerd, 
gaat de kaart na of het veld Certificate Holder Authorisation 
(CHA) correct is:  
— In de CHA van het certificaat VU.Link moet een ERCA 
vermeld zijn.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 410  
— In de CHA van het certificaat VU.CA moet een MSCA 
vermeld zijn.  
— In het veld CHA van het VU-certificaat moet een VU- 
certificaat voor wederzijdse authenticatie zijn vermeld 
(zie aanhangsel 1, gegevenstype EquipmentType). ◄ 
Figuur 5  
Stroomschema ter verificatie van de certificaatketen op VU-niveau door de kaart
  
Toelichtingen bij Figuur 5:  
— De VU-certificaten en openbare sleutels in deze figuur dienen voor 
de wederzijdse authenticatie. In punt 9.1.4 worden deze aangeduid als 
VU_MA.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 411  
— De openbare sleutels en certificaten VU.CA in deze figuur dienen om 
certificaten van voertuigunits en externe GNSS-modules te onderteke ­
nen. In punt 9.1.3 worden deze aangeduid als MSCA_VU-EGF.  
— Het certificaat VU.CA.EUR in deze figuur is het Europese basiscer ­
tificaat dat vermeld staat in de referentie van de certificeringsautoriteit 
(CAR) van het certificaat VU.CA.  
— Het certificaat VU.Link in deze figuur is het verbindingscertificaat 
van de VU (indien aanwezig). Zoals verduidelijkt in punt 9.1.2, is dit 
een verbindingscertificaat voor een nieuw Europees basissleutelpaar 
dat door de ERCA is aangemaakt en dat met de vorige Europese 
particuliere sleutel is ondertekend.  
— Het certificaat VU.Link.EUR is het Europese basiscertificaat dat ver ­
meld staat in de referentie van de certificeringsautoriteit (CAR) van 
het certificaat VU.Link.  
CSM_162 Zoals blijkt uit Figuur 5, begint de verificatie van de certi ­
ficaatketen van de VU op het ogenblik dat de VU probeert 
zijn eigen openbare sleutel in te stellen voor gebruik in de 
tachograafkaart. Als de VU daarin slaagt, betekent dit dat de 
kaart de certificaatketen van de VU in het verleden met 
succes heeft geverifieerd en het VU-certificaat voor toekom ­
stig gebruik heeft opgeslagen. In dit geval wordt het VU- 
certificaat voor gebruik ingesteld en wordt de procedure 
voortgezet met de VU-authenticatie. Indien de kaart het 
VU-certificaat niet kent, biedt de VU achtereenvolgens het 
certificaat VU.CA aan ter verificatie van het VU-certificaat, 
het EUR-certificaat ter verificatie van het certificaat VU.CA, 
en in voorkomend geval het verbindingscertificaat ter veri ­
ficatie van het EUR-certificaat, om een door de kaart ge ­
kend certificaat te vinden. Indien een dergelijk certificaat 
wordt gevonden, gebruikt de kaart dit ter verificatie van 
de onderliggende VU-certificaten die werden aangeboden. 
Bij een succesvolle verificatie stelt de VU de openbare 
sleutel in voor gebruik in de tachograafkaart. Zo niet, wordt 
de kaart genegeerd door de VU.  
Opmerking: de kaart kan het certificaat VU.CA.EUR op 
drie manieren kennen:  
— het certificaat VU.CA.EUR is hetzelfde certificaat als 
het EUR-certificaat van de kaart zelf;  
— het certificaat VU.CA.EUR gaat het EUR-certificaat van 
de kaart zelf vooraf en is bij afgifte al in de kaart opge ­
slagen (zie CSM_91);  
— het certificaat VU.CA.EUR volgt op het EUR-certificaat 
van de kaart zelf en de kaart heeft in het verleden een 
verbindingscertificaat van een andere voertuigunit ont ­
vangen, geverifieerd en voor toekomstig gebruik opge ­
slagen.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 412  
CSM_163 De VU gebruikt het MSE: Set AT-commando om de open ­
bare sleutel in te stellen voor gebruik in de tachograafkaart. 
Zoals gespecificeerd in aanhangsel 2, geeft dit commando 
aan welk cryptografisch mechanisme met de ingestelde sleu ­
tel wordt gebruikt. Dit mechanisme is, zoals gespecificeerd 
in CSM_50, de VU-authenticatie met behulp van het 
ECDSA-algoritme, in combinatie met het hashalgoritme 
dat gerelateerd is aan de grootte van het sleutelpaar 
VU_MA van de VU.  
CSM_164 Het MSE: Set AT-commando geeft ook aan welk tijdelijk 
sleutelpaar de VU gebruikt voor de sleutelovereenstemming 
tijdens de sessie (zie punt 10.4). Bijgevolg genereert de VU 
een tijdelijk ECC-sleutelpaar alvorens het MSE:Set AT- 
commando te verzenden. Om het tijdelijke sleutelpaar te 
genereren, gebruikt de VU de gestandaardiseerde domein ­
parameters die in het kaartcertificaat vermeld staan. Het 
tijdelijke sleutelpaar wordt aangeduid als (VU.SK  eph , 
VU.PK  eph , Card.DP). De VU neemt de x-coördinaat van 
het met het ECDH-algoritme bepaalde tijdelijke openbare 
punt als sleutelidentificatie. Dit is de gecomprimeerde voor ­
stelling van de openbare sleutel, aangeduid als 
Comp(VU.PK  eph ). 
▼M1 
CSM_165 In het MSE:Set AT-commando succesvol is, stelt de kaart 
de opgegeven sleutel VU.PK in voor later gebruik bij VU- 
authenticatie, en wordt de sleutel Comp(VU.PKeph) tijdelijk 
opgeslagen. Indien twee of meer MSE:Set AT-commando’s 
met succes worden verzonden vóór de sleutelovereenstem ­
ming tijdens de sessie, slaat de kaart alleen de laatste ont ­
vangen sleutel Comp(VU.PKeph) op. De kaart zal 
Comp(VU.PKeph) resetten na een succesvol commando 
GENERAL AUTHENTICATE.  
▼B 
CSM_166 De kaart verifieert de temporele geldigheid van elk certifi ­
caat dat door de VU wordt aangeboden of waarnaar de VU 
verwijst in het kaartgeheugen. Vervallen certificaten worden 
verworpen.  
CSM_167 Om de temporele geldigheid van een door de VU aange ­
boden certificaat te verifiëren, slaat elke tachograafkaart be ­
paalde gegevens met betrekking tot de huidige tijd (hierna 
„lopende tijd”) intern op. Deze gegevens kunnen niet recht ­
streeks door een VU worden geactualiseerd. Bij afgifte 
wordt de lopende tijd van de kaart ingesteld op de ingangs ­
datum van het certificaat Card_MA van de kaart. De kaart 
actualiseert de lopende tijd indien de ingangsdatum van een 
authentiek certificaat dat door de VU als „geldige tijdbron” 
wordt aangeboden, recenter is dan de tijdaanduiding van de 
kaart. In dit geval stelt de kaart de lopende tijd in op basis 
van de ingangsdatum van dat certificaat. De kaart accepteert 
uitsluitend de volgende certificaten als geldige tijdbron:  
— ERCA-verbindingscertificaten van de tweede generatie;  
— MSCA-certificaten van de tweede generatie;  
— VU-certificaten van de tweede generatie die zijn afge ­
geven door dezelfde lidstaat als het (de) kaartcertifi ­
ca(a)t(en) zelf.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 413  
Opmerking:  het laatste voorschrift houdt in dat de referentie 
van de certificeringsautoriteit (CAR) van het VU-certificaat, 
dat wil zeggen het certificaat MSCA_VU-EGF, herkenbaar 
is voor de kaart. Deze referentie verschilt van de CAR van 
het kaartcertificaat zelf, namelijk het certificaat 
MSCA_Card.  
CSM_168 Zoals aangegeven in Figuur 5, kan de kaart na verificatie 
van de authenticiteit en geldigheid van een tot dan toe niet 
bekend certificaat, dit certificaat voor toekomstig gebruik 
opslaan. Op die manier hoeft de kaart de authenticiteit 
van dit certificaat niet opnieuw te verifiëren wanneer het 
nogmaals wordt aangeboden. Zoals uiteengezet in punt 
9.3.2, kan de kaart in plaats van het volledige certificaat 
alleen het inhoudelijk deel van het certificaat opslaan.  
10.3.  VU-authenticatie  
CSM_169 Voertuigunits en kaarten gaan te werk volgens het stroom ­
schema in Figuur 6 om de VU te authenticeren bij de kaart. 
Door de VU te authenticeren, kan de tachograafkaart zeker 
stellen dat de VU authentiek is. Daartoe gebruikt de VU 
zijn particuliere sleutel om een door de kaart afgegeven 
identiteit („challenge”) te ondertekenen.  
CSM_170  ►M1 Naast de door de kaart afgegeven identiteit vermeldt 
de VU in de handtekening de in het kaartcertificaat ver ­
melde referentie van de certificaathouder. ◄ 
Opmerking:  hiermee wordt gewaarborgd dat de kaart waar ­
bij de VU zich authenticeert dezelfde kaart is waarvan de 
certificaatketen eerder door de VU werd geverifieerd.  
CSM_171 De VU vermeldt in de handtekening ook de identificator 
van de tijdelijke openbare sleutel Comp(VU.PK  eph ), waar­
mee de VU de beveiligde berichtenuitwisseling (SM) tot 
stand brengt tijdens de in punt 10.4 uiteengezette procedure 
voor chipauthenticatie.  
Opmerking:  hiermee wordt gewaarborgd dat de VU waar ­
mee de kaart tijdens een SM-sessie communiceert dezelfde 
VU is die eerder door de kaart werd geauthenticeerd.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 414  
Figuur 6  
Stroomschema van de VU-authenticatie
  
▼B 
CSM_172 Indien de VU tijdens de VU-authenticatie meerdere GET 
CHALLENGE-commando's verzendt, zendt de kaart telkens 
een nieuwe aselecte identiteit („challenge”) van 8 bytes te ­
rug, terwijl alleen de laatste identiteit wordt opgeslagen.  
CSM_173 Voor de VU-authenticatie gebruikt de VU het onderteke ­
ningsalgoritme ECDSA, zoals gespecificeerd in [DSS]. 
Daarbij wordt het hashalgoritme toegepast dat gerelateerd 
is aan het grootte van het sleutelpaar VU_MA van de 
VU, zoals gespecificeerd in CSM_50. Het handtekeningfor ­
maat is ongecodeerd, zoals gespecificeerd in [TR-03111]. 
De VU verzendt de resulterende handtekening naar de kaart.  
▼M1 
CSM_174 Op het ogenblik dat de kaart de handtekening van de VU 
ontvangt in een EXTERNAL AUTHENTICATE-comman ­
do: 
— berekent de kaart het authenticatietoken door samenvoe ­
ging van Card.CHR, de door de kaart afgegeven iden ­
titeit rcard en de identificator van de tijdelijke openbare 
sleutel van de VU Comp(VU.PKeph);  
— verifieert de kaart de handtekening van de VU met be ­
hulp van het ECDSA-algoritme, met behulp van het 
hashalgoritme dat gerelateerd is aan de grootte van het 
sleutelpaar VU_MA van de VU, zoals gespecificeerd in 
CSM_50, in combinatie met de sleutel VU.PK en het 
berekende authenticatietoken.  ▼M1
 02016R0799 — NL — 26.02.2020 — 002.001 — 415  
10.4.  Chipauthenticatie en sleutelovereenstemming tijdens de sessie  
CSM_175 Voertuigunits en kaarten gaan te werk volgens het stroom ­
schema in  Figuur 7  om de kaart te authenticeren bij de VU. 
Door de chipkaart te authenticeren, kan de voertuigunit ze ­
ker stellen dat de kaart authentiek is.  
Figuur 7  
Chipauthenticatie en sleutelovereenstemming tijdens de sessie
  
CSM_176 De voertuigunit (VU) en de kaart voeren de volgende stap ­
pen uit:  
1. De VU start de procedure voor chipauthenticatie door het 
MSE: Set AT-commando te verzenden ter aankondiging 
van de ‘chipauthenticatie met behulp van het ECDH-al ­
goritme, met als resultaat een AES-sessiesleutel waarvan 
de lengte gerelateerd is aan de grootte van het sleutelpaar 
Card_MA van de kaart, zoals gespecificeerd in 
CSM_50’. De VU bepaalt op basis van het kaartcertifi ­
caat de grootte van het sleutelpaar van de kaart.  
▼M1 
2. De VU verzendt het openbare punt VU.PK  eph van zijn 
tijdelijke sleutelpaar naar de kaart. Zoals gespecificeerd 
in [TR-03111], wordt het openbare punt omgezet in een 
bytereeks (octet string). Het niet-gecomprimeerde code ­
ringsformaat wordt gebruikt. Zoals uiteengezet in 
CSM_164, heeft de VU dit tijdelijke sleutelpaar gegene ­
reerd alvorens de certificaatketen op VU-niveau te veri ­
fiëren. De VU verzendt de identificator van de tijdelijke 
openbare sleutel Comp(VU.PK  eph ) naar de kaart, en de 
kaart slaat deze op.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 416  
3. De kaart berekent Comp(VU.PK  eph ) op basis van 
VU.PK  eph en vergelijkt het resultaat met de opgeslagen 
waarde van Comp(VU.PK  eph ). 
4. Met behulp van het ECDH-algoritme, gecombineerd met 
de statische particuliere sleutel van de kaart en de tijde ­
lijke openbare sleutel van de VU, berekent de kaart een 
geheime sleutel K.  
5. De kaart kiest een  nonce  (willekeurig getal) van 8 bytes 
N PICC om twee AES-sessiesleutels K  MAC en K  ENC af te 
leiden van de geheime sleutel K (zie CSM_179).  
▼M1 
6. Met behulp van K  MAC berekent de kaart een authentica ­
tietoken voor de identificator van de tijdelijke openbare 
punt van de VU: T  PICC = CMAC(K  MAC , VU.PK  eph ). Het 
openbare punt is in het formaat dat door de VU wordt 
gebruikt (zie tweede streepje hierboven). De kaart ver ­
zendt N  PICC en T  PICC naar de voertuigunit.  
▼B 
7. Met behulp van het ECDH-algoritme, gecombineerd met 
de statische openbare sleutel van de kaart en de tijdelijke 
particuliere sleutel van de VU, berekent de VU dezelfde 
geheime sleutel K als de kaart al eerder heeft gedaan in 
stap 4.  
8. De VU leidt de sessiesleutels K  MAC en K  ENC af van K 
en N  PICC (zie CSM_179).  
9. De VU verifieert het authenticatietoken T  PICC . 
CSM_177 In stap 3 hierboven berekent de kaart Comp(VU.PKeph) als 
x-coördinaat van het openbare punt in VU.PKeph.  
CSM_178 In stappen 4 en 7 hierboven passen de kaart en de voertuig ­
unit het ECKA-EG-algoritme toe, zoals vastgelegd in [TR- 
03111].  
CSM_179 In stappen 5 en 8 hierboven passen de kaart en de voertuig ­
unit de sleutelafleidingsfunctie (KDF) voor de in [TR- 
03111] vastgelegde AES-sessiesleutels toe, met de volgende 
preciseringen en aanpassingen:  
— De teller heeft de waarde ‘00 00 00 01’ voor K  ENC en 
‘00 00 00 02’ voor K  MAC . 
— De facultatieve nonce  r wordt gebruikt en is gelijk aan 
N PICC . 
— Om de 128-bits AES-sleutels af te leiden, wordt het 
hashalgoritme SHA-256 gebruikt.  
— Om de 192-bits AES-sleutels af te leiden, wordt het 
hashalgoritme SHA-384 gebruikt.  
— Om de 256-bits AES-sleutels af te leiden, wordt het 
hashalgoritme SHA-512 gebruikt.  
De lengte van de sessiesleutels (dat wil zeggen de lengte 
vanaf welke de hashwaarde wordt afgekapt) is gerelateerd 
aan de grootte van het sleutelpaar Card_MA, zoals gespe ­
cificeerd in CSM_50.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 417  
CSM_180 In stappen 6 en 9 hierboven passen de kaart en de voertuig ­
unit het AES-algoritme toe in CMAC( Cipher-based Mes ­
sage Authentication Code )-modus, zoals gespecificeerd in 
[SP 800-38B]. De lengte van T  PICC is gerelateerd aan de 
lengte van de AES-sessiesleutels, zoals gespecificeerd in 
CSM_50.  
10.5.  Beveiligde berichtenuitwisseling  
10.5.1  Algemeen  
CSM_181 Nadat de chip met succes is geauthenticeerd, worden alle 
commando's en antwoorden die de voertuigunit en tacho ­
graafkaart met elkaar uitwisselen beschermd door beveiligde 
berichtenuitwisseling (SM) tot op het ogenblik dat de sessie 
wordt beëindigd.  
CSM_182 Tenzij wanneer gegevens worden gelezen in een bestand 
met toegangsconditie SM-R-ENC-MAC-G2 (zie aanhangsel 
2, hoofdstuk 4), vindt de beveiligde berichtenuitwisseling 
plaats in alleen-authenticeren-modus. In deze modus wordt 
aan alle commando's en antwoorden een cryptografische 
controlesom (ook berichtauthenticatiecode of MAC ge ­
noemd) toegevoegd om de authenticiteit en integriteit te 
waarborgen.  
CSM_183 Bij het lezen van gegevens in een bestand met toegangs ­
conditie SM-R-ENC-MAC-G2, wordt de beveiligde berich ­
tenuitwisseling gebruikt in eerst-coderen-dan-authenticeren- 
modus. Dit betekent dat de antwoordgegevens eerst worden 
gecodeerd om de vertrouwelijkheid van het bericht te waar ­
borgen en dat daarna een MAC voor de geformatteerde 
gecodeerde gegevens wordt berekend om de authenticiteit 
en integriteit te waarborgen.  
CSM_184 De beveiligde berichtenuitwisseling gebruikt het AES-algo ­
ritme, zoals vastgelegd in [AES], met de sessiesleutels 
K MAC en K  ENC die werden overeengekomen tijdens de chi ­
pauthenticatie.  
CSM_185 Een niet-getekend geheel getal wordt gebruikt als zendse ­
quentieteller (SSC) om replay-aanvallen tegen te gaan. De 
grootte van de SSC is gelijk aan de AES-blokgrootte, na ­
melijk 128 bits. De SSC heeft het formaat „MSB-first” 
(meest significante bits eerst). Bij het starten van de bevei ­
ligde berichtenuitwisseling wordt de zendsequentieteller geï ­
nitialiseerd op nul (dat wil zeggen ‘00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00’). Voordat een APDU-com ­
mando of -antwoord wordt gegenereerd, wordt de SSC tel ­
kens met 1 verhoogd. Aangezien de SSC aan het begin van 
een SM-sessie op ‘0’ staat, is de waarde van de SSC in het 
eerste commando gelijk aan ‘1’. Voor het eerste antwoord is 
de waarde van de SSC gelijk aan ‘2’.  
CSM_186 Om het bericht te coderen, wordt K  ENC gebruikt met het 
AES-algoritme in de CBC(Cipher Block Chaining)-wer ­
kingsmodus, zoals vastgelegd in [ISO 10116], met een in ­
terleave-parameter  m = 1 en een initialisatievector IV = 
E(K  ENC , SSC), dat wil zeggen de huidige waarde van de 
zendsequentieteller (SCC), gecodeerd met K  ENC . 
CSM_187 Om het bericht te authenticeren, wordt K  MAC gebruikt met 
het AES-algoritme in CMAC-modus, zoals gespecificeerd in 
[SP 800-38B]. De lengte van de berichtauthenticatiecode 
(MAC) is gerelateerd aan de lengte van de AES-sessiesleu ­
tels, zoals gespecificeerd in CSM_50. De zendsequentietel ­
ler wordt in de MAC opgenomen door die te laten voor ­
afgaan aan het te authenticeren datagram.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 418  
10.5.2  Structuur van het beveiligde bericht  
CSM_188 De beveiligde berichtenuitwisseling (SM) gebruikt uitslui ­
tend de in Tabel 5 opgesomde SM-gegevensobjecten (zie 
[ISO 7816-4]). In elk bericht worden deze gegevensobjecten 
gebruikt in de volgorde die wordt aangegeven in deze tabel.  
Tabel 5  
Gegevensobjecten voor beveiligde berichtenuitwisseling (SM DO's)  
Naam gegevensobject  Label  Aanwezigheid (V)erplicht, 
(C)onditioneel of (N)iet 
toegestaan in  
Comman­
do's Antwoorden  
Ongecodeerde waarde van niet met 
BER-TLV gecodeerde gegevens  ‘81’ C  C  
Ongecodeerde waarde van met BER- 
TLV gecodeerde gegevens, exclusief 
SM-gegevensobjecten  ‘B3’ C  C  
Paddingindicator gevolgd door crypto ­
gram, ongecodeerde waarde van niet 
met BER-TLV gecodeerde gegevens  ‘87’ C  C  
Beschermde lengtebyte (Le)  ‘97’  C  N  
Verwerkingsstatus  ‘99’  N  V  
Cryptografische controlesom  ‘8E’  V  V  
Opmerking:  Zoals gespecificeerd in aanhangsel 2, kunnen 
tachograafkaarten het READ BINARY- en UPDATE BI ­
NARY-commando ondersteunen met een oneven instructie ­
byte (INS) (respectievelijk ‘B1’ en ‘D7’). Deze varianten 
van commando zijn nodig om bestanden met 32 768 bytes 
of meer te lezen en te actualiseren. Indien geen dergelijke 
variant wordt gebruikt, wordt een gegevensobject met label 
‘B3’ gebruikt in plaats van een gegevensobject met label 
‘81’. Zie aanhangsel 2 voor meer informatie.  
CSM_189 Alle SM-gegevensobjecten worden gecodeerd met DER 
TLV, zoals gespecificeerd in [ISO 8825-1]. Door deze co ­
dering wordt de waarde van de labellengte (TLV) als volgt 
gestructureerd:  
Label: het label wordt ingevoerd in 1 of 2 bytes en geeft 
de inhoud aan.  
Lengte: de lengte wordt ingevoerd als niet-getekend ge ­
heel getal in 1, 2 of 3 bytes, wat een maximum ­
lengte van 65 535 bytes geeft. Er worden zo wei ­
nig mogelijk bytes gebruikt.  
Waarde: de waarde wordt ingevoerd in nul of meer bytes.  
CSM_190 Door beveiligde berichtenuitwisseling beschermde APDU's 
worden als volgt aangemaakt:  
— Het koplabel (header) van het commando wordt opge ­
nomen in de MAC-berekening. Bijgevolg wordt de 
waarde ‘0C’ wordt gebruikt voor de bytecategorie CLA.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 419  
— Zoals gespecificeerd in aanhangsel 2, zijn alle instruc ­
tiebytes (INS) even, met als mogelijke uitzondering on ­
even instructiebytes voor de READ BINARY- en UP ­
DATE BINARY-commando's.  
— De werkelijke waarde van Lc wordt gewijzigd in Lc' na 
toepassing van de beveiligde berichtenuitwisseling.  
— Het gegevensveld bestaat uit gegevensobjecten voor be ­
veiligde berichtenuitwisseling (SM DO's).  
— In het beveiligde APDU-commando wordt de nieuwe 
lengtebyte (Le) ingesteld op ‘00’. Indien nodig wordt 
een gegevensobject ‘97’ toegevoegd aan het gegevens ­
veld om de oorspronkelijke waarde van Le door te ge ­
ven. 
▼M1 
CSM_191 Elk te coderen gegevensobject wordt opgevuld overeenkom ­
stig [ISO 7816-4] met behulp van de paddingindicator „01”. 
Om de MAC te berekenen, worden gegevensobjecten in de 
APDU opgevuld overeenkomstig [ISO 7816-4].  
Opmerking:  de opvulling (padding) voor beveiligde berich ­
tenuitwisseling wordt altijd uitgevoerd door de SM-laag, 
niet door het CMAC- of CBC-algoritme.  
Samenvatting en voorbeelden  
Afhankelijk van het desbetreffende onbeveiligde commando heeft een 
APDU-commando waarop beveiligde berichtenuitwisseling is toegepast, 
de volgende structuur („DO” staat voor gegevensobject):  
Geval 1: CLA INS P1 P2 || Lc' || DO „8E” 
|| Le 
Geval 2: CLA INS P1 P2 || Lc' || DO „97” 
|| DO„8E” || Le  
Geval 3 (even instructiebyte INS): CLA INS P1 P2 || Lc' || DO „81” 
|| DO„8E” || Le  
Geval 3 (oneven instructiebyte INS): CLA INS P1 P2 || Lc' || DO „B3” 
|| DO„8E” || Le  
Geval 4 (even instructiebyte INS): CLA INS P1 P2 || Lc' || DO „81” 
|| DO„97” || DO„8E” || Le  
Geval 4 (oneven instructiebyte INS): CLA INS P1 P2 || Lc' || DO „B3” 
|| DO„97” || DO‘8E’ || Le  
waarbij de lengtebyte Le = „00” of „00 00” naargelang velden met korte 
lengte of met uitgebreide lengte worden gebruikt; zie [ISO 7816-4].  
Afhankelijk van het desbetreffende onbeveiligde antwoord heeft een AP ­
DU-antwoord waarop beveiligde berichtenuitwisseling is toegepast, de 
volgende structuur:  
Geval 1 of 3: DO „99” || DO „8E” || 
SW1SW2  
Geval 2 of 4 (even instructiebyte INS) 
zonder codering: DO „81” || DO „99” || DO 
„8E” || SW1SW2  
Geval 2 of 4 (even instructiebyte INS) 
met codering: DO „87” || DO „99” || DO 
„8E” || SW1SW2  
Geval 2 of 4 (oneven instructiebyte INS) 
zonder codering: DO „B3” || DO „99” || DO 
„8E” || SW1SW2  
Opmerking:  geval 2 of 4 (oneven instructiebyte INS) met codering wordt 
nooit gebruikt bij de communicatie tussen een VU en een kaart.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 420  
Hieronder staan drie voorbeelden van APDU-transformaties voor com ­
mando's met een even instructiecode (INS). Figuur 8 toont een geauthen ­
ticeerd APDU-commando in geval 4, Figuur 9 toont een geauthenticeerd 
APDU-antwoord in geval 1/geval 3, en Figuur 10 toont een gecodeerd en 
geauthenticeerd APDU-antwoord in geval 2/geval 4.  
Figuur 8  
Transformatie van een geauthenticeerd APDU-commando in geval 4
  
Figuur 9  
Transformatie van een geauthenticeerd APDU-antwoord in geval 1/geval 3
  ▼M1
 02016R0799 — NL — 26.02.2020 — 002.001 — 421  
Figuur 10  
Transformatie van een gecodeerd en geauthenticeerd APDU-antwoord in geval 2/geval 4
  
▼B 
10.5.3  Afbreken van een sessie voor beveiligde berichtenuitwisseling  
CSM_192 De voertuigunit breekt een actieve sessie voor beveiligde 
berichtenuitwisseling (SM-sessie) enkel en alleen af indien 
een van de volgende omstandigheden zich voordoet:  
— de VU ontvangt een ongecodeerd APDU-antwoord;  
— de VU stelt een SM-fout in een APDU-antwoord vast:  
— een verwacht SM-gegevensobject ontbreekt, de gege ­
vensobjecten staan niet in de juiste volgorde, of er is 
een onbekend gegevensobject aanwezig;  
— een SM-gegevensobject is onjuist, bijvoorbeeld on ­
juiste MAC-waarde, onjuiste TLV-structuur of pad ­
dingindicator in label ‘87’ verschilt van ‘01’;  
— de kaart zendt een statusbyte terug om te melden dat een 
SM-fout werd vastgesteld (zie CSM_194);  
— het maximumaantal commando's en bijbehorende ant ­
woorden van de huidige sessie is bereikt. Dit maximum ­
aantal wordt voor de VU vastgelegd door de fabrikant, 
rekening houdend met de beveiligingseisen van de ge ­
bruikte hardware, en bedraagt 240 SM-commando's en 
bijbehorende antwoorden per sessie.  ▼M1
 02016R0799 — NL — 26.02.2020 — 002.001 — 422  
CSM_193 De tachograafkaart breekt een actieve SM-sessie enkel en 
alleen af indien een van de volgende omstandigheden zich 
voordoet:  
— de kaart ontvangt een ongecodeerd APDU-commando;  
— de kaart stelt een SM-fout in een APDU-commando vast:  
— een verwacht SM-gegevensobject ontbreekt, de gege ­
vensobjecten staan niet in de juiste volgorde, of er is 
een onbekend gegevensobject aanwezig;  
— een SM-gegevensobject is onjuist, bijvoorbeeld on ­
juiste MAC-waarde of onjuiste TLV-structuur;  
— onderbreking van de stroomvoorziening of kaartterugstel ­
ling (reset);  
— de VU start de VU-authenticatieprocedure,  
— het maximumaantal commando’s en bijbehorende ant ­
woorden van de huidige sessie is bereikt. Dit maximum ­
aantal wordt voor de kaart vastgelegd door de fabrikant, 
rekening houdend met de beveiligingseisen van de ge ­
bruikte hardware, en bedraagt 240 SM-commando’s en 
bijbehorende antwoorden per sessie.  
▼B 
CSM_194 De tachograafkaart behandelt SM-fouten als volgt:  
— Indien sommige in een APDU-commando verwachte 
SM-gegevensobjecten ontbreken, gegevensobjecten niet 
in de juiste volgorde staan of onbekende gegevensobjec ­
ten aanwezig zijn, zendt de tachograafkaart de statusby ­
tes ‘69 87’ terug.  
— Indien een APDU-commando een onjuist SM-gegevens ­
object bevat, zendt de tachograafkaart de statusbytes ‘69 
88’ terug.  
In dit geval worden de statusbytes teruggezonden zonder 
SM. 
CSM_195 Indien een SM-sessie tussen de VU en tachograafkaart wordt 
afgebroken, voeren de VU en tachograafkaart de volgende 
acties uit:  
— de opgeslagen sessiesleutels worden veilig vernietigd;  
— er wordt onmiddellijk een nieuwe SM-sessie tot stand 
gebracht, zoals beschreven in punten 10.2 tot en met 
10.5.  
CSM_196 Indien de VU om welke reden dan ook beslist de weder ­
zijdse authenticatie voor een ingebrachte kaart opnieuw te 
starten, begint de procedure opnieuw met de verificatie van 
de certificaatketen op kaartniveau, zoals uiteengezet in punt 
10.2. Vervolgens wordt de procedure voortgezet zoals be ­
schreven in punten 10.2 tot en met 10.5.  ▼M1
 02016R0799 — NL — 26.02.2020 — 002.001 — 423  
11. KOPPELING, WEDERZIJDSE AUTHENTICATIE EN BEVEILIGDE 
BERICHTENUITWISSELING TUSSEN VU EN EXTERNE GNSS- 
MODULE  
11.1.  Algemeen  
CSM_197 De GNSS-module die de VU gebruikt om zijn positie te 
bepalen, kan zich zowel binnen de VU bevinden (in de 
VU-systeemkast ingebouwd en niet demonteerbaar) als daar ­
buiten, in de vorm van een externe module. In het eerste 
geval is het niet nodig de interne communicatie tussen de 
GNSS-module en de VU te standaardiseren, en zijn de in dit 
hoofdstuk vastgelegde voorschriften Niet van to- 
epassing. In het tweede geval moet de communicatie tussen 
de VU en de externe GNSS-module worden gestandaardi ­
seerd en beschermd op de in dit hoofdstuk beschreven wijze.  
CSM_198 De beveiligde communicatie tussen een voertuigunit en ex ­
terne GNSS-module vindt op dezelfde wijze plaats als tussen 
een voertuigunit en tachograafkaart, met dit verschil dat de 
externe GNSS-module (EGF) de rol van de kaart overneemt. 
De externe GNSS-module moet voldoen aan alle in hoofd ­
stuk 10 vermelde voorschriften voor tachograafkaarten, on ­
verminderd de in dit hoofdstuk genoemde afwijkingen, ver ­
duidelijkingen en aanvullingen. In het bijzonder de weder ­
zijdse verificatie van de certificaatketen, de VU-authenticatie 
en chipauthenticatie moeten worden uitgevoerd zoals be ­
schreven in punten 11.3 en 11.4.  
CSM_199 Anders dan bij de communicatie tussen een voertuigunit en 
tachograafkaart, moeten de voertuigunit en externe GNSS- 
module eenmaal worden gekoppeld in de werkplaats voordat 
ze op GNSS gebaseerde gegevens kunnen uitwisselen tijdens 
normaal bedrijf. Het koppelingsproces wordt nader toegelicht 
in punt 11.2.  
CSM_200 Voor de communicatie tussen een voertuigunit en externe 
GNSS-module worden op [ISO 7816-4] en [ISO 7816-8] 
gebaseerde APDU-commando's en -antwoorden gebruikt. 
De exacte structuur daarvan wordt gedefinieerd in aanhang ­
sel 2 van deze bijlage.  
11.2.  Koppeling tussen VU en externe GNSS-module  
CSM_201 De voertuigunit en de externe GNSS-module worden in de 
werkplaats gekoppeld. Zodra de voertuigunit en de externe 
GNSS-module gekoppeld zijn, kunnen ze met elkaar com ­
municeren tijdens normaal bedrijf.  
CSM_202 Het is alleen mogelijk een voertuigunit en externe GNSS- 
module te koppelen indien de voertuigunit in kalibrerings ­
modus staat. De koppelingsprocedure wordt gestart door de 
voertuigunit.  
CSM_203 In de werkplaats kan een voertuigunit te allen tijde aan een 
andere of opnieuw aan dezelfde externe GNSS-module wor ­
den gekoppeld. Bij het opnieuw koppelen wordt het be ­
staande certificaat EGF_MA in het geheugen van de VU 
veilig vernietigd, en slaat de VU het certificaat EGF_MA 
op van de externe GNSS-module waaraan hij wordt gekop ­
peld.  
CSM_204 In de werkplaats kan een externe GNSS-module te allen tijde 
aan een andere of opnieuw aan dezelfde voertuigunit worden 
gekoppeld. Bij het opnieuw koppelen wordt het bestaande 
certificaat VU_MA in het geheugen van de externe GNSS- 
module veilig vernietigd, en slaat de module het certificaat 
VU_MA op van de VU waaraan hij wordt gekoppeld.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 424  
11.3.  Wederzijdse verificatie van de certificaatketen  
11.3.1  Algemeen  
CSM_205 De wederzijdse verificatie van de certificaatketen tussen een 
VU en externe GNSS-module vindt uitsluitend plaats op het 
ogenblik dat de VU en de externe GNSS-module in de werk ­
plaats worden gekoppeld. Tijdens normaal bedrijf van een 
gekoppelde VU en externe GNSS-module worden geen cer ­
tificaten geverifieerd. In plaats daarvan worden de certifica ­
ten die tijdens de koppelingsprocedure zijn opgeslagen als 
vertrouwde certificaten beschouwd door de VU en de ex ­
terne GNSS-module, nadat ze op temporele geldigheid zijn 
gecontroleerd. Andere certificaten wordt niet vertrouwd ter 
bescherming van de communicatie tussen de VU en de ex ­
terne GNSS-module tijdens normaal bedrijf.  
11.3.2  Tijdens de koppeling tussen VU en externe GNSS-module  
CSM_206 Tijdens de koppeling met een externe GNSS-module gaat de 
voertuigunit te werk volgens het stroomschema in Figuur 4 
(zie punt 10.2.1) om de certificaatketen van de externe 
GNSS-module te verifiëren.  
Toelichtingen bij Figuur 4 in deze context:  
— De communicatiecontrole valt buiten het toepassings ­
gebied van dit aanhangsel. Een externe GNSS-module 
is echter geen smartcard, waardoor de VU wellicht 
geen terugstelcommando (reset) zal verzenden om de 
communicatie te initiëren en evenmin een antwoord op 
terugstellen (ATR) zal ontvangen.  
— De kaartcertificaten en openbare sleutels in deze figuur 
worden opgevat als die van de externe GNSS-module ten 
behoeve van de wederzijdse authenticatie. In punt 9.1.6 
worden deze aangeduid als EGF_MA.  
— De openbare sleutels en certificaten Card.CA in deze 
figuur worden opgevat als die van de MSCA ter onder ­
tekening van de certificaten van de externe GNSS-mo ­
dule. In punt 9.1.3 worden deze aangeduid als 
MSCA_VU-EGF.  
— Het certificaat Card.CA.EUR in deze figuur wordt opge ­
vat als het Europese basiscertificaat dat vermeld staat in 
de referentie van de certificeringsautoriteit (CAR) van 
het certificaat MSCA_VU-EGF.  
— Het certificaat Card.Link in deze figuur wordt opgevat 
als het verbindingscertificaat van de externe GNSS-mo ­
dule (indien aanwezig). Zoals verduidelijkt in punt 9.1.2, 
is dit een verbindingscertificaat voor een nieuw Europees 
basissleutelpaar dat door de ERCA is aangemaakt en dat 
met de vorige Europese particuliere sleutel is onder ­
tekend.  
— Het certificaat Card.Link.EUR is het Europese basiscer ­
tificaat dat vermeld staat in de referentie van de certifi ­
ceringsautoriteit (CAR) van het certificaat Card.Link.  
— In plaats van
  leest de 
VU
 in het hoofdbestand 
van de chipkaart (EF ICC).  
— De VU selecteert hier niet de toepassingsidentificator 
(AID) van de tachograaf, maar die van de externe 
GNSS-module (EGF AID).  
— De instructie ‘Ignore Card’ wordt opgevat als ‘Ignore 
EGF’.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 425  
CSM_207 Na verificatie van het certificaat EGF_MA slaat de voertuig ­
unit dit certificaat op voor gebruik tijdens normaal bedrijf 
(zie punt 11.3.3).  
CSM_208  ►M1 Tijdens de koppeling met een VU gaat de externe 
GNSS-module te werk volgens het stroomschema in Figuur 
5 (zie punt 10.2.2) om de certificaatketen op VU-niveau te 
verifiëren. ◄ 
Toelichtingen bij Figuur 5 in deze context:  
— De VU genereert een nieuw tijdelijk sleutelpaar op basis 
van de domeinparameters in het certificaat van de ex ­
terne GNSS-module.  
— De VU-certificaten en openbare sleutels in deze figuur 
dienen voor de wederzijdse authenticatie. In punt 9.1.4 
worden deze aangeduid als VU_MA.  
— De openbare sleutels en certificaten VU.CA in deze fi ­
guur dienen om certificaten van voertuigunits en externe 
GNSS-modules te ondertekenen. In punt 9.1.3 worden 
deze aangeduid als MSCA_VU-EGF.  
— Het certificaat VU.CA.EUR in deze figuur is het Euro ­
pese basiscertificaat dat vermeld staat in de referentie van 
de certificeringsautoriteit (CAR) van het certificaat 
VU.CA.  
— Het certificaat VU.Link in deze figuur is het verbindings ­
certificaat van de VU (indien aanwezig). Zoals verduide ­
lijkt in punt 9.1.2, is dit een verbindingscertificaat voor 
een nieuw Europees basissleutelpaar dat door de ERCA 
is aangemaakt en dat met de vorige Europese particuliere 
sleutel is ondertekend.  
— Het certificaat VU.Link.EUR is het Europese basiscerti ­
ficaat dat vermeld staat in de referentie van de certifice ­
ringsautoriteit (CAR) van het certificaat VU.Link.  
CSM_209 In afwijking van het voorschrift CSM_167 gebruikt de ex ­
terne GNSS-module de eigen tijdaanduiding om de tempo ­
rele geldigheid van een aangeboden certificaat te verifiëren.  
▼M1 
CSM_210 Na verificatie van het certificaat VU_MA slaat de externe 
GNSS-module dit certificaat op voor gebruik tijdens normaal 
bedrijf; zie punt 11.3.3.  
▼B 
11.3.3  Tijdens normaal bedrijf  
CSM_211  ►M1 Tijdens normaal bedrijf gaan de voertuigunit en ex ­
terne GNSS-module te werk volgens het stroomschema in 
Figuur 11 om de temporele geldigheid te verifiëren van het 
opgeslagen EGF_MA-certificaat en om de openbare sleutel 
VU_MA in te stellen met het oog op de VU-authenticatie op 
een later tijdstip. Er vindt geen verdere wederzijdse verifica ­
tie van de certificaatketens plaats tijdens normaal bedrijf. ◄ 
Het stroomschema in Figuur 11 omvat in wezen de eerste 
stappen die terug te vinden zijn in Figuur 4 en Figuur 5. 
Zoals gezegd, is een externe GNSS-module echter geen 
smartcard, waardoor de VU ook hier wellicht geen terugstel ­
commando (reset) zal verzenden om de communicatie te 
initiëren en evenmin een antwoord op terugstellen (ATR) 
zal ontvangen. Dit valt hoe dan ook buiten het toepassings ­
gebied van dit aanhangsel.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 426  
Figuur 11  
Wederzijdse verificatie van de temporele geldigheid van het certificaat tijdens normaal bedrijf van VU en externe 
GNSS-module
  
CSM_212 Zoals blijkt uit Figuur 11, registreert de voertuigunit een fout 
indien het certificaat EGF_MA niet langer geldig is. De 
wederzijdse authenticatie, sleutelovereenstemming en latere 
communicatie via beveiligde berichtenuitwisseling verlopen 
echter op de gebruikelijke wijze.  
11.4.  VU-authenticatie, chipauthenticatie en sleutelovereenstemming tij ­
dens de sessie  
CSM_213 De VU-authenticatie, chipauthenticatie en sleutelovereen ­
stemming tijdens de sessie tussen een VU en externe 
GNSS-module vinden plaats tijdens de koppelingsprocedure 
en telkens wanneer een nieuwe sessie voor beveiligde be ­
richtenuitwisseling (SM-sessie) tot stand wordt gebracht tij ­
dens normaal bedrijf. De VU en de externe GNSS-module 
voeren de in punten 10.3 en 10.4 beschreven procedures uit. 
Alle in deze punten vastgestelde voorschriften zijn van toe ­
passing.  
11.5.  Beveiligde berichtenuitwisseling  
CSM_214 Nadat de chip met succes is geauthenticeerd en tot op het 
ogenblik dat de sessie wordt beëindigd, worden alle com ­
mando's en antwoorden die de voertuigunit en externe 
GNSS-module met elkaar uitwisselen beschermd door bevei ­
ligde berichtenuitwisseling in alleen-authenticeren-modus. 
Alle in punt 10.5 vastgestelde voorschriften zijn van toepas ­
sing.  
CSM_215 Indien de beveiligde berichtenuitwisseling tussen een VU en 
externe GNSS-module wordt afgebroken, brengt de VU on ­
middellijk een nieuwe SM-sessie tot stand, zoals uiteengezet 
in punten 11.3.3 en 11.4.  
12. KOPPELING EN COMMUNICATIE TUSSEN VU EN BEWEGINGS ­
SENSOR  
12.1.  Algemeen  
CSM_216 Tijdens de koppelingsprocedure en tijdens normaal bedrijf 
communiceren de voertuigunit en bewegingssensor met el ­
kaar overeenkomstig het in [ISO 16844-3] gespecificeerde 
interfaceprotocol, onverminderd de wijzigingen die nader 
worden omschreven in dit hoofdstuk en in punt 9.2.1.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 427  
Opmerking: de lezer wordt bekend verondersteld met de 
inhoud van [ISO 16844-3].  
12.2.  Koppeling tussen VU en bewegingssensor met gebruikmaking van 
sleutels van verschillende generaties  
Zoals uiteengezet in punt 9.2.1, wordt de hoofdsleutel van de bewegings ­
sensor met alle bijbehorende sleutels regelmatig vervangen. Het gevolg 
hiervan is dat op werkplaatskaarten tot drie aan de bewegingssensor 
gerelateerde AES-sleutels K  M-WC  (van opeenvolgende generaties) kunnen 
voorkomen. Ook bewegingssensoren kunnen tot drie verschillende op 
AES gebaseerde gegevenscoderingen bevatten (die berusten op opeen ­
volgende generaties van de hoofdsleutel van de bewegingssensor K  M ). 
De voertuigunit bevat slechts één aan de bewegingssensor gerelateerde 
sleutel K  M-VU  . 
CSM_217 Een VU van de tweede generatie en een bewegingssensor 
van de tweede generatie worden als volgt gekoppeld (zie ook 
tabel 6 in [ISO 16844-3]):  
1. De werkplaatskaart van de tweede generatie wordt in ­
gebracht in de VU en de VU wordt verbonden met de 
bewegingssensor.  
2. De VU leest alle beschikbare sleutels K  M-WC  op de werk ­
plaatskaart, controleert het versienummer van de sleutels 
en kiest de sleutel die overeenstemt met het versienum ­
mer van de sleutel K  M-VU  van de VU. Indien de werk ­
plaatskaart geen overeenstemmende sleutel K  M-WC  bevat, 
wordt de koppelingsprocedure afgebroken door de VU en 
krijgt de werkplaatskaarthouder een foutmelding te zien.  
3. Zoals gespecificeerd in punt 9.2.1, berekent de VU de 
hoofdsleutel van de bewegingssensor K  M op basis van 
de sleutels K  M-VU  en K  M-WC  en de identificatiesleutel 
K ID op basis van de sleutel K  M . 
4. De VU geeft de bewegingssensor opdracht om de kop ­
pelingsprocedure te starten, zoals beschreven in [ISO 
16844-3], en codeert het van de bewegingssensor ontvan ­
gen serienummer met de identificatiesleutel K  ID . De VU 
zendt het gecodeerde serienummer terug naar de be ­
wegingssensor.  
5. De bewegingssensor vergelijkt het gecodeerde serienum ­
mer achtereenvolgens met de intern opgeslagen geco ­
deerde versies van het serienummer. Indien een overeen ­
stemmend serienummer wordt gevonden, wordt de VU 
geauthenticeerd. De bewegingssensor registreert de gene ­
ratie van de door de VU gebruikte sleutel K  ID en zendt de 
overeenstemmende gecodeerde versie van de koppelings ­
sleutel terug, dat wil zeggen de gecodeerde sleutel die 
werd aangemaakt met de sleutel K  M van dezelfde gene ­
ratie.  
6. De VU decodeert de koppelingssleutel met K  M , genereert 
een sessiesleutel K  S , codeert die met de koppelingssleutel 
en zendt het resultaat terug naar de bewegingssensor. De 
bewegingssensor decodeert de sessiesleutel K  S . 
7. De VU verzamelt de koppelingsinformatie zoals aange ­
geven in [ISO 16844-3] en codeert die met de kop ­
pelingssleutel. Vervolgens zendt de VU het resultaat terug 
naar de bewegingssensor. De bewegingssensor decodeert 
de koppelingsinformatie.  
8. De bewegingssensor codeert de ontvangen koppelings ­
informatie met de ontvangen sessiesleutel K  S en zendt 
deze terug naar de VU. De VU controleert of de kop ­
pelingsinformatie identiek is aan de informatie die in de 
vorige stap naar de bewegingssensor werd verzonden. 
Indien het gaat om dezelfde informatie, bewijst dit dat  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 428  
de bewegingssensor dezelfde sessiesleutel K  S heeft ge­
bruikt als de VU en bijgevolg in stap 5 de koppelings ­
sleutel heeft teruggezonden nadat die met de sleutel K  M 
van de juiste generatie werd gecodeerd. Bijgevolg wordt 
de bewegingssensor geauthenticeerd.  
Stappen 2 en 5 verschillen van de standaardprocedure in 
[ISO 16844-3]; de overige stappen komen overeen met de 
standaardprocedure.  
Voorbeeld:  Stel dat de koppelingsprocedure wordt uitge ­
voerd in het eerste jaar van geldigheid van het certificaat 
ERCA (3); zie Figuur 2 in punt 9.2.1.2. Stel verder dat  
— de bewegingssensor in gebruik werd genomen in het 
laatste jaar van geldigheid van het certificaat ERCA 
(1). De bewegingssensor bevat bijgevolg de volgende 
sleutels en gegevens:  
— N  s [1]: het serienummer van de bewegingssensor, ge ­
codeerd met de identificatiesleutel K  ID van de eerste 
generatie;  
— N  s [2]: het serienummer van de bewegingssensor, ge ­
codeerd met de identificatiesleutel K  ID van de tweede 
generatie;  
— N  s [3]: het serienummer van de bewegingssensor, ge ­
codeerd met de identificatiesleutel K  ID van de derde 
generatie;  
— K  P [1]: de koppelingssleutel van de eerste genera ­
tie (  1 ), gecodeerd met de sleutel K  M van de eerste 
generatie;  
— K  P [2]: de koppelingssleutel van de tweede generatie, 
gecodeerd met de sleutel K  M van de tweede genera ­
tie; 
— K  P [3]: de koppelingssleutel van de derde generatie, 
gecodeerd met de sleutel K  M van de derde generatie.  
— Stel dat de werkplaatskaart werd afgegeven in het eerste 
jaar van geldigheid van het certificaat ERCA (3). Deze 
kaart bevat bijgevolg de sleutel K  M-WC  van de tweede en 
de derde generatie.  
— Stel dat de VU van de tweede generatie is en de sleutel 
K M-VU  van de tweede generatie bevat.  
In dit geval verlopen stappen 2 tot en met 5 als volgt:  
— Stap 2: de VU leest de sleutel K  M-WC  van de tweede en 
de derde generatie op de werkplaatskaart, en controleert 
de versienummers ervan.  
— Stap 3: de VU combineert de sleutel K  M-WC  van de 
tweede generatie met zijn sleutel K  M-VU  om K  M en 
K ID af te leiden.  
— Stap 4: de VU codeert het van de bewegingssensor ont ­
vangen serienummer met de identificatiesleutel K  ID . 
— Stap 5: de bewegingssensor vergelijkt de ontvangen ge ­
gevens met N  s [1] en vindt geen overeenkomst. Daarna 
vergelijkt de bewegingssensor de gegevens met N  s [2] en 
vindt een overeenkomst. De bewegingssensor maakt hier ­
uit op dat de VU van de tweede generatie is en zendt 
bijgevolg K  P [2] terug.  ▼B 
( 1 ) Zoals uiteengezet in CSM_117, kunnen de koppelingssleutels van de eerste, tweede en 
derde generatie betrekking hebben op dezelfde sleutel dan wel op drie verschillende 
sleutels met een onderling afwijkende lengte.
 02016R0799 — NL — 26.02.2020 — 002.001 — 429  
12.3.  Koppeling en communicatie tussen VU en bewegingssensor via AES  
CSM_218 Zoals gespecificeerd in Tabel 3 onder 9.2.1, zijn alle sleutels 
die worden gebruikt voor de koppeling van een voertuigunit 
(van de tweede generatie) en een bewegingssensor en voor 
de latere communicatie, AES-sleutels en geen TDES-sleutels 
met dubbele lengte zoals gespecificeerd in [ISO 16844-3]. 
Deze AES-sleutels kunnen 128, 192 of 256 bits lang zijn. 
Aangezien de AES-blokgrootte 16 bytes bedraagt, moet de 
lengte van een gecodeerd bericht een veelvoud zijn van 16 
bytes, tegenover 8 bytes voor TDES-sleutels. Bovendien 
worden sommige van die berichten gebruikt om AES-sleu ­
tels over te brengen met een lengte van 128, 192 of 256 bits. 
Bijgevolg wordt het in tabel 5 van [ISO 16844-3] vermelde 
aantal gegevensbytes per instructie aangepast zoals aange ­
geven in Tabel 6:  
▼M1 
Tabel 6  
Aantal ongecodeerde en gecodeerde gegevensbytes per instructie overeenkomstig [ISO 16844-3]  
Instructie  Type  Gegevensbeschrijving  Aantal ongecodeerde 
gegevensbytes over ­
eenkomstig 
[ISO 16844-3]  Aantal ongecodeerde 
gegevensbytes bij 
gebruik van AES- 
sleutels  Aantal gecodeerde gegevens ­
bytes bij gebruik van AES- 
sleutels met bitlengte  
128 192  256  
10 Verzoek  Authenticatiegege ­
vens + bestandsnum ­
mer 8 8  16  16  16  
11 Antwoord  Authenticatiegege ­
vens + bestands ­
inhoud  16 of 32, afhanke ­
lijk van bestand  16 of 32, afhanke ­
lijk van bestand  32 / 48  32 / 48  32 / 48  
41 Verzoek  Serienummer be ­
wegingssensor  8 8  16  16  16  
41 Antwoord  Koppelingssleutel  16  16 / 24 / 32  16  32  32  
42 Verzoek  Sessiesleutel  16  16 / 24 / 32  16  32  32  
43 Verzoek  Koppelingsinformatie  24  24  32  32  32  
50 Antwoord  Koppelingsinformatie  24  24  32  32  32  
70 Verzoek  Authenticatiegege ­
vens 8 8  16  16  16  
80 Antwoord  Tellerwaarde be ­
wegingssensor + au ­
thenticatiegegevens  8 8  16  16  16  
▼B 
CSM_219 De koppelingsinformatie die wordt verzonden in instructies 
43 (verzoek VU) en 50 (antwoord bewegingssensor), wordt 
verzameld zoals gespecificeerd in punt 7.6.10 van [ISO 
16844-3], met dit verschil dat in het coderingsschema van 
de koppelingsgegevens het AES-algoritme wordt toegepast 
in plaats van het TDES-algoritme, waardoor twee AES-co ­
deringen ontstaan, en dat de in CSM_220 vermelde padding 
wordt gebruikt ter aanpassing aan de AES-blokgrootte. De 
voor deze codering gebruikte sleutel K'  p wordt als volgt 
gegenereerd:  
— Indien de koppelingssleutel K  P 16 bytes lang is: K'  p = K  P 
XOR (N  s ||N s ) ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 430  
— Indien de koppelingssleutel K  P 24 bytes lang is: K'  p = K  P 
XOR (N  s ||N s ||N s ) 
— Indien de koppelingssleutel K  P 32 bytes lang is: K'  p = K  P 
XOR (N  s ||N s ||N s ||N s ) 
waarbij N  s het serienummer van 8 bytes van de bewegings ­
sensor is.  
CSM_220 Indien de ongecodeerde gegevenslengte (bij gebruik van 
AES-sleutels) geen veelvoud van 16 bytes is, wordt de in 
[ISO 9797-1] vastgelegde paddingmethode 2 toegepast.  
Opmerking:  in [ISO 16844-3] is het aantal ongecodeerde 
gegevensbytes altijd een veelvoud van 8, zodat bij gebruik 
van TDES geen padding nodig is. De definitie van gegevens 
en berichten in [ISO 16844-3] wordt niet gewijzigd door dit 
onderdeel van dit aanhangsel, waardoor padding noodzake ­
lijk is.  
CSM_221 Voor instructie 11 en indien men meerdere gegevensblokken 
moet coderen, wordt de CBC(Cipher Block Chaining)-wer ­
kingsmodus toegepast, zoals vastgelegd in [ISO 10116], met 
een interleave-parameter  m = 1. Hierbij wordt de volgende 
initialisatievector (IV) gebruikt:  
— Voor instructie 11: het authenticatieblok van 8 bytes 
zoals gespecificeerd in punt 7.6.3.3 van [ISO 16844-3], 
opgevuld volgens de in [ISO 9797-1] vastgelegde pad ­
dingmethode 2; zie ook punten 7.6.5 en 7.6.6 van [ISO 
16844-3].  
— Voor alle andere instructies waarin meer dan 16 bytes 
worden overgebracht, zoals gespecificeerd in Tabel 6: 
‘00’ {16}, dat wil zeggen 16 bytes met een binaire nul.  
Opmerking:  zoals verduidelijkt in punten 7.6.5 en 7.6.6 van 
[ISO 16844-3], in het geval dat de bewegingssensor gege ­
vensbestanden codeert om die op te nemen in instructie 11, 
wordt het authenticatieblok:  
— gebruikt als de initialisatievector om de gegevensbestan ­
den in CBC-modus te coderen;  
— gecodeerd en als eerste blok opgenomen in de naar de 
VU verzonden gegevens.  
12.4.  Koppeling tussen VU en bewegingssensor voor apparatuur van ver ­
schillende generaties  
CSM_222 Zoals uiteengezet in punt 9.2.1, kan een bewegingssensor 
van de tweede generatie de op TDES gebaseerde codering 
van de koppelingsgegevens bevatten (zoals vastgelegd in 
deel A van dit aanhangsel). Hierdoor kan de bewegingssen ­
sor worden gekoppeld aan een VU van de eerste generatie. 
In dit geval moet men de VU van de eerste generatie en de 
bewegingssensor van de tweede generatie koppelen zoals 
beschreven in deel A van dit aanhangsel en in [ISO 
16844-3]. Voor de koppelingsprocedure kan een werkplaats ­
kaart van de eerste of van de tweede generatie worden ge ­
bruikt.  
Opmerkingen:  
— Het is niet mogelijk een VU van de tweede generatie te 
koppelen aan een bewegingssensor van de eerste gene ­
ratie. ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 431  
— Het is niet mogelijk een werkplaatskaart van de eerste 
generatie te gebruiken om een VU van de tweede gene ­
ratie te koppelen aan een bewegingssensor.  
13. BEVEILIGING VOOR COMMUNICATIE OP AFSTAND VIA DE 
DSRC-INTERFACE  
13.1.  Algemeen  
Zoals gespecificeerd in aanhangsel 14, genereert een VU regelmatig 
gegevens over de tachograafcontrole op afstand (RTM), en verzendt 
die naar de (interne of externe) inrichting voor communicatie op afstand 
(RCF). De inrichting voor communicatie op afstand dient deze gegevens 
naar het systeem voor ondervraging op afstand te verzenden via de in 
aanhangsel 14 beschreven DSRC-interface. In aanhangsel 1 worden de 
RTM-gegevens gespecificeerd als samenvoeging van:  
gecodeerde payloadgegevens van de tachograaf  de codering van de 
ongecodeerde payloadgegevens van de tachograaf;  
DSRC-beveiligingsgegevens  zie onderstaande beschrijving.  
Het formaat van de ongecodeerde payloadgegevens van de tachograaf 
wordt gespecificeerd in aanhangsel 1 en nader toegelicht in aanhangsel 
14. In dit gedeelte wordt een beschrijving gegeven van de structuur van 
de DSRC-beveiligingsgegevens; de formele specificaties zijn terug te 
vinden in aanhangsel 1.  
CSM_223 De ongecodeerde
  -gegevens die de 
VU doorgeeft aan een inrichting voor communicatie op af ­
stand (indien de RCF zich buiten de VU bevindt) of aan een 
systeem voor ondervraging op afstand via de DSRC-inter ­
face (indien de RCF zich in de VU bevindt), worden bevei ­
ligd in eerst-coderen-dan-authenticeren-modus. Dit betekent 
dat de payloadgegevens van de tachograaf eerst worden ge ­
codeerd om de vertrouwelijkheid van het bericht te waarbor ­
gen, waarna een berichtauthenticatiecode (MAC) wordt be ­
rekend om de authenticiteit en integriteit van de gegevens te 
waarborgen.  
CSM_224 De DSRC-beveiligingsgegevens bestaan uit de samenvoe ­
ging van de volgende gegevenselementen in de hieronder 
aangegeven volgorde (zie ook Figuur 12):  
Lopende datum/tijd  de huidige datum en tijd van de VU (gegevenstype
  
) 
Teller  een teller van 3 bytes (zie CSM_225)  
▼M1 
Serienummer van de VU  het serienummer van de VU of de identificator van 
de certificaataanvraag (gegevenstype VuSerialNum ­
ber of CertificateRequestID) – zie CSM_123  
▼B 
Versienummer van DSRC-hoofdsleutel  het versienummer van 1 byte van de DSRC-hoofd ­
sleutel waarvan de VU-specifieke DSRC-sleutels zijn 
afgeleid (zie punt 9.2.2)  
MAC  de berichtauthenticatiecode, berekend op basis van 
alle vorige bytes in de RTM-gegevens.  
CSM_225 De teller van 3 bytes in de DSRC-beveiligingsgegevens heeft 
het formaat „MSB-first” (meest significante bits eerst). Wan ­
neer de VU voor het eerst na ingebruikname een reeks 
RTM-gegevens berekent, wordt de teller op nul gezet. Alvo ­
rens een nieuwe reeks RTM-gegevens te berekenen, ver ­
hoogt de VU de waarde van de teller telkens met 1.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 432  
13.2.  Codering van de payloadgegevens van de tachograaf en MAC-gene ­
rering  
CSM_226 Stel een ongecodeerd gegevenselement met gegevenstype
  
, zoals beschreven in aanhangsel 
14. De VU codeert deze gegevens zoals aangegeven in Fi ­
guur 12. De DSRC-coderingssleutel K_VU  DSRC  _ENC van 
de VU (zie punt 9.2.2) wordt gebruikt met het AES-algo ­
ritme in de CBC(Cipher Block Chaining)-werkingsmodus, 
zoals vastgelegd in [ISO 10116], met een interleave-parame ­
ter m = 1. De initialisatievector is gelijk aan  IV = lopende 
datum/tijd  || ‘00 00 00 00 00 00 00 00 00’  || teller , met  
lopende datum/tijd  en  teller  zoals gespecificeerd in 
CSM_224. De te coderen gegevens worden opgevuld vol ­
gens de in [ISO 9797-1] vastgelegde paddingmethode 2.  
CSM_227 De VU berekent de berichtauthenticatiecode (MAC) in de 
DSRC-beveiligingsgegevens zoals verduidelijkt in Figuur 
12. De MAC wordt berekend voor alle vorige bytes in de 
RTM-gegevens, tot en met het versienummer van de DSRC- 
hoofdsleutel, met inbegrip van de labels en rekening hou ­
dend met de lengte van de gegevensobjecten. De VU ge ­
bruikt deze DSRC-sleutel om de authenticiteit te waarborgen 
met K_VU  DSRC  _MAC (zie punt 9.2.2) en past daarbij het 
AES-algoritme toe in CMAC-modus, zoals gespecificeerd in 
[SP 800-38B]. De lengte van de berichtauthenticatiecode 
(MAC) is gerelateerd aan de lengte van de VU-specifieke 
DSRC-sleutels, zoals gespecificeerd in CSM_50.  
Figuur 12  
Codering van de payloadgegevens van de tachograaf en MAC-generering
  
13.3.  Verificatie en decodering van de payloadgegevens van de tachograaf  
CSM_228 Bij ontvangst van RTM-gegevens van een VU brengt het 
systeem voor ondervraging op afstand alle RTM-gegevens 
over op een controlekaart in het gegevensveld van een PRO ­
CESS DSRC MESSAGE-commando, zoals beschreven in 
aanhangsel 2. Daarna gebeurt het volgende:  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 433  
1. De controlekaart inspecteert het versienummer van de 
DSRC-hoofdsleutel in de DSRC-beveiligingsgegevens. 
Indien de controlekaart de opgegeven DSRC-hoofdsleutel 
niet kent, zendt deze een fout terug, zoals gespecificeerd 
in aanhangsel 2, en wordt de procedure afgebroken.  
▼M1 
2. De controlekaart gebruikt de opgegeven DSRC-hoofd ­
sleutel in combinatie met het VU-serienummer of de 
identificator van de certificaataanvraag in de DSRC-be ­
veiligingsgegevens om de VU-specifieke DSRC-sleutels 
K_VU  DSRC  _ENC en K_VU  DSRC  _MAC af te leiden, zoals 
gespecificeerd in CSM_124.  
▼B 
3. De controlekaart gebruikt de sleutel K_VU  DSRC  _MAC 
om de berichtauthenticatiecode (MAC) in de DSRC-be ­
veiligingsgegevens te verifiëren, zoals gespecificeerd in 
CSM_227. Indien de MAC onjuist is, zendt de contro ­
lekaart een fout terug, zoals gespecificeerd in aanhangsel 
2, en wordt de procedure afgebroken.  
4. De controlekaart gebruikt de sleutel K_VU  DSRC  _ENC om 
de gecodeerde payloadgegevens van de tachograaf te de ­
coderen, zoals gespecificeerd in CSM_226. De contro ­
lekaart verwijdert de padding en zendt de gedecodeerde 
payloadgegevens van de tachograaf terug naar het sys ­
teem voor ondervraging op afstand.  
CSM_229 Om replay-aanvallen tegen te gaan, controleert het systeem 
voor ondervraging op afstand of de RTM-gegevens up-to- 
date zijn door zeker te stellen dat de tijdstempel ( lopende 
datum/tijd ) van de DSRC-beveiligingsgegevens niet te veel 
afwijkt van zijn eigen tijdaanduiding.  
Opmerkingen:  
— het systeem voor ondervraging op afstand moet daartoe 
beschikken over een nauwkeurige en betrouwbare tijd ­
bron.  
— Aangezien de VU overeenkomstig aanhangsel 14 om de 
60 seconden een nieuwe reeks RTM-gegevens moet be ­
rekenen, en de interne klok van de VU 1 minuut van de 
werkelijke tijd mag afwijken, wordt een grenswaarde van 
2 minuten toegepast om te bepalen of de RTM-gegevens 
up-to-date zijn. De vereiste mate van actueel-zijn hangt 
ook af van de nauwkeurigheid van de klok van het sys ­
teem voor ondervraging op afstand.  
CSM_230 Wanneer in de werkplaats wordt gecontroleerd of de DSRC- 
functie van een VU goed functioneert, worden alle van de 
VU ontvangen RTM-gegevens overgebracht op een werk ­
plaatskaart in het gegevensveld van een PROCESS DSRC 
MESSAGE-commando, zoals beschreven in aanhangsel 2. 
De werkplaatskaart voert alle in CSM_228 gespecificeerde 
controles en acties uit.  
14. ONDERTEKENING VAN GEDOWNLOADE GEGEVENS EN HAND ­
TEKENINGVERIFICATIE  
14.1.  Algemeen  
CSM_231 De gegevens die de intelligente toepassingsgerichte appara ­
tuur (IDE) van een VU of kaart ontvangt tijdens een downlo ­
adsessie, worden opgeslagen in een fysiek gegevensbestand. 
De gegevens kunnen ook op een extern opslagmedium 
(ESM) worden bewaard. Dit bestand bevat digitale handteke ­
ningen van gegevensblokken, zoals gespecificeerd in aan ­
hangsel 7. Dit bestand bevat eveneens de volgende certifi ­
caten (zie punt 9.1):  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 434  
— Indien gegevens worden gedownload van een VU:  
— het certificaat VU_Sign,  
— het certificaat MSCA_VU-EGF met de openbare 
sleutel ter verificatie van het certificaat VU_Sign.  
— Indien gegevens worden gedownload van een kaart:  
— het certificaat Card_Sign,  
— het certificaat MSCA_Card met de openbare sleutel 
ter verificatie van het certificaat Card_Sign.  
CSM_232 Daarnaast beschikt de IDE over de volgende certificaten.  
— Bij handtekeningverificatie met behulp van een contro ­
lekaart, zoals verduidelijkt in Figuur 13: het verbindings ­
certificaat tussen het laatste EUR-certificaat en het in 
voorkomend geval onmiddellijk daaraan voorafgaande 
EUR-certificaat.  
— Bij handtekeningverificatie door de IDE zelf: alle geldige 
Europese basiscertificaten.  
Opmerking:  de methode die de IDE gebruikt om deze certi ­
ficaten te lezen, wordt niet nader gespecificeerd in dit aan ­
hangsel.  
14.2.  Generering van de handtekening  
CSM_233 Om voor de gedownloade gegevens digitale handtekeningen 
aan te maken, wordt het ondertekeningsalgoritme ECDSA 
gebruikt, zoals gespecificeerd in [DSS]. Daarbij wordt het 
hashalgoritme toegepast dat gerelateerd is aan het sleutel ­
grootte van de VU of de kaart, zoals gespecificeerd in 
CSM_50. Het handtekeningformaat is ongecodeerd, zoals 
gespecificeerd in [TR-03111].  
14.3.  Handtekeningverificatie  
CSM_234  ►M1 De IDE kan de handtekening van gedownloade gege ­
vens zelf verifiëren of kan daartoe gebruikmaken van een 
controlekaart. Bij gebruik van een controlekaart verloopt de 
handtekeningverificatie zoals aangegeven in figuur 13. Om 
de temporele geldigheid van een door de IDE aangeboden 
certificaat te verifiëren, gebruikt de controlekaart zijn interne 
klok, zoals gespecificeerd in CSM_167. De controlekaart 
actualiseert de lopende tijd indien de ingangsdatum van 
een authentiek „geldige tijdbron”-certificaat recenter is dan 
de tijdaanduiding van de kaart. De kaart accepteert uitslui ­
tend de volgende certificaten als geldige tijdbron:  
— ERCA-verbindingscertificaten van de tweede generatie;  
— MSCA-certificaten van de tweede generatie;  
— VU_Sign of Card_Sign van de tweede generatie die zijn 
afgegeven door het land dat ook het kaartcertificaat van 
de controlekaart heeft afgegeven.  
Indien de IDE de handtekeningverificatie zelf uitvoert, veri ­
fieert de IDE de authenticiteit en geldigheid van alle certifi ­
caten in de certificaatketen van het gegevensbestand, alsook 
de handtekening van de gegevens volgens het in [DSS] vast ­
gestelde handtekeningschema. In beide gevallen moet voor 
elk certificaat dat van het gegevensbestand wordt gelezen, 
worden nagegaan of het veld Certificate Holder Authorisa ­
tion (CHA) correct is:  
— In het veld CHA van het EQT-certificaat moet een VU- 
certificaat of kaartcertificaat (al naargelang van toepas ­
sing) zijn vermeld voor ondertekening (zie aanhangsel 1, 
gegevenstype EquipmentType).  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 435  
— In de CHA van het certificaat EQT.CA moet een MSCA 
vermeld zijn.  
— In de CHA van het certificaat EQT.Link moet een ERCA 
vermeld zijn. ◄ 
Toelichtingen bij Figuur 13:  
— De apparatuur die de te analyseren gegevens heeft onder ­
tekend, wordt aangeduid als EQT.  
— De openbare sleutels en certificaten van de apparatuur 
(EQT) in deze figuur dienen om de certificaten VU_Sign 
of Card-Sign te ondertekenen.  
— De openbare sleutels en certificaten EQT.CA in deze 
figuur dienen in voorkomend geval om de VU- of kaart ­
certificaten te ondertekenen.  
— Het certificaat EQT.CA.EUR in deze figuur is het Euro ­
pese basiscertificaat dat vermeld staat in de referentie van 
de certificeringsautoriteit (CAR) van het certificaat 
EQT.CA.  
— Het certificaat EQT.Link in deze figuur is het verbin ­
dingscertificaat van de apparatuur (EQT), indien aan ­
wezig. Zoals verduidelijkt in punt 9.1.2, is dit een ver ­
bindingscertificaat voor een nieuw Europees basissleutel ­
paar dat door de ERCA is aangemaakt en dat met de 
vorige Europese particuliere sleutel is ondertekend.  
— Het certificaat EQT.Link.EUR is het Europese basiscer ­
tificaat dat vermeld staat in de referentie van de certifi ­
ceringsautoriteit (CAR) van het certificaat EQT.Link.  
CSM_235 De hashwaarde M die naar de controlekaart in het 
PSO:Hash-commando wordt verzonden, wordt door de IDE 
berekend met behulp van het hashalgoritme dat gerelateerd is 
aan de sleutelgrootte van de VU of de kaart waarvan de 
gegevens worden gedownload, zoals gespecificeerd in 
CSM_50.  
CSM_236 Ter verificatie van de handtekening van de apparatuur (EQT) 
volgt de controlekaart het in [DSS] vastgestelde handteke ­
ningschema.  
Opmerking:  in dit aanhangsel wordt niet nader gespecifi ­
ceerd welke acties men moet uitvoeren indien de handteke ­
ning van een gedownload gegevensbestand niet kan worden 
geverifieerd of indien de verificatie niet succesvol is.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 436  
Figuur 13  
Stroomschema ter verificatie van de handtekening van een gedownload gegevensbestand
  ▼M1
 02016R0799 — NL — 26.02.2020 — 002.001 — 437  
Aanhangsel 12  
PLAATSBEPALING OP BASIS VAN WERELDWIJD 
SATELLIETNAVIGATIESYSTEEM (GNSS)  
INHOUDSOPGAVE  
1. INLEIDING  
1.1. Toepassingsgebied  
1.2. Acroniemen en notaties  
2. SPECIFICATIE VAN DE GNSS-ONTVANGER  
3. NMEA-ZINNEN  
4. VOERTUIGUNIT MET EXTERNE GNSS-MODULE  
4.1. Configuratie  
4.1.1 Belangrijkste onderdelen en interfaces  
4.1.2 Status van de externe GNSS-module aan het eind van de productie  
4.2. Communicatie tussen de externe GNSS-module en de voertuigunit  
4.2.1 Communicatieprotocol  
4.2.2 Beveiligde GNSS-gegevensoverdracht  
4.2.3 Structuur van het Read Record-commando  
4.3. Koppeling, wederzijdse authenticatie en sleutelovereenstemming tijdens 
de sessie tussen de externe GNSS-module en de voertuigunit  
4.4. Behandeling van fouten  
4.4.1 Fout in communicatie met de externe GNSS-module  
4.4.2 Aantasting van de fysieke integriteit van de externe GNSS-module  
4.4.3 Afwezigheid van positie-informatie van de GNSS-ontvanger  
4.4.4 Geldigheidsduur certificaat van de externe GNSS-module verstreken  
5. VOERTUIGUNIT ZONDER EXTERNE GNSS-MODULE  
5.1. Configuratie  
5.2. Behandeling van fouten  
5.2.1 Afwezigheid van positie-informatie van de GNSS-ontvanger  
6. TEGENSTRIJDIGE GNSS-TIJDGEGEVENS  
7. TEGENSTRIJDIGE BEWEGINGSGEGEVENS  
1. INLEIDING  
Dit aanhangsel bevat de technische voorschriften voor de door de voer ­
tuigunit gebruikte GNSS-gegevens, met inbegrip van de protocollen die 
moeten worden toegepast om een veilige en correcte overdracht van 
plaatsbepalingsinformatie te waarborgen.  
Deze voorschriften vinden hun grondslag in de volgende belangrijke 
artikelen van deze Verordening (EU) nr. 165/2014: artikel 8 „Registratie 
van de positie van het voertuig op bepaalde momenten tijdens de dage ­
lijkse werktijd”, artikel 10 „Interface met intelligente vervoerssystemen” 
en artikel 11 „Gedetailleerde bepalingen voor de slimme tachograaf”.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 438  
1.1. Toepassingsgebied  
GNS_1 Ter ondersteuning van de uitvoering van artikel 8 verzamelt de 
voertuigunit (VU) locatiegegevens van ten minste één GNSS.  
Zoals wordt verduidelijkt in Figuur 1, kan de voertuigunit al dan niet met 
een externe GNSS-module uitgerust zijn:  
Figuur 1  
Configuratiemogelijkheden voor de GNSS-ontvanger
  
1.2. Acroniemen en notaties  
De onderstaande acroniemen worden in dit aanhangsel gebruikt:  
DOP Dilution of Precision (verzwakking van nauwkeurigheid)  
EGF Externe GNSS-module  
EGNOS European Geostationary Navigation Overlay Service (Europees 
overlaysysteem voor geostationaire navigatie)  
GNSS Global Navigation Satellite System (wereldwijd satellietnavi ­
gatiesysteem)  
GSA GPS DOP en actieve satellieten  
HDOP Horizontal Dilution of Precision (verzwakking van horizontale 
nauwkeurigheid)  
ICD Interfacebesturingsdocument  
NMEA National Marine Electronics Association  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 439  
PDOP Position Dilution of Precision (verzwakking van positienauw ­
keurigheid)  
RMC Recommended Minimum Specific (aanbevolen minimale spe ­
cifieke [GNSS-gegevens])  
SIS Signal in Space (ruimtesignaal)  
VDOP Vertical Dilution of Precision (verzwakking van verticale 
nauwkeurigheid)  
VU Voertuigunit  
2. SPECIFICATIE VAN DE GNSS-ONTVANGER  
Ongeacht de configuratie van de slimme tachograaf, met of zonder ex ­
terne GNSS-module, is het verstrekken van nauwkeurige en betrouwbare 
plaatsbepalingsinformatie een essentieel onderdeel van de effectieve wer ­
king van de slimme tachograaf. Het systeem moet dan ook compatibel 
zijn met de door de Galileo- en Egnos-programma's geboden diensten, 
zoals uiteengezet in Verordening (EU) nr. 1285/2013 van het Europees 
Parlement en de Raad (  1 ). Het in het kader van het Galileo-programma 
ontwikkelde systeem is een onafhankelijk wereldwijd satellietnavigatie ­
systeem en het in het kader van het Egnos-programma ingestelde systeem 
is een regionaal satellietnavigatiesysteem dat de kwaliteit van het signaal 
van het global positioning system verbetert.  
GNS_2 De fabrikanten zien erop toe dat de GNSS-ontvangers in de 
slimme tachografen compatibel zijn met de plaatsbepalings ­
diensten van de systemen Galileo en Egnos. De fabrikanten 
kunnen voorts ook kiezen voor compatibiliteit met andere sa ­
tellietnavigatiesystemen.  
GNS_3 De GNSS-ontvanger ondersteunt authenticatie van de open 
dienst die wordt aangeboden door het in het kader van het 
Galileo-programma ingestelde systeem, zodra dit beschikbaar 
is en door de fabrikanten van GNSS-ontvangers wordt onder ­
steund. Voor slimme tachografen die op de markt zijn gebracht 
vóór aan de bovenstaande voorwaarden is voldaan en die de 
authenticatie van de open dienst van Galileo niet ondersteunen, 
is retrofitting niet vereist.  
3. NMEA-ZINNEN  
In dit gedeelte wordt een beschrijving gegeven van de NMEA-zinnen die 
voor de werking van de slimme tachograaf worden gebruikt. Dit gedeelte 
geldt voor de configuratie van de slimme tachograaf, zowel met als 
zonder externe GNSS-module.  
GNS_4 De locatiegegevens berusten op de aanbevolen minimale spe ­
cifieke (RMC) GNSS-gegevens van de NMEA-zin, bestaande 
uit de positie-informatie (breedte- en lengtegraad), de UTC-tijd 
(gecoördineerde wereldtijd) in het formaat hhmmss.ss, de in 
knopen uitgedrukte snelheid over de grond (SOG) alsook op 
extra waarden.  
De RMC-zin heeft de volgende notatie (vanaf NMEA-standaard V4.1):  ▼B 
( 1 ) Verordening (EU) nr. 1285/2013 van het Europees Parlement en de Raad van 11 decem ­
ber 2013 betreffende de uitvoering en exploitatie van de Europese satellietnavigatiesys ­
temen en tot intrekking van Verordening (EG) nr. 876/2002 van de Raad en Verordening 
(EG) nr. 683/2008 van het Europees Parlement en de Raad (PB L 347 van 20.12.2013, 
blz. 1).
 02016R0799 — NL — 26.02.2020 — 002.001 — 440  
Figuur 2  
Opbouw van de RMC-zin
  
De status geeft aan of het GNSS-signaal beschikbaar is. Zolang de status ­
waarde verschilt van „A”, kunnen de ontvangen gegevens (bijvoorbeeld 
de tijd of breedte-/lengtegraad) niet worden gebruikt om de voertuig ­
positie te registreren in de VU.  
▼M1 
De positienauwkeurigheid (resolutie) is gebaseerd op de hierboven be ­
schreven notatie van de RMC-zin. De eerste twee cijfers van de velden 3 
en 5 stellen de graden voor. De resterende cijfers stellen de minuten voor 
met drie cijfers achter de komma. De resolutie bedraagt bijgevolg één 
duizendste van een minuut of één zestigduizendste van een graad (aange ­
zien een minuut één zestigste van een graad is).  
GNS_5 Zoals toegelicht in aanhangsel 1 voor het type GeoCoordinates, 
slaat de voertuigunit de positie-informatie voor de breedte- en 
lengtegraad op in de VU-database met een resolutie van één 
tiende van een minuut of één zeshonderdste van een graad.  
Met behulp van het GSA-commando (GPS DOP en actieve 
satellieten) kan de VU de beschikbaarheid en nauwkeurigheid 
van het signaal bepalen en registreren. Met name de HDOP- 
waarde wordt gebruikt als aanwijzing voor de mate van nauw ­
keurigheid van de geregistreerde locatiegegevens (zie punt 
4.2.2). De VU slaat de verzwakking van horizontale nauwkeu ­
righeid (HDOP) op, berekend als minimum van de HDOP- 
waarden die voor de beschikbare GNSS-systemen werden ver ­
zameld.  
In de GNSS Id is de overeenkomstige NMEA Id voor elke 
GNSS-constellatie en elk satellietaugmentatiesysteem (SBAS) 
vermeld.  
Figuur 3  
Opbouw van de GSA-zin
  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 441  
GNS_6 De  GSA -zin wordt opgeslagen onder recordnummer„02” tot en 
met „06”.  
▼B 
GNS_7 De maximumgrootte van de NMEA-zinnen (bijvoorbeeld 
RMC-zinnen, GSA-zinnen e.d.) om het formaat van het Read 
Record-commando aan te passen, bedraagt 85 bytes (zie Tabel 
1). 
4. VOERTUIGUNIT MET EXTERNE GNSS-MODULE  
4.1. Configuratie  
4.1.1  Belangrijkste onderdelen en interfaces  
In deze configuratie maakt de GNSS-ontvanger deel uit van de externe 
GNSS-module.  
GNS_8 De externe GNSS-module moet van stroom worden voorzien 
via een specifieke voertuiginterface.  
GNS_9 De externe GNSS-module bestaat uit de volgende onderdelen 
(zie Figuur 4):  
a) Een commerciële GNSS-ontvanger die de positiegegevens 
verstrekt via de GNSS-gegevensinterface. De GNSS-gege ­
vensinterface kan bijvoorbeeld vallen onder NMEA-stan ­
daard V4.10, waarbij de GNSS-ontvanger functioneert als 
zender en NMEA-zinnen verstuurt naar de beveiligde 
GNSS-transceiver. De zendfrequentie bedraagt 1 Hz voor 
de vooraf gedefinieerde reeks NMEA-zinnen, die ten minste 
de RMC- en GSA-zinnen moeten bevatten. De keuze van de 
GNSS-gegevensinterface wordt overgelaten aan de fabrikant 
van de externe GNSS-module.  
b) Een zendontvanger (beveiligde GNSS-transceiver) die vol ­
doet aan de norm ISO/IEC 7816-4:2013 (zie 4.2.1) om te 
communiceren met de voertuigunit en ondersteuning te bie ­
den aan de GNSS-gegevensinterface met de GNSS-ontvan ­
ger. De transceiver heeft een geheugen om de identificatie ­
gegevens van de GNSS-ontvanger en de externe GNSS- 
module op te slaan.  
c) Een behuizing (systeemkast) voor de GNSS-ontvanger en de 
beveiligde GNSS-transceiver, uitgerust met een functie om 
manipulatie te detecteren. In de functie om manipulatie te 
detecteren worden de beveiligingsmaatregelen toegepast die 
zijn voorgeschreven in het beschermingsprofiel van de 
slimme tachograaf.  
d) Een op het voertuig gemonteerde GNSS-antenne die via de 
systeemkast verbonden is met de GNSS-ontvanger.  
GNS_10 De externe GNSS-module is ten minste uitgerust met de vol ­
gende externe interfaces:  
a) de interface met de op het voertuig gemonteerde GNSS- 
antenne, voor zover een externe antenne wordt gebruikt;  
b) de interface met de voertuigunit.  
GNS_11 De beveiligde VU-transceiver is het andere eindpunt van het 
communicatiesysteem met de beveiligde GNSS-transceiver; 
deze moet voldoen aan ISO/IEC 7816-4:2013 wat de verbin ­
ding met de externe GNSS-module betreft.  ▼M1
 02016R0799 — NL — 26.02.2020 — 002.001 — 442  
GNS_12 Voor de fysieke communicatielaag met de externe GNSS-mo ­
dule ondersteunt de voertuigunit ISO/IEC 7816-12:2005 of an ­
dere normen die ISO/IEC 7816-4:2013 ondersteunen (zie 
4.2.1).  
4.1.2  Status van de externe GNSS-module aan het eind van de productie  
GNS_13 Bij het verlaten van de fabriek slaat de externe GNSS-module 
de volgende waarden op in het niet-vluchtige geheugen van de 
beveiligde GNSS-transceiver:  
— het sleutelpaar EGF_MA met bijbehorend certificaat;  
— het certificaat MSCA_VU-EGF met de openbare sleutel 
MSCA_VU-EGF.PK ter verificatie van het certificaat 
EGF_MA;  
— het EUR-certificaat met de openbare sleutel EUR.PK ter 
verificatie van het certificaat MSCA_VU-EGF;  
— het EUR-certificaat waarvan de geldigheidsduur onmiddel ­
lijk voorafgaat aan die van het EUR-certificaat ter verifica ­
tie van het certificaat MSCA_VU-EGF (indien bestaand);  
— het verbindingscertificaat dat beide EUR-certificaten met 
elkaar in verband brengt (indien bestaand);  
— het verlengde serienummer van de externe GNSS-module;  
— de identificator van het besturingssysteem (OS — Ope ­
rating System) van de GNSS-module;  
— het typegoedkeuringsnummer van de externe GNSS-modu ­
le; 
— de identificator van de beveiligingscomponent van de ex ­
terne GNSS-module.  
4.2. Communicatie tussen de externe GNSS-module en de voertuigunit  
4.2.1  Communicatieprotocol  
GNS_14 Het communicatieprotocol tussen de externe GNSS-module en 
de voertuigunit ondersteunt drie functies:  
1. de verzameling en verspreiding van GNSS-gegevens (bij ­
voorbeeld positie, tijd en snelheid);  
2. de verzameling van de configuratiegegevens van de externe 
GNSS-module;  
3. het beheerprotocol ter ondersteuning van de koppeling, we ­
derzijdse authenticatie en sleutelovereenstemming tijdens de 
sessie tussen de externe GNSS-module en de VU.  
GNS_15 Het communicatieprotocol is gebaseerd op de norm ISO/IEC 
7816-4:2013, waarbij de beveiligde VU-transceiver de rol van  
master  en de beveiligde GNSS-transceiver die van  slave  ver­
vult. De fysieke verbinding tussen de externe GNSS-module en 
de voertuigunit is gebaseerd op ISO/IEC 7816-12:2005 of an ­
dere normen die ISO/IEC 7816-4:2013 ondersteunen.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 443  
GNS_16 Velden met uitgebreide lengte worden niet ondersteund in het 
communicatieprotocol.  
▼B 
GNS_17 Het communicatieprotocol van ISO 7816 (zowel *-4:2013 als 
*-12:2005) tussen de externe GNSS-module en de VU wordt 
ingesteld op T = 1.  
▼M1 
GNS_18 Wat betreft de functies 1) verzameling en verspreiding van 
GNSS-gegevens en 2) verzameling van configuratiegegevens 
van de externe GNSS-module en 3) beheerprotocol, simuleert 
de beveiligde GNSS-transceiver een smartcard met een be ­
standssysteemarchitectuur bestaande uit een stambestand (MF 
— Master File), een toepassingsgericht bestand (DF — Dedi ­
cated File) waarvan de toepassingsidentificator is gespecificeerd 
in aanhangsel 1, punt 6.2 („FF 44 54 45 47 4D”) en drie 
hoofdbestanden (EF's — Elementary Files) die certificaten be ­
vatten en één hoofdbestand (EF.EGF) waarvan de identificator 
gelijk is aan „2F2F”, zoals beschreven in Tabel 1.  
▼B 
GNS_19 De beveiligde GNSS-transceiver slaat de gegevens van de 
GNSS-ontvanger en de configuratie op in het hoofdbestand 
EF.EGF. Dit is een lineair recordbestand met variabele lengte 
en met als identificator ‘2F2F’ in hexadecimale notatie.  
▼M1 
GNS_20 De beveiligde GNSS-transceiver slaat de gegevens op in een 
geheugen en kan ten minste 20 miljoen lees-/schrijfcycli uit ­
voeren. Afgezien daarvan worden het interne ontwerp en de 
uitvoering van de beveiligde GNSS-transceiver overgelaten 
aan de fabrikanten.  
De recordnummers en gegevens worden toegewezen zoals aan ­
gegeven in Tabel 1. Er zijn vijf GSA-zinnen voor de GNSS- 
systemen en het satellietaugmentatiesysteem (SBAS).  
▼B 
GNS_21 De bestandsstructuur wordt verduidelijkt in Tabel 1. De toe ­
gangscondities (ALW, NEV, SM-MAC) zijn te vinden in aan ­
hangsel 2, punt 3.5.  
Tabel 1  
Bestandsstructuur  
Toegangscondities (AC)  
Bestand  Bestandsidentifica ­
tie Lezen  Bijwerken  Gecodeerd  
MF 3F00  
EF.ICC  0002  ALW  NEV 
(door VU)  Neen  
DF GNSS-module  0501  ALW  NEV  Neen  
EF EGF_MA_Certificate  C100  ALW  NEV  Neen  
EF CA_Certificate  C108  ALW  NEV  Neen  
EF Link_Certificate  C109  ALW  NEV  Neen  
EF.EGF  2F2F  SM-MAC  NEV 
(door VU)  Neen  ▼M1
 02016R0799 — NL — 26.02.2020 — 002.001 — 444  
Bestand/gegevenselement  Record-nummer  Grootte (in bytes)  Standaardwaar ­
den 
Min.  Max.  
MF 552.  1 031  
EF.ICC  
sensorGNSSSerialNumber  8  8  
DF GNSS-module  612  1 023  
EF EGF_MA_Certificate  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  
NMEA RMC-zin  ‘01’  85  85  
Eerste NMEA GSA-zin  ‘02’  85  85  
Tweede NMEA GSA-zin  ‘03’  85  85  
Derde NMEA GSA-zin  ‘04’  85  85  
Vierde NMEA GSA-zin  ‘05’  85  85  
Vijfde NMEA GSA-zin  ‘06’  85  85  
Verlengd serienummer van de externe 
GNSS-module, in aanhangsel 1 gede ­
finieerd als SensorGNSSSerialNum ­
ber ‘07’ 8  8  
Identificator van het besturingssys ­
teem van de beveiligde GNSS-trans ­
ceiver, in aanhangsel 1 gedefinieerd 
als SensorOSIdentifier  ‘08’ 2  2  
Typegoedkeuringsnummer van de ex ­
terne GNSS-module, in aanhangsel 1 
gedefinieerd als SensorExternalGNS ­
SApprovalNumber  ‘09’ 16  16  
Identificatiesymbool van de beveili ­
gingscomponent van de externe 
GNSS-module, in aanhangsel 1 gede ­
finieerd als SensorExternalGNSSS ­
CIdentifier  ‘10’ 8  8  
RFU — Gereserveerd voor toekomstig ge ­
bruik  ‘11’ t/m ‘FD’  
4.2.2  Beveiligde GNSS-gegevensoverdracht  
GNS_22 De beveiligde overdracht van GNSS-positiegegevens kan alleen 
plaatsvinden onder de volgende voorwaarden:  
1. Het koppelingsproces is voltooid zoals beschreven in aan ­
hangsel 11 „Algemene veiligheidsmechanismen”.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 445  
2. De periodieke wederzijdse authenticatie en sleutelovereen ­
stemming tijdens de sessie tussen de VU en de externe 
GNSS-module (zie beschrijving in aanhangsel 11 „Alge ­
mene veiligheidsmechanismen”) werden met voldoende re ­
gelmaat uitgevoerd.  
GNS_23 Tenzij de koppeling of wederzijdse authenticatie en sleutelover ­
eenstemming tijdens de sessie plaatsvindt, vraagt de VU iedere 
T seconden — waarbij T een waarde is kleiner dan of gelijk 
aan 10 — de positie-informatie op van de externe GNSS-mo ­
dule. Dit proces verloopt als volgt:  
1. De VU vraagt locatiegegevens op van de externe GNSS- 
module, samen met de DOP-waarden (mate van onnauw ­
keurigheid, gebaseerd op de GSA NMEA-zin). De bevei ­
ligde VU-transceiver gebruikt de Select- en Read Record- 
commando's van de norm ISO/IEC 7816-4:2013 voor bevei ­
ligde berichtenuitwisseling in alleen-authenticeren-modus, 
zoals beschreven in punt 11.5 van aanhangsel 11; de be ­
standsidentificator is ‘2F2F’ en het recordnummer is ‘01’ 
voor de NMEA RMC-zin en ‘02’, ‘03’, ‘04’, ‘05’, ‘06’ 
voor de NMEA GSA-zin.  
2. De laatste ontvangen locatiegegevens worden in het hoofd ­
bestand (EF) opgeslagen met de identificator ‘2F2F’. De in 
Tabel 1 omschreven records worden opgeslagen in de be ­
veiligde GNSS-transceiver naarmate die via de GNSS-inter ­
face NMEA-gegevens met een frequentie van ten minste 
1 Hz ontvangt van de GNSS-ontvanger.  
3. De beveiligde GNSS-transceiver verstuurt het antwoord naar 
de beveiligde VU-transceiver en gebruikt daarvoor het AP ­
DU-antwoordbericht met beveiligde berichtenuitwisseling in 
alleen-authenticeren-modus, zoals toegelicht in punt 11.5 
van aanhangsel 11.  
4. De beveiligde VU-transceiver controleert de authenticiteit en 
integriteit van het ontvangen antwoord. Bij een positieve 
uitkomst worden de locatiegegevens via de GNSS-interface 
overgebracht naar de verwerkingseenheid van de VU.  
▼M1 
5. De verwerkingseenheid van de VU controleert de ontvangen 
gegevens door de informatie (bijvoorbeeld lengtegraad, 
breedtegraad, tijd) te lezen in de NMEA RMC-zin. Indien 
de positie geldig is, staat deze informatie in de NMEA 
RMC-zin. Is de positie ongeldig, dan zijn er nog geen lo ­
catiegegevens beschikbaar en is het niet mogelijk de voer ­
tuigpositie op basis daarvan te registreren. Indien de positie 
geldig is, leest de verwerkingseenheid van de VU ook de 
HDOP-waarden in de NMEA GSA-zinnen en wordt de mi ­
nimumwaarde voor de beschikbare satellietsystemen bere ­
kend (voor zover positiebepaling mogelijk is).  
▼B 
6. De verwerkingseenheid van de VU slaat de ontvangen en 
verwerkte informatie, zoals breedtegraad, lengtegraad, tijd 
en snelheid, op in het in aanhangsel 1 „Data Dictionary” 
vastgestelde formaat als geografische coördinaten samen 
met de HDOP-waarde, berekend als minimum van de 
voor de beschikbare GNSS-systemen verzamelde HDOP- 
waarden.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 446  
4.2.3  Structuur van het Read Record-commando  
In dit gedeelte wordt een uitvoerige beschrijving gegeven van de struc ­
tuur van het Read Record-commando. Daarbij komt ook de beveiligde 
berichtenuitwisseling (in alleen-authenticeren-modus) aan bod, zoals be ­
schreven in aanhangsel 11 „Algemene beveiligingsmechanismen”.  
GNS_24 Het commando ondersteunt de beveiligde berichtenuitwisseling 
in alleen-authenticeren-modus (zie aanhangsel 11).  
GNS_25 Commandobericht  
Byte  Lengte  Waarde  Omschrijving  
CLA  1  ‘0Ch’  Beveiligde berichtenuitwisseling gevraagd  
INS 1  ‘B2h’  Record lezen  
P1 1  ‘XXh’  Recordnummer (‘00’ verwijst naar de hui ­
dige record)  
P2 1  ‘04h’  Record lezen waarvan het nummer in P1 
staat 
Le 1  ‘XXh’  Lengte van verwachte gegevens. Aantal te 
lezen bytes  
GNS_26 De in P1 aangeduide record wordt de geldige record.  
Byte  Lengte  Waarde  Omschrijving  
#1-#X  X  ‘XX..XXh’  Gelezen gegevens  
SW 2.  ‘XXXXh’  Statuswoorden (SW1, SW2)  
— Indien het commando succesvol is, zendt de beveiligde 
GNSS-transceiver ‘ 9000 ’ terug.  
— Indien het huidige bestand niet recordgeoriënteerd is, zendt 
de beveiligde GNSS-transceiver ‘ 6981 ’ terug.  
— Indien het commando wordt gebruikt met P1 = ‘00’ terwijl 
er geen geldig hoofdbestand (EF) is, zendt de beveiligde 
GNSS-transceiver ‘ 6986 ’ terug (commando niet toe ­
gestaan).  
— Indien de record niet wordt gevonden, zendt de beveiligde 
GNSS-transceiver ‘ 6A83 ’ terug.  
— Indien manipulatie werd vastgesteld, zendt de externe 
GNSS-module de statuswoorden ‘ 6690 ’ terug.  
GNS_27 De beveiligde GNSS-transceiver ondersteunt de volgende com ­
mando's van tachografen van de tweede generatie:  
Commando  Verwijzing  
Select (Selecteer)  Aanhangsel 2, punt 3.5.1  
Read Binary (Lees binair getal)  Aanhangsel 2, punt 3.5.2  
Get Challenge (Vraag naar identiteit)  Aanhangsel 2, punt 3.5.4  
PSO: Verify Certificate (Verifieer certifi ­
caat)  Aanhangsel 2, punt 3.5.7  
External Authenticate (Externe authentica ­
tie) Aanhangsel 2, punt 3.5.9  
General Authenticate (Algemene authenti ­
catie)  Aanhangsel 2, punt 3-5-2010  
MSE:SET  Aanhangsel 2, punt 3-5-2011  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 447  
4.3. Koppeling, wederzijdse authenticatie en sleutelovereenstemming tij ­
dens de sessie tussen de externe GNSS-module en de voertuigunit  
In hoofdstuk 11 van aanhangsel 11 „Algemene veiligheidsmechanismen” 
wordt een beschrijving gegeven van de koppeling, wederzijdse authenti ­
catie en sleutelovereenstemming tijdens de sessie tussen de externe 
GNSS-module en de voertuigunit.  
4.4. Behandeling van fouten  
In dit gedeelte wordt uiteengezet hoe mogelijke fouttoestanden van de 
externe GNSS-module worden behandeld en geregistreerd in de VU.  
4.4.1  Fout in communicatie met de externe GNSS-module  
▼M1 
GNS_28 Indien de VU gedurende ten minste twintig aaneengesloten 
minuten er niet in slaagt te communiceren met de gekoppelde 
externe GNSS-module, genereert en registreert de VU een 
voorval van het type EventFaultType met de enum-waarde 
„0E”H Communication error with the external GNSS facility 
(Communicatiefout externe GNSS-module) en waarvan de tijd ­
aanduiding is ingesteld op de huidige tijd. Het voorval wordt 
uitsluitend gegenereerd indien aan de volgende twee voorwaar ­
den is voldaan: a) de slimme tachograaf staat niet in kalibre ­
ringsmodus en b) het voertuig is aan het rijden. In dit geval is 
sprake van een communicatiefout indien de beveiligde VU- 
transceiver geen antwoordbericht ontvangt op een verzoekbe ­
richt, zoals omschreven in 4.2.  
▼B 
4.4.2  Aantasting van de fysieke integriteit van de externe GNSS-module  
▼M1 
GNS_29 Indien de fysieke integriteit is aangetast, wist de externe 
GNSS-module het volledige geheugen samen met al het cryp ­
tografisch materiaal. Zoals omschreven in GNS_25 en 
GNS_26, detecteert de VU manipulatie indien de antwoordsta ­
tus „6690” is. De VU genereert dan een voorval van het type 
EventFaultType met de enum-waarde „19”H Tamper detection 
of GNSS (Manipulatie GNSS gedetecteerd). Als alternatief is 
het ook mogelijk dat de GNSS-module op geen enkele externe 
aanvraag meer antwoordt.  
▼B 
4.4.3  Afwezigheid van positie-informatie van de GNSS-ontvanger  
▼M1 
GNS_30 Indien gedurende ten minste drie aaneengesloten uren geen 
gegevens van de GNSS-ontvanger worden ontvangen, genereert 
de beveiligde GNSS-transceiver een antwoordbericht op het 
Read Record-commando waarvan het recordnummer gelijk is 
aan „01” en met een gegevensveld van 12 bytes, allemaal 
ingesteld op „0xFF”. Bij ontvangst van het antwoordbericht 
waarvan het gegevensveld deze waarde heeft, genereert en re ­
gistreert de VU een voorval van het type EventFaultType met 
de enum-waarde „0D”H Absence of position information from 
GNSS receiver (ontbreken van plaatsbepalingsinformatie van 
de GNSS-ontvanger). De tijdaanduiding van dit voorval is uit ­
sluitend gelijk aan de huidige tijd indien aan de volgende twee 
voorwaarden is voldaan: a) de slimme tachograaf staat niet in 
kalibreringsmodus en b) het voertuig is aan het rijden.  
▼B 
4.4.4  Geldigheidsduur certificaat van de externe GNSS-module verstreken  
GNS_31  ►M1 Indien de VU vaststelt dat het voor de wederzijdse au ­
thenticatie gebruikte certificaat van de externe GNSS-module 
niet langer geldig is, genereert en registreert de VU een con ­
troleapparaatvoorval van het type EventFaultType met de 
enum-waarde  ‘1B’H External GNSS facility certificate expired  
(Geldigheidsduur certificaat externe GNSS-module verstreken) 
en waarvan de tijdaanduiding gelijk is aan de huidige tijd. De 
VU blijft gebruikmaken van de ontvangen GNSS- 
positiegegevens. ◄ ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 448  
Figuur 4  
Overzicht van de externe GNSS-module
  
5. VOERTUIGUNIT ZONDER EXTERNE GNSS-MODULE  
5.1. Configuratie  
In deze configuratie bevindt de GNSS-ontvanger zich binnen de voer ­
tuigunit, zoals omschreven in Figuur 1.  
GNS_32 De GNSS-ontvanger functioneert als zender en verstuurt 
NMEA-zinnen naar de verwerkingseenheid van de VU, die 
functioneert als ontvanger. De zendfrequentie bedraagt 1/10 Hz 
of meer voor de vooraf gedefinieerde reeks NMEA-zinnen, die 
ten minste de RMC- en GSA-zinnen moeten bevatten.  
GNS_33 Een op het voertuig gemonteerde externe GNSS-antenne of een 
ingebouwde GNSS-antenne wordt aangesloten op de VU.  
5.2. Behandeling van fouten  
5.2.1  Afwezigheid van positie-informatie van de GNSS-ontvanger  
▼M1 
GNS_34 Indien gedurende ten minste drie aaneengesloten uren geen 
gegevens van de GNSS-ontvanger worden ontvangen, genereert 
en registreert de VU een voorval van het type EventFaultType 
met de enum-waarde „0D”H Absence of position information 
from GNSS receiver (ontbreken van plaatsbepalingsinformatie 
van de GNSS-ontvanger). De tijdaanduiding van dit voorval is 
uitsluitend gelijk aan de huidige tijd indien aan de volgende 
twee voorwaarden is voldaan: a) de slimme tachograaf staat 
niet in kalibreringsmodus en b) het voertuig is aan het rijden.  
6. TEGENSTRIJDIGE GNSS-TIJDGEGEVENS  
Indien een verschil van meer dan één minuut wordt vastgesteld tussen de 
door de tijdmetingsfunctie van de VU vastgestelde tijd en de tijdaandui ­
ding afkomstig van de GNSS-ontvanger, registreert de VU een voorval 
van het type EventFaultType met de enum-waarde  ‘0B’H Time conflict 
(GNSS versus VU internal clock)  (Tegenstrijdige tijdgegevens tussen 
GNSS en interne klok VU). Nadat een voorval van tegenstrijdige tijd ­
gegevens werd gestart, voert de VU de eerstvolgende twaalf uren geen 
controle op tijdverschillen uit. Er wordt geen tijdsoverlapping gegene ­
reerd indien de GNSS-ontvanger de jongste 30 dagen geen geldig GNSS- 
signaal heeft kunnen detecteren.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 449  
7. TEGENSTRIJDIGE BEWEGINGSGEGEVENS  
GNS_35 Indien de berekeningsinformatie van de bewegingssensor wordt 
tegengesproken door die van de interne GNSS-ontvanger of 
van de externe GNSS-module, start en registreert de VU een 
voorval van tegenstrijdige bewegingsgegevens (zie voorschrift 
84 in deze bijlage) waarvan de tijdaanduiding gelijk is aan de 
huidige tijd. Tegenstrijdige bewegingsgegevens worden opge ­
spoord op basis van de mediaan van de verschillen in de door 
deze bronnen gemeten snelheid, zoals hieronder gespecificeerd:  
— Maximaal één keer per 10 seconden wordt de absolute 
waarde berekend van het verschil tussen de via GNSS ge ­
raamde voertuigsnelheid en de door de bewegingssensor 
geraamde voertuigsnelheid.  
— De mediaan wordt berekend op basis van alle waarden 
binnen een tijdvenster dat de voertuigbeweging over de 
laatste vijf minuten bestrijkt.  
— De mediaan wordt berekend als gemiddelde van 80 % van 
de betreffende snelheidswaarden, na eliminatie van de 
hoogste absolute waarden.  
Het voorval van tegenstrijdige bewegingsgegevens wordt ge ­
start indien de mediaan van de snelheidsverschillen gedurende 
vijf ononderbroken minuten groter is dan 10 km/h. Er mag 
facultatief gebruik worden gemaakt van andere onafhankelijke 
bronnen van bewegingsinformatie, met het doel (pogingen tot) 
manipulatie van de tachograaf op een meer betrouwbare wijze 
te detecteren. ( Opmerking:  door de mediaan over de laatste vijf 
minuten te berekenen, wordt het risico van uitschieters en tij ­
delijk afwijkende meetwaarden tegengegaan). Dit voorval 
wordt niet gestart in de volgende omstandigheden: a) tijdens 
vervoer per veerboot/trein, b) indien geen positie-informatie 
van de GNSS-ontvanger beschikbaar is en c) in kalibrerings ­
modus.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 450  
Aanhangsel 13  
ITS-INTERFACE  
INHOUD  
1. INLEIDING  
2. TOEPASSINGSGEBIED  
2.1. Acroniemen, definities en notaties  
3. REFERENTIEVERORDENINGEN EN -NORMEN  
4. WERKINGSBEGINSELEN VAN DE INTERFACE  
4.1. Eerste vereisten voor gegevensoverdracht via de ITS-interface  
4.1.1 Via de ITS-interface beschikbaar gestelde gegevens  
4.1.2 Gegevensinhoud  
4.1.3 ITS-toepassingen  
4.2. Communicatietechnologie  
4.3. Pincodeverificatie  
4.4. Berichtformaat  
4.5. Toestemming van de bestuurder  
4.6. Standaardgegevens opvragen  
4.7. Persoonsgegevens opvragen  
4.8. Fout- en voorvalgegevens opvragen  
1. INLEIDING  
In dit aanhangsel worden de ontwerpspecificaties en toepasselijke pro ­
cedures uiteengezet ter implementatie van de interface met intelligente 
vervoerssystemen (ITS), zoals voorgeschreven in artikel 10 van Verorde ­
ning (EU) nr. 165/2014 (tachograafverordening).  
Deze verordening bepaalt dat de tachografen van voertuigen mogen wor ­
den uitgerust met een gestandaardiseerde interface die het gebruik in ope ­
rationele modus van de door de tachograaf geregistreerde of verstrekte 
gegevens door een extern apparaat mogelijk maakt, mits aan de volgende 
voorwaarden is voldaan:  
a) de interface doet geen afbreuk aan de authenticiteit en de integriteit 
van de gegevens van de tachograaf;  
b) de interface voldoet aan de gedetailleerde bepalingen in artikel 11 van 
de tachograafverordening;  
c) het externe apparaat dat is aangesloten op de interface krijgt alleen 
toegang tot de persoonsgegevens, inclusief positioneringsgegevens, 
na verifieerbare toestemming van de bestuurder op wie de gegevens 
betrekking hebben.  
2. TOEPASSINGSGEBIED  
Dit aanhangsel beoogt nader te omschrijven hoe toepassingen die zich op 
externe apparaten bevinden, via een Bluetooth®-verbinding gegevens van 
een tachograaf kunnen verkrijgen.  
In bijlage 1 bij dit aanhangsel staat een beschrijving van de gegevens die 
via deze interface beschikbaar zijn. Deze interface verhindert niet de im ­
plementatie van andere interfaces (bijvoorbeeld via de CAN-bus) om de 
gegevens van de voertuigunit (VU) naar de verwerkingseenheden van 
andere voertuigen te verzenden.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 451  
Dit aanhangsel bevat specificaties met betrekking tot:  
— de gegevens die beschikbaar zijn via de ITS-interface;  
— het Bluetooth®-profiel dat wordt gebruikt om de gegevens over te 
brengen;  
— de opvraag- en downloadprocedures en de volgorde van bewerkingen;  
— het koppelingsmechanisme tussen de tachograaf en het externe appa ­
raat; 
— het toestemmingsmechanisme waarover de bestuurder beschikt.  
▼M1 
Voor alle duidelijkheid: dit aanhangsel bevat  geen specificaties met be ­
trekking tot:  
— de verzameling van  de gegevens  met het oog op de werking en het 
beheer in de VU (deze wordt elders in  de verordening  gespecificeerd 
of hangt af van het productontwerp);  
— de aanbiedingsvorm van de verzamelde gegevens aan de toepassing op 
het externe apparaat;  
— de bepalingen inzake gegevensbeveiliging die verder gaan dan hetgeen 
waarin Bluetooth® voorziet (zoals codering) met betrekking tot de 
inhoud van  de gegevens  (die elders in  de verordening  worden gespe ­
cificeerd [aanhangsel 11 „Algemene beveiligingsmechanismen”]);  
— de door de ITS-interface gebruikte Bluetooth®-protocollen.  
▼B 
2.1. Acroniemen, definities en notaties  
In dit aanhangsel worden de volgende acroniemen en definities gebruikt in 
de daarachter vermelde betekenis:  
communicatie  uitwisseling van informatie/gegevens tussen een 
hoofdunit (dat wil zeggen de tachograaf) en een 
externe unit via de ITS-interface met gebruik ­
making van Bluetooth®;  
gegevens  de in bijlage 1 gespecificeerde datasets;  
tachograafverordening  Verordening (EU) nr. 165/2014 van het Euro ­
pees Parlement en van de Raad van 4 februari 
2014 betreffende tachografen in het wegvervoer, 
tot intrekking van Verordening (EEG) nr. 
3821/85 van de Raad betreffende het contro ­
leapparaat in het wegvervoer en tot wijziging 
van Verordening (EG) nr. 561/2006 van het 
Europees Parlement en de Raad tot harmonisatie 
van bepaalde voorschriften van sociale aard 
voor het wegvervoer;  
BR Basissnelheid  
EDR  Verhoogde gegevenssnelheid  
GNSS  Wereldwijd satellietnavigatiesysteem  
IRK  Sleutel ter vaststelling van de identiteit  
ITS Intelligent vervoerssysteem  
LE Lage energie  
PIN Persoonlijk identificatienummer (pincode)  
PUC  Persoonlijke ontgrendelingscode  
SID Identificator van de dienst  
SPP Serieel poortprofiel  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 452  
SSP Secure Simple Pairing  
TRTP  Overdrachtparameter verzoek  
TREP  Overdrachtparameter antwoord  
VU Voertuigunit  
3. REFERENTIEVERORDENINGEN EN -NORMEN  
De in dit aanhangsel vastgestelde specificatie verwijst naar en wordt ge ­
regeld door de hierna genoemde verordeningen en normen of gedeelten 
daarvan. In de bepalingen van dit aanhangsel wordt uitdrukkelijk aange ­
geven welke normen of clausules daarvan toepassing vinden. In geval van 
tegenstrijdigheid prevaleren de bepalingen in dit aanhangsel.  
In dit aanhangsel wordt verwezen naar de volgende verordeningen en 
normen:  
— Verordening (EU) nr. 165/2014 van het Europees Parlement en van de 
Raad van 4 februari 2014 betreffende tachografen in het wegvervoer, 
tot intrekking van Verordening (EEG) nr. 3821/85 van de Raad be ­
treffende het controleapparaat in het wegvervoer en tot wijziging van 
Verordening (EG) nr. 561/2006 van het Europees Parlement en de 
Raad tot harmonisatie van bepaalde voorschriften van sociale aard 
voor het wegvervoer  
— Verordening (EG) nr. 561/2006 van het Europees Parlement en de 
Raad van 15 maart 2006 tot harmonisatie van bepaalde voorschriften 
van sociale aard voor het wegvervoer, tot wijziging van Verordeningen 
(EEG) nr. 3821/85 en (EG) nr. 2135/98 van de Raad en tot intrekking 
van Verordening (EEG) nr. 3820/85 van de Raad  
— ISO 16844 — 4: Road vehicles — Tachograph systems — Part 4: 
CAN interface  
— ISO 16844 — 7: Road vehicles — Tachograph systems — Part 7: 
Parameters  
— Bluetooth® — Serial Port Profile — V1.2  
— Bluetooth®– Core Version 4.2  
— NMEA 0183 V4.1-protocol  
4. WERKINGSBEGINSELEN VAN DE INTERFACE  
4.1. Eerste vereisten voor gegevensoverdracht via de ITS-interface  
De VU dient de gegevens die in de VU moeten worden opgeslagen, te 
actualiseren en bij te houden zonder tussenkomst van de ITS-interface. De 
daartoe gebruikte middelen hangen af van het interne ontwerp van de VU, 
zoals elders gespecificeerd in de tachograafverordening, en worden niet 
nader gespecificeerd in dit aanhangsel.  
4.1.1  Via de ITS-interface beschikbaar gestelde gegevens  
De VU dient de via de ITS-interface beschikbaar gestelde gegevens te 
actualiseren met een regelmaat die in de VU-procedures wordt vastgesteld, 
zonder tussenkomst van de ITS-interface. De VU-gegevens worden ge ­
bruikt als uitgangspunt voor het samenstellen en actualiseren van de ge ­
gevens. De daartoe gebruikte middelen worden elders in de tachograafver ­
ordening gespecificeerd; bij gebrek aan ter zake dienende specificaties 
hangen deze middelen af van het productontwerp en worden zij niet nader 
omschreven in dit aanhangsel.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 453  
4.1.2  Gegevensinhoud  
De gegevensinhoud wordt nader omschreven in bijlage 1 bij dit aanhang ­
sel. 
4.1.3  ITS-toepassingen  
De via de ITS-interface beschikbaar gestelde gegevens worden gebruikt 
door ITS-toepassingen, bijvoorbeeld om de activiteiten van de bestuurder 
optimaal te beheren met inachtneming van de tachograafverordening, om 
eventuele fouten in de tachograaf op te sporen of om de GNSS-gegevens 
te gebruiken. De specificatie van deze toepassingen valt buiten het toe ­
passingsgebied van dit aanhangsel.  
4.2. Communicatietechnologie  
De gegevens worden door middel van de ITS-interface uitgewisseld via 
een compatibele Bluetooth®-interface van versie 4.2 of hoger. Bluetooth® 
werkt in een licentievrije frequentieband voor industriële, wetenschappelijk 
en medische doeleinden (ISM-band) van 2,4 tot en met 2,485 GHz. Blu ­
etooth® 4.2 biedt niet alleen verbeterde mechanismen voor informatiebe ­
veiliging en privacybescherming, maar verhoogt ook de snelheid en be ­
trouwbaarheid van de gegevensoverdracht. Ten behoeve van deze specifi ­
catie wordt Bluetooth® klasse 2-radioapparatuur gebruikt met een bereik 
tot 10 m. Meer informatie over Bluetooth® 4.2 is te vinden op www.Blu ­
etooth.com (https://www.Bluetooth.org/en-us/specification/adopted-specifi ­
cations?_ga=1.215147412.2083380574.1435305676).  
De communicatie wordt tot stand gebracht door middel van de communi ­
catieapparatuur na voltooiing van een koppelingsprocedure met een goed ­
gekeurd apparaat. Bluetooth® gebruikt een master-slavemodel om te con ­
troleren wanneer en waar apparaten gegevens kunnen verzenden. Bij ­
gevolg vervult de tachograaf de rol van  master  en het externe apparaat 
die van  slave . 
▼M1 
Wanneer een extern apparaat voor het eerst binnen het bereik van de VU 
komt, kan de Bluetooth®-koppelingsprocedure worden gestart (zie ook 
bijlage 2). Beide apparaten wisselen hun adressen, namen en profielen 
uit en delen een gemeenschappelijke geheime sleutel, waardoor ze nadien 
automatisch verbinding met elkaar kunnen maken. Na deze stap wordt het 
externe apparaat vertrouwd en kan dit verzoeken initiëren om gegevens 
van de tachograaf te downloaden. Het is niet de bedoeling coderings ­
mechanismen in te voeren die verder gaan dan hetgeen waarin Bluetooth® 
voorziet. Indien aanvullende beveiligingsmechanismen noodzakelijk zijn, 
worden die ingevoerd overeenkomstig aanhangsel 11 Algemene beveili ­
gingsmechanismen.  
▼B 
De communicatie verloopt in principe zoals aangegeven in de onder ­
staande figuur:
  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 454  
Het seriële poortprofiel (SPP) van Bluetooth® wordt gebruikt om gege ­
vens van de VU over te brengen naar het externe apparaat.  
4.3. Pincodeverificatie  
▼M1 
Om veiligheidsredenen vereist de VU een systeem voor pincodeverificatie 
dat losstaat van de Bluetooth-koppelingsprocedure. Elke VU kan voor 
authenticatiedoeleinden pincodes genereren die ten minste uit vier cijfers 
bestaan. Een extern apparaat dat aan de VU wordt gekoppeld, kan pas 
gegevens ontvangen nadat een juiste pincode is opgegeven.  
▼B 
Na het invoeren van de juiste pincode wordt het apparaat op de witte lijst 
geplaatst. De witte lijst bevat ten minste 64 apparaten die aan de speci ­
fieke VU werden gekoppeld.  
Na drie opeenvolgende mislukte pogingen om de juiste pincode in te 
voeren, wordt het apparaat tijdelijk op de zwarte lijst geplaatst. Zolang 
het apparaat op de zwarte lijst staat, wordt elke toegangspoging gewei ­
gerd. Na nogmaals drie opeenvolgende mislukte pogingen om de juiste 
pincode in te voeren, wordt het apparaat voor langere tijd geblokkeerd (zie 
tabel 1). Zodra de juiste pincode wordt ingevoerd, worden de blokkerings ­
tijd en het aantal pogingen opnieuw ingesteld. In figuur 1 van bijlage 2 
staat een overzicht van de blokkeringstijd als functie van het aantal mis ­
lukte invoerpogingen van de pincode.  
Tabel 1  
Blokkeringstijd als functie van het aantal mislukte invoerpogingen 
van de pincode  
Aantal mislukte invoerpogingen  Blokkeringstijd  
3 30 seconden  
6 5 minuten  
9 1 uur  
12 24 uur  
15 Voor onbepaalde tijd  
Na vijftien (vijf keer drie) opeenvolgende mislukte pogingen om de juiste 
pincode in te voeren, wordt de ITS-unit voor onbepaalde tijd op de zwarte 
lijst geplaatst. Deze blokkering voor onbepaalde tijd kan uitsluitend wor ­
den opgeheven door de correcte PUC-code in te voeren.  
Deze achtcijferige PUC-code wordt door de fabrikant geleverd bij de VU. 
Na tien opeenvolgende mislukte pogingen om de juiste PUC-code in te 
voeren, wordt de ITS-unit voorgoed op de zwarte lijst geplaatst.  
▼M1 
De PUC-code kan niet worden gewijzigd, ook al biedt de fabrikant de 
mogelijkheid om de pincode rechtstreeks te wijzigen via de VU. Om de 
pincode in voorkomend geval te wijzigen, moet de huidige pincode recht ­
streeks in de VU worden ingevoerd.  
▼B 
Bovendien blijven alle apparaten op de witte lijst staan totdat de gebruiker 
ze handmatig verwijdert (bijvoorbeeld via de mens-machine-interface van 
de VU of op een andere wijze). Dit maakt het mogelijk om bij verlies of 
diefstal ITS-units uit de witte lijst te verwijderen. Elke ITS-unit die zich 
langer dan vierentwintig uur buiten het bereik van de Bluetooth®-ver ­
binding bevindt, wordt automatisch uit de witte lijst van de VU verwijderd 
en moet opnieuw de juiste pincode invoeren om verbinding te maken.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 455  
Het formaat van de tussen de VU-interface en de VU uitgewisselde be ­
richten is niet vastgelegd, maar wordt overgelaten aan de fabrikant. Niet ­
temin moet de fabrikant ervoor zorgen dat het formaat voor de berichte ­
nuitwisseling tussen de ITS-unit en de VU-interface in acht wordt ge ­
nomen (zie ASN.1-specificaties).  
Bijgevolg mag aan een verzoek om gegevensoverdracht pas gevolg wor ­
den gegeven nadat de verzender eenduidig is geïdentificeerd. Deze pro ­
cedure wordt verduidelijkt in figuur 2 van bijlage 2. Elke verbindings ­
poging van een apparaat dat op de zwarte lijst staat, wordt automatisch 
geweigerd; voor apparaten die noch op de zwarte lijst, noch op de witte 
lijst zijn geplaatst, moet een juiste pincode worden ingevoerd voordat het 
verzoek om gegevensoverdracht wordt verzonden.  
4.4. Berichtformaat  
Alle tussen de ITS-unit en de VU-interface uitgewisselde berichten zijn 
opgemaakt volgens een uit drie delen bestaande structuur: een koptitel 
(“header”) bestaande uit een doelbyte (TGT), een bronbyte (SRC) en 
mogelijk een lengtebyte (LEN);  
het gegevensveld bestaande uit een identificatiebyte van de dienst (SID) 
en een variabel aantal gegevensbytes (ten hoogste 255);  
de controlesombyte (CS), zijnde de 1-bits somserie module 256 van alle 
bytes van het bericht exclusief de CS zelf.  
Het bericht staat in de bytevolgorde “Big Endian”.  
Tabel 2  
Algemeen berichtformaat  
Header  Gegevensveld  Controlesom  
TGT  SRC  LEN  SID  TRTP  CC  CM  DATA  CS  
3 bytes  Max. 255 bytes  1 byte  
Header  
TGT- en SRC-byte: de identificatie (ID) van het doelapparaat (TGT) en 
het bronapparaat (SRC) van het bericht. De ID van de VU-interface is 
standaard ingesteld op “EE”. Deze ID kan niet worden gewijzigd. De ITS- 
unit gebruikt de standaardidentificatie “A0” voor het eerste bericht van de 
communicatiesessie. De VU-interface wijst dan een unieke ID toe aan de 
ITS-unit en geeft deze ID door aan de ITS-unit voor toekomstige berichten 
tijdens de sessie.  
De lengtebyte (LEN) houdt uitsluitend rekening met het “DATA”-onder ­
deel van het gegevensveld (zie tabel 2); de eerste vier bytes zijn impliciet.  
De VU-interface bevestigt de authenticiteit van de verzender van het 
bericht door de eigen lijst van ID's te vergelijken met de Bluetooth®- 
gegevens. Daarbij wordt nagegaan of de ITS-unit die voor de opgegeven 
ID in de lijst staat, zich binnen het bereik van de Bluetooth®-verbinding 
bevindt.  
Gegevensveld  
Naast de identificator van de dienst (SID) bevat het gegevensveld ook 
andere parameters: een overdrachtparameterbyte (TRTP) en tellerbytes.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 456  
Indien de te verwerken gegevens te groot zijn voor de beschikbare ruimte 
van één bericht, wordt het bericht opgesplitst in meerdere subberichten. 
Elk subbericht bevat dezelfde header en SID, maar heeft ook een teller 
van 2 bytes, te weten de teller van het huidige subberichtnummer (CC — 
Counter Current) en de teller van het maximumaantal subberichten (CM 
— Counter Max), om het subberichtnummer aan te geven. Met het oog op 
foutencontrole en voortijdige beëindiging van de overdracht bevestigt de 
ontvanger elk subbericht. De ontvanger kan het subbericht accepteren, 
vragen om het opnieuw te zenden, de verzender verzoeken om opnieuw 
te beginnen of de overdracht voortijdig beëindigen.  
▼B 
Indien de tellers CC en CM niet worden gebruikt, wordt de waarde ervan 
ingesteld op “0xFF”.  
Zo wordt bijvoorbeeld het volgende bericht:  
HEADER  SID  TRTP  CC  CM  DATA  CS  
3 bytes  Langer dan 255 bytes  1 byte  
overgebracht als:  
HEADER  SID  TRTP  01  n  DATA  CS  
3 bytes  255 bytes  1 byte  
HEADER  SID  TRTP  02  n  DATA  CS  
3 bytes  255 bytes  1 byte  
… 
HEADER  SID  TRTP  N  N  DATA  CS  
3 bytes  Max. 255 bytes  1 byte  
In tabel 3 staan de berichten die de VU en de ITS-unit met elkaar kunnen 
uitwisselen. De inhoud van elke parameter wordt in hexadecimale notatie 
voorgesteld. Duidelijkheidshalve worden de tellers CC en CM in deze 
tabel niet getoond (zie hierboven voor het volledige formaat).  
Tabel 3  
Gedetailleerde berichtinhoud  
Bericht  Header  DATA  Controle­
som 
TGT  SRC  LEN  SID  TRTP  DATA  
RequestPIN  ITSID  EE  00  01  FF  
SendITSID  ITSID  EE  01  02  FF  ITSID  
SendPIN  EE  ITSID  04  03  FF  4*INTEGER (0..9)  
PairingResult  ITSID  EE  01  04  FF  BOOLEAN (T/F)  
SendPUC  EE  ITSID  08  05  FF  8*INTEGER (0..9)  ▼M1
 02016R0799 — NL — 26.02.2020 — 002.001 — 457  
Bericht  Header  DATA  Controle­
som 
TGT  SRC  LEN  SID  TRTP  DATA  
BanLiftingResult  ITSID  EE  01  06  FF  BOOLEAN (T/F)  
RequestRejected  ITSID  EE  08  07  FF  Tijd  
RequestData  
standardTachData  EE  ITSID  01  08  01  
personalTachData  EE  ITSID  01  08  02  
gnssData  EE  ITSID  01  08  03  
standardEventData  EE  ITSID  01  08  04  
personalEventData  EE  ITSID  01  08  05  
standardFaultData  EE  ITSID  01  08  06  
manufacturerData  EE  ITSID  01  08  07  
ResquestAccepted  ITSID  EE  Len  09  TREP  Gegevens  
DataUnavailable  
Geen gegevens  ITSID  EE  02  0A  TREP  10  
Persoonsgegevens 
niet gedeeld  ITSID  EE  02  0A  TREP  11  
NegativeAnswer  
Algemene verwer ­
ping ITSID  EE  02  0B  SID Req  10  
Dienst niet onder ­
steund  ITSID  EE  02  0B  SID Req  11  
Subfunctie niet 
ondersteund  ITSID  EE  02  0B  SID Req  12  
Onjuiste bericht ­
lengte  ITSID  EE  02  0B  SID Req  13  
Voorwaarden niet 
correct of ver ­
zoeksequentiefout  ITSID  EE  02  0B  SID Req  22  
Verzoek buiten 
bereik  ITSID  EE  02  0B  SID Req  31  
Antwoord in be ­
handeling  ITSID  EE  02  0B  SID Req  78  
ITSID komt niet 
overeen  ITSID  EE  02  0B  SID Req  FC  
ITSID niet gevon ­
den ITSID  EE  02  0B  SID Req  FB  
RequestPIN (SID 01)  
Dit bericht wordt door de VU-interface verstrekt als antwoord op een 
verzoek om gegevensoverdracht van een ITS-unit die noch op de zwarte 
lijst, noch op de witte lijst is geplaatst.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 458  
SendITSID (SID 02)  
Dit bericht wordt door de VU-interface verstrekt telkens wanneer een 
nieuw apparaat een verzoek verzendt. Dit apparaat gebruikt de standaar ­
didentificatie “A0” voordat het een unieke ID voor de communicatiesessie 
toegewezen krijgt.  
SendPIN (SID 03)  
Dit bericht wordt door de ITS-unit verstrekt om op de witte lijst te worden 
geplaatst door de VU-interface. De inhoud van dit bericht is een geheel 
getal (“INTEGER”) met vier cijfers tussen 0 en 9.  
PairingResult (SID 04)  
Dit bericht wordt door de VU-interface verstrekt om de ITS-unit op de 
hoogte te brengen van het resultaat van de pincodeverificatie. De inhoud 
van dit bericht is een Booleaanse operator (“BOOLEAN”) met de waarde 
“True” (waar) voor een juiste pincode en de waarde “False” (onwaar) in 
het tegenovergestelde geval.  
SendPUC (SID 05)  
Dit bericht wordt door de ITS-unit verstrekt ter opheffing van een blok ­
kering die het gevolg is van de plaatsing op de zwarte lijst door de VU- 
interface. De inhoud van dit bericht is een geheel getal (“INTEGER”) met 
acht cijfers tussen 0 en 9.  
BanLiftingResult (SID 06)  
Dit bericht wordt door de VU-interface verstrekt om de ITS-unit te melden 
of de juiste PUC-code werd opgegeven ter opheffing van de blokkering. 
De inhoud van dit bericht is een Booleaanse operator (“BOOLEAN”) met 
de waarde “T(rue)” (waar) voor een correcte PUC-code en de waarde 
“F(alse)” (onwaar) in het tegenovergestelde geval.  
RequestRejected (SID 07)  
Dit bericht wordt door de VU-interface verstrekt als antwoord op elk 
bericht van een op de zwarte lijst geplaatste ITS-unit, met uitzondering 
van het bericht “SendPUC”. In het bericht staat hoelang de ITS-unit nog 
op de zwarte lijst is geplaatst (resterende blokkeringstijd), volgens het in 
bijlage 3 vastgestelde tijdreeksformaat “Time”.  
RequestData (SID 08)  
Dit bericht voor gegevenstoegang wordt verstrekt door de ITS-unit. Een 
overdrachtparameter verzoek (TRTP) van één byte geeft het type van de 
opgevraagde gegevens aan. Er zijn verschillende gegevenstypen:  
— standardTachData (TRTP 01): beschikbare tachograafgegevens die als 
niet-persoonsgebonden worden aangemerkt.  
— personalTachData (TRTP 02): beschikbare tachograafgegevens die als 
persoonsgebonden worden aangemerkt.  
— gnssData (TRTP 03): GNSS-gegevens, die altijd als persoonsgebonden 
worden aangemerkt.  
— standardEventData (TRTP 04): geregistreerde voorvalgegevens die als 
niet-persoonsgebonden worden aangemerkt.  
— personalEventData (TRTP 05): geregistreerde voorvalgegevens die als 
persoonsgebonden worden aangemerkt.  
— standardFaultData (TRTP 06): geregistreerde foutgegevens die als niet- 
persoonsgebonden worden aangemerkt.  
— manufacturerData (TRTP 07): door de fabrikant beschikbaar gestelde 
gegevens.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 459  
Zie bijlage 3 van dit aanhangsel voor meer informatie over de inhoud van 
elk gegevenstype.  
Zie aanhangsel 12 voor meer informatie over het formaat en de inhoud 
van GNSS-gegevens.  
Zie bijlagen I B en I C voor meer informatie over voorval- en foutgege ­
vens.  
ResquestAccepted (SID 09)  
Dit bericht wordt door de VU-interface verstrekt indien een bericht “Re ­
questData” van de ITS-unit werd geaccepteerd. Dit bericht bevat een 
overdrachtparameter antwoord (TREP) van één byte, die correspondeert 
met de overdrachtparameter verzoek (TRTP) van het bijbehorende bericht 
“RequestData”, alsook alle gegevens van het opgevraagde type.  
DataUnavailable (SID 0A)  
Dit bericht wordt door de VU-interface verstrekt indien de opgevraagde 
gegevens om een bepaalde reden niet beschikbaar zijn voor verzending 
naar een op de witte lijst geplaatste ITS-unit. Dit bericht bevat een over ­
drachtparameter antwoord (TREP) van één byte, die correspondeert met de 
overdrachtparameter verzoek (TRTP) van de opgevraagde gegevens, en 
een in tabel 3 gespecificeerde foutcode van één byte. De onderstaande 
codes zijn beschikbaar:  
— Geen gegevens beschikbaar (10): de VU-interface heeft om niet nader 
bepaalde redenen geen toegang tot de VU-gegevens.  
— Persoonsgegevens niet gedeeld (11): de ITS-unit probeert persoons ­
gegevens op te halen terwijl die niet worden gedeeld.  
NegativeAnswer (SID 0B)  
Deze berichten worden door de VU-interface verstrekt indien het verzoek 
niet kan worden afgehandeld om een andere reden dan de niet-beschik ­
baarheid van de gegevens. Deze berichten zijn doorgaans — maar niet 
altijd — het gevolg van een ongeldig formaat van het verzoek (lengte, 
SID, ITSID enz.). De overdrachtparameter verzoek (TRTP) in het gege ­
vensveld bevat de SID van het verzoek. Het gegevensveld bevat de code 
die de reden van het negatieve antwoord specificeert. De onderstaande 
codes zijn beschikbaar:  
— Algemene verwerping (code 10)  
— De actie kan niet worden uitgevoerd om een reden die niet wordt 
genoemd hieronder, noch in punt (vul het nummer van het punt in  
DataUnavailable  in). 
— Dienst niet ondersteund (code 11)  
— De SID van het verzoek wordt niet herkend.  
— Subfunctie niet ondersteund (code 12)  
— De overdrachtparameter verzoek (TRTP) wordt niet herkend, bijvoor ­
beeld omdat die ontbreekt of ongeldig is.  
— Onjuiste berichtlengte (code 13)  
— De lengte van het ontvangen bericht is onjuist (de LEN-byte stemt niet 
overeen met de werkelijke berichtlengte).  
— Voorwaarden niet correct of verzoeksequentiefout (code 22)  
— De gevraagde dienst is niet actief of de sequentie van verzoekberichten 
is niet correct.  
— Verzoek buiten bereik (code 33)  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 460  
— De parameterrecord van het verzoek (gegevensveld) is niet geldig.  
— Antwoord in behandeling (code 78)  
— De verzochte actie kan niet op tijd worden beëindigd en de VU is niet 
klaar om een ander verzoek te accepteren.  
— ITSID  komt niet overeen (code FB)  
— Uit de vergelijking met de Bluetooth®-informatie blijkt dat de SRC  
ITSID  niet overeenkomt met het aangesloten apparaat.  
— ITSID  niet gevonden (code FC)  
— Geen enkel apparaat is verbonden aan de SRC  ITSID . 
De regels 1 tot en met 72 ( FormatMessageModule ) van de ASN.1-code 
in bijlage 3 specificeren het berichtformaat, zoals verduidelijkt in tabel 3. 
De berichtinhoud wordt hieronder nader toegelicht.  
4.5. Toestemming van de bestuurder  
Alle beschikbare gegevens worden als standaardgegevens dan wel als 
persoonsgegevens aangemerkt. Er wordt alleen toegang verschaft tot per ­
soonsgegevens indien de bestuurder daarin heeft toegestemd door te ver ­
klaren dat zijn via de tachograaf beschikbare persoonsgegevens buiten het 
communicatienetwerk van het voertuig mogen worden gebruikt door derde 
toepassingen.  
Die toestemming wordt verleend op het ogenblik dat een voor de voer ­
tuigunit onbekende bestuurders- of werkplaatskaart voor het eerst wordt 
ingebracht en de kaarthouder wordt gevraagd erin toe te stemmen dat zijn 
aan de tachograaf gerelateerde persoonsgegevens toegankelijk worden ge ­
maakt via de facultatieve ITS-interface (zie ook bijlage I C, punt 3.6.2).  
De status van de toestemming (actief/inactief) wordt geregistreerd in het 
geheugen van de tachograaf.  
Indien er meerdere bestuurders zijn, worden alleen de persoonsgegevens 
van de bestuurders die hierin hebben toegestemd, gedeeld met de ITS- 
interface. Indien er bijvoorbeeld twee bestuurders in het voertuig aanwezig 
zijn en alleen de eerste bestuurder heeft erin toegestemd dat zijn persoons ­
gegevens worden gedeeld, worden de persoonsgegevens van de tweede 
bestuurder niet gedeeld.  
4.6. Standaardgegevens opvragen  
In figuur 3 van bijlage 2 staat een stroomschema van een geldig verzoek 
dat door de ITS-unit wordt verzonden om toegang te krijgen tot standaard ­
gegevens. Aangezien de ITS-unit op de witte lijst staat en geen persoons ­
gegevens opvraagt, is geen verdere controle nodig. In dit stroomschema 
wordt ervan uitgegaan dat de gepaste procedure, zoals verduidelijkt in 
figuur 2 van bijlage 2, is nageleefd. Dit stroomschema is te vergelijken 
met het grijs gearceerde vak “REQUEST TREATMENT” in figuur 2.  
Van de beschikbare gegevens worden als standaardgegevens aangemerkt:  
— standardTachData (TRTP 01)  
— StandardEventData (TRTP 04)  
— standardFaultData (TRTP 06)  
4.7. Persoonsgegevens opvragen  
In figuur 4 van bijlage 2 staat het stroomschema voor de behandeling van 
een verzoek om persoonsgegevens. Zoals eerder aangegeven, worden per ­
soonsgegevens uitsluitend via de VU-interface verzonden indien de be ­
stuurder uitdrukkelijk daarin heeft toegestemd (zie ook punt 4.5). Zo niet, 
moet het verzoek automatisch worden verworpen.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 461  
Van de beschikbare gegevens worden als persoonsgegevens aangemerkt:  
— personalTachData (TRTP 02)  
— gnssData (TRTP 03)  
— personalEventData (TRTP 05)  
— manufacturerData (TRTP 07)  
4.8. Fout- en voorvalgegevens opvragen  
De ITS-units kunnen voorvalgegevens opvragen in de vorm van een lijst 
van alle onverwachte voorvallen. Deze gegevens worden als standaard ­
gegevens dan wel als persoonsgegevens aangemerkt (zie bijlage 3). De 
inhoud van elk voorval stemt overeen met de documentatie in bijlage 1 
van dit aanhangsel.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 462  
BIJLAGE 1  
▼M1 
1. LIJST VAN VIA DE ITS-INTERFACE BESCHIKBARE GEGEVENS  
▼C2 
Gegevens  Bron  Gegevensclassificatie 
(persoonlijk/niet 
persoonlijk)  
VehicleIdentificationNumber  Voertuigunit  niet persoonlijk  
CalibrationDate  Voertuigunit  niet persoonlijk  
TachographVehicleSpeed speed instant t  Voertuigunit  persoonlijk  
Driver1WorkingState Selector driver  Voertuigunit  persoonlijk  
Driver2WorkingState  Voertuigunit  persoonlijk  
DriveRecognize Speed Threshold detected  Voertuigunit  niet persoonlijk  
Driver1TimeRelatedStates Weekly day time  Bestuurderskaart  persoonlijk  
Driver2TimeRelatedStates  Bestuurderskaart  persoonlijk  
DriverCardDriver1  Voertuigunit  niet persoonlijk  
DriverCardDriver2  Voertuigunit  niet persoonlijk  
OverSpeed  Voertuigunit  persoonlijk  
TimeDate  Voertuigunit  niet persoonlijk  
HighResolutionTotalVehicleDistance  Voertuigunit  niet persoonlijk  
ServiceComponentIdentification  Voertuigunit  niet persoonlijk  
ServiceDelayCalendarTimeBased  Voertuigunit  niet persoonlijk  
Driver1Identification  Bestuurderskaart  persoonlijk  
Driver2Identification  Bestuurderskaart  persoonlijk  
NextCalibrationDate  Voertuigunit  niet persoonlijk  
Driver1ContinuousDrivingTime  Bestuurderskaart  persoonlijk  
Driver2ContinuousDrivingTime  Bestuurderskaart  persoonlijk  
Driver1CumulativeBreakTime  Bestuurderskaart  persoonlijk  
Driver2CumulativeBreakTime  Bestuurderskaart  persoonlijk  
Driver1CurrentDurationOfSelectedActivity  Bestuurderskaart  persoonlijk  
Driver2CurrentDurationOfSelectedActivity  Bestuurderskaart  persoonlijk  
SpeedAuthorised  Voertuigunit  niet persoonlijk  
TachographCardSlot1  Bestuurderskaart  niet persoonlijk  
TachographCardSlot2  Bestuurderskaart  niet persoonlijk  
Driver1Name  Bestuurderskaart  persoonlijk  
Driver2Name  Bestuurderskaart  persoonlijk  ▼C2
 02016R0799 — NL — 26.02.2020 — 002.001 — 463  
Gegevens  Bron  Gegevensclassificatie 
(persoonlijk/niet 
persoonlijk)  
OutOfScopeCondition  Voertuigunit  niet persoonlijk  
ModeOfOperation  Voertuigunit  niet persoonlijk  
Driver1CumulatedDrivingTimePreviousAndCur ­
rentWeek  Bestuurderskaart  persoonlijk  
Driver2CumulatedDrivingTimePreviousAndCur ­
rentWeek  Bestuurderskaart  persoonlijk  
EngineSpeed  Voertuigunit  persoonlijk  
RegisteringMemberState  Voertuigunit  niet persoonlijk  
VehicleRegistrationNumber  Voertuigunit  niet persoonlijk  
Driver1EndOfLastDailyRestPeriod  Bestuurderskaart  persoonlijk  
Driver2EndOfLastDailyRestPeriod  Bestuurderskaart  persoonlijk  
Driver1EndOfLastWeeklyRestPeriod  Bestuurderskaart  persoonlijk  
Driver2EndOfLastWeeklyRestPeriod  Bestuurderskaart  persoonlijk  
Driver1EndOfSecondLastWeeklyRestPeriod  Bestuurderskaart  persoonlijk  
Driver2EndOfSecondLastWeeklyRestPeriod  Bestuurderskaart  persoonlijk  
Driver1CurrentDailyDrivingTime  Bestuurderskaart  persoonlijk  
Driver2CurrentDailyDrivingTime  Bestuurderskaart  persoonlijk  
Driver1CurrentWeeklyDrivingTime  Bestuurderskaart  persoonlijk  
Driver2CurrentWeeklyDrivingTime  Bestuurderskaart  persoonlijk  
Driver1TimeLeftUntilNewDailyRestPeriod  Bestuurderskaart  persoonlijk  
Driver2TimeLeftUntilNewDailyRestPeriod  Bestuurderskaart  persoonlijk  
Driver1CardExpiryDate  Bestuurderskaart  persoonlijk  
Driver2CardExpiryDate  Bestuurderskaart  persoonlijk  
Driver1CardNextMandatoryDownloadDate  Bestuurderskaart  persoonlijk  
Driver2CardNextMandatoryDownloadDate  Bestuurderskaart  persoonlijk  
TachographNextMandatoryDownloadDate  Voertuigunit  niet persoonlijk  
Driver1TimeLeftUntilNewWeeklyRestPeriod  Bestuurderskaart  persoonlijk  
Driver2TimeLeftUntilNewWeeklyRestPeriod  Bestuurderskaart  persoonlijk  
Driver1NumberOfTimes9hDailyDrivingTimesEx ­
ceeded  Bestuurderskaart  persoonlijk  
Driver2NumberOfTimes9hDailyDrivingTimesEx ­
ceeced  Bestuurderskaart  persoonlijk  ▼C2
 02016R0799 — NL — 26.02.2020 — 002.001 — 464  
Gegevens  Bron  Gegevensclassificatie 
(persoonlijk/niet 
persoonlijk)  
Driver1CumulativeUninterruptedRestTime  Bestuurderskaart  persoonlijk  
Driver2CumulativeUninterruptedRestTime  Bestuurderskaart  persoonlijk  
Driver1MinimumDailyRest  Bestuurderskaart  persoonlijk  
Driver2MinimumDailyRest  Bestuurderskaart  persoonlijk  
Driver1MinimumWeeklyRest  Bestuurderskaart  persoonlijk  
Driver2MinimumWeeklyRest  Bestuurderskaart  persoonlijk  
Driver1MaximumDailyPeriod  Bestuurderskaart  persoonlijk  
Driver2MaximumDailyPeriod  Bestuurderskaart  persoonlijk  
Driver1MaximumDailyDrivingTime  Bestuurderskaart  persoonlijk  
Driver2MaximumDailyDrivingTime  Bestuurderskaart  persoonlijk  
Driver1NumberOfUsedReducedDailyRestPeriods  Bestuurderskaart  persoonlijk  
Driver2NumberOfUsedReducedDailyRestPeriods  Bestuurderskaart  persoonlijk  
Driver1RemainingCurrentDrivingTime  Bestuurderskaart  persoonlijk  
Driver2RemainingCurrentDrivingTime  Bestuurderskaart  persoonlijk  
GNSS position  Voertuigunit  persoonlijk  
▼B 
2. GNSS-GEGEVENS DIE CONTINU BESCHIKBAAR ZIJN MET TOE ­
STEMMING VAN DE BESTUURDER  
Zie Aanhangsel 12 „GNSS”.  
3. VOORVALGEGEVENS DIE BESCHIKBAAR ZIJN ZONDER TOESTEM ­
MING VAN DE BESTUURDER  
Voorval  Opslagregels  Te registreren gegevens per voorval  
Inbrengen van een ongeldige 
kaart  — de 10 meest recente voorvallen  — datum en tijd van het voorval 
— kaartsoort, kaartnummer, lidstaat van af ­
gifte en generatie van de kaart die het 
voorval veroorzaakt 
— aantal vergelijkbare voorvallen op die dag  
Kaartconflict  — de 10 meest recente voorvallen  — datum en tijd van het begin van het voorval 
— datum en tijd van het einde van het voorval 
— kaartsoort, kaartnummer, lidstaat van af ­
gifte en generatie van de twee kaarten die 
het conflict veroorzaken  
Laatste kaartsessie niet cor ­
rect afgesloten  — de 10 meest recente voorvallen  — datum en tijd van kaartinbrenging 
— kaartsoort, kaartnummer, lidstaat van af ­
gifte en generatie van de kaart die het 
voorval veroorzaakt 
— laatste sessiegegevens zoals af te lezen van 
de kaart: 
— datum en tijd van kaartinbrenging 
— kentekennummer van het voertuig, lid ­
staat van registratie en generatie van de 
VU ▼C2
 02016R0799 — NL — 26.02.2020 — 002.001 — 465  
Voorval  Opslagregels  Te registreren gegevens per voorval  
Onderbreking in de stroom ­
voorziening (2)  — het langste voorval op elk van de 
laatste 10 dagen waarop een der ­
gelijk voorval is opgetreden 
— de 5 langste voorvallen gedu ­
rende de afgelopen 365 dagen  — datum en tijd van het begin van het voorval 
— datum en tijd van het einde van het voorval 
— kaartsoort, kaartnummer, lidstaat van af ­
gifte en generatie van de kaart die bij het 
begin en/of einde van het voorval is in ­
gebracht 
— aantal vergelijkbare voorvallen op die dag  
Fout in communicatie met de 
inrichting voor communicatie 
op afstand  — het langste voorval op elk van de 
laatste 10 dagen waarop een der ­
gelijk voorval is opgetreden 
— de 5 langste voorvallen gedu ­
rende de afgelopen 365 dagen  — datum en tijd van het begin van het voorval 
— datum en tijd van het einde van het voorval 
— kaartsoort, kaartnummer, lidstaat van af ­
gifte en generatie van de kaart die bij het 
begin en/of einde van het voorval is in ­
gebracht 
— aantal vergelijkbare voorvallen op die dag  
Afwezigheid van positie-in ­
formatie van de GNSS-ont ­
vanger  — het langste voorval op elk van de 
laatste 10 dagen waarop een der ­
gelijk voorval is opgetreden 
— de 5 langste voorvallen gedu ­
rende de afgelopen 365 dagen  — datum en tijd van het begin van het voorval 
— datum en tijd van het einde van het voorval 
— kaartsoort, kaartnummer, lidstaat van af ­
gifte en generatie van de kaart die bij het 
begin en/of einde van het voorval is in ­
gebracht 
— aantal vergelijkbare voorvallen op die dag  
▼M1 
Fout in de communicatie met 
de externe GNSS-module  — het langste voorval op elk van de 
laatste 10 dagen waarop een der ­
gelijk voorval is opgetreden 
— de 5 langste voorvallen gedu ­
rende de afgelopen 365 dagen  — datum en tijdstip van het begin van het 
voorval 
— datum en tijdstip van het einde van het 
voorval 
— type, nummer, lidstaat van afgifte en gene ­
ratie van de bij het begin en/of het einde 
van het voorval ingevoerde kaart(en) 
— aantal vergelijkbare voorvallen op die dag  
▼B 
Fout in de bewegingsgege ­
vens — het langste voorval op elk van de 
laatste 10 dagen waarop een der ­
gelijk voorval is opgetreden 
— de 5 langste voorvallen gedu ­
rende de afgelopen 365 dagen  — datum en tijd van het begin van het voorval 
— datum en tijd van het einde van het voorval 
— kaartsoort, kaartnummer, lidstaat van af ­
gifte en generatie van de kaart die bij het 
begin en/of einde van het voorval is in ­
gebracht 
— aantal vergelijkbare voorvallen op die dag  
Tegenstrijdige bewegings ­
gegevens  — het langste voorval op elk van de 
laatste 10 dagen waarop een der ­
gelijk voorval is opgetreden 
— de 5 langste voorvallen gedu ­
rende de afgelopen 365 dagen  — datum en tijd van het begin van het voorval 
— datum en tijd van het einde van het voorval 
— kaartsoort, kaartnummer, lidstaat van af ­
gifte en generatie van de kaart die bij het 
begin en/of einde van het voorval is in ­
gebracht 
— aantal vergelijkbare voorvallen op die dag  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 466  
Voorval  Opslagregels  Te registreren gegevens per voorval  
Poging tot inbreuk op de 
beveiliging  de 10 meest recente voorvallen per 
soort voorval  — datum en tijd van het begin van het voorval 
— datum en tijd van het einde van het voorval 
(indien relevant) 
— kaartsoort, kaartnummer, lidstaat van af ­
gifte en generatie van de kaart die bij het 
begin en/of einde van het voorval is in ­
gebracht 
— soort voorval  
Tegenstrijdige tijdgegevens  — het langste voorval op elk van de 
laatste 10 dagen waarop een der ­
gelijk voorval is opgetreden 
— de 5 langste voorvallen gedu ­
rende de afgelopen 365 dagen  — door het controleapparaat geregistreerde da ­
tum en tijd 
— door het GNSS-systeem geregistreerde da ­
tum en tijd 
— kaartsoort, kaartnummer, lidstaat van af ­
gifte en generatie van de kaart die bij het 
begin en/of einde van het voorval is in ­
gebracht 
— aantal vergelijkbare voorvallen op die dag  
4. VOORVALGEGEVENS DIE BESCHIKBAAR ZIJN MET TOESTEMMING 
VAN DE BESTUURDER  
Voorval  Opslagregels  Te registreren gegevens per voorval  
Rijden zonder geschikte kaart  — het langste voorval op elk van de 
laatste 10 dagen waarop een der ­
gelijk voorval is opgetreden 
— de 5 langste voorvallen gedu ­
rende de afgelopen 365 dagen  — datum en tijd van het begin van het voorval 
— datum en tijd van het einde van het voorval 
— kaartsoort, kaartnummer, lidstaat van af ­
gifte en generatie van de kaart die bij het 
begin en/of einde van het voorval is in ­
gebracht 
— aantal vergelijkbare voorvallen op die dag  
Kaartinbrenging tijdens het 
rijden  — het laatste voorval op elk van de 
laatste 10 dagen waarop een der ­
gelijk voorval is opgetreden  — datum en tijd van het voorval 
— kaartsoort, kaartnummer, lidstaat van af ­
gifte en generatie van de kaart die het voor ­
val veroorzaakt 
— aantal vergelijkbare voorvallen op die dag  
Snelheidsoverschrijding (1)  — het ernstigste voorval op elk van 
de laatste 10 dagen waarop een 
dergelijk voorval is opgetreden 
(d.w.z. het voorval met de hoog ­
ste gemiddelde snelheid) 
— de 5 ernstigste voorvallen gedu ­
rende de afgelopen 365 dagen 
— het eerste voorval dat is opgetre ­
den na de laatste kalibrering  — datum en tijd van het begin van het voorval 
— datum en tijd van het einde van het voorval 
— tijdens het voorval gemeten maximumsnel ­
heid 
— tijdens het voorval gemeten rekenkundige 
maximumsnelheid 
— kaartsoort, kaartnummer, lidstaat van af ­
gifte en generatie van de bestuurderskaart 
(indien van toepassing) 
— aantal vergelijkbare voorvallen op die dag  
5. FOUTGEGEVENS DIE BESCHIKBAAR ZIJN ZONDER TOESTEMMING 
VAN DE BESTUURDER  
Fout Opslagregels  Te registreren gegevens per fout  
Kaartfout  — de 10 meest recente bestuurders ­
kaartfouten  — datum en tijd van het begin van de fout 
— datum en tijd van het einde van de fout 
— kaartsoort, kaartnummer, lidstaat van af ­
gifte en generatie van de kaart die de 
fout veroorzaakt  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 467  
Fout Opslagregels  Te registreren gegevens per fout  
Controleapparaatfouten  — de 10 meest recente fouten van 
iedere soort 
— de eerste fout na de laatste kali ­
brering  — datum en tijd van het begin van de fout 
— datum en tijd van het einde van de fout 
— soort fout 
— kaartsoort, kaartnummer, lidstaat van af ­
gifte en generatie van de kaart die bij het 
begin en/of einde van de fout is ingebracht  
Deze fout wordt veroorzaakt door de onderstaande storingen, echter niet in de 
kalibreringsmodus:  
— Interne fout in de VU  
— Printerfout  
— Displayfout  
— Downloadfout  
— Sensorfout  
— Fout in de GNSS-ontvanger of externe GNSS-module  
— Fout in de inrichting voor communicatie op afstand  
▼M1 
— ITS-interfacefout (indien van toepassing)  
▼B 
6. FABRIKANTSPECIFIEKE VOORVALLEN EN FOUTEN ZONDER TOE ­
STEMMING VAN DE BESTUURDER  
Voorval of fout  Opslagregels  Te registreren gegevens per voorval  
Nog te bepalen door de fa ­
brikant  Nog te bepalen door de fabrikant  Nog te bepalen door de fabrikant  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 468  
BIJLAGE 2  
STROOMSCHEMA'S VOOR DE BERICHTENUITWISSELING MET DE ITS-UNIT  
Figuur 1  
Stroomschema voor een poging tot validatie van de pincode
  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 469  
Figuur 2  
Stroomschema voor de autorisatiecontrole van de ITS-unit
  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 470  
Figuur 3  
Stroomschema voor de behandeling van een verzoek om overdracht van als niet-persoonsgebonden aangemerkte 
gegevens (na invoer van juiste pincode)
  
Figuur 4  
Stroomschema voor de behandeling van een verzoek om overdracht van als persoonsgebonden aangemerkte 
gegevens (na invoer van juiste pincode)
  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 471  
Figuur 5  
Stroomschema voor een poging tot validatie van de PUC-code
  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 472  
BIJLAGE 3  
ASN.1 SPECIFICATIONS
  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 473
  
▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 474
  
▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 475
  
▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 476
  
► (1) M1 ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 477
  
► (1) (2) (3)  M1 ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 478
  
► (1) M1 ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 479
  
► (1) (2) M1 ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 480
  
▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 481
  
▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 482
  
► (1) M1 ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 483
  
▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 484  
Aanhangsel 14  
FUNCTIE VOOR COMMUNICATIE OP AFSTAND  
INHOUDSOPGAVE  
1 INLEIDING  
2 TOEPASSINGSGEBIED  
3 ACRONIEMEN, DEFINITIES EN NOTATIES  
4 OPERATIONELE SCENARIO'S  
4.1 Overzicht  
4.1.1 Eerste vereisten voor gegevensoverdracht via 5,8 GHz DSRC-interfaces  
4.1.2 Profiel 1a: via een in de hand gehouden of tijdelijk langs de weg opge ­ 
stelde REDCR  
4.1.3 Profiel 1b: via een in het voertuig gemonteerde en van daaruit gerichte 
REDCR  
4.2 Beveiliging/integriteit  
5 ONTWERP EN PROTOCOLLEN VOOR COMMUNICATIE OP AF ­ 
STAND  
5.1 Ontwerp  
5.2 Workflow  
5.2.1 Operaties  
5.2.2 Interpretatie van de via de DSRC-interface ontvangen gegevens  
5.3 Fysieke DSRC-interfaceparameters voor communicatie op afstand  
5.3.1 Beperkingen met betrekking tot de gebruikslocatie  
5.3.2 Downlink- en uplinkparameters  
5.3.3 Antenneontwerp  
5.4 DSRC-protocolvereisten voor RTM  
5.4.1 Overzicht  
5.4.2 Commando's  
5.4.3 Volgorde van ondervragingscommando's  
5.4.4 Gegevensstructuren  
5.4.5 Elementen van RtmData, uitgevoerde acties en definities  
5.4.6 Mechanisme voor gegevensoverdracht  
5.4.7 Gedetailleerde beschrijving van transacties via DSRC-interfaces  
5.4.8 Beschrijving van de testtransactie via DSRC-interfaces  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 485  
5.6 Gegevensoverdracht tussen DSRC-VU en VU  
5.6.1 Fysieke verbinding en interfaces  
5.6.2 Toepassingsprotocol  
5.7 Behandeling van fouten  
5.7.1 Registratie en doorgifte van de gegevens in de DSRC-VU  
5.7.2 Fouten in de draadloze communicatie  
6 TESTS BIJ INBEDRIJFSTELLING EN PERIODIEKE CONTROLE 
VAN DE FUNCTIE VOOR COMMUNICATIE OP AFSTAND  
6.1 Algemeen  
6.2 Echo-commando  
6.3 Tests om de beveiligde gegevensinhoud te bevestigen  
1 INLEIDING  
In dit aanhangsel worden de ontwerpspecificaties en de toepasselijke 
procedures uiteengezet om de functie voor communicatie op afstand 
uit te voeren zoals voorgeschreven in artikel 9 van Verordening (EU) 
nr. 165/2014 (tachograafverordening).  
DSC_1 Op grond van Verordening (EU) nr. 165/2014 wordt de tacho ­
graaf uitgerust met een functie voor communicatie op afstand 
waarmee de personeelsleden van de bevoegde controleautori ­
teiten tachograafinformatie van voorbijrijdende voertuigen 
kunnen lezen met behulp van apparatuur voor ondervraging 
op afstand (lezer voor communicatie over vroegtijdige detectie 
op afstand [REDCR]), in het bijzonder draadloze ondervra ­
gingssystemen die gebruikmaken van DSRC-interfaces in de 
frequentieband van 5,8 GHz en die voldoen aan de voorschrif ­
ten van het Europees Comité voor normalisatie (CEN).  
Het is van belang in te zien dat deze functie uitsluitend dient 
als voorfilter om de voertuigen te selecteren voor nadere con ­
trole, en niet bedoeld is ter vervanging van de formele con ­
troleprocedure waarin Verordening (EU) nr. 165/2014 voor ­
ziet. Punt 9 van de considerans van de tachograafverordening 
bepaalt inderdaad dat communicatie op afstand tussen de ta ­
chograaf en de controleautoriteiten alleen beoogt gerichte weg ­
controles te vergemakkelijken.  
DSC_2 De gegevens worden uitgewisseld via communicatie op af ­
stand, waarbij de transmissie langs draadloze weg plaatsvindt 
via een 5,8 GHz DSRC-systeem dat in overeenstemming is 
met dit aanhangsel en dat werd getoetst aan de desbetreffende 
parameters van EN 300 674-1, {Electromagnetic compatibility 
and Radio spectrum Matters (ERM); Road Transport and  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 486  
Traffic Telematics (RTTT); Dedicated Short Range Communi ­
cation (DSRC) transmission equipment (500 kbit/s / 250 
kbit/s) operating in the 5,8 GHz Industrial, Scientific and Me ­
dical (ISM) band; Part 1: General characteristics and test me ­
thods for Road Side Units (RSU) and On-Board Units 
(OBU)}.  
DSC_3 De communicatieverbinding wordt uitsluitend tot stand ge ­
bracht door toedoen van het apparaat van de controleautoritei ­
ten, met gebruikmaking van een conform radiocommunicatie ­
middel (lezer voor communicatie over vroegtijdige detectie op 
afstand (REDCR)).  
DSC_4 De gegevens worden beveiligd om de integriteit te waarbor ­
gen. 
DSC_5 Toegang tot de uitgewisselde gegevens wordt beperkt tot voor 
controle bevoegde autoriteiten die gemachtigd zijn inbreuken 
op Verordening (EG) nr. 561/2006 en Verordening (EU) nr. 
165/2014 te controleren, en tot werkplaatsen voor zover het 
noodzakelijk is te controleren of de tachograaf goed functio ­
neert.  
DSC_6 Tijdens de communicatie op afstand worden uitsluitend gege ­
vens uitgewisseld die nodig zijn voor gerichte wegcontrole van 
voertuigen met een tachograaf ten aanzien waarvan het ver ­
moeden van manipulatie of misbruik bestaat.  
DSC_7 De gegevensintegriteit en -beveiliging worden gewaarborgd 
door de gegevens in de voertuigunit (VU) te versleutelen en 
door uitsluitend versleutelde payload- en beveiligingsgegevens 
(zie punt 5.4.4) door te geven via het draadloze 5,8 GHz 
DSRC-systeem voor communicatie op afstand. Dit betekent 
dat alleen daartoe gemachtigde personen van de bevoegde 
controleautoriteiten in staat zijn de via de communicatie op 
afstand uitgewisselde gegevens te begrijpen en de authenticiteit 
daarvan te controleren. Zie aanhangsel 11 „Algemene beveili ­
gingsmechanismen”.  
DSC_8 De gegevens bevatten een tijdaanduiding die aangeeft wanneer 
ze voor het laatst werden geactualiseerd.  
DSC_9 Uitsluitend de bevoegde controleautoriteiten en de partijen met 
wie zij deze informatie delen, zijn op de hoogte van de be ­
veiligingsgegevens, en hebben de controle over de inhoud 
daarvan. Deze inhoud valt buiten de werkingssfeer van de in 
dit aanhangsel vervatte bepalingen met betrekking tot com ­
municatie op afstand. Niettemin wordt ervoor gezorgd dat bij 
elke overdracht van payloadgegevens ook beveiligingsgege ­
vens worden meegezonden.  
DSC_10 Dezelfde architectuur en apparatuur moeten het mogelijk ma ­
ken andere gegevens (bijvoorbeeld van een weegsysteem aan 
boord van het voertuig) te verzamelen met toepassing van de 
hierin vervatte architectuurvoorschriften.  
DSC_11 Voor alle duidelijkheid: overeenkomstig artikel 7 van Verorde ­
ning (EU) nr. 165/2014 worden via communicatie op afstand 
geen gegevens over de identiteit van de bestuurder uitgewis ­
seld. 
2 TOEPASSINGSGEBIED  
In dit aanhangsel wordt gespecificeerd hoe personeelsleden van de be ­
voegde controleautoriteiten een specifiek 5,8 GHz DSRC-systeem voor 
draadloze communicatie op afstand gebruiken met het doel gegevens te 
verzamelen ter identificatie van een bepaald voertuig dat mogelijkerwijs  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 487  
inbreuk maakt op Verordening (EU) nr. 165/2014 en dat daarom moet 
worden tegengehouden voor nadere controle.  
Overeenkomstig artikel 9 van Verordening (EU) nr. 165/2014 moeten de 
verzamelde gegevens beperkt blijven tot, of betrekking hebben op ge ­
gevens ter identificatie van eventuele inbreuken op de tachograafver ­
ordening.  
▼M1 
In dit geval is de voor  de communicatie  beschikbare tijd beperkt omdat 
gerichte gegevens over korte afstand moeten worden uitgewisseld. 
Voorts kunnen de bevoegde controleautoriteiten dezelfde communicatie ­
middelen voor tachograafcontrole op afstand (RTM) ook voor andere 
toepassingen inzetten (bijvoorbeeld ter bepaling van de maximaal toe ­
gestane afmetingen en gewichten van zware vrachtvoertuigen als be ­
doeld in Richtlijn (EU) 2015/719). Dit kan, naar keuze van de bevoegde 
controleautoriteiten, geschieden in de vorm van aparte of opeenvolgende 
verrichtingen.  
▼B 
Dit aanhangsel bevat specificaties met betrekking tot:  
— de voor de communicatie op afstand te gebruiken apparatuur, pro ­
cedures en -protocollen;  
— de normen en verordeningen waaraan de radioapparatuur dient te 
voldoen;  
— de aanbiedingsvorm van de gegevens aan de communicatieappa ­
ratuur;  
— de opvraag- en downloadprocedures en de bewerkingsvolgorde;  
— de over te brengen gegevens;  
— de mogelijke interpretatie van de via communicatie op afstand over ­
gebrachte gegevens;  
— de bepalingen met betrekking tot beveiligingsgegevens in het kader 
van de communicatie op afstand;  
— de beschikbaarstelling van de gegevens aan de bevoegde controleau ­
toriteiten;  
— de wijze waarop de lezer voor communicatie over vroegtijdige de ­
tectie op afstand (REDCR) uiteenlopende gegevens over het vracht ­
vervoer en voertuigenpark kan opvragen.  
Voor alle duidelijkheid: dit aanhangsel bevat  geen specificaties met 
betrekking tot:  
— het verzamelen van gegevens met het oog op de werking en het 
beheer in de VU (dit hangt af van het productontwerp tenzij anders 
is bepaald in Verordening (EU) nr. 165/2014);  
— de aanbiedingsvorm van de verzamelde gegevens aan de personeels ­
leden van de bevoegde controleautoriteiten, noch de criteria die deze 
autoriteiten toepassen om te beslissen welke voertuigen worden te ­
gengehouden (dit hangt af van het productontwerp, tenzij anders is 
bepaald in Verordening (EU) nr. 165/2014 of in beleidsbeslissingen 
van de bevoegde controleautoriteiten). Voor alle duidelijkheid: de 
functie voor communicatie op afstand beoogt uitsluitend de gegevens 
beschikbaar te stellen aan de bevoegde controleautoriteiten zodat zij  
zelf met kennis van zaken een beslissing kunnen nemen;  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 488  
— de bepalingen inzake gegevensbeveiliging (zoals codering) met be ­
trekking tot de gegevensinhoud (die worden gespecificeerd aanhang ­
sel 11 „Algemene beveiligingsmechanismen”);  
— bijzonderheden over andere gegevens die losstaan van de tachograaf ­
controle op afstand (RTM) en die met behulp van dezelfde architec ­
tuur en apparatuur kunnen worden verkregen;  
— bijzonderheden over de wisselwerking en het beheer tussen de VU 
en de DSRC-VU, noch over de interne werking van de DSRC-VU 
(tenzij om de door een REDCR opgevraagde gegevens te verstrek ­
ken).  
3 ACRONIEMEN, DEFINITIES EN NOTATIES  
In dit aanhangsel worden de volgende acroniemen en begrippen gebruikt 
in de daarachter vermelde betekenis:  
antenne:  elektrisch apparaat dat wisselstroom om ­
zet in radiofrequente energie (zendanten ­
ne) en omgekeerd (ontvangantenne), in 
combinatie met een radiozender of ra ­
dio-ontvanger. Bij gebruik als zend ­
antenne voert een radiozender radiofre ­
quente wisselstroom toe aan de antenne ­
klemmen en straalt de antenne deze ra ­
diofrequente energie uit in de vorm van 
elektromagnetische golven (radiogolven). 
Bij gebruik als ontvangantenne onttrekt 
de antenne een bepaalde hoeveelheid 
energie aan een elektromagnetische golf 
om op de antenneklemmen wisselstroom 
op te wekken; deze wisselstroom wordt 
aangelegd op een ontvanger om het sig ­
naal te versterken;  
communicatie:  uitwisseling van informatie/gegevens op 
master-slavebasis tussen een DSRC- 
REDCR en DSRC-VU, zoals uiteengezet 
in punt 5, met het doel gerichte gegevens 
te verkrijgen;  
gegevens:  beveiligde gegevens in een vastgelegd 
formaat (zie punt 5.4.4), die door de 
DSRC-REDCR worden opgevraagd en 
door de DSRC-VU aan de DSRC- 
REDCR worden verstrekt via een 
5,8 GHz DSRC-interface als bedoeld in 
punt 5 hieronder;  
tachograafverordening:  Verordening (EU) nr. 165/2014 van het 
Europees Parlement en van de Raad van 
4 februari 2014 betreffende tachografen 
in het wegvervoer, tot intrekking van  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 489  
Verordening (EEG) nr. 3821/85 van de 
Raad betreffende het controleapparaat in 
het wegvervoer en tot wijziging van Ver ­
ordening (EG) nr. 561/2006 van het Eu ­
ropees Parlement en de Raad tot har ­
monisatie van bepaalde voorschriften 
van sociale aard voor het wegvervoer;  
AID Toepassingsidentificator  
BLE  Bluetooth Low Energy  
BST  Dienstrooster radiobaken  
CIWD  Inbrengen van de kaart tijdens het rijden  
CRC  Cyclische redundantiecontrole  
DSC (n)  Identificator van een voorschrift voor een 
specifieke DSRC-inrichting  
DSRC  Speciale korteafstandscommunicatie  
DSRC-REDCR  DSRC-lezer voor communicatie over 
vroegtijdige detectie op afstand  
DSRC-VU  DSRC-voertuigunit. Dit is de „apparatuur 
voor vroegtijdige detectie op afstand” als 
gedefinieerd in bijlage 1 C.  
DWVC  Rijden zonder geldige kaart  
EID Elementidentificator  
LLC  Logische verbindingsbesturing  
LPDU  LLC-protocol gegevensunit  
OWS  Weegsysteem aan boord van een voertuig  
PDU  Protocol gegevensunit  
REDCR  Lezer voor communicatie over vroegtij ­
dige detectie op afstand. Dit is de „ap ­
paratuur voor communicatie over vroeg ­
tijdige detectie op afstand” als gedefini ­
eerd in bijlage 1 C.  
RTM  Tachograafcontrole op afstand  
SM-REDCR  Beveiligingsmodule van de lezer voor 
communicatie over vroegtijdige detectie 
op afstand  
TARV  Telematics Applications for Regulated 
Vehicles (ISO 15638-normenreeks)  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 490  
VU Voertuigunit  
VUPM  Payloadgeheugen van de voertuigunit  
VUSM  Beveiligingsmodule van de voertuigunit  
VST  Dienstrooster voertuig  
WIM  Wegen terwijl het voertuig aan het rijden 
is 
WOB  Wegen aan boord van het voertuig  
De in dit aanhangsel vastgestelde specificatie verwijst naar en wordt 
geregeld door de hierna genoemde verordeningen en normen of gedeel ­
ten daarvan. In dit aanhangsel zijn de relevante normen of de relevante 
bepalingen van normen gespecificeerd. In geval van tegenspraak preva ­
leert dit aanhangsel. Indien er zich tegenstrijdigheden voordoen waar ­
voor een duidelijke specificatie in dit aanhangsel ontbreekt, prevaleert 
aanbeveling 70-03 van het Europees Comité voor radiocommunicatie 
(ERC) (na toetsing aan de desbetreffende parameters van EN 300 674- 
1), in afnemende volgorde van voorkeur gevolgd door EN 12795, EN 
12253, EN 12834 en EN 13372, punten 6.2, 6.3, 6.4 en 7.1.  
In dit aanhangsel wordt verwezen naar de volgende verordeningen en 
normen:  
[1] Verordening (EU) nr. 165/2014 van het Europees Parlement en van 
de Raad van 4 februari 2014 betreffende tachografen in het weg ­
vervoer, tot intrekking van Verordening (EEG) nr. 3821/85 van de 
Raad betreffende het controleapparaat in het wegvervoer en tot 
wijziging van Verordening (EG) nr. 561/2006 van het Europees 
Parlement en de Raad tot harmonisatie van bepaalde voorschriften 
van sociale aard voor het wegvervoer  
[2] Verordening (EG) nr. 561/2006 van het Europees Parlement en de 
Raad van 15 maart 2006 tot harmonisatie van bepaalde voorschrif ­
ten van sociale aard voor het wegvervoer, tot wijziging van Ver ­
ordeningen (EEG) nr. 3821/85 en (EG) nr. 2135/98 van de Raad en 
tot intrekking van Verordening (EEG) nr. 3820/85 van de Raad 
(Voor de EER relevante tekst)  
[3] ERC 70-03 CEPT: ECC Recommendation 70-03: Relating to the 
Use of Short Range Devices (SRD)  
[4] ISO 15638 Intelligent transport systems — Framework for coope ­
rative telematics applications for regulated commercial freight ve ­
hicles (TARV)  
[5] EN 300 674-1 Electromagnetic compatibility and Radio spectrum 
Matters (ERM); Road Transport and Traffic Telematics (RTTT); 
Dedicated Short Range Communication (DSRC) transmission 
equipment (500 kbit/s / 250 kbit/s) operating in the 5.8 GHz Indu ­
strial, Scientific and Medical (ISM) band; Part 1: General charac ­
teristics 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 — NL — 26.02.2020 — 002.001 — 491  
[7] EN 12795 Road transport and traffic telematics — Dedicated short- 
range communication — Data link layer: medium access and logi ­
cal link control.  
[8] EN 12834 Road transport and traffic telematics — Dedicated short- 
range communication — Application layer.  
[9] EN 13372 Road transport and traffic telematics — Dedicated short- 
range communication — Profiles for RTTT applications  
[10] ISO 14906 Electronic fee collection — Application interface defi ­
nition for dedicated short- range communication  
4 OPERATIONELE SCENARIO'S  
4.1 Overzicht  
De tachograafverordening voorziet in specifieke, duidelijk afgebakende 
scenario's waarin gebruik dient te worden gemaakt van communicatie op 
afstand.  
De ondersteunde scenario's zijn:  
„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  Eerste vereisten voor gegevensoverdracht via 5,8 GHz DSRC-interfaces  
OPMERKING: voor een beter begrip van het kader waarin deze eerste 
vereisten worden toegepast, wordt verwezen naar figuur 14.3 hieronder.  
4.1.1.1 In de VU bewaarde gegevens  
DSC_12 De VU dient de gegevens die in de VU moeten worden opge ­
slagen, om de 60 seconden te actualiseren en bij te houden 
zonder tussenkomst van de DSRC-functie voor communicatie 
op afstand. De daartoe gebruikte middelen hangen af van het 
interne ontwerp van de VU, zoals gespecificeerd in de tacho ­
graafverordening, bijlage 1 C, punt 3.19 „Communicatie op 
afstand voor gerichte wegcontroles”, en worden niet behandeld 
in dit aanhangsel.  
4.1.1.2 Aan de DSRC-VU verstrekte gegevens  
DSC_13 De VU dient de DSRC-gerelateerde tachograafgegevens bij te 
werken telkens wanneer de in de VU opgeslagen gegevens 
worden geactualiseerd met de in punt 4.1.1.1 (DSC_12) be ­
paalde regelmaat, zonder tussenkomst van de DSRC-functie 
voor communicatie op afstand.  
DSC_14 De VU-gegevens dienen als uitgangspunt voor het samenstel ­
len en actualiseren van de tachograafgegevens. De daartoe 
gebruikte middelen worden gespecificeerd in de tachograafver ­
ordening, bijlage 1 C, punt 3.19 „Communicatie op afstand 
voor gerichte wegcontroles”. Bij gebrek aan ter zake dienende 
specificaties hangen deze middelen af van het productontwerp 
en worden zij niet behandeld in dit aanhangsel. Zie punt 5.6 
voor meer informatie over het ontwerp van de communicatie ­
verbinding tussen de DSRC-VU en de VU.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 492  
4.1.1.3 Gegevensinhoud  
DSC_15 De gegevens zijn inhoudelijk zodanig opgemaakt dat ze na 
decodering kunnen worden gestructureerd en beschikbaar ge ­
steld in de vorm die en het formaat dat is vastgelegd in punt 
5.4.4 „Gegevensstructuren” van dit aanhangsel.  
4.1.1.4 Aanbiedingsvorm van de gegevens  
DSC_16 De gegevens die met de in punt 4.1.1.1 bepaalde regelmaat 
zijn geactualiseerd, worden op voorhand versleuteld en als 
beveiligde gegevens aangeboden aan de DSRC-VU om daar 
tijdelijk te worden opgeslagen als huidige versie van de gege ­
vens. De VUSM brengt deze gegevens over naar de VUPM 
via de DSRC-functie. De VUSM en VUPM zijn functionele 
voorzieningen en niet noodzakelijk fysieke inrichtingen. De 
uitvoeringsvorm van deze functionele voorzieningen hangt af 
van het productontwerp tenzij anders is bepaald in de tacho ­
graafverordening.  
4.1.1.5 Beveiligingsgegevens  
DSC_17 Beveiligingsgegevens ( securityData ), met inbegrip van de ge ­
gevens die de REDCR nodig heeft om de tachograafgegevens 
te decoderen, worden verstrekt op de in aanhangsel 11 „Alge ­
mene beveiligingsmechanismen” vastgelegde wijze, en aange ­
boden in de vorm van gegevens die tijdelijk in de DSRC-VU 
worden opgeslagen als huidige versie van  securityData , in het 
in punt 5.4.4 van dit aanhangsel omschreven formaat.  
4.1.1.6 Voor overdracht via de DSRC-interface beschikbare VUPM-gegevens  
DSC_18 In punt 5.4.4 wordt in het kader van de integrale specificaties 
van de ASN.1-module vastgelegd welke gegevens altijd be ­
schikbaar moeten zijn in de VUPM voor onmiddellijke over ­
dracht op verzoek van de REDCR.  
Algemeen overzicht van communicatieprofiel 1  
Dit profiel is van toepassing indien een personeelslid van de bevoegde 
controleautoriteiten („controleambtenaar”) gebruikmaakt van een DSRC- 
REDCR (5,8 GHz DSRC-interfaces die functioneren overeenkomstig 
ERC-aanbeveling 70-03 en die zijn getoetst aan de desbetreffende pa ­
rameters van EN 300 674-1 zoals omschreven in punt 5) teneinde op 
afstand een voertuig te identificeren dat mogelijkerwijs inbreuk maakt op 
de tachograafverordening. Zodra dit voertuig is geïdentificeerd, beslist 
de controleambtenaar op basis van de opgevraagde gegevens of het 
voertuig moet worden tegengehouden.  
4.1.2  Profiel 1a: via een in de hand gehouden of tijdelijk langs de weg opge ­
stelde REDCR  
De controleambtenaar staat in dit geval aan de wegkant en richt een in 
de hand gehouden, op een statief gemonteerde of soortgelijke draagbare 
REDCR naar het midden van de voorruit van het gecontroleerde voer ­
tuig. Voor de ondervraging wordt gebruikgemaakt van 5,8 GHz DSRC- 
interfaces die functioneren overeenkomstig ERC-aanbeveling 70-03 en 
die zijn getoetst aan de desbetreffende parameters van EN 300 674-1 
zoals omschreven in punt 5. Zie figuur 14.1 (praktijkgeval 1).  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 493  
Figuur 14.1  
Ondervraging aan de wegkant via 5,8 GHz DSRC-interfaces
  
4.1.3  Profiel 1b: via een in het voertuig gemonteerde en van daaruit gerichte 
REDCR  
De controleambtenaar zit in dit geval in een rijdend voertuig en richt van 
daaruit een in de hand gehouden, draagbare REDCR naar het midden 
van de voorruit van het gecontroleerde voertuig. De REDCR kan ook in 
of op het voertuig van de controleambtenaar gemonteerd zijn. In dit 
geval wordt de REDCR naar het midden van de voorruit van het ge ­
controleerde voertuig gericht indien het voertuig van de controleambte ­
naar zich in een bepaalde positie bevindt (bijvoorbeeld voorligger) ten 
opzichte van het gecontroleerde voertuig (achterligger). Voor de onder ­
vraging wordt gebruikgemaakt van 5,8 GHz DSRC-interfaces die func ­
tioneren overeenkomstig ERC-aanbeveling 70-03 en die zijn getoetst aan 
de desbetreffende parameters van EN 300 674-1 zoals omschreven in 
punt 5. Zie figuur 14.2 (praktijkgeval 2)  
Figuur 14.2  
Ondervraging vanuit het voertuig via 5,8 GHz DSRC-interfaces
  
4.2 Beveiliging/integriteit  
Teneinde de authenticiteit en integriteit van de via communicatie op 
afstand gedownloade gegevens te kunnen verifiëren, worden de bevei ­
ligde gegevens geverifieerd en gedecodeerd overeenkomstig aanhangsel 
11 „Algemene beveiligingsmechanismen”.  
5 ONTWERP EN PROTOCOLLEN VOOR COMMUNICATIE OP AF ­
STAND  
5.1 Ontwerp  
Het ontwerp van de functie voor communicatie op afstand in de slimme 
tachograaf wordt verduidelijkt in figuur 14.3.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 494  
Figuur 14.3  
Ontwerp van de functie voor communicatie op afstand
  
DSC_19 Hieronder wordt een overzicht gegeven van de functies die 
zich in de VU bevinden.  
— VUSM (beveiligingsmodule van de VU): deze functie in 
de VU beveiligt de gegevens die de DSRC-VU via com ­
municatie op afstand doorgeeft aan de controleambtenaar.  
— De beveiligde gegevens worden opgeslagen in het geheu ­
gen van de VUSM. De in het geheugen van de DSRC-VU 
bijgehouden RTM-gegevens (met inbegrip van de verderop 
in dit aanhangsel bepaalde payload- en beveiligingsgege ­
vens) worden door de VU gecodeerd en gecompleteerd 
met de in punt 4.1.1.1 (DSC_12) bepaalde regelmaat. De 
werking van de beveiligingsmodule wordt nader omschre ­
ven in aanhangsel 11 „Algemene beveiligingsmechanis ­
men” en valt buiten het toepassingsgebied van dit aanhang ­
sel. Niettemin moet de beveiligingsmodule, telkens wan ­
neer de VUSM-gegevens veranderen, aangepaste gegevens 
verstrekken aan de VU-inrichting voor communicatie op 
afstand.  
— De communicatie tussen de VU en de DSRC-VU vindt 
plaats via een kabel- of draadverbinding dan wel langs 
draadloze weg, via een BLE(Bluetooth Low Energy)-ver ­
binding. De DSRC-VU kan geïntegreerd zijn in de antenne 
op de voorruit van het voertuig, in de VU ingebouwd zijn 
of zich ergens daartussen bevinden.  
— De DSRC-VU moet beschikken over een betrouwbare, on ­
onderbroken stroomvoorziening. De daartoe gebruikte mid ­
delen worden in de ontwerpfase vastgesteld.  
— De DSRC-VU heeft een niet-vluchtig geheugen zodat de 
gegevens in de DSRC-VU bewaard blijven zelfs wanneer 
de ontsteking van het voertuig uitgeschakeld is.  
— Indien de VU en de DSRC-VU via een BLE-verbinding 
met elkaar communiceren en de DSRC-VU via een niet- 
oplaadbare batterij van stroom wordt voorzien, moet deze 
stroombron bij elke periodieke controle van de DSRC-VU 
worden vervangen. De fabrikant van de DSRC-VU dient  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 495  
ervoor te zorgen dat de stroomvoorziening gewaarborgd 
blijft tussen twee periodieke controles. Daarbij moeten de 
gegevens op normale wijze en zonder enige storing of 
onderbreking toegankelijk blijven voor een REDCR.  
— VUPM (payloadgeheugen van de VU) voor tachograafcon ­
trole op afstand (RTM): via deze functie in de VU worden 
de gegevens verstrekt en geactualiseerd. De gegevens ­
inhoud („TachographPayload”) wordt hieronder gedefini ­
eerd in punten 5.4.4 en 5.4.5, en wordt geactualiseerd 
met de in punt 4.1.1.1 (DSC_12) bepaalde regelmaat.  
— DSRC-VU: deze functie is geïntegreerd in of aangesloten 
op de antenne en communiceert met de VU via een kabel- 
of draadverbinding dan wel langs draadloze weg, via een 
BLE-verbinding. Deze functie houdt de huidige gegevens 
(VUPM-gegevens) bij en beheert het antwoord op een on ­
dervraging via de 5,8 GHz DSRC-interface. Het loskop ­
pelen van de DSRC-interface of het anderszins belemme ­
ren of verhinderen van de werking daarvan tijdens normaal 
bedrijf van het voertuig wordt aangemerkt als inbreuk op 
de tachograafverordening.  
— SM-REDCR (beveiligingsmodule van de REDCR): deze 
functie wordt gebruikt om de gegevens afkomstig van de 
VU te decoderen en op integriteit te controleren. De daar ­
toe gebruikte middelen worden niet nader omschreven in 
dit aanhangsel, maar vastgelegd in aanhangsel 11 „Alge ­
mene beveiligingsmechanismen”.  
— DSRC-REDCR: deze functie bevat een 5,8 GHz zendont ­
vangapparaat („transceiver”) met bijbehorende firmware en 
software voor het beheer van de communicatie op afstand 
met de DSRC-VU overeenkomstig dit aanhangsel.  
— De DSRC-REDCR ondervraagt de DSRC-VU van het ge ­
controleerde voertuig en ontvangt de gegevens (de huidige 
VUPM-gegevens van het gecontroleerde voertuig) via de 
DSRC-interface, verwerkt die en slaat ze op in de SM- 
REDCR.  
▼M1 
— De antenne van de DSRC-VU wordt aangebracht op een 
plaats waar zij zorgt voor optimale DSRC-communicatie 
tussen het voertuig en de antenne langs de weg, waarbij de 
lezer op een afstand van 15 m vóór het voertuig en een 
hoogte van 2 m wordt geïnstalleerd, gericht op het hori ­
zontale en verticale middenpunt van de voorruit. Voor 
lichte voertuigen (bestelwagens e.d.) kan de antenne aan 
de bovenzijde van de voorruit worden gemonteerd. Voor 
alle andere voertuigen wordt de DSRC-antenne in de na ­
bijheid van de onderzijde of de bovenzijde van de voorruit 
geïnstalleerd.  
▼B 
DSC_20 De antenne en de functie voor communicatie op afstand wer ­
ken overeenkomstig ERC-aanbeveling 70-03 en zijn getoetst 
aan de desbetreffende parameters van EN 300 674-1 zoals 
omschreven in punt 5. In de antenne en de functie voor com ­
municatie op afstand kunnen ontstoringstechnieken worden 
toegepast om interferentie van andere draadloze apparaten te ­
gen te gaan, zoals omschreven in rapport 228 van het Comité 
voor elektronische communicatie (ECC), bijvoorbeeld door 
gebruik te maken van ontstoringsfilters voor de CEN DSRC 
5,8 GHz communicatie.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 496  
DSC_21 De antenne wordt hetzij rechtstreeks aangesloten op de DSRC- 
VU in de module op of nabij de voorruit, hetzij via een spe ­
cifieke kabel die niet onrechtmatig kan worden losgekoppeld. 
Het loskoppelen van de antenne of het anderszins belemmeren 
of verhinderen van de werking daarvan wordt beschouwd als 
een inbreuk op de tachograafverordening. Het opzettelijk mas ­
keren/afschermen van de antenne of het anderszins nadelig 
beïnvloeden van de operationele prestaties daarvan wordt be ­
schouwd als een inbreuk op de tachograafverordening.  
DSC_22  ►M1 De vormfactor van de antenne is niet nader bepaald: de 
beslissing daarover wordt in de commerciële sfeer genomen 
mits de geïnstalleerde DSRC-VU voldoet aan de in punt 5 
hierna vastgestelde conformiteitsvoorschriften. De antenne 
wordt geplaatst volgens het bepaalde in DSC_19 en biedt op 
efficiënte wijze ondersteuning aan de in punten 4.1.2 en 4.1.3 
toegelichte praktijkgevallen. ◄ 
Figuur 14.4  
Montage van de 5,8 GHz DSRC-antenne op de voorruit van 
gereglementeerde voertuigen
  
De vormfactor van de REDCR en bijbehorende antenne kan variëren 
afhankelijk van de opstellingswijze van de lezer (op statief, in de hand 
gehouden, in het voertuig gemonteerd enz.) en de werkmethode van de 
controleambtenaar.  
Via een weergave- en/of meldfunctie wordt de controleambtenaar op de 
hoogte gebracht van de resultaten van de communicatie op afstand. De 
resultaten kunnen beschikbaar worden gesteld door weergave in een 
leesvenster, in de vorm van een afdruk, via een akoestisch waarschu ­
wingssignaal of een combinatie daarvan. De uitvoeringsvorm van deze 
weergave- en/of meldfunctie hangt af van vereisten van de controleamb ­
tenaren, en wordt niet behandeld in dit aanhangsel.  
DSC_23 Het ontwerp en de vormfactor van de REDCR hangen af van 
de commerciële vormgeving, van de werking overeenkomstig 
ERC-aanbeveling 70-03 alsook van de in punt 5.3.2 van dit  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 497  
aanhangsel gespecificeerde ontwerp- en prestatie-eigenschap ­
pen. Zo wordt marktdeelnemers zoveel mogelijk marge gebo ­
den om apparatuur te ontwerpen en te leveren die afgestemd is 
op de specifieke ondervragingsscenario's van de bevoegde con ­
troleautoriteiten.  
DSC_24 Het ontwerp en de vormfactor van de DSRC-VU alsook de 
opstellingswijze daarvan (binnen of buiten de VU) hangen af 
van de commerciële vormgeving, van de werking overeenkom ­
stig ERC-aanbeveling 70-03 alsmede van de in dit voorschrift 
(punt 5.1) en de in punt 5.3.2 van dit aanhangsel gespecifi ­
ceerde ontwerp- en prestatie-eigenschappen.  
DSC_25 Niettemin moet de DSRC-VU redelijkerwijs in staat zijn ge ­
gevens van andere slimme voertuigapparatuur, zoals weegsys ­
temen aan boord van het voertuig, te ontvangen via op een 
open industrienorm gebaseerde verbindingen en protocollen. 
Als voorwaarde daarbij geldt dat deze gegevens worden ge ­
ïdentificeerd door unieke en bekende toepassingsidentificato ­
ren/bestandsnamen, dat de gebruiksinstructies voor deze pro ­
tocollen beschikbaar worden gesteld aan de Europese Com ­
missie en tevens kosteloos verkrijgbaar zijn voor de betrokken 
apparatuurfabrikanten.  
5.2 Workflow  
5.2.1  Operaties  
De operationele workflow wordt verduidelijkt in figuur 14.5.  
Figuur 14.5  
Workflow van de functie voor communicatie op afstand
  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 498  
Hieronder wordt een stapsgewijze beschrijving gegeven van deze work ­
flow.  
a. Wanneer het voertuig in gebruik is (contact aangezet), verstrekt de 
tachograaf gegevens aan de VU-functie. De VU-functie maakt de 
gegevens gereed voor communicatie op afstand door ze te coderen, 
en actualiseert de VUPM-gegevens die worden bijgehouden in het 
geheugen van de DSRC-VU (zoals omschreven in punten 4.1.1.1 en 
4.1.1.2). De verzamelde gegevens worden opgemaakt volgens het in 
punten 5.4.4 en 5.4.5 hieronder vastgestelde formaat.  
b. Telkens wanneer de gegevens worden geactualiseerd, wordt de tijd ­
aanduiding van de beveiligingsgegevens bijgewerkt.  
c. De VUSM-functie beveiligt de gegevens volgens de in aanhangsel 
11 vastgestelde procedures.  
d. Telkens wanneer de gegevens worden geactualiseerd (zie punten 
4.1.1.1 en 4.1.1.2), worden ze overgebracht naar de DSRC-VU en 
worden eventueel bestaande gegevens overschreven. Op die manier 
zijn de huidige gegevens altijd up-to-date in het geval dat het voer ­
tuig wordt ondervraagd door een REDCR. De gegevens die de VU 
aan de DSRC-VU verstrekt, zijn identificeerbaar aan de hand van de 
bestandsnaam  RTMData  of de toepassingsidentificator (AID) en de 
attribuutidentificator.  
e. Indien een controleambtenaar de gegevens van een voertuig wil 
verzamelen voor controledoeleinden, plaatst hij zijn smartcard in 
de REDCR om de functie voor communicatie op afstand te active ­
ren en om de SM-REDCR in staat te stellen een authenticiteitscon ­
trole uit te voeren en de gegevens te decoderen.  
f. De controleambtenaar richt vervolgens de REDCR op het gecontro ­
leerde voertuig en vraagt de gegevens op via de communicatie op 
afstand. De REDCR start een 5,8 GHz DSRC-interfacesessie met de 
DSRC-VU van het gecontroleerde voertuig, en vraagt de gegevens 
op. De gegevens worden via het draadloze communicatiesysteem 
naar de REDCR overgebracht als DSRC-attribuut met behulp van 
het GET-commando van de toepassing, zoals omschreven in punt 
5.4. Het attribuut bevat de gecodeerde payloadgegevens en de 
DSRC-beveiligingsgegevens.  
g. De gegevens worden geanalyseerd door de REDCR en doorgegeven 
aan de controleambtenaar.  
h. Aan de hand van deze gegevens kan de controleambtenaar beslissen 
om het voertuig al dan niet tegen te houden voor nadere controle, of 
kan hij een collega vragen het voertuig tegen te houden.  
5.2.2  Interpretatie van de via de DSRC-interface ontvangen gegevens  
DSC_26 De via de 5,8 GHz DSRC-interface ontvangen gegevens mo ­
gen uitsluitend worden opgevat in de betekenis en binnen de 
draagwijdte die daaraan worden gegeven in punten 5.4.4 en 
5.4.5 hieronder. Deze gegevens moeten worden begrepen in 
het licht van de hierbij nagestreefde doelstellingen. Overeen ­
komstig de tachograafverordening worden de gegevens uit ­
sluitend gebruikt om ter zake dienende informatie te verstrek ­
ken aan de bevoegde controleambtenaar zodat die kan  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 499  
beslissen of het voertuig moet worden tegengehouden voor 
nadere controle. Nadien worden deze gegevens gewist zoals 
voorgeschreven in artikel 9 van de tachograafverordening.  
5.3 Fysieke DSRC-interfaceparameters voor communicatie op afstand  
5.3.1  Beperkingen met betrekking tot de gebruikslocatie  
DSC_27 Het op een 5,8 GHz DSRC-interface gebaseerde systeem voor 
ondervraging op afstand van voertuigen mag niet worden 
gebruikt op minder dan 200 m van een 5,8 GHz DSRC-weg ­
portaal.  
5.3.2  Downlink- en uplinkparameters  
DSC_28 De voor de tachograafcontrole op afstand (RTM) gebruikte 
apparatuur moet voldoen aan en functioneren overeenkomstig 
ERC-aanbeveling 70-03 en de in tabellen 14.1 en 14.2 hier ­
onder aangegeven parameters.  
DSC_29 De gebruikte RTM-apparatuur voldoet bovendien aan de in 
EN 12253 en EN 13372 vastgestelde parameters ter waarbor ­
ging van de compatibiliteit met de operationele parameters 
van andere gestandaardiseerde 5,8 GHz DSRC-systemen.  
Het betreft met name:  
▼C2 
Tabel 14.1  
Downlinkparameters  
Item nr.  Parameter  Waarde(n)  Opmerking  
D1 Draaggolffrequenties van 
downlinkkanaal  Een REDCR kan vier alter ­
natieve frequenties gebrui ­
ken: 
5,7975 GHz 
5,8025 GHz 
5,8075 GHz 
5,8125 GHz  Overeenkomstig ERC-aanbeveling 
70-03. 
Draaggolffrequenties kunnen wor ­
den gekozen door de uitvoerder 
van het wegkantsysteem en hoeven 
niet bekend te zijn in de DSRC- 
VU. 
(Conform EN 12253 en EN 13372)  
D1a (*) Tolerantie van draaggolffre ­
quenties  Binnen ± 5 ppm  (Conform EN 12253)  
D2 (*) Zenderspectrummasker 
RSU (REDCR)  Overeenkomstig ERC-aan ­
beveling 70-03. 
REDCR voldoet aan klasse 
B en C, als bedoeld in EN 
12253. 
Geen ander specifiek voor ­
schrift in deze bijlage.  Parameter gebruikt voor storings ­
onderdrukking tussen nabijgelegen 
ondervragingssystemen (als be ­
doeld in EN 12253 en EN 13372).  
D3 Minimaal frequentiebereik 
OBU (DSRC-VU)  5,795 - 5,815 GHz  (Conform EN 12253)  
D4 (*) Maximaal equivalent iso ­
troop uitgestraald vermogen 
(EIRP)  Overeenkomstig ERC-aan ­
beveling 70-03 (zonder li ­
centie) en nationale regelge ­
ving 
Maximaal + 33 dBm  (Conform EN 12253)  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 500  
Item nr.  Parameter  Waarde(n)  Opmerking  
D4a Hoekscheidend EIRP-mas ­
ker Zoals in aangegeven en be ­
kendgemaakte specificatie 
van ontwerper ondervra ­
gingssysteem  (Conform EN 12253)  
D5 Polarisatie  Cirkelvormig linksdraaiend  (Conform EN 12253)  
D5a Kruispolarisatie  Kruispolarisatiediscriminatie 
(XPD): 
in as van de antenne: 
(REDCR) RSU t ≥ 15 dB 
(DSRC-VU) OBU r ≥ 
10 dB 
In gebied van – 3 dB: 
(REDCR) RSU t ≥ 10 dB 
(DSRC-VU) OBU r ≥ 6 dB  (Conform EN 12253)  
D6 (*) Modulatie  Amplitudemodulatie met 
twee niveaus  (Conform EN 12253)  
D6a (*) Modulatie-index  0,5 … 0,9  (Conform EN 12253)  
D6b Oogpatroon  ≥ 90 % (tijd)/ ≥ 85 % (am ­
plitude)  
D7 (*) Gegevenscodering  FM0 
Bit „1” heeft alleen over ­
gang bij het begin en einde 
van het bitinterval. Bit „0” 
heeft een extra overgang in 
het midden van het bitinter ­
val vergeleken met bit „1”.  (Conform EN 12253)  
D8 (*) Bitsnelheid  500 kBit/s  (Conform EN 12253)  
D8a Bitkloktolerantie  Beter dan ± 100 ppm  (Conform EN 12253)  
D9 (*) Bitfoutenkans 
voor communicatie  ≤ 10  – 6 indien invallend 
vermogen van OBU 
(DSRC-VU) ligt binnen het 
bereik van [D11a t/m D11b]  (Conform EN 12253)  
D10 Startsignaal voor activering 
OBU (DSRC-VU)  OBU (DSRC-VU) wordt 
geactiveerd bij ontvangst 
van een frame van 11 bytes 
of meer (inclusief blokvoor ­
loper)  Geen bijzonder activeringspatroon 
is vereist. 
DSRC-VU kan ook worden geacti ­
veerd bij ontvangst van een frame 
met minder dan 11 bytes. 
(Conform EN 12253)  
D10a  Maximale aanlooptijd  ≤ 5 ms  (Conform EN 12253)  
D11 Communicatiegebied  Ruimtelijk gebied waarin 
een bitfoutenkans volgens 
D9a wordt bereikt  (Conform EN 12253)  
D11a  (*) Bovenste vermogensgrens 
voor communicatie  – 24 dBm  (Conform EN 12253)  ▼C2
 02016R0799 — NL — 26.02.2020 — 002.001 — 501  
Item nr.  Parameter  Waarde(n)  Opmerking  
D11b  (*) Onderste vermogensgrens 
voor communicatie  Invallend vermogen: 
– 43 dBm (as van de anten ­
ne) 
– 41 dBm (binnen – 45° tot 
+ 45° volgens het horizon ­
tale vlak (azimut) evenwij ­
dig aan het wegdek indien 
de DSRC-VU later in het 
voertuig wordt gemonteerd)  (Conform EN 12253) 
Uitgebreidere vereisten voor hori ­
zontale hoeken tot ± 45° als gevolg 
van de in deze bijlage vastgestelde 
gebruiksgevallen.  
D12 (*) Grensvermogens-niveau van 
(DSRC-VU)  – 60 dBm  (Conform EN 12253)  
D13 Blokvoorloper  Verplicht  (Conform EN 12253)  
D13a  Lengte en patroon 
van blokvoorloper  16 bits ± 1 bit van FM0- 
gecodeerde bits „1”  (Conform EN 12253)  
D13b  Golfvorm van blokvoor ­
loper  Afwisselende reeks voor ­
loopsignalen van laag en 
hoog niveau met een puls ­
duur van 2 μs. 
De tolerantie wordt bepaald 
door D8a  (Conform EN 12253)  
D13c  Staartbits  De RSU (REDCR) mag na 
de eindvlag ten hoogste 8 
bits verzenden. Een OBU 
(DSRC-VU) is niet vereist 
om deze extra bits in reke ­
ning te brengen.  (Conform EN 12253)  
(*) – Downlinkparameters moeten aan conformiteitstests worden onderworpen overeenkomstig de relevante parametertest van EN 
300 674-1.  
Tabel 14.2  
Uplinkparameters  
Item nr.  Parameter  Waarde(n)  Opmerking  
U1 (*) Subdraaggolffrequenties  Een OBU (DSRC-VU) 
ondersteunt 1,5 MHz en 
2,0 MHz 
Een RSU (REDCR) onder ­
steunt 1,5 MHz of 2,0 MHz 
of allebei. U1-0: 1,5 MHz 
U1-1: 2,0 MHz  Keuze van subdraaggolffrequentie 
(1,5 MHz of 2,0 MHz) hangt af 
van het gekozen EN 13372-profiel.  
U1a (*) Tolerantie van subdraag ­
golffrequenties  Binnen ± 0,1 %  (Conform EN 12253)  
U1b Gebruik van zijbanden  Dezelfde gegevens aan 
beide zijden  (Conform EN 12253)  
U2 (*) Zenderspectrummasker 
OBU (DSRC-VU)  Conform EN 12253 
1) Buiten-de-band-ver ­
mogen: 
zie EN 300674-1 van 
het Europees Instituut 
voor telecommunicatie ­
normen (ETSI)  (Conform EN 12253)  ▼C2
 02016R0799 — NL — 26.02.2020 — 002.001 — 502  
Item nr.  Parameter  Waarde(n)  Opmerking  
2) Binnen-de-band-ver ­
mogen: 
[U4a] dBm op 500 kHz 
3) Emissie in een ander 
uplinkkanaal: 
U2(3)-1 = – 35 dBm op 
500 kHz  
U4a (*) Maximaal EIRP enkelzij ­
band (as van de antenne)  Twee opties: 
U4a-0: – 14 dBm 
U4a-1: – 21 dBm  Zoals in aangegeven en bekendge ­
maakte specificatie van ontwerper 
apparatuur  
U4b (*) Maximaal EIRP enkelzij ­
band (35°)  Twee opties: 
— niet van toepassing 
— – 17 dBm  Zoals in aangegeven en bekendge ­
maakte specificatie van ontwerper 
apparatuur  
U5 Polarisatie  Cirkelvormig linksdraaiend  (Conform EN 12253)  
U5a Kruispolarisatie  XPD: 
in as van de antenne: 
(REDCR) RSU r ≥ 15 dB 
(DSRC-VU) OBU t ≥ 
10 dB 
Op -3 dB: (REDCR) RSU r 
≥ 10 dB 
(DSRC-VU) OBU t ≥ 6 dB  (Conform EN 12253)  
U6 Subdraaggolfmodulatie  2-PSK 
Gecodeerde gegevens ge ­
synchroniseerd op sub ­
draaggolf: overgangen van 
gecodeerde gegevens vallen 
samen met overgangen van 
subdraaggolf  (Conform EN 12253)  
U6b Bedrijfscyclus  Bedrijfscyclus: 
50 % ± α, α ≤ 5 %  (Conform EN 12253)  
U6c Modulatie op draaggolf  Vermenigvuldiging van ge ­
moduleerde subdraaggolf 
met draaggolf  (Conform EN 12253)  
U7 (*) Gegevenscodering  NRZI (Non-Return to Zero, 
Inverted) (geen overgang bij 
begin van bit „1”, overgang 
bij begin van bit „0”, geen 
overgang binnen bit)  (Conform EN 12253)  
U8 (*) Bitsnelheid  250 kBit/s  (Conform EN 12253)  
U8a Bitkloktolerantie  Binnen ± 1 000 ppm  (Conform EN 12253)  
U9 Bitfoutenkans voor com ­
municatie  ≤ 10  – 6 (Conform EN 12253)  ▼C2
 02016R0799 — NL — 26.02.2020 — 002.001 — 503  
Item nr.  Parameter  Waarde(n)  Opmerking  
U11 Communicatiegebied  Het ruimtelijk gebied 
waarin de DSRC-VU zich 
bevindt, wordt zodanig ge ­
kozen dat de REDCR de 
door de DSRC-VU verzon ­
den gegevens kan ontvan ­
gen met een bitfoutenkans 
die kleiner is dan bepaald 
in U9a.  (Conform EN 12253)  
U12a  (*) Conversieversterking (on ­
dergrens)  1 dB voor elke zijband 
Hoekbereik: cirkelvormig 
symmetrisch tussen as van 
antenne en ± 35° 
en 
binnen – 45° t/m + 45° vol ­
gens het horizontale vlak 
(azimut) evenwijdig aan 
het wegdek indien de 
DSRC-VU later in het voer ­
tuig wordt gemonteerd.  Groter dan het gespecificeerde 
waardebereik voor horizontale hoe ­
ken tot ± 45°, als gevolg van de in 
deze bijlage vastgestelde gebruiks ­
gevallen.  
U12b  (*) Conversieversterking (bo ­
vengrens)  10 dB voor elke zijband  Kleiner dan het gespecificeerde 
waardebereik voor elke zijband 
binnen een cirkelkegel rond de as 
van de antenne met een openings ­
hoek van ± 45°  
U13 Blokvoorloper  Verplicht  (Conform EN 12253)  
U13a  Blokvoorloper 
Lengte en patroon  32 tot 36 μs, alleen gemo ­
duleerd met subdraaggolf, 
gevolgd door 8 bits van 
NRZI-gecodeerde bits „0”  (Conform EN 12253)  
U13b  Staartbits  De DSRC-VU mag na de 
eindvlag ten hoogste 8 bits 
verzenden. Een RSU 
(REDCR) is niet vereist 
om deze extra bits in reke ­
ning te brengen.  (Conform EN 12253)  
(*) – Uplinkparameters moeten aan conformiteitstests worden onderworpen overeenkomstig de relevante parametertest van EN 
300 674-1.  
▼B 
5.3.3  Antenneontwerp  
5.3.3.1 REDCR-antenne  
DSC_30 Het ontwerp van de REDCR-antenne wordt bepaald door de 
commerciële vormgeving en met het oog op de werking bin ­
nen de in punt 5.3.2 bepaalde grenswaarden, waar nodig aan ­
gepast om de leesprestaties van de DSRC-REDCR optimaal 
af te stemmen op het specifieke gebruiksdoel en de werkings ­
omstandigheden waarvoor de REDCR is ontworpen.  
5.3.3.2 VU-antenne  
DSC_31 Het ontwerp van de antenne van de DSRC-VU wordt bepaald 
door de commerciële vormgeving en met het oog op de wer ­
king binnen de in punt 5.3.2 bepaalde grenswaarden, waar 
nodig aangepast om de leesprestaties van de DSRC-REDCR 
optimaal af te stemmen op het specifieke gebruiksdoel en de 
werkingsomstandigheden waarvoor de REDCR is ontworpen.  ▼C2
 02016R0799 — NL — 26.02.2020 — 002.001 — 504  
DSC_32 De VU-antenne wordt bevestigd op of nabij de voorruit van 
het voertuig, zoals gespecificeerd in punt 5.1 hierboven.  
DSC_33 Een DSRC-VU-antenne die, overeenkomstig punt 5.1 hier ­
boven, aan de binnenzijde van een heldere standaardvoorruit 
is vastgemaakt, kan in de testomgeving van een werkplaats 
(zie punt 6.3) een succesvolle verbinding tot stand brengen 
met standaardtestapparatuur en met succes een RTM-trans ­
actie uitvoeren op de in dit aanhangsel omschreven wijze, 
op een afstand van 2 tot en met 10 m, met een slaagpercen ­
tage van meer dan 99 %, berekend als gemiddelde over 1 000 
ondervragingen met leestoegang.  
5.4 DSRC-protocolvereisten voor RTM  
5.4.1  Overzicht  
DSC_34 Het transactieprotocol om de gegevens te downloaden via de 
5,8 GHz DSRC-interface verloopt in de hieronder toegelichte 
stappen. De beschrijving van de transactiestroom in dit ge ­
deelte berust op ideale omstandigheden zonder hertransmissie 
of onderbreking van de communicatie.  
Opmerking: het doel van de initialisatiefase (stap 1) is twee ­
ledig: enerzijds de verbindingsopbouw tussen de REDCR en 
de DSRC-VU's die binnen het bereik van de 5,8 GHz DSRC- 
interface (op master-slavebasis) zijn gekomen, maar nog niet 
in verbinding staan met de REDCR en anderzijds de aanmel ­
ding van toepassingsprocedures.  
— Stap 1  Initialisatie De REDCR verzendt een frame met 
een dienstrooster radiobaken (BST) waarin de toepas ­
singsidentificatoren (AID's) van de lijst van ondersteunde 
diensten zijn opgenomen. Voor de RTM-toepassing is dit 
doorgaans de dienst waarvan de AID gelijk is aan 2 
(„Freight&Fleet”). De DSRC-VU onderzoekt de ontvan ­
gen BST, verzendt als antwoord (zie verder) de lijst van 
ondersteunde toepassingen in het domein 
„Freight&Fleet”, of antwoordt niet indien geen toepassin ­
gen worden ondersteund. Indien de REDCR geen AID=2 
verzendt, geeft de DSRC-VU geen antwoord aan de 
REDCR.  
— Stap 2  De DSRC-VU verzendt een frame met een ver ­
zoek om toewijzing van een tijdvenster.  
— Stap 3  De REDCR verzendt een frame met het toegewe ­
zen tijdvenster.  
— Stap 4  De DSRC-VU verzendt binnen het toegewezen 
tijdvenster een frame met het dienstrooster voertuig 
(VST). Deze VST bevat een lijst van alle toepassingen 
die deze DSRC-VU ondersteunt in het domein 
„Freight&Fleet” (AID=2). De verschillende toepassingen 
worden geïdentificeerd door unieke elementidentificatoren 
(EID's), gekoppeld aan een parameterwaarde van de con ­
textmarkering die de ondersteunde norm en toepassing 
aangeeft.  
— Stap 5  De REDCR analyseert de ontvangen VST. Indien 
de VST irrelevant is (bijvoorbeeld een VST ontvangen 
van een DSRC-VU die geen ondersteuning biedt aan de 
RTM-transactie), verbreekt de REDCR de verbinding 
(Release-commando). Indien de ontvangen VST geschikt 
wordt bevonden, begint de REDCR de toepassing te con ­
cretiseren.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 505  
— Stap 6  Daartoe verzendt de REDCR een frame met een 
commando om de RTM-gegevens op te halen, waarbij de 
geconcretiseerde RTM-toepassing wordt geïdentificeerd 
op basis van de corresponderende identificator die de 
DSRC-VU in de VST heeft gespecificeerd. Verder wijst 
de REDCR een tijdvenster toe.  
— Stap 7  De DSRC-VU verzendt binnen het nieuw toege ­
wezen tijdvenster een frame met de adresidentificator die 
voor de geconcretiseerde RTM-toepassing in de VST is 
opgegeven, gevolgd door het attribuut  RtmData  (payload­
element + beveiligingselement).  
— Stap 8  Indien meerdere diensten worden aangeroepen, 
wordt de waarde ‘n’ gewijzigd in het volgende referen ­
tienummer van de dienst, en wordt de procedure opnieuw 
uitgevoerd.  
— Stap 9  De REDCR bevestigt ontvangst van de gegevens 
door een frame met een Release-commando naar de 
DSRC-VU te verzenden om de sessie te beëindigen OF 
gaat terug naar stap 6 indien de REDCR er niet in ge ­
slaagd is de geslaagde ontvangst van de LDPU te valide ­
ren. 
Het transactieprotocol wordt grafisch verduidelijkt in figuur 
14.6. ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 506  
Figuur 14.6  
Stroomschema RTM-proces via 5,8 GHz DSRC-interface
  
5.4.2  Commando's  
DSC_35 De volgende commando's zijn de enige functies die tijdens de 
RTM-transactie worden gebruikt:  
— INITIALISATION.request : door de REDCR verzonden 
commando met de definitie van de door de REDCR on ­
dersteunde toepassingen.  
— INITIALISATION.response : antwoord waarin de 
DSRC-VU de verbinding bevestigt en waarin een lijst is 
opgenomen van ondersteunde toepassingen met kenmer ­
ken en nadere informatie om deze aan te roepen (EID).  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 507  
— GET.request : door de REDCR naar de DSRC-VU ver ­
zonden commando waarin nauwkeurig wordt aangegeven 
welke toepassing moet worden aangeroepen met behulp 
van een bepaalde EID in de ontvangen VST, en waarin de 
DSRC-VU wordt gevraagd de geselecteerde attributen te 
verzenden met de gegevens. Het Get-commando zorgt 
ervoor dat de REDCR de gegevens verkrijgt van de 
DSRC-VU.  
— GET.response : antwoord van de DSRC-VU waarin de 
gevraagde gegevens zijn opgenomen.  
— ACTION.request ECHO : commando waarin de DSRC- 
VU wordt gevraagd gegevens terug te zenden naar de 
REDCR. Dankzij het Echo-commando kunnen werkplaat ­
sen of testcentra voor typegoedkeuring de werking van de 
DSRC-interface testen zonder toegang te moeten krijgen 
tot beveiligingsreferenties.  
— ACTION.response ECHO : antwoord van de DSRC VU 
op het Echo-commando.  
— EVENT_REPORT.request RELEASE : commando 
waarin de DSRC-VU wordt opgedragen de transactie te 
beëindigen. Het Release-commando heeft tot doel de ses ­
sie met de DSRC-VU te beëindigen. Na ontvangst van 
het Release-commando reageert de DSRC-VU niet meer 
op aanvullende ondervragingen tijdens de huidige verbin ­
ding. Overeenkomstig EN 12834 maakt de DSRC-VU 
niet nogmaals verbinding met hetzelfde ondervragingssys ­
teem tenzij de DSRC-VU zich gedurende 255 seconden 
buiten het communicatiegebied heeft bevonden, of de ba ­
ken-ID van het ondervragingssysteem wordt gewijzigd.  
5.4.3  Volgorde van ondervragingscommando's  
▼C2 
DSC_36 Rekening houdend met de volgorde van commando's en ant ­
woorden kan de transactie als volgt worden omschreven:  
Sequentie  Zender  Ontvanger  Omschrijving  Actie  
1 REDCR  >  DSRC-VU  Initialisatie van de com ­
municatieverbinding — 
Vraag  REDCR zendt BST  
2 DSRC-VU  >  REDCR  Initialisatie van de com ­
municatieverbinding — 
Antwoord  Als BST AID = 2 onder ­
steunt, vraagt DSRC-VU een 
privaat venster  
3 REDCR  >  DSRC-VU  Wijst privaat venster toe  Zendt frame met toewijzing 
privaat venster  
4 DSRC-VU  >  REDCR  Zendt VST  Zendt frame met VST  
5 REDCR  >  DSRC-VU  Zendt GET.request over 
gegevens in attribuut voor 
specifiek EID  
6 DSRC-VU  >  REDCR  Zendt GET.response met 
gevraagd attribuut voor 
specifiek EID  Zendt attribuut (RTMData, 
OWSData…) met gegevens 
voor specifiek EID  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 508  
Sequentie  Zender  Ontvanger  Omschrijving  Actie  
▼M1 
7 REDCR  >  DSRC-VU  Sends GET.request for data 
of other Attribute (if appro ­
priate)  
▼C2 
8 DSRC-VU  >  REDCR  Zendt GET.response met 
gevraagd attribuut  Zendt attribuut met gegevens 
voor specifiek EID  
9 REDCR  >  DSRC-VU  Bevestigt ontvangst van ge ­
gevens  Zendt RELEASE-commando 
ter beëindiging van de trans ­
actie  
10 DSRC-VU  Beëindigt transactie  
Punten 5.4.7 en 5.4.8 bevatten een voorbeeld van de trans ­
actievolgorde en de inhoud van de uitgewisselde frames.  
▼B 
5.4.4  Gegevensstructuren  
DSC_37 De semantische structuur van de via de 5,8 GHz DSRC-inter ­
face uitgewisselde gegevens stemt overeen met de in dit aan ­
hangsel vervatte beschrijving. In dit punt wordt uiteengezet 
hoe deze gegevens worden gestructureerd.  
DSC_38 De payloadgegevens (RTM-gegevens) bestaan uit de samen ­
voeging van:  
1. EncryptedTachographPayload data, zijnde de codering van 
de in punt 5.4.5 van ASN.1 gedefinieerde TachographPay ­
load. De coderingsmethode wordt nader toegelicht in aan ­
hangsel 11.  
2. DSRCSecurityData, zoals gespecificeerd in aanhangsel 11.  
DSC_39 De RTM-gegevens worden aangeroepen met RTM-attribuut=1 
en overgebracht in RtmContainer=10.  
DSC_40 Rtm-ContextMark identificeert het deel van de ondersteunde 
norm uit de TARV-normenreeks (voor RTM is dit deel 9).  
De ASN.1-module voor de DSRC-interfacegegevens in de 
RTM-toepassing wordt als volgt gedefinieerd:  ▼C2
 02016R0799 — NL — 26.02.2020 — 002.001 — 509
  
► (1) (2) (3) (4)  M1 ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 510
  
5.4.5  Elementen van RtmData, uitgevoerde acties en definities  
DSC_41 De VU berekent de gegevenswaarden waarmee de beveiligde 
gegevens in de DSRC-VU worden geactualiseerd, overeen ­
komstig de regels in tabel 14.3.  
▼C2 
Tabel 14.3  
Elementen van RtmData, uitgevoerde acties en definities  
(1) RTM-gege ­
venselement  (2) Door de VU uitgevoerde actie  (3)  Gegevensdefinitie in ASN.1  
RTM1 
Kenteken van 
het voertuig  De VU stelt de waarde van het gegevensele ­
ment RTM1  tp15638VehicleRegistrationPlate  
in op basis van de geregistreerde waarde van 
het gegevenstype  VehicleRegistrationIdentifica ­
tion zoals gedefinieerd in aanhangsel 1  Vehi­
cleRegistrationIdentification  Kenteken van het 
voertuig, uit ­
gedrukt als te ­
kenreeks (string)
  
RTM2 
Snelheids ­
overschrij ­
ding  De VU genereert een booleaanse waarde voor 
het gegevenselement RTM2 tp15638Speed ­
ingEvent. 
De VU berekent de waarde van tp15638Speed ­
ingEvent op basis van het aantal in de VU 
geregistreerde snelheidsoverschrijdingen tijdens 
de laatste tien dagen waarop een voorval heeft 
plaatsgehad, zoals gedefinieerd in bijlage 1C.  1 (TRUE) — 
onregelmatighe ­
den in snelheid 
tijdens de laatste 
tien dagen 
waarop een 
voorval heeft 
plaatsgehad
  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 511  
(1) RTM-gege ­
venselement  (2) Door de VU uitgevoerde actie  (3)  Gegevensdefinitie in ASN.1  
Indien er ten minste één tp15638SpeedingE ­
vent is tijdens de laatste tien dagen waarop 
een voorval heeft plaatsgehad, wordt de waarde 
van tp15638SpeedingEvent ingesteld op TRUE 
(waar). 
Indien er geen dergelijke voorvallen hebben 
plaatsgehad tijdens de laatste tien dagen 
waarop een voorval heeft plaatsgehad, wordt 
tp15638SpeedingEvent ingesteld op FALSE 
(onwaar).  
RTM3 
Rijden zon ­
der geldige 
kaart  De VU genereert een booleaanse waarde voor 
het gegevenselement RTM3 tp15638Driving ­
WithoutValidCard. 
De VU wijst de waarde TRUE (waar) toe aan 
de variabele tp15638DrivingWithoutValidCard 
indien de VU tijdens de laatste tien dagen 
waarop een voorval heeft plaatsgehad ten min ­
ste één voorval heeft geregistreerd van het type 
„Rijden zonder geldige kaart”, zoals gedefini ­
eerd in bijlage 1C. 
Indien er geen dergelijke voorvallen hebben 
plaatsgehad tijdens de laatste tien dagen 
waarop een voorval heeft plaatsgehad, wordt 
de variabele tp15638DrivingWithoutValidCard 
ingesteld op FALSE (onwaar).  1 (TRUE) = ge ­
bruik van een 
ongeldige kaart
  
RTM4 
Geldige be ­
stuurders ­
kaart  De VU genereert een booleaanse waarde voor 
het gegevenselement RTM4 tp15638Driver ­
Card op basis van de in de VU opgeslagen 
gegevens, zoals gedefinieerd in aanhangsel 1. 
Indien er geen geldige bestuurderskaart is, stelt 
de VU de variabele in op TRUE (waar). 
Indien er een geldige bestuurderskaart is, stelt 
de VU de variabele in op FALSE (onwaar).  0 (FALSE) = 
geldige bestuur ­
derskaart
  
RTM5 
Inbrengen 
van de kaart 
tijdens het 
rijden  De VU genereert een booleaanse waarde voor 
het gegevenselement RTM5. 
De VU wijst de waarde TRUE (waar) toe aan 
de variabele tp15638CardInsertion indien de 
VU tijdens de laatste tien dagen waarop een 
voorval heeft plaatsgehad ten minste één voor ­
val heeft geregistreerd van het type „Inbrengen 
van de kaart tijdens het rijden”, zoals gedefi ­
nieerd in bijlage 1C. 
Indien er geen dergelijke voorvallen hebben 
plaatsgehad tijdens de laatste tien dagen 
waarop een voorval heeft plaatsgehad, wordt 
de variabele tp15638CardInsertion ingesteld 
op FALSE (onwaar).  1 (TRUE) = tij ­
dens de laatste 
tien dagen 
waarop een 
voorval heeft 
plaatsgehad is de 
kaart ingebracht 
tijdens het rijden
  
RTM6 
Fout in de 
bewegingsge ­
gevens  De VU genereert een booleaanse waarde voor 
het gegevenselement RTM6. 
De VU wijst de waarde TRUE (waar) toe aan 
de variabele tp15638MotionDataError indien 
de VU tijdens de laatste tien dagen waarop 
een voorval heeft plaatsgehad ten minste één 
voorval heeft geregistreerd van het type „Fout 
in de bewegingsgegevens”, zoals gedefinieerd 
in bijlage 1C. 
Indien er geen dergelijke voorvallen hebben 
plaatsgehad tijdens de laatste tien dagen 
waarop een voorval heeft plaatsgehad, wordt 
de variabele tp15638MotionDataError ingesteld 
op FALSE (onwaar).  1 (TRUE) = fout 
in de bewegings ­
gegevens tijdens 
de laatste tien 
dagen waarop 
een voorval heeft 
plaatsgehad
  ▼C2
 02016R0799 — NL — 26.02.2020 — 002.001 — 512  
(1) RTM-gege ­
venselement  (2) Door de VU uitgevoerde actie  (3)  Gegevensdefinitie in ASN.1  
RTM7 
Tegenstrij ­
dige be ­
wegingsgege ­
vens  De VU genereert een booleaanse waarde voor 
het gegevenselement RTM7. 
De VU wijst de waarde TRUE (waar) toe aan 
de variabele tp15638vehicleMotionConflict in ­
dien de VU tijdens de laatste tien dagen 
waarop een voorval heeft plaatsgehad ten min ­
ste één voorval heeft geregistreerd van het type 
„Tegenstrijdige bewegingsgegevens”, (waarde 
„0A”H). 
Indien er geen dergelijke voorvallen hebben 
plaatsgehad tijdens de laatste tien dagen 
waarop een voorval heeft plaatsgehad, wordt 
de variabele tp15638vehicleMotionConflict in ­
gesteld op FALSE (onwaar).  1 (TRUE) = te ­
genstrijdige be ­
wegingsgegevens 
tijdens de laatste 
tien dagen 
waarop een 
voorval heeft 
plaatsgehad
  
RTM8 
Tweede be ­
stuurders ­
kaart  De VU genereert een booleaanse waarde voor 
het gegevenselement RTM8 op basis van bij ­
lage 1C („Gegevens over de bestuurdersactivi ­
teiten” BEMANNING en BIJRIJDER). 
Indien er een tweede geldige bestuurderskaart 
is, stelt de VU de variabele in op TRUE 
(waar). 
Indien er geen tweede geldige bestuurderskaart 
is, stelt de VU de variabele in op FALSE (on ­
waar).  1 (TRUE) = er is 
een tweede be ­
stuurderskaart in ­
gebracht
  
RTM9 
Lopende acti ­
viteit  De VU genereert een booleaanse waarde voor 
het gegevenselement RTM9. 
De VU stelt deze variabele in op TRUE (waar) 
indien in de VU een andere lopende activiteit 
dan „RIJDEN” is geregistreerd, zoals gedefini ­
eerd in bijlage 1C. 
Indien de in de VU geregistreerde lopende ac ­
tiviteit „RIJDEN” is, stelt de VU deze varia ­
bele in op FALSE (onwaar).  1 (TRUE) = an ­
dere activiteit ge ­
kozen; 
0 (FALSE) = ge ­
kozen activiteit is 
„rijden”
  
RTM10 
Afsluiting 
van laatste 
sessie  De VU genereert een booleaanse waarde voor 
het gegevenselement RTM10. 
De VU stelt deze variabele in op TRUE (waar) 
indien de laatste rijsessie niet juist is afgeslo ­
ten, zoals gedefinieerd in bijlage 1C. 
Indien de laatste rijsessie juist is afgesloten, 
wordt de variabele ingesteld op FALSE (on ­
waar).  1 (TRUE) = niet 
juist afgesloten 
0 (FALSE) = 
juist afgesloten
  
RTM11 
Onderbre ­
king in 
stroomvoor ­
ziening  De VU genereert een integerwaarde voor het 
gegevenselement RTM11. 
De VU wijst aan de variabele tp15638Power ­
SupplyInterruption een waarde toe gelijk aan 
de langste stroomstoring in de zin van artikel 9 
van Verordening (EU) nr. 165/2014, voor een 
voorval van het type „Onderbreking in stroom ­
voorziening”, als bedoeld in bijlage 1C.  — Aantal on ­
derbrekingen 
in stroom­
voorziening 
tijdens de 
laatste tien 
dagen 
waarop een 
voorval heeft 
plaatsgehad
  ▼C2
 02016R0799 — NL — 26.02.2020 — 002.001 — 513  
(1) RTM-gege ­
venselement  (2) Door de VU uitgevoerde actie  (3)  Gegevensdefinitie in ASN.1  
Indien er geen enkele onderbreking in stroom ­
voorziening is opgetreden tijdens de laatste tien 
dagen waarop een voorval heeft plaatsgehad, 
wordt de integerwaarde ingesteld op 0.  
▼M1 
RTM12 
Sensor Fault  De VU genereert een integerwaarde voor het 
gegevenselement RTM12. 
De VU wijst aan de variabele sensorFault de 
volgende waarde toe: 
— 1 indien tijdens de laatste tien dagen een 
voorval van het type „35”H (Fout in de 
sensor) is geregistreerd. 
— 2 indien tijdens de laatste tien dagen een 
voorval van het type fout in de GNSS-ont ­
vanger (interne fout of externe fout met 
enum-waarden „36”H of „37”H) is ge ­
registreerd. 
— 3 indien tijdens de laatste tien dagen een 
voorval van het type „0E”H (communica ­
tiefout met de externe GNSS-module) is 
geregistreerd. 
— 4 indien tijdens de laatste tien dagen fou ­
ten in zowel de sensor als de GNSS-ont ­
vanger zijn geregistreerd. 
— 5 indien tijdens de laatste tien dagen zowel 
fouten in de sensor als communicatiefouten 
met de externe GNSS-module zijn geregis ­
treerd. 
— 6 indien tijdens de laatste tien dagen zowel 
fouten in de GNSS-ontvanger als com ­
municatiefouten met de externe GNSS-mo ­
dule zijn geregistreerd. 
— 7 indien tijdens de laatste tien dagen alle 
drie de fouten in de sensor zijn geregis ­
treerd. Indien er tijdens de laatste tien da ­
gen geen voorvallen zijn geregistreerd, 
wordt aan de variabele de waarde 0 toege ­
kend.  — fout in de 
sensor één 
byte volgens 
de verklarende 
woordenlijst 
van de gege ­
vens
 
▼C2 
RTM13 
Tijdafstelling  De VU genereert voor het gegevenselement 
RTM13 een integerwaarde (timeReal volgens 
aanhangsel 1) op basis van de aanwezigheid 
van tijdafstellingsgegevens, als bedoeld in bij ­
lage 1C. 
De VU kent de waarde toe van het laatste tijd ­
stip waarop het voorval „Tijdafstelling” heeft 
plaatsgehad. 
Indien in de VU-gegevens geen voorval „Tijd ­
afstelling” in de zin van bijlage 1C is geregis ­
treerd, wordt de variabele ingesteld op 0.  Tijdstip van laat ­
ste tijdafstelling
  
RTM14 
Poging tot in ­
breuk op de 
beveiliging  De VU genereert voor het gegevenselement 
RTM14 een integerwaarde (timeReal volgens 
aanhangsel 1) op basis van de aanwezigheid 
van een poging tot inbreuk op de beveiliging, 
als bedoeld in bijlage 1C.  Tijdstip van Iaat ­
ste poging tot in ­
breuk op de be ­
veiliging 
— Standaard ­
waarde = 
0x00FF
  ▼C2
 02016R0799 — NL — 26.02.2020 — 002.001 — 514  
(1) RTM-gege ­
venselement  (2) Door de VU uitgevoerde actie  (3)  Gegevensdefinitie in ASN.1  
De VU stelt de waarde in van het laatste tijd ­
stip waarop de VU het voorval „Poging tot 
inbreuk op de beveiliging” heeft geregistreerd. 
Indien in de VU-gegevens geen voorval „Po ­
ging tot inbreuk op de beveiliging” in de zin 
van bijlage 1C is geregistreerd, wordt de vari ­
abele ingesteld op een waarde van 0x00FF.  
RTM15 
Laatste kali ­
brering  De VU genereert voor het gegevenselement 
RTM15 een integerwaarde (timeReal volgens 
aanhangsel 1) op basis van de aanwezigheid 
van laatste kalibreringsgegevens, als bedoeld 
in bijlage 1C. 
De VU stelt de tijdwaarde in van de laatste 
twee kalibreringen (RTM15 en RTM16), die 
worden ingesteld in VuCalibrationData, als be ­
doeld in aanhangsel 1. 
De VU stelt de waarde voor RTM15 in op de 
timeReal van het voorval „Laatste kalibrering”.  Tijdstip van laat ­
ste kalibrerings ­
gegevens
  
RTM16 
Vorige kali ­
brering  De VU genereert een integerwaarde (timeReal 
volgens aanhangsel 1) voor het gegevensele ­
ment RTM16 van de geregistreerde kalibrering 
die voorafgaat aan de laatste kalibrering. 
Indien er geen vorige kalibrering is, stelt de 
VU de waarde van RTM16 in op 0.  Tijdstip van vo ­
rige kalibrerings ­
gegevens
  
RTM17 
Datum van 
aansluiting 
tachograaf  Voor het gegevenselement RTM17 genereert 
de VU een integerwaarde (timeReal volgens 
aanhangsel 1). 
De VU stelt de waarde in van het tijdstip 
waarop de VU voor het eerst is geïnstalleerd. 
De VU leidt dit gegeven af van VuCalibration ­
Data (aanhangsel 1) in vuCalibrationRecords 
waarbij CalibrationPurpose gelijk is aan: 
„03”H  Datum van aan ­
sluiting tacho ­
graaf
  
RTM18 
Effectieve 
snelheid  De VU genereert een integerwaarde voor het 
gegevenselement RTM18. 
De VU stelt de waarde voor RTM18 in op de 
laatste effectieve snelheid die is geregistreerd 
op het ogenblik dat de RtmData voor het laatst 
zijn geactualiseerd.  Laatste effectieve 
snelheid die is 
geregistreerd
  
RTM19 
Tijdaandui ­
ding  Voor het gegevenselement RTM19 genereert 
de VU een integerwaarde (timeReal volgens 
aanhangsel 1). 
De VU stelt de waarde voor RTM19 in op het 
tijdstip waarop de RtmData voor het laatst zijn 
geactualiseerd.  Tijdaanduiding 
van huidige Ta ­
chographPayload
  
▼B 
5.4.6  Mechanisme voor gegevensoverdracht  
DSC_42 Eerder gedefinieerde payloadgegevens worden na de initia ­
lisatiefase opgevraagd door de REDCR en vervolgens door 
de DSRC-VU verzonden binnen het toegewezen tijdvenster. 
De REDCR gebruikt het Get-commando om de gegevens op 
te halen.  ▼C2
 02016R0799 — NL — 26.02.2020 — 002.001 — 515  
DSC_43 Voor elke uitwisseling via DSRC-interfaces worden de gege ­
vens gecodeerd op basis van PER (Packed Encoding Rules) 
UNALIGNED, behalve
  en
  
, die worden gecodeerd op basis van OER 
(Octet Encoding Rules), zoals gedefinieerd in ISO/IEC 8825- 
7, Rec. ITU-T X.696.  
▼B 
5.4.7  Gedetailleerde beschrijving van transacties via DSRC-interfaces  
DSC_44 De initialisatie wordt uitgevoerd overeenkomstig de voor ­
schriften DSC_44 tot en met DSC_48 en de tabellen 14.4 
tot en met 14.9. Bij aanvang van de initialisatiefase verzendt 
de REDCR een frame met een dienstrooster radiobaken (BST) 
overeenkomstig EN 12834 en EN 13372, punten 6.2, 6,3, 6,4 
en 7.1, waarvan de instellingen worden gespecificeerd in de 
onderstaande tabel 14.4.  
▼C2 
Tabel 14.4  
Initialisatie: instellingen BST-frame  
Veld  Instellingen  
Link Identifier  Broadcast-adres  
Beacon ID  Conform EN 12834  
Time  Conform EN 12834  
Profile  Geen extensie, 0 of 1 te ge ­
bruiken  
MandApplications  Geen extensie, EID niet aan ­
wezig, parameter niet aan ­
wezig, AID = 2 
Freight&Fleet  
NonMandApplications  Niet aanwezig  
ProfileList  Geen extensie, aantal profie ­
len in lijst = 0  
Fragmentation header  Geen fragmentatie  
Layer 2 Settings  PDU commando, UI-com ­
mando  
▼B 
In de onderstaande tabel 14.5 worden de instellingen van 
tabel 14.4 verduidelijkt aan de hand van een praktijkvoor ­
beeld, met aanduiding van de bitcodering.  
▼C2 
Tabel 14.5  
Initialisatie: voorbeeld inhoud BST-frame
 Byte nr. 
Attribuut/veld  Bits in byte  Omschrijving  
1 FLAG
  Startvlag  
2 Broadcast ID
  Broadcast-adres  
3 MAC Control Field
  PDU commando  
4 LLC Control Field
  UI-commando  ▼M1
 02016R0799 — NL — 26.02.2020 — 002.001 — 516
 Byte nr. 
Attribuut/veld  Bits in byte  Omschrijving  
5 Fragmentation header
  Geen fragmentatie  
6 BST
  Verzoek om initialisatie  
SEQUENCE {  
OPTION indicatorBeaconID SEQUENCE { 
ManufacturerId INTEGER (0..65535)
  NonMand-toepassingen 
niet aanwezig
  
Fabrikant-ID  
7
 
8
 
IndividualID INTEGER (0..134217727) 
}
 27-bits ID beschikbaar 
voor fabrikant  
9
 
10
 
11
 
12 Time INTEGER (0..4294967295)
  32-bits UNIX realtime  
13
 
14
 
15
 
16 Profile INTEGER (0..127,…)
  Geen extensie. Voor ­
beeldprofiel 0  
17 MandApplications SEQUENCE (SI ­
ZE(0..127,…)) OF {
  Geen extensie, aantal 
mand-toepassingen = 1  
18 SEQUENCE {  
OPTION indicator
  EID niet aanwezig  
OPTION indicator
  Parameter niet aanwezig  
AID DSRCApplicationEntityID}}
  Geen extensie. AID = 2 
Freight&Fleet  ▼C2
 02016R0799 — NL — 26.02.2020 — 002.001 — 517
 Byte nr. 
Attribuut/veld  Bits in byte  Omschrijving  
19 ProfileList SEQUENCE (0..127,…) OF 
Profile}
  Geen extensie, aantal 
profielen in 
lijst = 0  
20 FCS
  Framecontrolevolgorde  
21
 
22 Flag
  Eindvlag  
▼B 
DSC_45 Bij ontvangst van een BST verzendt de DSRC-VU een ver ­
zoek om toewijzing van een tijdvenster, als bedoeld in EN 
12795 en EN 13372, punt 7.1.1, zonder specifieke RTM-in ­
stellingen. In tabel 14.6 staat een voorbeeld van de bitcode ­
ring. 
▼C2 
Tabel 14.6  
Initialisatie: frame-inhoud verzoek om toewijzing van tijdvenster
 Byte nr. 
Attribuut/veld  Bits in byte  Omschrijving  
1 FLAG
  Startvlag  
2 Private LID
  Verbindingsadres van spe ­
cifieke DSRC-VU  
3
 
4
 
5
 
6 MAC Control Field
  Verzoek om toewijzing 
particulier tijdvenster  
7 FCS
  Framecontrolevolgorde  
8
 
9 Flag
  Eindvlag  
▼B 
DSC_46 De REDCR beantwoordt dit verzoek door een tijdvenster toe 
te wijzen, als bedoeld in EN 12795 en EN 13372, punt 7.1.1, 
zonder specifieke RTM-instellingen.  
In tabel 14.7 staat een voorbeeld van de bitcodering.  
▼C2 
Tabel 14.7  
Initialisatie: frame-inhoud toewijzing van tijdvenster
 Byte nr. 
Attribuut/veld  Bits in byte  Omschrijving  
1 FLAG
  Startvlag  
2 Private LID
  Verbindingsadres van spe ­
cifieke DSRC-VU  
3
 ▼C2
 02016R0799 — NL — 26.02.2020 — 002.001 — 518
 Byte nr. 
Attribuut/veld  Bits in byte  Omschrijving  
4
 
5
 
6 MAC Control Field
  Toewijzing particulier 
tijdvenster  
7 FCS
  Framecontrolevolgorde  
8
 
9 Flag
  Eindvlag  
▼B 
DSC_47 Bij ontvangst van het toegewezen tijdvenster verzendt de 
DSRC-VU het dienstrooster voertuig (VST), als bedoeld in 
EN 12834 en EN 13372, punten 6.2, 6,3, 6.4 en 7.1, volgens 
de in tabel 14.8 gespecificeerde instellingen en binnen het 
toegewezen tijdvenster voor verzending.  
▼C2 
Tabel 14.8  
Initialisatie: instellingen VST-frame  
Veld  Instellingen  
Private LID  Conform EN 12834  
VST parameters  Opvulling = 0, daarna voor elke ondersteunde 
toepassing: EID aanwezig, parameter aan ­
wezig, 
AID = 2, EID zoals gegenereerd door OBU  
Parameter  Geen extensie, bevat de RTM-contextmarke ­
ring 
ObeConfiguration  Het facultatieve veld OBE-status kan aanwezig 
zijn, maar wordt niet gebruikt door de REDCR  
Fragmentation header  Geen fragmentatie  
Layer 2 settings  PDU commando, UI-commando  
▼B 
DSC_48 De DSRC-VU ondersteunt de toepassing „Freight and Fleet”, 
geïdentificeerd door toepassingsidentificator (AID) ‘2’. Moge ­
lijk worden andere toepassingsidentificatoren ondersteund, 
maar die staan niet in deze VST, aangezien de BST alleen 
AID=2 vereist. Het veld „Toepassingen” bevat een lijst van 
ondersteunde toepassingen in de DSRC-VU. Voor elke onder ­
steunde toepassing wordt een verwijzing naar de toepasselijke 
norm opgegeven, met name Rtm-ContextMark, bestaande uit 
een objectidentificator die de bijbehorende norm voorstelt, het 
deel van de norm (deel 9 voor RTM) en in voorkomend geval 
de versie daarvan, alsook een EID die door de DSRC-VU 
wordt gegenereerd en die aan deze toepassing gekoppeld is.  
In de onderstaande tabel 14.9 worden de instellingen van 
tabel 14.8 verduidelijkt aan de hand van een praktijkvoor ­
beeld, met aanduiding van de bitcodering.  ▼C2
 02016R0799 — NL — 26.02.2020 — 002.001 — 519  
Tabel 14.9  
Initialisatie: voorbeeld inhoud VST-frame  
Byte 
nr. Attribuut/veld  Bits in byte  Omschrijving  
1 FLAG
  Startvlag  
2 Private LID
  Verbindingsadres van spe ­
cifieke DSRC-VU  
3
 
4
 
5
 
6 MAC Control Field
  PDU commando  
7 LLC Control Field
  UI-commando  
8 Fragmentation header
  Geen fragmentatie  
9 VST 
SEQUENCE {
  Antwoord op initialisatie  
Fill BIT STRING (SIZE(4))
  Niet gebruikt en ingesteld 
op 0  
10 Profile INTEGER (0..127,…) 
Applications SEQUENCE OF {
  Geen extensie. Voorbeeld ­
profiel 0  
11
 Geen extensie, 1 toepas ­
sing 
12 SEQUENCE {  
OPTION indicator
  EID aanwezig  
OPTION indicator
  Parameter aanwezig  
AID DSRCApplicationEntityID
  Geen extensie. AID = 2 
Freight&Fleet  
13 EID Dsrc-EID
  Gedefinieerd in OBU en 
identificeert het toepas ­
singsexemplaar.  
14 Parameter Container {
  Geen extensie, gekozen 
container = 02, 
Bytestring  
15
 Geen extensie, lengte Rtm- 
contextmarkering = 8  ▼C2
 02016R0799 — NL — 26.02.2020 — 002.001 — 520  
Byte 
nr. Attribuut/veld  Bits in byte  Omschrijving  
16 Rtm-ContextMark::= SEQUENCE { 
Standaard-ID 
StandardIdentifier 
standardIdentifier
  ►M1 Object Identifier of 
the supported standard, 
part, and version. Bijvoor ­
beeld: ISO (1) Standard 
(0) TARV (15638) part9 
(9) Version1 (1). 
Eerste byte is 06H, zijnde 
de object-ID. Tweede 
byte is 06H, zijnde de 
lengte ervan. De volgende 
6 bytes bevatten het voor ­
beeld van de object-ID. ◄ 17
 
18
 
19
 
20
 
21
 
22
 
23
 
24 ObeConfiguration Sequence {  
OPTION indicator
  ObeStatus niet aanwezig  
eEquipmentClass INTEGER (0..32767)
  
25
 
26 ManufacturerId INTEGER (0..65535)
  Fabrikant-ID voor DSRC- 
VU, zoals beschreven in 
register ISO 14816  
27
 
28 FCS
  Framecontrolevolgorde  
29
 
30 Flag
  Eindvlag  
▼B 
DCS_49 De REDCR leest vervolgens de gegevens door een Get-com ­
mando te verzenden, zoals gedefinieerd in EN 13372, punten 
6.2, 6.3 en 6.4 en in EN 12834, met de in tabel 14.10 ge ­
specificeerde instellingen.  
▼C2 
Tabel 14.10  
Overzicht: instellingen GET.request-frame  
Veld  Instellingen  
Invoker Identifier (IID)  Niet aanwezig  
Link Identifier (LID)  Verbindingsadres van specifieke 
DSRC-VU  
Chaining  Neen  
Element Identifier (EID) identificatie 
(EID)  Zoals opgegeven in de VST. Geen 
extensie  ▼C2
 02016R0799 — NL — 26.02.2020 — 002.001 — 521  
Veld  Instellingen  
Access Credentials Toegangsreferen ­
ties Neen  
AttributeIdlist  Geen extensie, 1 attribuut, Attribue ­
tId = 1 (RtmData)  
Fragmentation  Neen  
Layer 2 settings  PDU commando, Polled ACn-com ­
mando  
▼B 
In tabel 14.11 wordt aan de hand van een voorbeeld verdui ­
delijkt hoe de RTM-gegevens worden gelezen.  
▼C2 
Tabel 14.11  
Voorstelling: voorbeeld GET.request-frame
 Byte nr. 
Attribuut/veld  Bits in byte  Omschrijving  
1 FLAG
  Startvlag  
2 Private LID
  Verbindingsadres van spe ­
cifieke DSRC-VU  
3
 
4
 
5
 
6 MAC Control Field
  PDU commando  
7 LLC Control Field
  Polled ACn-commando, 
n-bit  
8 Fragmentation header
  Geen fragmentatie  
9 Get.request 
SEQUENCE {
  Verzoek om gegevens op 
te halen (GET)  
OPTION indicator
  Toegangsreferenties niet 
aanwezig  
OPTION indicator
  IID niet aanwezig  
OPTION indicator
  AttributeIdList aanwezig  
Fill BIT STRING(SIZE(1))
  Ingesteld op 0  
10 EID INTEGER (0..127,…)
  De EID van het RTM-toe ­
passingsexemplaar, 
zoals opgegeven in de 
VST. Geen extensie  
11 AttributeIdList'SEQUENCE OF { 
AttributeId}}
  Geen extensie, aantal at ­
tributen = 1  
12
 Attribuut-ID = 1, RtmDa ­
ta. Geen extensie  
13 FCS
  Framecontrolevolgorde  
14
 
15 Flag
  Eindvlag  ▼C2
 02016R0799 — NL — 26.02.2020 — 002.001 — 522  
DSC_50 Bij ontvangst van een verzoek om gegevens op te halen (Get- 
commando) verzendt de DSRC-VU een antwoord met de 
opgevraagde gegevens, zoals gedefinieerd in EN 13372, pun ­
ten 6.2, 6.3 en 6.4 en in EN 12834, met de in tabel 14.12 
gespecificeerde instellingen.  
▼C2 
Tabel 14.12  
Voorstelling: instellingen GET.response-frame  
Veld  Instellingen  
Invoker Identifier (IID)  Niet aanwezig  
Link Identifier (LID)  Conform EN 12834  
Chaining  Neen  
Element Identifier (EID)  Zoals opgegeven in de VST  
Access Credentials  Neen  
Fragmentation  Neen  
Layer2 Settings  Antwoord PDU, antwoord 
beschikbaar en commando 
geaccepteerd, ACn-comman ­
do 
▼B 
In tabel 14.13 wordt aan de hand van een voorbeeld verdui ­
delijkt hoe de RTM-gegevens worden gelezen.  
▼C2 
Tabel 14.13  
Voorstelling: voorbeeld inhoud antwoordframe
 Byte nr. 
Attribuut/veld  Bits in byte  Omschrijving  
1 FLAG
  Startvlag  
2 Private LID
  Verbindingsadres van spe ­
cifieke DSRC-VU  
3
 
4
 
5
 
6 MAC Control Field
  Antwoord PDU  
7 LLC Control Field
  Antwoord beschikbaar, 
ACn-commando n-bit  
8 LLC Status Field
  Antwoord beschikbaar en 
commando geaccepteerd  
9 Fragmentation header
  Geen fragmentatie  
10 Get.response 
SEQUENCE {
  Antwoord GET  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 523
 Byte nr. 
Attribuut/veld  Bits in byte  Omschrijving  
OPTION indicator
  IID niet aanwezig  
OPTION indicator
  Attribuutlijst aanwezig  
OPTION indicator
  Retourstatus niet aan ­
wezig  
Fill BIT STRING(SIZE(1))
  Niet gebruikt  
11 EID INTEGER (0..127,…)
  Antwoord verzonden van ­
uit RTM- 
toepassingsexemplaar. 
Geen extensie  
12 AttributeList SEQUENCE OF {
  Geen extensie, aantal at ­
tributen = 1  
13 Attributes SEQUENCE { 
AttributeId
  Geen extensie, attribuut- 
ID = 1 (RtmData)  
14 AttributeValue CONTAINER {
  Geen extensie, gekozen 
container = 10  10 
15
 RtmData  
16
 
17
 
… …  
n }}}}
  
n+1 FCS
  Framecontrolevolgorde  
n+2
 
n+3 Flag
  Eindvlag  
▼B 
DSC_51 De REDCR verbreekt vervolgens de verbinding door een 
Event_Report, Release-commando te verzenden overeenkom ­
stig EN 13372, punten 6.2, 6.3 en 6.4 en EN 12834, punt 
7.3.8, zonder specifieke RTM-instellingen. In tabel 14.14 staat 
een voorbeeld van de bitcodering voor het Release-comman ­
do. 
▼C2 
Tabel 14.14  
Beëindiging. EVENT_REPORTinhoud Release-Frame
 Byte nr. 
Attribuut/veld  Bits in byte  Omschrijving  
1 FLAG
  Startvlag  
2 Private LID
  Verbindingsadres van spe ­
cifieke DSRC-VU  
3
 
4
 ▼C2
 02016R0799 — NL — 26.02.2020 — 002.001 — 524
 Byte nr. 
Attribuut/veld  Bits in byte  Omschrijving  
5
 
6 MAC Control Field
  Het frame bevat een 
LPDU-commando  
7 LLC Control Field
  UI-commando  
8 Fragmentatie header
  Geen fragmentatie  
9 EVENT_REPORT.request 
SEQUENCE {
  EVENT_REPORT (Re ­
lease)  
OPTION indicator
  Toegangsreferenties niet 
aanwezig  
OPTION indicator
  Voorvalparameter niet 
aanwezig  
OPTION indicator
  IID niet aanwezig  
Mode BOOLEAN
  Geen antwoord verwacht  
10 EID INTEGER (0..127,…)
  Geen extensie, EID = 0 
(System)  
11 EventType INTEGER (0..127,…)}
  Voorvaltype 0 = Release  
12 FCS
  Framecontrolevolgorde  
13
 
14 Vlag
  Eindvlag  
▼B 
DSC_52 De DSRC-VU dient het Release-commando niet te beant ­
woorden. De verbinding wordt daarop verbroken.  
5.4.8  Beschrijving van de testtransactie via DSRC-interfaces  
DSC_53 Zoals vastgelegd in aanhangsel 11 „Algemene beveiligings ­
mechanismen” moeten met behulp van het hierboven toege ­
lichte Get-commando volledige tests, met inbegrip van gege ­
vensbeveiliging, worden uitgevoerd door personen die over de 
nodige bevoegdheden beschikken om toegang te krijgen tot 
beveiligingsprocedures.  
DSC_54 Zoals voorgeschreven in aanhangsel 11 „Algemene beveili ­
gingsmechanismen” en in aanhangsel 9 „Lijst van minimaal 
vereiste typegoedkeuringstests” moeten op het ogenblik van 
inbedrijfstelling en bij periodieke controles tests worden uit ­
gevoerd.  
Niettemin kan de basisfunctie voor communicatie op afstand 
via DSRC-interfaces worden getest met behulp van het Echo- 
commando. Deze tests kunnen niet alleen worden vereist op 
het ogenblik van inbedrijfstelling of bij periodieke controles, 
maar ook indien de bevoegde controleautoriteit dit verlangt of 
indien de tachograafverordening zulks voorschrijft (zie punt 6 
hieronder).  ▼C2
 02016R0799 — NL — 26.02.2020 — 002.001 — 525  
DSC_55 Om deze basistest uit te voeren, verzendt de REDCR het 
Echo-commando tijdens een verbindingssessie, dat wil zeggen 
nadat de initialisatiefase met succes is voltooid. De volgorde 
van interacties is derhalve vergelijkbaar met die van een on ­
dervraging:  
— Stap 1 De REDCR verzendt een dienstrooster radiobaken 
(BST) met de toepassingsidentificatoren (AID's) in de lijst 
van ondersteunde diensten. Voor RTM-toepassingen is dit 
doorgaans de dienst waarvan de AID gelijk is aan 2.  
De DSRC-VU onderzoekt de ontvangen BST en verzendt 
een antwoord indien blijkt dat in de BST de toepassing 
„Freight&Fleet” (AID=2) wordt aangeroepen. Indien de 
REDCR geen AID=2 verzendt, beëindigt de DSRC-VU 
de transactie met de REDCR.  
— Stap 2 De DSRC-VU verzendt een verzoek om toewij ­
zing van een tijdvenster.  
— Stap 3 De REDCR verzendt een toegewezen tijdvenster.  
— Stap 4 De DSRC-VU verzendt binnen het toegewezen 
tijdvenster een frame met het dienstrooster voertuig 
(VST). Deze VST bevat een lijst van alle toepassingen 
die deze DSRC-VU ondersteunt in het domein 
„Freight&Fleet” (AID=2). De verschillende toepassingen 
worden geïdentificeerd door unieke elementidentificatoren 
(EID's), gekoppeld aan een parameterwaarde die de on ­
dersteunde toepassing aangeeft.  
— Stap 5 De REDCR analyseert de ontvangen VST. Indien 
de VST als irrelevant wordt beschouwd (bijvoorbeeld een 
VST ontvangen van een DSRC-VU die geen RTM-VU 
is), verbreekt de REDCR de verbinding (Release-com ­
mando). Wordt de ontvangen VST geschikt bevonden, 
dan begint de REDCR de toepassing te concretiseren.  
— Stap 6 De REDCR verzendt een Echo-commando naar de 
betrokken DSRC-VU, en wijst een tijdvenster toe.  
— Stap 7 De DSRC-VU verzendt binnen het toegewezen 
tijdvenster een Echo-antwoordframe.  
De gegevensuitwisseling in het kader van een Echo-commando wordt 
verduidelijkt aan de hand van het praktijkvoorbeeld in de volgende 
tabellen.  
DSC_56 De initialisatie wordt uitgevoerd overeenkomstig punt 5.4.7 
(DSC_44 tot en met DSC_48) en tabellen 14.4 tot en met 
14.9.  
DSC_57 De REDCR verzendt een Action, Echo-commando overeen ­
komstig ISO 14906 met 100 gegevensbytes en zonder speci ­
fieke RTM-instellingen. De inhoud van het door de REDCR 
verzonden frame wordt verduidelijkt in tabel 14.15.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 526  
Tabel 14.15  
Voorbeeld van het Action, Echo-verzoekframe
 Byte nr. 
Attribuut/veld  Bits in byte  Omschrijving  
1 FLAG
  Startvlag  
2 Private LID
  Verbindingsadres van spe ­
cifieke DSRC-VU  
3
 
4
 
5
 
6 MAC Control Field
  PDU commando  
7 LLC Control Field
  Polled ACn-commando, n- 
bit 
8 Fragmentation Header
  Geen fragmentatie  
9 ACTION.request 
SEQUENCE {
  Verzoek om actie (ECHO)  
OPTION indicator
  Toegangsreferenties niet 
aanwezig  
OPTION indicator
  Actieparameter aanwezig  
OPTION indicator
  IID niet aanwezig  
Mode BOOLEAN
  Antwoord verwacht  
10 EID INTEGER (0..127,…)
  Geen extensie, EID = 0 
(System)  
11 ActionType INTEGER (0..127)
  Geen extensie, actietype 
ECHO-verzoek  
12 ActionParameter CONTAINER {
  Geen extensie, gekozen 
container = 2  
13
 Geen extensie. String ­
lengte = 100 bytes  
14
 Te echoën gegevens  
… …  
113 }}
  
114614  FCS
  Framecontrolevolgorde  
115715
  
116816  Flag
  Eindvlag  ▼C2
 02016R0799 — NL — 26.02.2020 — 002.001 — 527  
DSC_58 Bij ontvangst van het Echo-verzoek verzendt de DSRC-VU 
een Echo-antwoord van 100 bytes waarin het ontvangen com ­
mando wordt weergegeven overeenkomstig ISO 14906, zon ­
der specifieke RTM-instellingen. In tabel 14.16 wordt de bit ­
codering verduidelijkt aan de hand van een voorbeeld.  
▼C2 
Tabel 14.16  
Voorbeeld van het Action, Echo-antwoordframe
 Byte nr. 
Attribuut/veld  Bits in byte  Omschrijving  
1 FLAG
  Startvlag  
2 Private LID
  Verbindingsadres van spe ­
cifieke VU  
3
 
4
 
5
 
6 MAC Control Field
  Antwoord PDU  
7 LLC Control Field
  ACn-commando, n-bit  
8 LLC status field
  Antwoord beschikbaar  
9 Fragmentation header
  Geen fragmentatie  
10 ACTION.response 
SEQUENCE {
  Antwoord op ACTIE 
(ECHO)  
OPTIE-indicator
  IID niet aanwezig  
OPTIE-indicator
  Antwoordparameter aan ­
wezig  
OPTIE-indicator
  Retourstatus niet aan ­
wezig  
Fill BIT STRING (SIZE (1))
  Niet gebruikt  
11 EID INTEGER (0..127,…)
  Geen extensie, EID = 0 
(Systeem)  
12 ResponseParameter CONTAINER {
  Geen extensie, gekozen 
container = 2  
13
 Geen extensie. String ­
lengte = 100 bytes  
14
 Geëchode gegevens  
… …  
113 }}
  
114 FCS
  Framecontrolevolgorde  
115
 
116 Flag
  Eindvlag  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 528  
__________  
▼B 
5.6 Gegevensoverdracht tussen DSRC-VU en VU  
5.6.1  Fysieke verbinding en interfaces  
DSC_66 De verbinding tussen de VU en de DSRC-VU kan bestaan uit 
een fysieke kabel of een draadloze BLE-verbinding voor kor ­
teafstandscommunicatie op basis van Bluetooth v4.0.  
DSC_67 De volgende voorschriften moeten worden nageleefd, onge ­
acht de gekozen fysieke verbinding en interface:  
DSC_68  ►M1 a) De verbinding tussen de VU en de DSRC-VU die 
zich niet in de VU bevindt, moet berusten op een 
open industrienorm zodat verschillende fabrikanten 
in aanmerking komen voor de levering van de VU 
en de DSRC-VU, met inbegrip van de diverse 
uitvoeringsvormen daarvan. De VU wordt verbon ­
den met de DSRC-VU door middel van ◄ 
i) een vaste kabel met een lengte van ten minste 
2 m die via een goedgekeurde Straight DIN 
41612-conforme 11-pens H11-stekker van de 
DSRC-VU wordt aangesloten op een soortge ­
lijke DIN/ISO-conforme contrastekker van de 
VU, 
ii) een BLE(Bluetooth Low Energy)-verbinding,  
iii) een standaardverbinding die voldoet aan ISO 
11898 of SAE J1939.  
DSC_69 b) De definitie van de interfaces en verbinding tussen de VU 
en de DSRC-VU moet ondersteuning bieden aan de in 
punt 5.6.2 gedefinieerde commando's van het toepassings ­
protocol.  
DSC_70 c) De VU en de DSRC-VU moeten de gegevensoverdracht 
via de verbinding ondersteunen wat prestaties en stroom ­
voorziening betreft.  
5.6.2  Toepassingsprotocol  
DSC_71 Het toepassingsprotocol tussen de VU-inrichting voor com ­
municatie op afstand en de DSRC-VU staat in voor de peri ­
odieke gegevensoverdracht tussen de VU en de DSRC-VU.  
DSC_72 De belangrijkste commando's zijn:  
1. Verzoek om initialisatie van de communicatieverbinding  
2. Antwoord op het verzoek om initialisatie van de communi ­
catieverbinding  
3. Gegevens verzenden met de identificator van de RTM- 
toepassing en de door RtmData gedefinieerde payloadge ­
gevens  
4. Ontvangstbevestiging van de gegevens  
5. Verzoek om verbreking van de communicatieverbinding  
6. Antwoord op het verzoek om verbreking van de communi ­
catieverbinding  
DSC_73 In ASN1.0 kunnen de vorige commando's als volgt worden 
gedefinieerd:  ▼M2
 02016R0799 — NL — 26.02.2020 — 002.001 — 529
  
DSC_74 Beschrijving van de commando's en parameters:  
—
 
wordt gebruikt om de communicatieverbinding te initia ­
liseren. Dit commando wordt door de VU verzonden naar 
de DSRC-VU. De verbindingsidentificator (LID) wordt 
ingesteld door de VU en doorgegeven aan de DSRC- 
VU om een specifieke communicatieverbinding op te spo ­
ren. 
(Opmerking: dit is bedoeld ter ondersteuning van toekom ­
stige verbindingen en andere toepassingen/modules, zoals 
weging aan boord van het voertuig).  
—
 
wordt door de DSRC-VU gebruikt als antwoord op het 
verzoek om de communicatieverbinding te initialiseren. 
Dit commando wordt door de DSRC-VU verzonden 
naar de VU. Het commando geeft als resultaat van de 
initialisatie ‘1’ (Geslaagd) of ‘0’ (Mislukt).  
DSC_75 De communicatieverbinding wordt uitsluitend geïnitialiseerd 
na installatie, kalibrering en inschakeling van de motor/VU.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 530  
—
 wordt door de VU gebruikt om de 
getekende RCDTData (dat wil zeggen de gegevens van 
de communicatie op afstand) naar de DSRC-VU te ver ­
zenden. De gegevens worden iedere 60 seconden verzon ­
den. De parameter DataTransactionId identificeert de spe ­
cifieke datatransmissie. De verbindingsidentificator (LID) 
wordt ook gebruikt om te waarborgen dat de verbinding 
juist tot stand is gebracht.  
—
 wordt door de DSRC- 
VU verzonden om feedback te geven aan de VU over de 
gegevensontvangst via het comman ­
do
 dat wordt geïdentificeerd door de 
parameter DataTransactionId. Het antwoord heeft de 
waarde ‘1’ (Geslaagd) of ‘0’ (Mislukt). Indien een VU 
meer dan drie antwoorden met de waarde ‘0’ ontvangt 
of indien de VU geen RCDT-Data Acknowledgment ont ­
vangt voor een eerder verzonden RCDT–Send Data met 
een specifieke DataTransactionId, genereert en registreert 
de VU een voorval.  
—
 ­
wordt door de VU verzonden naar de DSRC-VU om de 
verbinding voor een specifieke verbindingsidentificator 
(LID) te verbreken.  
DSC_76 Bij het herstarten van de DSRC-VU of een VU moeten alle 
bestaande communicatieverbindingen worden verbroken om 
te vermijden dat er „hangende” verbindingen bestaan als ge ­
volg van de plotselinge uitschakeling van een VU.  
—
 ­
wordt door de DSRC-VU verzonden naar de VU ter be ­
vestiging van het door de VU verzonden verzoek om de 
verbinding voor de specifieke verbindingsidentificator 
(LID) te verbreken.  
5.7 Behandeling van fouten  
5.7.1  Registratie en doorgifte van de gegevens in de DSRC-VU  
▼M1 
DSC_77 De gegevens worden in beveiligde vorm beschikbaar gesteld 
aan de  DSRC-VU  door de  VUSM . De VUSM  controleert of de 
gegevens juist zijn geregistreerd in de  DSRC-VU . Eventuele 
fouten in de gegevensoverdracht van de VU naar het geheu ­
gen van de DSRC-VU worden geregistreerd en gemeld op 
basis van een voorval van het type EventFaultType met de 
enum-waarde „0C”H „Communicatiefout met het systeem 
voor communicatie op afstand”, samen met de tijdaanduiding.  
▼B 
DSC_78 Om interne communicatiestoringen van de VU te registreren, 
houdt de VU een bestand bij met een unieke naam die een ­
voudig identificeerbaar is voor de controleurs.  
DSC_79 Indien de VUPM er niet in slaagt VU-gegevens van de be ­
veiligingsmodule te verkrijgen (om die aan de DSRC-VU 
door te geven), wordt deze storing geregistreerd op basis 
van een voorval van het type EventFaultType met de enum- 
waarde  ‘62’H Fout in de inrichting voor communicatie op  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 531  
afstand , samen met de tijdaanduiding. De communicatiesto ­
ring wordt vastgesteld indien het bericht
  
meer dan drie keer na elkaar 
niet wordt ontvangen voor het bijbehorende bericht
  
(dat wil zeggen met dezelfde 
DataTransactionId in de berichten
  
). 
5.7.2  Fouten in de draadloze communicatie  
DSC_80 Communicatiefouten worden behandeld overeenkomstig de 
desbetreffende DSRC-normen, met name EN 300 674-1, EN 
12253, EN 12795, EN 12834 en de toepasselijke parameters 
van EN 13372.  
5.7.2.1  Fouten in codering en handtekening  
DSC_81 Fouten in codering en handtekening worden behandeld zoals 
toegelicht in aanhangsel 11 „Algemene beveiligingsmechanis ­
men”, en worden niet opgenomen in foutmeldingen die ver ­
band houden met de gegevensoverdracht via DSRC-interfa ­
ces. 
5.7.2.2  Registratie van fouten  
Als dynamisch instrument voor draadloze communicatie functioneert de 
DSRC-interface in een onzekere omgeving die wordt gekenmerkt door 
uiteenlopende weersomstandigheden en (storings)invloeden van buitenaf. 
Dit is met name het geval bij gebruik van de draagbare REDCR in 
combinatie met rijdende voertuigen. Bijgevolg moet onderscheid worden 
gemaakt tussen de ‘mislukking’ van een leesbewerking en een ‘foutcon ­
ditie’. Bij transacties via een draadloze interface komt het vaak voor dat 
leesbewerkingen mislukken. In dit geval wordt doorgaans een nieuwe 
poging ondernomen door de BST opnieuw te verzenden en de trans ­
acties nogmaals uit te voeren. In de meeste gevallen wordt de communi ­
catieverbinding dan met succes tot stand gebracht en worden de gege ­
vens met succes overgedragen, tenzij het gecontroleerde voertuig zich 
inmiddels buiten bereik bevindt. Om een leesbewerking met succes uit te 
voeren, worden doorgaans meerdere (nieuwe) pogingen ondernomen.  
Een leesbewerking kan mislukken doordat de antennes niet juist zijn 
gekoppeld (storing bij het ‘richten’) of doordat een van de antennes is 
afgeschermd. Een antenne kan opzettelijk worden afgeschermd, maar 
ook ongewild als gevolg van de fysieke aanwezigheid van een ander 
voertuig, radiostoringen, in het bijzonder van in de 5,8 GHz-frequentie ­
band werkende WiFi-apparatuur of andere publiek toegankelijke draad ­
loze communicatienetwerken. Verder kan een leesbewerking mislukken 
als gevolg van radarstoringen of ongunstige weersomstandigheden (bij ­
voorbeeld onweer) of doordat het gecontroleerde voertuig zich buiten het 
bereik van de DSRC-communicatieapparatuur bevindt. Afzonderlijke 
gevallen waarin leesbewerkingen mislukken kunnen per definitie niet 
worden geregistreerd om de eenvoudige reden dat er geen communicatie 
heeft plaatsgehad.  
Indien de controleambtenaar een specifiek voertuig wil controleren door 
de DSRC-VU ervan te ondervragen, maar er niet in slaagt gegevens over 
te brengen, kan dat ook het gevolg zijn van opzettelijke manipulatie. 
Daarom heeft de controleambtenaar een hulpmiddel nodig om dit voor ­
val in een logboek te registreren en collega's in het vervolgtraject te 
waarschuwen dat er mogelijk sprake is van een inbreuk. Zo kunnen 
deze collega's het voertuig tegenhouden en aan een nadere controle 
onderwerpen. Aangezien de communicatie mislukt is, kunnen daarover 
echter geen gegevens in de DSRC-VU worden geregistreerd. Bijgevolg 
moet deze rapportage deel uitmaken van het functionele ontwerp van de 
REDCR.  
Technisch gezien is het ‘mislukken’ van een leesbewerking niet het ­
zelfde als het optreden van een ‘fout’. In het kader van de tachograaf ­
toepassing betekent een ‘fout’ dat een onjuiste waarde werd verkregen.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 532  
De gegevens zijn al beveiligd wanneer ze aan de DSRC-VU worden 
doorgegeven. Bijgevolg moet de verstrekker van de gegevens ze veri ­
fiëren (zie punt 5.4).  
Gegevens die vervolgens via de ether worden overgebracht, ondergaan 
cyclische redundantiecontroles (CRC) op het niveau van de communi ­
catieverbinding. Een geslaagde CRC betekent dat de gegevens juist zijn. 
Indien de CRC mislukt, moeten de gegevens opnieuw worden verzon ­
den. De kans dat gegevens waarvoor de CRC mislukt toch met succes 
worden overgebracht, is statistisch gezien zo klein dat ze te verwaar ­
lozen is.  
Indien de CRC mislukt en er geen tijd is om de juiste gegevens opnieuw 
te verzenden en te ontvangen, is het resultaat geen fout, maar de con ­
cretisering van een mislukte leesbewerking.  
Het enige betekenisvolle gegeven dat over deze ‘mislukking’ kan wor ­
den geregistreerd, is het aantal keren dat transacties met succes werden 
geïnitialiseerd, zij het zonder succesvolle gegevensoverdracht naar de 
REDCR.  
DSC_82 De REDCR registreert bijgevolg — met tijdaanduiding — 
hoeveel keren de initialisatiefase van een ondervraging via 
de DSRC-interface met succes werd voltooid, maar de trans ­
actie niettemin werd beëindigd voordat de REDCR de gege ­
vens met succes heeft kunnen ophalen. Deze gegevens wor ­
den aan de controleambtenaar beschikbaar gesteld en opge ­
slagen in het geheugen van de REDCR. De daartoe gebruikte 
middelen hangen af van het productontwerp of van de speci ­
ficaties van de bevoegde controleautoriteiten.  
Het enige betekenisvolle gegeven dat over de ‘fout’ kan wor ­
den geregistreerd, is het aantal keren dat de REDCR er niet in 
geslaagd is de ontvangen gegevens te decoderen. Dit heeft 
echter alleen te maken met de doelmatigheid van de 
REDCR-software. Zelfs na decodering kunnen gegevens se ­
mantisch gezien betekenisloos zijn.  
DSC_83 De REDCR registreert bijgevolg — met tijdaanduiding — het 
aantal mislukte pogingen om de via de DSRC-interface ont ­
vangen gegevens te decoderen.  
6 TESTS BIJ INBEDRIJFSTELLING EN PERIODIEKE CONTROLE 
VAN DE FUNCTIE VOOR COMMUNICATIE OP AFSTAND  
6.1 Algemeen  
DSC_84 In het kader van de functie voor communicatie op afstand 
worden twee tests uitgevoerd:  
1) Een Echo-test om de draadloze tweerichtingsverbinding 
tussen de DSRC-REDCR en de DSRC-VU te bevestigen.  
2) Een beveiligingstest tussen bron en bestemming om te 
waarborgen dat een werkplaatskaart toegang kan krijgen 
tot de gecodeerde en getekende gegevens van de VU die 
via de draadloze communicatieverbinding worden verzon ­
den. 
6.2 Echo-commando  
De specifieke testvoorschriften in dit punt zijn bedoeld om na te gaan of 
de tweerichtingsverbinding tussen DSRC-REDCR en DSRC-VU vol ­
ledig operationeel is.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 533  
Dankzij het Echo-commando kunnen werkplaatsen of testcentra voor 
typegoedkeuring de werking van de DSRC-interface testen zonder toe ­
gang te moeten krijgen tot beveiligingsreferenties. De bediener van het 
testapparaat hoeft bijgevolg alleen een verbinding via de DSRC-interface 
te initialiseren (door een BST met AID=2 te verzenden) en daarna het 
Echo-commando te verzenden. Indien de DSRC-interface operationeel 
is, ontvangt hij daarna het antwoord op het Echo-commando. Zie punt 
5.4.8 voor meer informatie. Indien dit antwoord correct wordt ontvan ­
gen, mag ervan worden uitgegaan dat de DSRC-interface (tweerichtings ­
verbinding tussen DSRC-REDCR en DSRC-VU) correct functioneert.  
6.3 Tests om de beveiligde gegevensinhoud te bevestigen  
DSC_85 Met deze test wordt de beveiligde gegevensstroom tussen 
bron en bestemming bevestigd. Voor deze test moet de 
DSRC-testlezer worden gebruikt. De DSRC-testlezer voert 
dezelfde functies uit en wordt geïmplementeerd overeenkom ­
stig dezelfde specificaties als de door controleambtenaren ge ­
bruikte lezer. Het enige verschil is dat de gebruiker van de 
DSRC-testlezer wordt geauthenticeerd op basis van een werk ­
plaatskaart, en niet op basis van een controlekaart. De test kan 
worden uitgevoerd op het ogenblik dat de slimme tachograaf 
voor het eerst wordt geactiveerd of na afloop van de kalibre ­
ringsprocedure. Zodra de tachograaf is geactiveerd, genereert 
de voertuigunit de beveiligde gegevens voor vroegtijdige de ­
tectie, en geeft die door aan de DSRC-VU.  
DSC_86 De werkplaatsmedewerker plaatst de DSRC-testlezer op een 
afstand tussen 2 en 10 m vóór het voertuig.  
DSC_87 Vervolgens brengt de werkplaatsmedewerker een werkplaats ­
kaart in de DSRC-testlezer om de voertuigunit te ondervragen 
en gegevens over vroegtijdige detectie te verkrijgen. Indien de 
ondervraging met succes verloopt, leest de werkplaatsmede ­
werker de ontvangen gegevens om de integriteit ervan te con ­
troleren en zeker te stellen dat ze juist werden gedecodeerd.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 534  
Aanhangsel 15  
MIGRATIE: DE COËXISTENTIE VAN VERSCHILLENDE 
GENERATIES APPARATUUR BEHEREN  
INHOUDSOPGAVE  
1. DEFINITIES  
2. ALGEMENE BEPALINGEN  
2.1. Overzicht van de overgang  
2.2. Interoperabiliteit tussen VU's en kaarten  
2.3. Interoperabiliteit tussen VU's en bewegingssensoren  
2.4. Interoperabiliteit tussen voertuigunits, tachograafkaarten en apparatuur 
voor het downloaden van gegevens  
2.4.1 Kaarten rechtstreeks downloaden met intelligente toepassingsgerichte 
apparatuur (IDE)  
2.4.2 Het downloaden van een kaart via een voertuigunit  
2.4.3 Het downloaden van een voertuigunit  
2.5. Interoperabiliteit tussen VU's en kalibratieapparatuur  
3. BELANGRIJKSTE STAPPEN IN DE PERIODE VÓÓR DE DATUM 
VAN INVOERING  
4. BEPALINGEN VOOR DE PERIODE NA DE DATUM VAN INVOE ­ 
RING  
1. DEFINITIES  
Met het oog op de toepassing van dit aanhangsel wordt verstaan onder:  
slim tachograafsysteem : zoals gedefinieerd in deze bijlage (hoofdstuk 
1: definitie bbb);  
tachograafsysteem van de eerste generatie : zoals gedefinieerd in deze 
verordening (artikel 2: definitie 1);  
tachograafsysteem van de tweede generatie : zoals gedefinieerd in deze 
verordening (artikel 2: definitie 7);  
datum van invoering : zoals gedefinieerd in deze bijlage (hoofdstuk 1: 
definitie ccc);  
Intelligente toepassingsgerichte apparatuur : apparatuur die wordt ge ­
bruikt voor het downloaden van gegevens, zoals gedefinieerd in aan ­
hangsel 7 van deze bijlage.  
2. ALGEMENE BEPALINGEN  
2.1. Overzicht van de overgang  
In de preambule van deze bijlage wordt een overzicht gegeven van de 
overgang tussen de tachograafsystemen van de eerste en de tweede 
generatie.  
In aanvulling op de bepalingen van deze preambule:  
— zijn bewegingssensoren van de eerste generatie niet interoperabel 
met voertuigunits van de tweede generatie.  
— begint de installatie van bewegingssensoren van de tweede generatie 
in voertuigen op hetzelfde ogenblik als de installatie van voertuig ­
units van de tweede generatie.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 535  
— apparatuur voor het downloaden van gegevens en kalibreren moet 
evolueren om het gebruik van beide generaties controleapparaten en 
tachograafkaarten te ondersteunen.  
2.2. Interoperabiliteit tussen VU's en kaarten  
▼M1 
Er wordt van uitgegaan dat tachograafkaarten van de eerste generatie 
interoperabel zijn met voertuigunits van de eerste generatie, overeen ­
komstig bijlage IB bij Verordening (EEG  o nr. 3821/85), en dat tacho ­
graafkaarten van de tweede generatie interoperabel zijn met voertuigunits 
van de tweede generatie, overeenkomstig bijlage IC bij deze verorde ­
ning. Voorts zijn ook de onderstaande voorschriften van toepassing.  
▼B 
MIG_001 Behoudens het bepaalde in voorschrift MIG_004 en 
MIG_005, mogen tachograafkaarten van de eerste generatie 
verder worden gebruikt in voertuigunits van de tweede ge ­
neratie tot het einde van hun geldigheidsduur. De houders 
kunnen evenwel vragen ze te vervangen door tachograafkaar ­
ten van de tweede generatie zodra deze beschikbaar zijn.  
MIG_002 Het moet mogelijk zijn elke geldige bestuurders-, controle- 
en bedrijfskaart van de eerste generatie te gebruiken in voer ­
tuigunits van de tweede generatie.  
MIG_003 Werkplaatsen kunnen dit definitief onmogelijk maken, zodat 
tachograafkaarten van de eerste generatie niet meer worden 
aanvaard. Dit mag alleen gebeuren nadat de Europese Com ­
missie is gestart met een procedure die tot doel heeft werk ­
plaatsen te verzoeken dit te doen, bijvoorbeeld tijdens elke 
periodieke inspectie van de tachograaf.  
MIG_004 Voertuigunits van de tweede generatie mogen alleen werk ­
plaatskaarten van de tweede generatie kunnen gebruiken.  
MIG_005 Om de werkingsmodus te bepalen, houden voertuigunits van 
de tweede generatie alleen rekening met het type geldige 
kaarten dat wordt ingebracht, ongeacht de generatie.  
MIG_006 Elke geldige tachograafkaart van de tweede generatie kan in 
voertuigunits van de eerste generatie worden gebruikt op 
exact dezelfde wijze als hetzelfde type tachograafkaarten 
van de eerste generatie.  
2.3. Interoperabiliteit tussen VU's en bewegingssensoren  
Er wordt van uitgegaan dat bewegingssensoren van de eerste generatie 
interoperabel zijn met voertuigunits van de eerste generatie, en dat be ­
wegingssensoren van de tweede generatie interoperabel zijn met voer ­
tuigunits van de tweede generatie. Voorts zijn ook de onderstaande 
voorschriften van toepassing.  
MIG_007 Voertuigunits van de tweede generatie kunnen niet worden 
gekoppeld aan en gebruikt met bewegingssensoren van de 
eerste generatie.  
MIG_008 Bewegingssensoren van de tweede generatie kunnen worden 
gekoppeld aan en gebruikt met uitsluitend voertuigunits van 
de tweede generatie of met beide generaties voertuigunits.  
2.4. Interoperabiliteit tussen voertuigunits, tachograafkaarten en appara ­
tuur voor het downloaden van gegevens  
MIG_009 Apparatuur voor het downloaden van gegevens kan worden 
gebruikt met slechts één generatie van voertuigunits en ta ­
chograafkaarten of met beide.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 536  
2.4.1  Kaarten rechtstreeks downloaden met intelligente toepassingsgerichte 
apparatuur (IDE)  
MIG_010 De gegevens worden gedownload door IDE van tachograaf ­
kaarten van één generatie die in hun kaartlezers worden in ­
gebracht, met gebruikmaking van de beveiligingsmechanis ­
men en het downloadprotocol van deze generatie, en alle 
gedownloade gegevens hebben het formaat dat voor deze 
generatie is gedefinieerd.  
MIG_011 Om de controle van bestuurders door autoriteiten van buiten 
de EU mogelijk te maken, is het ook mogelijk om gegevens 
van bestuurders- (en werkplaats-)kaarten van de tweede ge ­
neratie te downloaden op exact dezelfde wijze als van be ­
stuurders- (en werkplaats-)kaarten van de eerste generatie. 
Een dergelijke download omvat:  
▼M1 
— de IC en ICC (facultatief) van niet-ondertekende EF’s,  
▼B 
— het
  en
  van 
niet-ondertekende EF's (1  ste generatie),  
▼M1 
— de andere gegevensbestanden van de EF’s (in DF Tacho ­
graph) die worden gevraagd door de eerste generatie van 
het downloadprotocol. Deze informatie wordt beveiligd 
met een digitale handtekening, volgens de beveiligings ­
mechanismen van de eerste generatie.  
Een dergelijke download omvat geen gegevensbestanden van 
EF’s die alleen aanwezig zijn in bestuurders- (en werkplaats-) 
kaarten van de tweede generatie (gegevensbestanden van EF’s in 
DF Tachograph_G2).  
▼B 
2.4.2  Het downloaden van een kaart via een voertuigunit  
MIG_012 De gegevens worden gedownload van een kaart van de 
tweede generatie die is ingebracht in een voertuigunit van 
de eerste generatie, met gebruikmaking van het download ­
protocol van de eerste generatie. De kaart reageert op exact 
dezelfde wijze als een kaart van de eerste generatie op de 
commando's van de voertuigunit en de gedownloade gege ­
vens hebben hetzelfde formaat als gegevens die zijn ge ­
download van een kaart van de eerste generatie.  
MIG_013 De gegevens worden gedownload van een kaart van de eerste 
generatie die is ingebracht in een voertuigunit van de tweede 
generatie met gebruikmaking van het in aanhangsel 7 van 
deze bijlage gedefinieerde downloadprotocol. De voertuigunit 
zendt commando's naar de kaart op precies dezelfde wijze als 
een voertuigunit van de eerste generatie, en de gedownloade 
gegevens beantwoorden aan het formaat dat is gedefinieerd 
voor kaarten van de eerste generatie.  
2.4.3  Het downloaden van een voertuigunit  
▼M1 
MIG_014 Buiten het kader van de controle van bestuurders door con ­
trole-autoriteiten van buiten de EU, wordt voor het downlo ­
aden van gegevens van een voertuigunit van de tweede ge ­
neratie gebruikgemaakt van de beveiligingsmechanismen van 
de tweede generatie en van het in aanhangsel 7 van deze 
bijlage gespecificeerde downloadprotocol.  
MIG_015 Om controle-autoriteiten van buiten de EU de mogelijkheid 
te geven om bestuurders te controleren, kan het ook mogelijk 
zijn om gegevens van voertuigunits van de tweede generatie 
te downloaden met de beveiligingsmechanismen. De ge ­
downloade gegevens hebben dan hetzelfde formaat als gege ­
vens die zijn gedownload uit een voertuigunit van de eerste 
generatie. Deze mogelijkheid kan worden geselecteerd via 
commando’s in het menu.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 537  
2.5. Interoperabiliteit tussen VU's en kalibratieapparatuur  
MIG_016 Kalibratieapparatuur is in staat kalibraties te verrichten van 
tachografen van elke generatie, met gebruikmaking van het 
kalibreringsprotocol van deze generatie. Kalibratieapparatuur 
kan worden gebruikt met één generatie tachografen of met 
beide.  
3. BELANGRIJKSTE STAPPEN IN DE PERIODE VÓÓR DE DATUM 
VAN INVOERING  
MIG_017 Testsleutels en -certificaten worden uiterlijk  30 maanden  
voor de datum van invoering ter beschikking gesteld van 
de fabrikanten.  
MIG_018 De interoperabiliteitstesten zijn uiterlijk  15 maanden  voor de 
datum van invoering klaar om van start te gaan, op verzoek 
van fabrikanten.  
MIG_019 Officiële sleutels en certificaten worden uiterlijk  12 maan ­
den voor de datum van invoering ter beschikking gesteld van 
de fabrikanten.  
MIG_020 De lidstaten kunnen uiterlijk  3 maanden  voor de datum van 
invoering werkplaatskaarten van de tweede generatie afge ­
ven. 
MIG_021 De lidstaten kunnen uiterlijk  1 maand  voor de datum van 
invoering alle types tachograafkaarten van de tweede gene ­
ratie afgeven.  
4. BEPALINGEN VOOR DE PERIODE NA DE DATUM VAN INVOE ­
RING  
MIG_022 Na de invoering geven de lidstaten alleen nog tachograaf ­
kaarten van de tweede generatie af.  
MIG_023 Fabrikanten van voertuigunits / bewegingssensoren mogen 
voertuigunits / bewegingssensoren van de eerste generatie 
blijven produceren zolang deze worden gebruikt op het ter ­
rein, zodat defecte onderdelen kunnen worden vervangen.  
MIG_024 Fabrikanten van voertuigunits / bewegingssensoren kunnen 
het behoud van de typegoedkeuring van voertuigunits / be ­
wegingssensoren van de eerste generatie waarvoor reeds ty ­
pegoedkeuring is verkregen, vragen en krijgen.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 538  
Aanhangsel 16  
ADAPTER VOOR VOERTUIGEN VAN DE CATEGORIEËN M1 EN N1  
INHOUD  
1. AFKORTINGEN EN REFERENTIEDOCUMENTEN  
1.1. Afkortingen  
1.2. Referentienormen  
2. ALGEMENE KENMERKEN EN FUNCTIES VAN DE ADAPTER  
2.1. Algemene beschrijving van de adapter  
2.2. Functies  
2.3. Beveiliging  
3. EISEN VOOR HET CONTROLEAPPARAAT WANNEER EEN ADAP ­ 
TER IS GEÏNSTALLEERD  
4. FABRICAGE EN FUNCTIONELE VEREISTEN VAN DE ADAPTER  
4.1. Totstandbrenging van interfaces en aanpassing van inkomende snelheids ­ 
impulsen  
4.2. Invoering van de inkomende impulsen in de ingebouwde bewegingssensor  
4.3. Ingebouwde bewegingssensor  
4.4. Veiligheidsvoorschriften  
4.5. Prestatiekenmerken  
4.6. Materialen  
4.7. Merktekens  
5. INSTALLATIE VAN HET CONTROLEAPPARAAT WANNEER EEN 
ADAPTER WORDT GEBRUIKT  
5.1. Installatie  
5.2. Verzegeling  
6. CONTROLES, INSPECTIES EN HERSTELLINGEN  
6.1. Periodieke controles  
7. TYPEGOEDKEURING VAN HET CONTROLEAPPARAAT WAN ­ 
NEER EEN ADAPTER WORDT GEBRUIKT  
7.1. Algemeen  
7.2. Functioneel certificaat  
1. AFKORTINGEN EN REFERENTIEDOCUMENTEN  
1.1. Afkortingen  
TBD  Nog vast te stellen  
VU Voertuigunit  
1.2. Referentienormen  
ISO16844-3 Road vehicles — Tachograph systems — Part 3: Motion 
sensor interface  
2. ALGEMENE KENMERKEN EN FUNCTIES VAN DE ADAPTER  
2.1. Algemene beschrijving van de adapter  
ADA_001 De adapter levert beveiligde bewegingsgegevens die permanent 
representatief zijn voor de snelheid en afgelegde afstand van 
het voertuig aan de aangesloten VU.  
De adapter is alleen bestemd voor voertuigen die overeenkom ­
stig deze verordening met een controleapparaat moeten worden 
uitgerust.  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 539  
De adapter wordt alleen geïnstalleerd en gebruikt in de onder 
(yy) ”adapter” van bijlage IC gedefinieerde voertuigtypen, 
wanneer het mechanisch niet mogelijk is een ander bestaand 
type bewegingssensor te installeren dat verenigbaar is met de 
bepalingen van deze bijlage en met de aanhangsels 1 tot en met 
16 daarbij.  
De adapter mag geen mechanische interface met een bewegend 
deel van het voertuig omvatten, maar moet aangesloten zijn op 
de snelheids-/afstandsimpulsen die worden gegenereerd door 
geïntegreerde sensoren of alternatieve interfaces.  
ADA_002 Een bewegingssensor waarvoor typegoedkeuring is verleend 
(volgens de voorschriften van deze bijlage IC, punt 8, Type ­
goedkeuring van controleapparaten en tachograafkaarten) wordt 
gemonteerd in de adapterbehuizing, die eveneens een impul ­
somvormer omvat welke de inkomende impulsen invoert in de 
ingebouwde bewegingssensor. De ingebouwde bewegingssen ­
sor zelf wordt aangesloten op de voertuigunit, zodat de inter ­
face tussen de voertuigunit en de adapter voldoet aan de eisen 
van ISO16844-3.  
2.2. Functies  
ADA_003 De adapter heeft de volgende functies:  
— fungeert als interface en past de inkomende snelheidsimpul ­
sen aan,  
— invoering van de inkomende impulsen in de ingebouwde 
bewegingssensor,  
— alle functies van de ingebouwde bewegingssensor die be ­
veiligde bewegingsgegevens aan de voertuigunit leveren.  
2.3. Beveiliging  
ADA_004 Er hoeft geen veiligheidscertificering van de adapter te worden 
uitgevoerd overeenkomstig de in aanhangsel 10 bij deze bijlage 
vastgestelde algemene beveiligingsdoelstelling voor de be ­
wegingssensor. In plaats daarvan zijn de in punt 4.4 van dit 
aanhangsel gespecificeerde veiligheidseisen van toepassing.  
3. EISEN VOOR HET CONTROLEAPPARAAT WANNEER EEN ADAP ­
TER IS GEÏNSTALLEERD  
Uit de in de volgende hoofdstukken vermelde eisen blijkt hoe de voor ­
schriften van deze bijlage moeten worden verstaan wanneer een adapter 
wordt gebruikt. Tussen haakjes is het nummer van het voorschrift van 
bijlage IC vermeld.  
ADA_005 Het controleapparaat van een voertuig dat met een adapter is 
uitgerust, moet voldoen aan alle voorschriften van deze bijlage, 
tenzij anders gespecificeerd in dit aanhangsel.  
ADA_006 Wanneer een adapter is geïnstalleerd, omvat het controleap ­
paraat kabels, de adapter (met inbegrip van een bewegingssen ­
sor) en een voertuigunit [01].  
ADA_007 De functie voor het detecteren van voorvallen en/of fouten van 
het controleapparaat wordt als volgt gewijzigd:  
— wanneer de stroomvoorziening van de ingebouwde be ­
wegingssensor [79] gedurende meer dan 200 milliseconden 
wordt onderbroken, veroorzaakt de voertuigunit, wanneer 
deze zich niet in de kalibreringsmodus bevindt, het voorval 
”onderbreking in de stroomvoorziening”;  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 540  
— wanneer de normale gegevensstroom tussen de ingebouwde 
bewegingssensor en de voertuigunit wordt onderbroken 
en/of wanneer zich een fout voordoet in de integriteit van 
de gegevens of in de authenticatie van de gegevens tijdens 
de gegevensuitwisseling tussen de ingebouwde bewegings ­
sensor en de voertuigunit [83], veroorzaakt de voertuigunit 
het voorval ”fout in de bewegingsgegevens”;  
— wanneer zich een ander voorval voordoet dat de beveiliging 
van de ingebouwde bewegingssensor aantast, wanneer deze 
zich niet in kalibreringsmodus bevindt, veroorzaakt de 
voertuigunit het voorval ”poging tot inbreuk op de bevei ­
liging” [85];  
— wanneer zich een fout in de ingebouwde bewegingssensor 
voordoet, wanneer deze zich niet in kalibreringsmodus be ­
vindt, veroorzaakt de voertuigunit het voorval ”fout in het 
controleapparaat” [88].  
ADA_008 De fouten van de adapter die door het controleapparaat kunnen 
worden vastgesteld, zijn die welke verband houden met de 
ingebouwde bewegingssensor [88].  
ADA_009 De kalibreringsmodus van de voertuigunit moet het mogelijk 
maken de ingebouwde bewegingssensor automatisch te verbin ­
den met koppelen de voertuigunit [202, 204].  
4. FABRICAGE EN FUNCTIONELE VEREISTEN VAN DE ADAPTER  
4.1. Totstandbrenging van interfaces en aanpassing van inkomende snel ­
heidsimpulsen  
ADA_011 De inputinterface van de adapter aanvaardt frequentie-impulsen 
die representatief zijn voor de snelheid van het voertuig en de 
afgelegde afstand. De elektrische kenmerken van de inkomende 
impulsen zijn:  nader vast te stellen door de fabrikant . Aan­
passingen die alleen kunnen worden uitgevoerd door de fabri ­
kant van de adapter en de goedgekeurde werkplaats die de 
adapter heeft geïnstalleerd, maken de correcte interface tussen 
de adapterinput en het voertuig mogelijk, voor zover van toe ­
passing.  
ADA_012 De inputinterface van de adapter moet, voor zover van toepas ­
sing, in staat zijn de frequentie-impulsen van de inkomende 
snelheidsimpulsen te vermenigvuldigen met of te delen door 
een vaste factor, teneinde het signaal te herleiden tot het in 
deze bijlage gedefinieerde bereik van de k-factor (4 000 tot 
25 000 impulsen/km). Deze vaste factor mag alleen worden 
geprogrammeerd door de fabrikant van de adapter en door de 
goedgekeurde werkplaats die de adapter heeft geïnstalleerd.  
4.2. Invoering van de inkomende impulsen in de ingebouwde bewegings ­
sensor  
ADA_013 De inkomende impulsen, eventueel aangepast zoals hierboven 
uiteengezet, worden zodanig in de ingebouwde bewegingssen ­
sor ingevoerd dat elke inkomende impuls door de bewegings ­
sensor wordt gedetecteerd.  
4.3. Ingebouwde bewegingssensor  
ADA_014 De ingebouwde bewegingssensor wordt gestimuleerd door de 
ingevoerde impulsen, waardoor hij bewegingsgegevens kan 
voortbrengen die accuraat de beweging van het voertuig weer ­
geven, alsof er een mechanische interface bestond tussen de 
sensor en een bewegend deel van het voertuig.  
ADA_015 De identificatiegegevens van de ingebouwde bewegingssensor 
worden door de voertuigunit gebruikt om de adapter te identi ­
ficeren [95].  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 541  
ADA_016 De in de ingebouwde bewegingssensor opgeslagen installatie ­
gegevens worden geacht de installatiegegevens van de adapter 
te vertegenwoordigen [122].  
4.4. Veiligheidsvoorschriften  
ADA_017 De behuizing van de adapter wordt zodanig ontworpen dat ze 
niet kan worden geopend. Ze wordt verzegeld, zodat pogingen 
om ermee te knoeien gemakkelijk kunnen worden vastgesteld 
(bijv. door een visuele inspectie, zie ADA_035). De verzege ­
ling moet voldoen aan dezelfde eisen als zegels van be ­
wegingsopnemers [398 tot en met 406]  
ADA_018 Het mag niet mogelijk zijn de ingebouwde bewegingssensor 
los te maken van de adapter zonder het zegel/de zegels van 
de adapterbehuizing of het zegel tussen de sensor en de adap ­
terbehuizing te verbreken (zie ADA_034).  
ADA_019 De adapter moet ervoor zorgen dat bewegingsgegevens uitslui ­
tend kunnen worden verwerkt en afgeleid van de adapterinput.  
4.5. Prestatiekenmerken  
ADA_020 De adapter moet volledig operationeel zijn binnen het door de 
fabrikant vastgestelde temperatuurbereik.  
ADA_021 De adapter moet volledig operationeel zijn binnen het vochtig ­
heidsbereik van 10 % tot 90 % [214].  
ADA_022 De adapter moet tegen overspanning, polariteitomkering en 
kortsluiting worden beveiligd [216].  
ADA_023 De adapter moet:  
— reageren op een magnetisch veld dat de detectie van be ­
weging van het voertuig stoort. In dat geval, wordt door de 
voertuigunit een fout in de sensor [88] geregistreerd en 
opgeslagen, ofwel  
— een aftastelement bevatten dat beschermd is tegen, of on ­
gevoelig is voor, een magnetisch veld [217].  
ADA_024 De adapter moet voldoen aan het internationale reglement VN 
ECE R 10 met betrekking tot elektromagnetische compatibili ­
teit en moet tegen elektrostatische ontladingen en stootspanning 
worden beveiligd [218]  
4.6. Materialen  
ADA_025 De adapter moet voldoen aan beschermingsklasse ( nader vast 
te stellen door de fabrikant, afhankelijk van de installatieposi ­
tie) [220, 221].  
ADA_026 De kleur van de adapterbehuizing moet geel zijn.  
4.7. Merktekens  
ADA_027 Op de adapter moet een opschriftenplaatje worden bevestigd 
waarop de volgende gegevens zijn vermeld:  
— naam en adres van de fabrikant van de adapter,  
— onderdeelnummer van de fabrikant en bouwjaar van de 
adapter,  
— goedkeuringsmerkteken van het type adapter of van het 
type controleapparaat met adapter,  
— de datum waarop de adapter is geïnstalleerd,  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 542  
— het voertuigidentificatienummer van het voertuig waarin de 
adapter is geïnstalleerd.  
ADA_028 Op het opschriftenplaatje moeten ook de volgende bijzonder ­
heden worden vermeld (indien niet direct leesbaar aan de bui ­
tenzijde van de ingebouwde bewegingssensor):  
— naam van de fabrikant van de ingebouwde bewegingssen ­
sor, 
— onderdeelnummer van de fabrikant en bouwjaar van de 
ingebouwde bewegingssensor,  
— goedkeuringsmerkteken van de ingebouwde bewegingssen ­
sor. 
5. INSTALLATIE VAN HET CONTROLEAPPARAAT WANNEER EEN 
ADAPTER WORDT GEBRUIKT  
5.1. Installatie  
ADA_029 Adapters voor installatie in voertuigen mogen alleen worden 
geïnstalleerd door voertuigfabrikanten of door erkende werk ­
plaatsen die gemachtigd zijn om digitale en slimme tachografen 
te installeren, te activeren en te kalibreren.  
ADA_030 Een erkende werkplaats die een adapter installeert, stelt de 
inputinterface in en selecteert de verdeelverhouding van het 
inputsignaal (indien van toepassing).  
ADA_031 Een erkende werkplaats die een adapter installeert, verzegelt de 
adapterbehuizing.  
ADA_032 De adapter wordt zo dicht mogelijk geïnstalleerd bij het deel 
van het voertuig dat de inkomende impulsen levert.  
ADA_033 De kabels voor de stroomvoorziening van de adapter zijn rood 
(positief) en zwart (aarding).  
5.2. Verzegeling  
ADA_034 De volgende verzegelingseisen zijn van toepassing:  
— de behuizing van de adapter wordt verzegeld (zie 
ADA_017),  
— de behuizing van de ingebouwde sensor wordt verzegeld 
aan de adapterbehuizing, tenzij het onmogelijk is de sensor 
uit de adapterbehuizing te verwijderen zonder het zegel/de 
zegels van de adapterbehuizing te verbreken (zie 
ADA_018),  
— de adapterbehuizing wordt verzegeld aan het voertuig,  
— de verbinding tussen de adapter en de apparatuur die de 
inkomende impulsen verstuurt, wordt aan beide uiteinden 
verzegeld (voor zover redelijkerwijze mogelijk).  
6. CONTROLES, INSPECTIES EN HERSTELLINGEN  
6.1. Periodieke controles  
ADA_035 Wanneer een adapter wordt gebruikt, moet bij elke periodieke 
inspectie (overeenkomstig voorschrift [409] tot en met [413] 
van bijlage 1C) van het controleapparaat worden gecontroleerd:  
— of de passende typegoedkeuringsmerktekens op de adapter 
zijn aangebracht,  
— of de zegels op de adapter en de verbindingen intact zijn,  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 543  
— of de adapter geïnstalleerd is zoals aangegeven op het in ­
stallatieplaatje,  
— of de adapter geïnstalleerd is zoals gespecificeerd door de 
aanpasser en/of fabrikant van het voertuig,  
— of het monteren van een adapter is toegestaan voor het 
geïnspecteerde voertuig.  
ADA_036 Bij deze controles moet een kalibrering plaatsvinden en moeten 
alle zegels, ongeacht de staat waarin ze zich bevinden, worden 
vervangen.  
7. TYPEGOEDKEURING VAN HET CONTROLEAPPARAAT WAN ­
NEER EEN ADAPTER WORDT GEBRUIKT  
7.1. Algemeen  
ADA_037 Het volledige controleapparaat, met de adapter, wordt ter type ­
goedkeuring ingediend [425].  
ADA_038 Een adapter kan met het oog op de typegoedkeuring van de 
adapter zelf of met het oog op de typegoedkeuring als onder ­
deel van een controleapparaat worden ingediend.  
ADA_039 Een dergelijke typegoedkeuring moet functionele tests van de 
adapter omvatten. Positieve testresultaten worden op een rele ­
vant certificaat vermeld [426].  
7.2. Functioneel certificaat  
ADA_040 Alleen als de adapter met succes de onderstaande tests heeft 
doorstaan, wordt een functioneel certificaat voor de adapter of 
voor het controleapparaat dat de adapter omvat, afgegeven aan 
de fabrikant van de adapter.  
Nr. Test  Beschrijving  Gerelateerde voorschrif ­
ten 
1. Administratieve controle  
1.1 Documentatie  Correctheid van de 
documentatie van 
de adapter  
2. Visuele inspectie  
2.1. Overeenstemming van de adapter met de docu ­
mentatie  
2.2. Identificatie van/opschriften op de adapter  ADA_027, 
ADA_028  
2.3 Materialen van de adapter  [219] tot en met 
[223] 
ADA_026  
2.4. Verzegeling  ADA_017, 
ADA_018, 
ADA_034  
3. Functionele tests  
3.1 Invoering van de snelheidsimpulsen in de inge ­
bouwde bewegingssensor  ADA_013  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 544  
Nr. Test  Beschrijving  Gerelateerde voorschrif ­
ten 
3.2 Totstandbrenging van interfaces en aanpassing 
van inkomende snelheidsimpulsen  ADA_011, 
ADA_012  
3.3 Juistheid van bewegingsmeting  [30] tot en met [35], 
[217]  
4. Milieutests  
4.1 Testresultaten van de fa ­
brikant  Resultaten van de 
milieutests van de 
fabrikant.  ADA_020, 
ADA_021, 
ADA_022, 
ADA_024  
5. EMC  
5.1 Stralingsemissies en ge ­
voeligheid  Controleer de over ­
eenstemming met 
Richtlijn 2006/28/ 
EG ADA_024  
5.2 Testresultaten van de fa ­
brikant  Resultaten van de 
milieutests van de 
fabrikant.  ADA_024  ▼B
 02016R0799 — NL — 26.02.2020 — 002.001 — 545  
BIJLAGE II  
GOEDKEURINGSMERK EN -CERTIFICAAT  
I. GOEDKEURINGSMERK  
1. Het goedkeuringsmerk bestaat uit:  
a) een rechthoek waarbinnen een kleine letter „e” is aangebracht, gevolgd 
door het nummer of de kenletters van het land waar de goedkeuring is 
afgegeven: 
België  6,  
Bulgarije  34,  
Tsjechië  8,  
Denemarken  18,  
Duitsland  1,  
Estland  29,  
Ierland  24,  
Griekenland  23,  
Spanje  9,  
Frankrijk  2,  
Kroatië  25,  
Italië  3,  
Cyprus  CY,  
Letland  32,  
Litouwen  36,  
Luxemburg  13,  
Hongarije  7,  
Malta  MT,  
Nederland  4,  
Oostenrijk  12,  
Polen  20,  
Portugal  21,  
Roemenië  19,  
Slovenië  26,  
Slowakije  27,  
Finland  17,  
Zweden  5,  
Verenigd Koninkrijk  11,  
en 
▼M1 
b) een goedkeuringsnummer, dat overeenstemt met het nummer op het goed ­
keuringscertificaat dat is opgesteld voor het model van het controleapparaat 
of van het registratieblad of van de tachograafkaart, en aangebracht in een 
willekeurige stand in de nabijheid van die rechthoek.  ▼C1
 02016R0799 — NL — 26.02.2020 — 002.001 — 546  
2. Het goedkeuringsmerk wordt aangebracht op het identificatieplaatje van elk 
apparaat, op elk registratieblad en op elke tachograafkaart. Het moet onuit ­
wisbaar zijn en steeds goed leesbaar blijven.  
3. De afmetingen van het hierna weergegeven goedkeuringsmerk (  1 ) zijn uit­
gedrukt in millimeters en gelden als minimumafmetingen. De verhoudingen 
tussen de afmetingen moeten in acht worden genomen.
  ▼C1 
( 1 ) Deze cijfers worden slechts aangegeven bij wijze van voorbeeld.
 02016R0799 — NL — 26.02.2020 — 002.001 — 547  
II. GOEDKEURINGSCERTIFICAAT VOOR ANALOGE TACHOGRAFEN  
De lidstaat die de goedkeuring heeft afgegeven, verleent de aanvrager een goed ­
keuringscertificaat volgens onderstaand model. Voor de mededeling van afgege ­
ven goedkeuringen aan de overige lidstaten of eventuele intrekkingen gebruikt 
elke lidstaat kopieën van dit document.  
GOEDKEURINGSCERTIFICAAT  
Naam van de bevoegde instantie  
Mededeling betreffende (  1 ): 
— goedkeuring van een type controleapparaat  
— intrekking van de goedkeuring van een type controleapparaat  
— goedkeuring van een modelregistratieblad  
— intrekking van de goedkeuring van een modelregistratieblad  
Goedkeuring nr.:  
...................................  
1. Fabrieks- of handelsmerk  
2. Benaming van het model  
3. Naam van de fabrikant  
4. Adres van de fabrikant  
5. Ter goedkeuring aangeboden op  
6. Getest te:  
7. Datum en nummer van de test(en)  
8. Datum van goedkeuring  
9. Datum waarop de goedkeuring is ingetrokken  
10. Types controleapparaten waarvoor het blad is ontworpen  
11. Plaats  
12. Datum  
13. Bijgevoegde beschrijvende documenten  
14. Opmerkingen (inclusief de eventuele plaats van de verzegelingen)  
(Handtekening)  ▼C1 
( 1 ) Doorhalen wat Niet van toepassing is.
 02016R0799 — NL — 26.02.2020 — 002.001 — 548  
III. GOEDKEURINGSCERTIFICAAT VOOR DIGITALE TACHOGRAFEN  
De lidstaat die de goedkeuring heeft afgegeven, verleent de aanvrager een goed ­
keuringscertificaat volgens onderstaand model. Voor de mededeling aan de ove ­
rige lidstaten van afgegeven goedkeuringen of eventuele intrekkingen gebruikt 
elke lidstaat kopieën van dit document.  
GOEDKEURINGSCERTIFICAAT VOOR DIGITALE TACHOGRAFEN  
Naam van de bevoegde instantie  
Mededeling betreffende (  1 ): 
□ goedkeuring van:  □ intrekking van de goedkeuring van:  
□ een type controleapparaat  
□ een onderdeel van een controleapparaat (  2 ) 
□ een bestuurderskaart  
□ een werkplaatskaart  
□ een bedrijfskaart  
□ een controleurskaart  
Goedkeuring nr.:  
1. Fabrieks- of handelsmerk  
2. Benaming van het model  
3. Naam van de fabrikant  
4. Adres van de fabrikant  
▼M1 
5. Ter goedkeuring aangeboden op  
▼C1 
6. Laboratori(um)(a)  
7. Datum en nummer van het laboratoriumverslag  
8. Datum van goedkeuring  
9. Datum waarop de goedkeuring is ingetrokken  
10. Types controleapparaten waarvoor het onderdeel is ontworpen  
11. Plaats  
12. Datum  
13. Bijgevoegde beschrijvende documenten  
14. Opmerkingen (waaronder desgevallend de plaats van de verzegeling)  
(Handtekening)  ▼C1 
( 1 ) Gelieve de toepasselijke vakjes aan te kruisen. 
( 2 ) In de kennisgeving aangeven welk onderdeel.
 02016R0799 — NL — 26.02.2020 — 002.001 — 549  
IV. GOEDKEURINGSCERTIFICAAT VOOR SLIMME TACHOGRAFEN  
De lidstaat die de goedkeuring heeft afgegeven, verleent de aanvrager een goed ­
keuringscertificaat volgens onderstaand model. Voor de mededeling van afgege ­
ven goedkeuringen of eventuele intrekkingen aan de overige lidstaten gebruikt 
elke lidstaat kopieën van dit document.  
GOEDKEURINGSCERTIFICAAT VOOR SLIMME TACHOGRAFEN  
Naam van de bevoegde instantie  
Mededeling betreffende (  1 ): 
□ goedkeuring van:  □ intrekking van de goedkeuring van:  
□ een type controleapparaat  
□ een onderdeel van een controleapparaat (  2 ) 
□ een bestuurderskaart  
□ een werkplaatskaart  
□ een bedrijfskaart  
□ een controleurskaart  
Goedkeuring nr.:  
1. Fabrieks- of handelsmerk  
2. Benaming van het model  
3. Naam van de fabrikant  
4. Adres van de fabrikant  
▼M1 
5. Ter goedkeuring aangeboden op  
▼C1 
6. a) Testlaboratorium voor functiecertificatie  
b) Testlaboratorium voor veiligheidscertificatie  
c) Testlaboratorium voor interoperabiliteitscertificatie  
7. a) Datum en nummer van het functiecertificaat  
b) Datum en nummer van het beveiligingscertificaat  
c) Datum en nummer van het interoperabiliteitscertificaat  
8. Datum van goedkeuring  
9. Datum waarop de goedkeuring is ingetrokken  
10. Types controleapparaten waarvoor het onderdeel is ontworpen  
11. Plaats  
12. Datum  
13. Bijgevoegde beschrijvende documenten  
14. Opmerkingen (waaronder desgevallend de plaats van de verzegeling)  
(Handtekening)  ▼C1 
( 1 ) Gelieve de toepasselijke vakjes aan te kruisen. 
( 2 ) In de kennisgeving aangeven welk onderdeel.