Veelgestelde vragen fabrikanten Boordcomputer Taxi - Inspectie ...

Veelgestelde vragen fabrikanten Boordcomputer Taxi 

Algemeen 

# Vraag Antwoord 

1 Waar worden de specificaties voor de Boordcomputer Taxi beschikbaar 

gesteld 

De specificaties zijn opgenomen in de Regeling specificaties en typegoedkeuring 

boordcomputer taxi. De regeling is te downloaden van 

https://zoek.officielebekendmakingen.nl/stcrt-2010-11225.html 

2 Worden de specificaties vertaald naar het Engels Nee, niet door de Inspectie Verkeer en Waterstaat. 

3 Wanneer verwacht de Inspectie VenW de boordcomputer kaarten voor 

de fabrikanten beschikbaar te hebben 

De Europese Commissie heeft de Regeling Specificaties en Typegoedkeuring die ter 

notificatie is aangeboden vertaald, maar hier kunnen geen rechten aan worden ontleend. 

Deze vertaling wijkt op een klein aantal punten af van de Nederlandse Regeling 

specificaties en typegoedkeuring boordcomputer taxi. De vertaling is hieronder te vinden. 

http://ec.europa.eu/enterprise/tris/pisa/app/search/index.cfm 

fuseaction=pisa_notif_overview&iYear=2010&inum=104&lang=EN&sNLang=EN 

Er komen referentiekaarten en echte boordcomputerkaarten beschikbaar. 

Referentiekaarten zijn kaarten die gelijk zijn aan de boordcomputerkaarten, maar gemaakt 

worden zodat de fabrikanten hun BCT kunnen ontwikkelen en een typegoedkeuring 

kunnen aanvragen. Pas nadat de BCT een typegoedkeuring heeft is kan deze werken met 

de echte boordcomputerkaarten. 

Boordcomputerkaarten zijn voorzien van één of meerdere digitale certificaten. Door het 

faillissement van de leverancier hiervan, DigiNotar, wordt nu door een andere leverancier 

een nieuwe productiefaciliteit voor deze certificaten ingericht. Naar verwachting zullen de 

‘echte’ boordcomputerkaarten hierdoor vanaf 1 april 2012 beschikbaar zijn. 

4 Artikel 11 noemt: 

" De boordcomputer stelt in de operationele modus, werkingsniveau 

taxivervoer, ten behoeve van het afdrukken van een ritbewijs ten 

minste de volgende gegevens, inclusief een korte aanduiding van het 

gegeven, ter beschikking....." 

De toelichting van artikel 1 en 11 lijkt vrij dwingend mbt het altijd 

uitprinten van een bon, echter zijn er situaties dat er wel een BCT in het 

De testreferentiekaarten zijn beschikbaar en kunnen worden besteld via: 

VragenfabrikantenBCT@ivw.nl. 

De Regeling dubbeltariefsysteem vereist een automatisch gegenereerd ritbewijs. 

Dit ritbewijs is niet vereist indien het contractvervoer betreft. De definitie van 

contractvervoer is dan: taxivervoer dat wordt verricht ter uitvoering van een schriftelijke 

overeenkomst waarbij gedurende een bij die overeenkomst vastgestelde periode 

meermalen taxivervoer wordt verricht tegen een in die overeenkomst vastgelegd tarief. 

Omdat er geen ritbewijs hoeft te worden overhandigd, hoeft er dan ook geen printer in de 

Versie 1.9 pagina 1/48 Datum: 15-5-2013



voertuig zit, maar een printer een overbodige investering lijkt: 

taxi aanwezig te zijn, 

Het gaat hierbij om contractvervoer waaraan geen 'directe financiele 

transactie' (dus ook geen bijdrage) gekoppeld is. De factuur voor het 

gehele vervoer bevat dan het 'ritbewijs'. Eigenlijk gaat het hierbij dan 

om een soort touringcar vervoer, maar aangezien alle voertuigen met 

blauwe kentekenplaten een BCT moeten hebben, komt dit wel voor. 

Is het mogelijk om het ritbewijs (de printer) achterwege te laten bij 

ritten zonder een directe financiele transactie 

5 Is het toegestaan boordcomputers te leveren met een softwarelicentie 

met een beperkte geldigheid 

De BCT regelgeving stelt de vervoerder verantwoordelijk voor het goed functioneren van 

de BCT. Hieronder kan in beginsel ook het tijdig nieuwe licenties voor de BCT aanschaffen 

vallen. Maar daarmee is nog niet het antwoord gegeven op de vraag of de fabrikanten vrij 

zijn om met licenties te werken. Daarvoor hebben fabrikanten ook te maken met de 

mededingingswet. 

Artikel 24 van die wet verbiedt ondernemingen om misbruik te maken van economische 

machtsposities. Van zo'n machtspositie zou in dit geval sprake kunnen zijn. Fabrikanten 

ontlenen immers een commercieel voordeel aan de omstandigheid dat vervoerders 

wettelijk verplicht zijn om de BCT goed te laten functioneren. 

Hoewel de BCT regelgeving het voeren van een systeem van licenties niet in de weg staat 

wordt wel op het risico van een mogelijke overtreding van de mededingingswet gewezen. 

Wellicht is het verstandig om dit aspect voor de eigen propositie door een ter zake 

deskundige jurist te laten toetsen. 



Specificaties 


1 Mag de GPS sensor ook een externe module zijn van de Boordcomputer 

Taxi 

Ja dat mag, mits er voldaan wordt aan de gestelde kwaliteitseisen voor de Boordcomputer 

Taxi. 

2 Mag de additionele software gebruik maken van bijvoorbeeld 

voorgeschreven functionaliteiten zoals de GPS sensor 

Meergebruik op het systeem is in beginsel toegestaan zolang de beveiligingseisen van de 

Boordcomputer Taxi intact blijven. Tijdens de beveiligingsevaluatie zal ook dit meer 

gebruik worden beoordeeld en dient te worden aangetoond dat het systeem als zodanig 

veilig is. 

3 Met welke frequentie vindt de periodieke opslag van GPS coördinaten 

door de Boordcomputer Taxi plaats 

Conform artikel 7 lid 6 van de regeling registreert de Boordcomputer de coördinaten met 

een interval van één maal per minuut. 

4 Moet de BCT weggebouwd worden, of kan de BCT op het dashboard als 

één geheel (dus inclusief scherm en paslezer chauffeur) gemonteerd 

worden 

5 Het scherm voor de BCT wordt eigenlijk alleen gebruikt voor begin 

dienst en einde dienst. Is het scherm voor de rest beschikbaar voor 

ander doeleinden b.v. navigatie, rit aanname etc. 

6 In artikel 10 lid 2 (blz. 6), wordt gesproken over het aantal zitplaatsen. 

Wat is hier de bedoeling van, wat moet er vastgelegd worden enz. En 

heeft dit alleen te maken met verhuur per zitplaats 

Vanuit de regelgeving bestaat er geen verplichting om de BCT weg te bouwen. De 

fabrikant bepaald de uiteindelijke verschijningsvorm van de BCT, zolang deze voldoet aan 

de eisen die er vanuit de regelgeving aan worden gesteld. Een BCT kan dus als één geheel 

(inclusief scherm en paslezer chauffeur) op het dashboard gemonteerd worden. 

Zolang er minimaal de werkingsmodus/werkingsniveau, kilometerstand en plaatselijke 

datum en tijd (zie artikel 21, eerste lid) op het scherm wordt getoond, kan het scherm 

verder gebruikt worden voor doeleinden die niet met de BCT samenhangen, zolang de 

boordcomputer blijft voldoen aan de eisen die de regelgeving eraan stelt. 

Artikel 10 lid 2 schrijft voor dat de boordcomputer een volledige ritadministratie moet 

kunnen vastleggen per zitplaats. Hiermee wordt het mogelijk gemaakt om verhuur per 

zitplaats te faciliteren. Als er per zitplaats vervoer wordt aangeboden, zal ook de 

ritadministratie per zitplaats volledig moeten worden vastgelegd. 

7 Situatie: de BCT heeft een storing en de BCT bevindt zich niet in het 

directe gezichtsveld van de bestuurder. 

Vraag: voldoet dan de foutsignalering middels een led- of zwaailamp 

o.i.d. (kleur oranje, rood, blauw, enz.) die zich wel in het directe 

gezichtsveld van de bestuurder bevindt De bestuurder dient 

vervolgens op het scherm/ bedieningspaneel o.i.d. van de BCT te kijken 

om welke storing het exact gaat. Hierbij dient er vanuit gegaan te 

worden dat op de BCT/scherm/bedieningspaneel een duidelijk 

afleesbare (tekst) foutmelding staat. 

8 Is het vanuit de diverse BCT-regelingen toegestaan, wanneer een BCTimplementatie 

uit meerdere delen bestaat, om een van de delen los te 

De oplossing die door de fabrikant gekozen is gaat uit van een getraptheid in de melding 

van storingen. In eerste instantie wordt het feit dat er een storing ontstaan is gemeld 

middels een visueel signaal, waarop vervolgens de gebruiker extra informatie betreffende 

de melding op kan zoeken. 

De opzet van artikel 29 verzet zich in beginsel niet tegen deze getrapte oplossing, mits de 

gebruiker hiermee in staat wordt gesteld om te voldoen aan de eisen uit de Regeling 

gebruik. Meer in brede zin geldt voor alle functionaliteit van de boordcomputer dat deze 

de gebruiker in staat moet stellen te voldoen aan de geldende weten regelgeving. Een 

relevant artikel in dit geval is bijvoorbeeld Artikel 18 van de Regeling Gebruik 

Boordcomputer en Boordcomputerkaarten. 

Een BCT-implementatie dient te voldoen aan de eisen die worden gesteld in de Regeling 

Boordcomputer Taxi en overige relevante regelgeving. Hierbij wordt geen 




koppelen, tijdelijk uit de taxi te halen en vervolgens bij een volgend 

gebruik weer terug te plaatsen 

implementatievorm voorgeschreven. Of het is toegestaan om één van de onderdelen los 

te koppelen en bij een volgend gebruik weer terug te plaatsen hangt met name samen 

met het al dan niet voldoen aan de beveiligingseisen zoals gesteld in bijlage 1 van de 

regeling. Het is dan ook raadzaam om dergelijke concrete implementatievragen voor te 

leggen aan het laboratorium dat de Common Criteria certificering zal uitvoeren. 

9 Moet het op de BCT, naast BSN, ook mogelijk zijn handmatig op basis 

van een NI nummer het werkingsniveau arbeidstijd in te schakelen 

Ja, het NI nummer moet kunnen worden gebruikt om het werkingsniveau arbeidstijd in te 

schakelen. 

10 Op basis van de specificaties in artt. 26, 27 en 29 moet een 

onderbreking van ten minste vijf seconden in de stroom leiden tot een 

detectie van een fout in de registratiefunctie en een waarschuwing die 

handmatig bevestigd moet worden door de gebruiker. 

Ja, de waarschuwing kan worden getoond nadat de spanningsonderbreking is hersteld. 

Wordt er voldaan aan de gestelde eisen als de BCT deze waarschuwing 

(met bevestiging) toont bij het opstarten nadat de 

spanningsonderbreking is hersteld 

11 In artikel 19 lid 4 worden verschillende onderdelen genoemd: 

1. Personenvervoer nummer 

2. KvK nummer 

3. Nummer ondernemerskaart 

4. Datum/tijd inschakeling bedrijfsvergrendeling (als van toepassing) 

5. Datum/tijd uitschakeling bedrijfsvergrendeling (als van toepassing) 

Alles moet geregistreerd worden, maar welke onderdelen hiervan 

moeten worden gebruikt voor bepalen unieke bedrijfsvergrendeling 

Combinatie Personenvervoer- en KvK-nummer 

12 Gaat de bedrijfsvergrendeling goed als een ondernemer meerdere 

ondernemerskaarten heeft Of hebben deze ondernemerskaarten dan 

allemaal hetzelfde nummer 

Alle "bedrijfsgegevens" moeten opvraagbaar zijn met een 

ondernemerskaart wat niet meer mogelijk lijkt te zijn als er meerdere 

kaarten met verschillende nummers van de ondernemerskaart. 

De bedrijfsvergrendeling komt op basis van artikel 19, derde lid, tot stand op basis van een 

bepaalde ondernemerskaart. 

Iedere ondernemerskaart heeft een uniek nummer bestaande uit: 

De letter O; 

Het KvK nummer van de onderneming; 

Het volgnummer van de kaart. 

Om de bedrijfsvergrendeling uniek te identificeren is het KvK nummer voldoende. 

Het kaartnummer van de ondernemerskaart is als volgt opgebouwd: 

[Kaarthoofdtype] + [KvK-nummer] + “-“ + [Kaartvolgnummer] 

Het kaartnummer van de eerste kaart voor een ondernemer met KvKnummer 123456789 

wordt dan O123456789-00001. Als deze ondernemer een tweede kaart aanvraagt, zal 

deze het nummer O123456789-00002 krijgen. 

Zie hiervoor ook de certificaatprofielen voor de BCT kaarten op 

http://www.ivw.nl/Images/Certificaatprofielen%20BCT%20kaarten_tcm247-277890.pdf. 

13 Is het juist dat "alleen gegevens die zijn vastgelegd behorende bij de Ja, alle gegevens die voor een ondernemer zijn vastgelegd, in één of meerdere 




actieve bedrijfsvergrendeling" (artikel 12 lid 2) betekent "alleen 

vergrendelingen, dienen aan die ondernemer beschikbaar gemaakt te kunnen worden. 

gegevens die zijn vastgelegd op een moment dat de huidige 

bedrijfsvergrendeling, of een eerdere bedrijfsvergrendeling van 

dezelfde vervoerder, actief was" 

14 Is het juist dat dit ook geldt voor arbeids-, rij- en rusttijden die vanaf een 

chauffeurskaart naar de BCT zijn gekopieerd (volgens artikel 17 lid 15), 

zodat vervoerder A geen gegevens geleverd krijgt die zijn geregistreerd 

tijdens de bedrijfsvergrendeling van vervoerder B 

Nee, de volledige inhoud van de chauffeurskaartdata dient aan de ondernemer van de 

actieve bedrijfsvergrendeling beschikbaar gemaakt te kunnen worden. 

15 Artikel 14 lid 3 luidt: 

Indien een stroomonderbreking heeft plaatsgevonden en de 

stroomvoorziening is hersteld, wordt de boordcomputer automatisch 

teruggebracht in de staat waarin de boordcomputer zich bevond 

voordat de stroomonderbreking optrad. 

Met “de staat” wordt bedoeld de toestand waarin de boordcomputer zich bevond op het 

moment dat de stroomonderbreking optrad. 

Wat is de definitie van "de staat" in deze eis 

16 Met "de staat" wordt bedoeld de toestand waarin de boordcomputer 

zich bevond op het moment dat de stroomonderbreking optrad. 

Moeten "de staat" worden geïnterpreteerd als de staat m.b.t. 

'ingeschakeld' of 'uitgeschakeld'. En als dit het geval is, wat wordt dan 

verstaan onder 'ingeschakeld'/'uitgeschakeld' 

Of moet de situatie (gebruikersscherm, werkingsmodus, operationele 

modus, registratie, etc.) na een spanningsonderbreking volledig identiek 

zijn vergeleken met voor de spanningsonderbreking Dit laatste kan wel 

in verschillende situaties niet/slecht realiseerbaar zijn. Bijv. in de 

situatie dat door de spanningsuitval een fout optreedt, gedurende het 

genereren van gegevensoverdracht data, registratie ritgegevens, etc. 

17 Artikel 11 stelt onder punt e) dat op het ritbewijs het nummer van de 

chauffeurskaart van de bestuurder afgedrukt moet worden. 

Als de chauffeur met zijn BSN of NI nummer is aangemeld, dient dan het 

BSN of NI nummer op het ritbewijs afgedrukt te worden 

18 Art 17 lid 2: De boordcomputer negeert ingebrachte ongeldige 

boordcomputerkaarten. 

Met de staat wordt bedoeld de werkingsmodus waarin de boordcomputer zich bevond 

voor de stroomonderbreking. Let hierbij overigens wel op de herauthenticatie eis uit 

FIA_UAU.6.1 in artikel 6.2 van bijlage 1. 

Nee, alleen bij het gebruik van de kaart is voldoende zekerheid over de identiteit van de 

chauffeur om het chauffeurskaartnummer op de bon te gebruiken. Bij handmatige invoer 

van BSN of NI is die zekerheid er onvoldoende. 

In artikel 1 van de regeling is de volgende definitie opgenomen: 

ongeldige boordcomputerkaart: ingetrokken boordcomputerkaart, defecte 

boordcomputerkaart, of een boordcomputerkaart waarvan de geldigheidsduur nog niet is 




Art 27 lid 1: Het optreden van de onderstaande gebeurtenissen leidt tot 

een fout als bedoeld in artikel 26, tweede lid, onderdeel i: 

a.het inbrengen van een ongeldige boordcomputerkaart; 

begonnen of reeds is verstreken; 

Huidige interpretatie / aannames: 

1. Als er een kaart wordt ingebracht (bijvoorbeeld een bankpas, karton, 

etc) die niet is geconfigureerd (de ATR, Answer To Reset, komt niet 

overeen met de kaartspecificatie) als boordcomputerkaart wordt deze 

genegeerd. Er wordt ook geen foutmelding vastgelegd. 

2. Als blijkt dat de ingebrachte kaart een ongeldig certificaat bevat 

(bijvoorbeeld verlopen of ongeldige handtekening) dan beschouwen we 

dat als een ongeldige boordcomputerkaart en wordt er een foutmeldig 

vastgelegd. 

Conform artikel 27, eerste lid, onderdeel a moet het inbrengen van een ongeldige 

boordcomputerkaart als foutmelding worden opgeslagen. Let hierbij op dat ook het 

inbrengen van een defecte kaart moet leiden tot een opgeslagen foutmelding. 

Zijn deze interpretaties / aannames correct 

19 Artikel 9 lid 7 van de Regeling BCT (van 19 juli 2010): "De 

boordcomputer toont de gegevens waarover een elektronische 

handtekening geplaatst wordt." 

Betekent dit dat alle geregistreerde gegevens aan de gebruiker getoond 

moeten worden (en door de gebruiker geaccepteerd) voordat ze met 

een elektronische handtekening worden weggeschreven 

Wat is de essentie van deze eis en hoe ver moeten we hierin gaan Is 

een overzicht (staat met totalen bijvoorbeeld) voldoende, of moet elk 

gegeven getoond worden 

20 Dient alleen handmatig ingevoerde informatie zoals start/stop, 

ritbedrag e.d. geannuleerd te kunnen worden, of geldt dit ook voor 

ingevoerde 'voorgaande werkzaamheden' 

De bestuurder moet weten over welke gegevens hij een handtekening plaatst. De 

bestuurder verklaart daarmee immers dat zijn 

- Rijtijd; 

- andere werkzaamheden dan rijden; en 

- pauze 

juist zijn. 

Minimaal moet aan de bestuurder de totalen van de aan deze activiteiten besteedde tijd 

van de af te sluiten kaartsessie worden getoond. 

Het is de bedoeling dat alle handmatig ingevoerde gegevens kunnen worden geannuleerd. 

Ook de ‘voorgaande werkzaamheden’ vallen onder handmatig ingevoerde gegevens en 

dienen te kunnen worden geannuleerd. 

Overigens kunnen uitsluitend de laatste handmatige ingevoerde en geaccepteerde 

gegevens worden geannuleerd. Het is bijvoorbeeld niet toegestaan om na het uitvoeren 

van de derde rit van de dag vervolgens de eerste rit te annuleren. 

Deze voorziening is met name bedoeld om fouten bij de handmatige invoer direct te 




kunnen corrigeren. 

21 Als ik het goed begrijp is het doel van de bandenmaat (lid 5g) dat bij 

inspectie een controle kan worden uitgevoerd of er wel dezelfde 

banden (met gelijke diameter) op het voertuig zitten zoals die ook 

tijdens activatie aanwezig waren. De ingegeven bandenmaat dient 

overeen te komen met de aanduiding op de banden. Het standaard 

(99% is radiale band) formaat van de bandencode is xxx-xx Rxx. 

Hoe de bandenmaat in het systeem wordt opgeslagen is niet voorgeschreven, zolang de 

bandenmaat als zodanig herkenbaar is op het scherm (Art. 22, vijfde lid juncto art. 21, 

tweede lid) en op de juiste manier in de gegevenslevering Onderzoek wordt opgenomen. 

Om het invoer voor de gebruiker eenvoudig te houden is het voorstel 

om bij invoer het formaat xxx-xx Rxx, waarbij de “-“ en “R” door de BCT 

al ingevuld worden. 

In het geval er toch een vreemde bandenmaat aanwezig is kan dit in het 

veld met opmerkingen (lid 5i) worden aangeven. 

Is het standaard plaatsen van "-" en "R" toegestaan, zodat alleen 

numerieke input ingevoerd hoeft te worden bij activatie 

22 Hoeven zowel de ingevoerde bandenmaat als de effectieve omtrek 

alleen in de BCT worden opgeslagen en op verzoek te worden 

uitgevoerd 

23 Bij de eerste bedrijfsvergrendeling voor een onderneming moeten een 

aantal aanvullende gegevens in de boordcomputer worden ingebracht. 

Bij grote ondernemingen moeten er dan bij veel BCT’s gegevens worden 

ingevoerd. Mogen deze gegevens ook geautomatiseerd van een extern 

medium ingeladen worden 

24 Artikel 15 lid 3 stelt: uitsluitend de laatste handmatig ingevoerde en 

geaccepteerde informatie kan door de bestuurder worden geannuleerd. 

Deze handeling wordt door de boordcomputer geregistreerd. 

In de toelichting worden als situaties genoemd: 

- begin en einde rit 

- begin en einde pauze 

- beladen of onbeladen 

De ingevoerde bandenmaat en de effectieve omtrek dienen als controle informatie bij 

keuring. Op basis hiervan kan een keurmeester nagaan op basis van welke informatie de 

constante van de boordcomputer tot stand is gekomen. 

Het systeem hoeft inderdaad niets anders te doen dat opslaan en uitvoeren. 

Ja, de additionele gegevens van een taxionderneming die tijdens het instellen van de 

eerste bedrijfsvergrendeling voor die onderneming moeten worden ingevoerd mogen 

vanaf een extern opslagmedium ingeladen worden. De gegevens die op de 

Ondernemerskaart staan dienen van de ondernemerskaart overgenomen te worden. 

a) Artikel 15 is van toepassing in alle gevallen waarin de bestuurder een handmatige 

handeling verricht 

b) Zie hiervoor de definitie van bestuurder: de bestuurder van een taxi. Het betreft dus de 

chauffeur van een taxi en niet de anderen. 

c) De annulering van “voorgaande werkzaamheden” moet per handeling. Hoe dit 

geïmplementeerd wordt is aan de fabrikant. 




a) Het is precies niet duidelijk in welke situaties dit artikel van 

toepassing is. 

b) Geldt dit alleen voor de chauffeur en niet voor de ondernemer, 

inspecteur of werkplaats 

c) Moet invoer van “voorgaande werkzaamheden” per regel of mag een 

tabel ineens Bij een tabel ineens is annuleren van de laatste actie 

lastiger. 

25 Moeten bij het overnemen van de chauffeurskaartgegevens op de 

boordcomputer ook de chauffeursgegevens worden overgenomen die 

zijn geregistreerd tijdens een dienst bij een andere ondernemer 

Wat gebeurt er als het geheugen vol is: bij grotere ondernemingen met 

veel chauffeurswisselingen staat na enige tijd op elke BCT een kopie van 

elke chauffeurskaart. 

De eis dat een chauffeur iedere vijf weken zijn chauffeurskaartgegevens moet 

overbrengen naar de boordcomputer wordt gegeven in de ‘Regeling gebruik 

boordcomputer en boordcomputerkaarten’, art. 19, derde lid 

(http://wetten.overheid.nl/BWBR0028974/). 

Conform artikel 8.1 onder toelichting b van de ‘Regeling specificaties en typegoedkeuring 

boordcomputer taxi’ (http://wetten.overheid.nl/BWBR0027945) bevat 

chauffeurskaartdata “de BASE64 gecodeerde weergave van de binaire inhoud van het 

bestand EF.Driver_Activity_Data, overgenomen van de chauffeurskaart”. Hierbij wordt 

geen onderscheid naar ondernemer gemaakt. 

26 In bijlage 2, artikel 6.1 van de regeling staat op pag. 68 bij de toelichting 

onder punt f het volgende: 

f.het attribuut ‘Status rijden auto’ wordt ingevuld op basis van gegevens 

van de verplaatsingsopnemer. 

Dit lijkt ons niet correct. Wij verwachten dat hier de bewegingsopnemer 

wordt bedoeld. 

Uit de ‘Kaartstructuur Chauffeurskaart’ 

(http://www.ivw.nl/Images/Kaartstructuur%20Chauffeurskaart_tcm247-277894.pdf) volgt 

dat de chauffeurskaartdata zo’n 50kB groot is voor de periode van 5 weken. Bij het 

downloaden van de boordcomputerdata per 3 maanden door de ondernemer levert dit 

een geheugengebruik op van 150kB per chauffeur. Mocht het geheugen van de 

boordcomputer vol zijn worden de oudste gegevens met de nieuwste gegevens 

overschreven zoals voorgeschreven in de ‘Regeling specificaties en typegoedkeuring 

boordcomputer taxi), art. 20, vierde lid, tenzij deze gegevens nog geen 52 weken oud zijn 

(art. 20, tweede lid). In dat geval treedt een fout op (art. 27, tweede lid onder a). 

Een belangrijke indicator of er gefraudeerd wordt met de BCT is of het voertuig in 

beweging is als er een bepaalde foutmelding optreedt. Om de BCT voor het bemerken van 

deze verplaatsing niet afhankelijk te laten zijn van een externe sensor, is gekozen voor een 

interne verplaatsingsopnemer conform artikel 5, vijfde lid. De toelichting bij bijlage 2, 

artikel 6.1 onder punt f. is dus correct. 

27 Onze oplossing zal bestaan uit een gecertificeerde BCT die voldoet aan Volgens FDP_ITC.1.3 verwerkt de TFS alleen gegevens als deze afkomstig zijn van o.a. 




de wettelijke eisen, en een aanvullend apparaat dat kan voldoen aan de 

bredere wensen van de klant. Hier komt direct een praktische wens/eis 

naar voren namelijk voornamelijk centraal bedienen van de apparatuur. 

Of je nu een eenvoudige losse taximeter gekoppeld hebt, of een 

uitgebreidere boord computer, het is per definitie wenselijk om basis 

bediening zoals het starten en stoppen van ritten en pauzes etc, 

eenmalig te doen op één apparaat. Als je deze handelingen dubbel zou 

moeten doen is dit a) onhandig, en b) verhoogd het de kans op fouten. 

Is het handmatig invoeren van gegevens op een extern apparaat en 

deze gegevens vervolgens overnemen in de boordcomputer 

toegestaan 

28 Volgens de regeling bijlage 1 heeft alleen de werkplaats het recht om de 

software van de BCT te wijzigen. Zie hiervoor 

bijlage 1, p28, FDP_ACF.1.2 bullet 6: WERKPLAATS mag 

O.SYSTEEMGEGEVENS aanpassen. Het software versie nummer 

is onderdeel van de systeemgegevens. 

In de praktijk zal het grote logistieke problemen opleveren als iedere 

taxi voor een software update langs een werkplaats 

moet komen. Uitrol van een software update binnen een grote 

taxionderneming vindt bij voorkeur plaats via draadloze 

data communicatie. Het starten van de installatie van een software 

update kan naar onze mening het beste door de 

operationele eindgebruiker (bestuurder) worden uitgevoerd. De 

feitelijke installatie kan daarna zonder tussenkomst van 

de bestuurder worden uitgevoerd. 

Daarom verzoeken wij toe te staan dat een BESTUURDER (indien 

invoer door de gebruiker via het bedieningspaneel. Het bedieningspaneel is in Figuur 4 

weergegeven als onderdeel van de TOE. Artikel 15, tweede lid van de Regeling 

specificaties stelt dat verplichte informatie die niet automatische met sensoren kan 

worden vergaard ook via een externe interface kan worden ingevoerd. Hierbij moet de 

bestuurder deze informatie handmatig accepteren via het bedieningspaneel op de BCT. 

Voor de toepassing van het PP wordt de handmatige acceptatie door de bestuurder op de 

TOE van informatie die buiten de TOE is ingevoerd gelijkgesteld met de invoer door de 

gebruiker via het bedieningspaneel. 

Bij het aangeven van de start en het einde van een rit kan het voorkomen dat de 

bestuurder deze eerst invoert op een extern apparaat en vervolgens moet bevestigen op 

de TOE. Hierbij dan nog steeds sprake van een dubbele handeling die meerder keren per 

dag zal plaatsvinden. Omdat dit de foutkans verhoogd is het toegestaan het starten en 

stoppen van een rit door de TOE te laten overnemen zonder dat de bestuurder dit hoeft te 

bevestigen. Hierbij dient wel steeds een waarschuwingssignaal te worden gegeven 

conform artikel 29, tweede en derde lid van de Regeling specificaties, zodat het de 

bestuurder duidelijk is dat de handeling door de boordcomputer is vastgelegd. 

Het is inderdaad correct dat alleen de werkplaats het recht heeft om software van de BCT 

te wijzigen. In de specificaties is hier voor de bestuurder geen rol voorzien. Als een 

bestuurder de mogelijkheid heeft uitvoerbare code te laden zou deze immers ook code 

van een discutabele herkomst kunnen uitvoeren. Om te voorkomen dat andere software 

dan legitieme updates worden uitgevoerd is deze taak voorbehouden aan de 

werkplaatsen. 

Door de upgrades door de werkplaatsen uit te laten voeren kon de noodzaak voor een 

periodieke keuring vervallen. Uitgangspunt voor de BCT blijft immers dat het een 

aantoonbaar betrouwbaar systeem is op basis waarvan handhaving kan plaatsvinden. Om 

aan de logistieke bezwaren rond het uitrollen van softwareupgrades door de fabrikanten 

tegemoet te komen is de mobiele werkplaats mogelijk gemaakt. 




aangemeld met een chauffeurskaart) een 

via draadloze communicatie verkregen software update op een BCT 

mag installeren. Uiteraard blijft hierbij de vereiste 

check door de BCT op authenticiteit van de software update van kracht. 

29 Artikel 4 lid 8 stelt dat het mogelijk moet zijn voor een chauffeur om in 

te loggen met zijn/haar BSN nummer. 

Scenario 1. Het invoeren van een inspectiekaart terwijl een BSN sessie 

actief is. 

Artikel 4 lid 10 stelt dat het invoeren van de inspectiekaart leidt tot het 

pauzeren van de operationele modus, "inclusief de betreffende 

kaartsessie". 

Afgezien van het pauzeren van de kaartsessie op de chauffeurskaart, 

omdat deze niet bestaat, behandelen wij de BSN sessie volgens dezelfde 

regels die gelden bij een chauffeurskaart. De sessie zal geblokkeerd 

worden en als deze binnen 60 minuten niet voortgezet wordt, zal deze 

afgesloten worden. Is deze aanname correct 

30 Artikel 4 lid 8 stelt dat het mogelijk moet zijn voor een chauffeur om in 

te loggen met zijn/haar BSN nummer. 

Scenario 2. Het invoeren van een chauffeurskaart / werkplaatskaart / 

ondernemerskaart terwijl een BSN sessie actief is. 

Deze aanname is correct. Een sessie die tot stand komt op basis van een BSN nummer 

dient op dezelfde wijze behandeld te worden als een reguliere chauffeurskaartsessie. Het 

uitnemen van de chauffeurskaart, zonder aan te geven dat de kaartsessie wordt 

beëindigd, resulteert in het blokkeren van die sessie (art. 17 lid 9). Het inbrengen van een 

inspectiekaart levert een situatie op als bedoeld in art. 4 lid 10, waarbij de operationele 

modus, inclusief de geblokkeerde kaartsessie, wordt gepauzeerd. Nadat de inspectiekaart 

weer is verwijderd wordt de operationele modus weer actief. Hierbij is dan nog steeds 

sprake van een geblokkeerde kaartsessie. 

Ja, een sessie die tot stand komt op basis van een BSN nummer dient op dezelfde wijze 

behandeld te worden als een reguliere chauffeurskaartsessie. 

Volstaat het om de BSN sessie af te breken, een nieuwe sessie te starten 

voor de desbetreffende kaart 

31 Wissen van gegevens na exporteren tijdens het deactiveren van de BCT 

In de ‘Regeling specificaties en type goedkeuring boordcomputer taxi’ 

wordt het volgende beschreven in artikel 23 lid 4: 

‘De ingevolge het tweede en derde lid overgebrachte gegevens worden 

na een succesvolle overbrenging ervan gewist, met uitzondering van de 

gegevens, bedoeld in artikel 22, tweede lid.’ 

Het gaat hier om de gegevens die tijdens het deactiveren van de BCT 

geëxporteerd dienen te worden en daarna gewist moeten worden. Dit 

lezen wij als automatisch wissen nadat alle gegevens succesvol 

De handmatige bevestiging van het wissen van de gegevens is opgenomen om te 

voorkomen dat er per ongeluk gegevens worden gewist. Een implementatievorm is niet 

voorgeschreven, maar zonder het overbrengen en wissen van de gegevens van een te 

deactiveren boordcomputer is er geen sprake van een succesvolle deactivering. 




overgebracht zijn naar een extern opslagmedium. 

Echter staat er in de toelichting op artikel 23 lid 4 het volgende 

beschreven: 

‘Na de overbrenging van deze gegevens worden deze na handmatige 

bevestiging gewist.’ 

Wat betekent in dit geval handmatige bevestiging Moet dit een 

melding zijn waarbij de gebruiker alleen met OK kan bevestigen of moet 

dit een vraag zijn die gesteld wordt waarbij de gebruiker JA of NEE kan 

kiezen Indien er gekozen wordt voor de JA/NEE optie wat gebeurd er 

dan als er op NEE wordt geklikt. 

Is het toegestaan pas te deactiveren als de gegevens succesvol zijn 

overgebracht en het geheugen is gewist Indien dit namelijk niet 

mogelijk is is er sprake van een defect apparaat en dient deze sowieso 

terug naar fabrikant te gaan. 

32 Mag de BCT bediend worden tijdens het rijden. 

Er wordt in de regelgeving niet beschreven dat tijdens het rijden het 

niet toegestaan is om de BCT te bedienen. Denk hierbij aan het starten 

van een rit of pauze. 

Vanuit sommige klanten is er de wens om dit niet te staan vanuit onder 

andere veiligheidsoverwegingen. 

Is het toegestaan om via de ondernemerskaart dit als instelling aan te 

bieden waarbij de BCT dus niet bedienbaar is als er voertuigbeweging 

wordt gedetecteerd 

33 Wij zien een onduidelijkheid m.b.t. bijlage 1, artikel 6.3 BCT 

toegangsbeleid / FDP_ACF.1.2: 

Hierin staat dat de bestuurder, toezichthouder, werkplaats en 

vervoerder O.KAARTHOUDERGEGEVENS mag tonen op een leesvenster. 

De toezichthouder, werkplaats en vervoerder mogen deze gegevens ook 

exporteren. 

Hiervoor is in bijlage 2 artikel 8 chauffeurskaartdata het xml formaat 

gespecificeerd. 

Hieruit concluderen wij dat het de bedoeling is dat de 4 rollen de 

kaartdata die door een chauffeur naar de BCT is gekopieerd, op het 

scherm moet kunnen tonen. 

Functionaliteit van de boordcomputer die niet is beschreven in de regeling valt in de 

categorie aanvullende functionaliteit. Aanvullende functionaliteit op het systeem is in 

beginsel toegestaan zolang de beveiligingseisen van de Boordcomputer Taxi intact blijven. 

Tijdens de beveiligingsevaluatie zal ook deze aanvullende functionaliteit worden 

beoordeeld en dient te worden aangetoond dat het systeem als zodanig veilig is. 

Dit is correct. De bestuurder, toezichthouder, werkplaats en vervoerder mogen zowel de 

kaarthoudergegevens die op de kaart geleverd worden als de geregistreerde rij- en 

rusttijden op het leesvenster tonen. 

34 In bijlage 1, artikel 6.3, FDP_ACF.1.2 staat dat de vervoerder basis-, De redactie van het artikel is wat ongelukkig met betrekking tot de systeemgegevens. 




arbeidstijd-, rit-, bedrijfs-, kaarthouder-, gebeurtenis- en 

systeemgegevens mag tonen. Hierbij wordt de restrictie opgelegd dat 

deze gegevens gedurende de eigen bedrijfsvergrendeling geregistreerd 

moeten zijn. 

Deze gegevens worden in de BCT ingebracht voordat er sprake is van een 

bedrijfsvergrendeling en dienen beschikbaar te zijn binnen elke bedrijfsvergrendeling. 

Voor de systeemgegevens lijkt ons dat niet correct. Dit is informatie die 

generiek is voor de BCT en niets met een bedrijfsvergrendeling te 

maken heeft. Het lijkt ons dat deze gegevens door iedere vervoerder 

getoond mogen worden. 

35 Wij zien een operationeel issue met artikel 26.7. Hier staat de BCT het 

uitvoeren van verdere handelingen moet staken als een storing wordt 

geconstateerd als bedoeld in artikel 26.4 a,b,c,en e. Onze interpretatie 

hiervan is dat als bij opstarten een permanente storing wordt 

geconstateerd, geen enkele gebruikersactie mogelijk mag zijn, maar dit 

kan in de praktijk tot onnodige service calls naar de fabrikant leiden. 

Stel dat de voedingskabel van een BCT los zit. Dan kan dat leiden tot een 

onderbreking van >5sec in de stroomvoorziening. Wij kunnen ons goed 

voorstellen dat deze fout 10x kort achterelkaar optreedt. De BCT komt 

hiermee dan in een permanente storing (art 28.2). 

Als een dergelijke BCT bij een werkplaats komt en deze de kabel 

hersteld, moet de gebruiker nog 30 dagen wachten voordat de 

permanente storing is opgeheven. Alternatief is om de BCT naar de 

fabrikant te sturen voor reparatie, maar een normale deactivatie is dan 

niet eens mogelijk. Dat lijkt ons geen wenselijke situatie. 

Er zijn meer voorbeelden te bedenken (bv gerelateerd aan de sensoren) 

waar een werkplaats een reparatie aan de buitenkant van de BCT kan 

uitvoeren, maar de permanente fout niet kan wegnemen voor de 

gebruiker. 

Kun je aangeven wat de visie achter artikel 26.7 is Zou een werkplaats 

rol in deze situaties nog wel functies mogen uitvoeren 

De rationale voor artikel 26, zevende lid is het voorkomen van fraude. Het herhaaldelijk 

optreden van bepaalde gebeurtenissen wordt geclassificeerd als potentieel misbruik. De 

BCT dient in een dergelijk geval de werking te staken en de ondernemer dient de BCT ter 

reparatie aan te bieden aan een werkplaats. Hierdoor wordt een drempel opgeworpen 

voor manipulatie van het apparaat. 

Uit het eerste lid van artikel 18 van de Regeling gebruik boordcomputer en 

boordcomputerkaarten volgt dat de vervoerder bij een storing binnen drie dagen de 

boordcomputer moet laten repareren. 

Artikel 18 

1. Ingeval van een storing als bedoeld in artikel 26, vierde lid, onder a, b, c of e, van de 

Regeling specificaties en typegoedkeuring boordcomputer taxi dan wel wanneer de 

boordcomputer buiten gebruik is, laat de vervoerder deze zo spoedig mogelijk, doch in 

ieder geval binnen drie werkdagen, door een erkenninghouder herstellen en draagt hij er 

zorg voor dat de bestuurder gedurende zijn dienst een registratie bijhoudt van diens 

arbeids- en rusttijden en van de gegevens, bedoeld in artikel 79, derde lid, onder a, c en d, 

en vijfde lid, onder d tot en met f, van het Besluit. 

De tekst van art. 26, zevende lid, Regeling specificaties en typegoedkeuring is gericht op 

het staken van de reguliere werking van de BCT, namelijk het uitvoeren van 

registratiewerkzaamheden. In het licht van het bovenstaande dient dit lid als volgt gelezen 

te worden: “De boordcomputer staakt het uitvoeren van verdere handelingen in de 

operationele modus wanneer een storing wordt gedetecteerd als bedoeld in het vierde lid, 

a, b, c en e”. Hierdoor blijven de functies in de overige modi gewoon bruikbaar, waardoor 

de werkplaats in staat is de storing op te lossen. 




36 Artikel 3 lid 5 stelt: “De boordcomputer hanteert ISO-8601 voor de 

numerieke presentatie van datum en tijd.” 

Dit formaat is onduidelijk voor gebruikers, kunnen wij hier de volgende 

notatie hanteren “DD-MMM-YYYY hh:mm:ss” (18-NOV-2012 13:00:00) 

of “DD-MM-YYYY hh:mm:ss” (18-11-2012 13:00:00) 

37 Stel een taxi wordt geparkeerd in een overdekte / ondergrondse 

parkeergarage. Ten tijde van het inrijden van de garage kan geen gps 

signaal meer worden verkregen. De BCT geeft een visuele 

waarschuwing. De chauffeur stopt de taxi en sluit zijn sessie af en zet 

vervolgens de BCT uit. Hier doet hij/zij meer dan 5 minuten over. De taxi 

wordt meer dan 24 uur niet gebruikt. Na deze periode wordt de taxi 

weer in bedrijf genomen, de BCT wordt automatisch aangezet en er 

wordt automatisch naar een gps signaal geluisterd. Aangezien de taxi 

nog in de garage staat is het signaal niet beschikbaar. Artikel 26 lid 7 

stelt: "7. De boordcomputer staakt het uitvoeren van verdere 

handelingen wanneer een storing wordt gedetecteerd als bedoeld in het 

vierde lid, onderdelen [..] c [..] (c. een storing in de werking van de 

sensoren)". 

De eerste fout van het niet vinden van gps signaal treed op na 5 

minuten. Er zijn desondanks scenario’s denkbaar dat men bovenstaande 

toch voor elkaar krijgt. We willen dat duidelijk wordt dat de 24 uur 

tussen de eerste gps fout niet een simpel vergelijk in tijd wordt, met 

bovenstaand scenario als gevolg, maar dat er gedurende die periode er 

een aantal maal geconstateerd is dat er geen signaal beschikbaar is. Het 

permanente karakter van de gps fout zou moeten blijken uit de duur 

van het optreden van de fout. 

Artikel 3, vijfde lid schrijft het gebruik van ISO-8601 voor voor de numerieke presentatie 

van datum en tijd. Hiermee wordt het formaat "DD-MM-YYYY hh:mm:ss" bedoeld. De 

notatie "DD-MMM-YYYY hh:mm:ss" leidt immers tot een alfanumerieke presentatie van 

datum en tijd. 

Deze aanname is juist. 

Ex. artikel 6, vijfde lid stelt de boordcomputer op basis van de door de 

positiebepalingsensor geleverde informatie eenmaal per minuut de positie van de auto 

vast en registreert deze positie. Indien de boordcomputer niet aan staat is deze ook niet in 

staat vast te stellen dat de positiebepalingsensor geen informatie levert en kan de 

bedoelde fout niet optreden. 

De periode van 24 uur uit artikel 28, derde lid dient berekend te worden over de tijd dat 

de boordcomputer aan staat en geen informatie van de betreffende sensor ontvangt. 

Onze aanname moet dan ook zijn dat de 24 uur berekend wordt over de 

tijd dat de BCT aan staat en dat er geen gps signaal beschikbaar is. 

38 Over het antwoord bij bovenstaande vraag 33 hebben we de volgende 

opmerking: 

Door toe te staan dat alle vier de rollen bevoegd zijn om de gekopieerde 

chauffeurskaartdata in te mogen zien is het mogelijk dat de rol 

Een vervoerder dient controle te voeren op het aantal uur dat een bestuurder achter het 

stuur zit. Als een deel van deze uren bij een andere ondernemer gemaakt worden zal de 

vervoerder van deze uren kennis moeten nemen omdat er anders geen controle te voeren 

is. Deze samenloop wordt op dit moment geadministreerd door twee of meer 




vervoerder arbeidstijdgegevens kan inzien van een chauffeur welke 

geen activiteiten heeft uitgevoerd voor de betreffende vervoerder. 

Hierdoor wordt het gebruik van een bedrijfsvergrendeling teniet gedaan 

voor arbeidstijd. 

werkmappen bij te houden waar de verschillende vervoerders kopieen van ontvangen. 

Indien dit niet is toegestaan dan nemen we aan dat de rol vervoerder 

geen enkele chauffeurskaartdata kan exporteren en tonen op het 

scherm aangezien er geen attributen geregistreerd zijn bij de 

chauffeurskaartdata die gekoppeld zijn aan een bedrijfsvergrendeling. 

Of er dient een aanpassing te komen dat de chauffeurskaartdata ook 

voorzien wordt van een attribuut tbv bedrijfsvergrendeling. 

39 Wij hebben nog een vraag over aanmelden met NI nummers. Uit de 

informatie die wij hierover bij de overheid kunnen vinden op internet is 

ons niet helder wat het formaat van dit nummer is. 

De situatie met de boordcomputer is daarin niet anders. De vervoerder krijgt beschikking 

over de chauffeurskaartdata van de bestuurder die voor hem werkt. In deze data zijn ook 

de uren verwerkt die voor andere vervoerders zijn gewerkt. De vervoerder krijgt overigens 

alleen beschikking over de chauffeurskaartdata. De rij- en rusttijden die door de 

boordcomputer voor een andere vervoerder zijn geregistreerd en op de boordcomputer 

zijn vastgelegd worden niet uitgevoerd. 

Het NI nummer binnen de context van de BCT is geïntroduceerd om kaarten uit te kunnen 

geven aan niet in Nederland ingezeten taxichauffeurs voordat de rijksbrede Registratie 

Niet Ingezetenen (RNI) faciliteiten gereed zijn. 

Wij verwachten dat dit nummer dezelfde eigenschappen heeft als het 

BSN nummer ( 8 of 9 cijfers, voldoet aan 11-proef). 

Het NI-nummer is onderdeel van het kaartnummer. De huidige implementatie van de 

kaartnummers wordt onder andere beschreven in het document “Certificaatprofielen en 

CRL model” 

(http://www.ilent.nl/Images/Certificaatprofielen%20en%20CRL%20Model%20- 

%20v1.2_tcm334-320226.pdf) zie paragraaf 3.6.3. 

Het NI nummer heeft niet dezelfde eigenschappen als het BSN nummer, maar bestaat uit 

de letters NI gevolgd door een 7 posities lang IVW nummer. 

Chauffeurs die zijn uitgerust met een chauffeurskaart op basis van een NI nummer kunnen 

alleen met de chauffeurskaart aanloggen. De BCT accepteert namelijk alleen een inlog op 

basis van een boordcomputerkaart of inlog op basis van een BSN. Zie hiervoor artikel 4, 

achtste lid van de Regeling specificaties en typegoedkeuring boordcomputer taxi. 

40 Wat wordt bedoelt met werkelijke afgelegde afstand in art. 5, derde lid 

Volgens ons wordt hiermee de afgelegde afstand bedoelt dat is 

afgelegd tijdens het calibreren/keuren van de BCT. Indien dat klopt dan 

kan deze validatie alleen tijdens het calibreren/keuren uitgevoerd 

worden en niet terwijl de BCT ‘normaal’ gebruikt wordt ten behoeve 

Inloggen op basis van het NI nummer zonder kaart is niet toegestaan. 

Met de werkelijke afgelegde afstand wordt de daadwerkelijk door het voertuig afgelegde 

afstand bedoeld. Tijdens 'normaal' bedrijf wordt de afstand gemeten door de 

bewegingsopnemer gecontroleerd op basis van de gegevens van de 

positiebepalingssensor (zie art. 7, derde lid) 




van de registratie van arbeids-, rij-, en rustijden. Indien onze aanname 

niet klopt dan horen we graag hoe dit wel gelezen moet worden. 

41 Wij hebben de volgende vraag over het registreren van gebeurtenissen 

bij het niet juist werken van de systeemkaart. De volgende 

gebeurtenissen worden o.a. geregistreerd bij het niet juist werken van 

een systeemkaart: 

• S005 – een storing in de werking van de systeemkaart 

• F008 – een fout bij het gebruik van de systeemkaart 

Alle gebeurtenissen dienen elektronisch ondertekent te worden door de 

systeemkaart ten behoeve van de integriteit. Echter in het geval een 

systeemkaart niet meer goed werkt en het plaatsen van een 

elektronische handtekening niet meer mogelijk is zal dit resulteren in 

een oneindige loop. Namelijk het steeds niet kunnen plaatsen van een 

elektronische handtekening zal resulteren in een gebeurtenis F008, 

gevolgd door gebeurtenissen S005 welke allemaal niet elektronisch 

ondertekent kunnen worden. 

Artikel 26, lid 7 schrijft voor dat de boordcomputer bij het optreden van (o.a) een storing 

in de werking van de systeemkaart het uitvoeren van verdere handelingen staakt. 

Deze storing zal vervolgens door de werkplaats moeten worden opgelost. Indien de 

storing kan worden opgelost is de boordcomputer in staat om de S005 registratie te 

ondertekenen, en voldoet de registratie aan de XSD. 

Is de fout niet op te lossen zal de boordcomputer moeten worden gedeactiveerd en 

zullen, conform art. 23 tweede lid, alle in het geheugen geregistreerde gegevens naar een 

externe gegevensdrager moeten worden overgedragen. De consequentie hiervan is dat de 

S005 registratie in dit specifieke geval niet voldoet aan het XSD. 

Onze aanname is dat we na het registeren van een S005, en dus de BCT 

het uitvoeren van verdere handelingen staakt, geen gebeurtenissen 

registeren. Hierbij is de laatst geregistreerde gebeurtenis S005 niet 

eletronisch ondertekent door de systeemkaart en voldoen we op dat 

moment niet meer aan het XSD voor gebeurtenissen. Klopt onze 

aanname Zo ja, hoe moeten we dan omgaan met het XSD waarbij de 

integriteit een verplicht veld is. 

42 Wat wordt bedoelt met de werkelijke positie in artikel 6.4 Met de werkelijke positie wordt de feitelijke positie van het voertuig bedoeld. Dit artikel is 

een kwaliteitseis aan de positiebepalingssensor. Het verschil tussen de gemeten positie en 

de feitelijke positie moet kleiner zijn dat hetgeen gesteld in artikel 6.4. 

43 De gebeurtenissen M009, M010, M011 en M012 worden geregistreerd 

bij het ontstaan/beëindigen van onvoldoende opslagcapaciteit op de 

boordcomputer en/of op de chauffeurskaart. Onze aanname is dat deze 

gebeurtenissen alleen van toepassing zijn zodra de gegevens op de 

boordcomputer en/of chauffeurskaart niet ouder zijn dan de verplichte 

bewaartijd en er onvoldoende opslagcapaciteit is. 

Als er eenmaal onvoldoende ruimte ontstaat op de boordcomputer 

Bij het ontstaan van onvoldoende opslagcapaciteit dient eenmalig een gebeurtenis M009 

of M011 geregistreerd te worden. Zolang er onvoldoende opslagcapaciteit is wordt er niet 

opnieuw een M009 of M011 geregistreerd. Is er weer voldoende opslagcapaciteit 

beschikbaar wordt een M010 of M012 geregistreerd. Als daarnaar weer onvoldoende 

opslag beschikbaar is wordt opnieuw een M009 of M011 geregistreerd. 

N.B.: Een dergelijke gebeurtenis leidt tot een fout in de registratiefunctie (art 27, tweede 

lid onder a). Een dergelijk fout moet aan de gebruiker worden getoond (art 29 eerste lid 




en/of chauffeurskaart dan zal dit bij elke schrijfactie zo zijn die hierop 

volgt. Hierbij wordt FIFO (First In First Out) methodiek toegepast om de 

nieuwe gegevens te registreren. 

Het lijkt ons niet handig om dan constant deze meldingen te registreren 

aangezien dit juist extra ruimte inneemt. 

onder a). 

Onze aanname is dat we bij de eerste keer optreden van het ontstaan 

van onvoldoende opslagcapaciteit (M009/M011) , deze gebeurtenis 

tonen en registreren. De eerstvolgende keer dat we deze gebeurtenis 

tonen en registreren (M009/M011) is op het moment er opnieuw 

onvoldoende opslagcapaciteit is ontstaan en dat er hiervoor al een 

gebeurtenis (M010/M012) is opgetreden. Klopt deze aanname 

44 De gebeurtenissen M031 en M032 worden geregistreerd bij het rijden / 

niet rijden in operationele modus werkingsniveau taxivervoer zonder 

chauffeurskaart. Dit betekent dat deze meldingen constant 

geregistreerd worden in een scenario waarbij de chauffeur moet 

stoppen voor een stoplicht, vervolgens weer gaat rijden. Dit lijkt ons 

niet wenselijk en leidt tot extra veel registraties van deze 

gebeurtenissen. 

Onze aanname is in dit geval dat we deze gebeurtenissen alleen 

registeren op het moment van het starten van een rit en het stoppen 

van een rit (onbeladen/beladen). Klopt deze aanname 

45 Aanvullende vraag op vraag/antwoord 20 (blz. 31) uit document 

‘20130107FAQFabrikantenv1.7_tcm334-336989’ 

Een vervolgvraag die hierop van toepassing is: 

Referentie: Artikel 10.4 

Artikel 10.4 beschrijft het volgende: “Indien de coördinaten van het 

beginpunt of het eindpunt van de rit niet beschikbaar zijn op het 

moment van optreden, vindt deze registratie alsnog plaats zodra deze 

coördinaten beschikbaar komen.” 

Gebeurtenissen M031 en M032 zien toe op de situatie waarbij er sprake is van de 

operationele modus werkingsniveau taxivervoer zonder dat er een chauffeurskaart 

aanwezig is, en er met het voertuig wordt gereden. Het werkingsniveau taxivervoer kan 

niet worden gestart zonder dat daarbij het werkingsniveau arbeidstijd actief is (art 4, lid 

7). Het werkingsniveau arbeidstijd wordt gestart op basis van de chauffeurskaart (of, in 

bijzondere omstandigheden, BSN van chauffeur). De situatie dat er gereden wordt met het 

voertuig in de werkingsmodus taxivervoer is daarmee een afwijkende en dient vastgelegd 

te worden. Het ingelogd zijn op basis van BSN is hierbij gelijk gesteld aan het aanwezig zijn 

van de chauffeurskaart. 

Artikel 10, lid 4 schrijft voor dat een ritregistratie uitgebreid moet kunnen worden met 

later beschikbaar gekomen positiegegevens. Voor het aanpassen van de registratie kan 

gebruik gemaakt worden van de systematiek die ook wordt gebruikt voor het annuleren 

van het einde van de laatste rit. Ook in dat geval wordt immers informatie over het einde 

van de rit gewijzigd. 

Deze systematiek staat beschreven in bijlage 2, artikel 3.2 onder opmerking e. Hiermee 

wordt het einde van de rit waarvoor geen positiegegevens beschikbaar waren 

geannuleerd, om vervolgens de rit opnieuw te sluiten met de juiste positiegegevens. 

Situatieschets: 




1. Er wordt een rit gestart en alle benodigde ritgegevens worden 

geregistreerd, inclusief de startlocatie (coördinaten) van de rit. 

2. De rit, welke gestart is in stap 1, wordt gestopt. Allen benodigde 

ritgegevens worden geregistreerd met uitzondering van de eindlocatie 

(coördinaten) van de rit omdat deze op het moment van stoppen niet 

beschikbaar zijn (bijvoorbeeld in een garage). Vervolgens wordt een 

handtekening gezet over de ritgegevens met de systeemkaart van de 

BCT. 

3. Na 2 minuten komen er GPS posities beschikbaar. 

Volgens artikel 10.4 moeten we alsnog de eindlocatie (coördinaten) van 

de rit, welke gestopt is in stap 2, registreren zodra deze beschikbaar 

komen. 

Onze aanname is dat dit niet mogelijk is aangezien de ritgegevens al 

ondertekent zijn met de elektronische handtekening van de 

systeemkaart. 

46 Een vraag betreffende POSITIEGEGEVENS: 

Voordat de BCT is geactiveerd worden POSITIEGEGEVENS opgeslagen 

zoals beschreven is in Bijlage 2 - artikel 5.2, opmerkingen, het volgende: 

a. Alle coördinaten met een datumtijd registratie die ligt voor het 

tijdstip van de laatste activering van de boordcomputer worden 

gegroepeerd bij dezelfde AUTO-VERVOERDER-ONDERNEMERSKAART 

combinatie. 

b. Alle coördinaten die zijn geregistreerd na het tijdstip van de laatste 

activering worden geleverd met het kenteken van de auto, het KvKnummer 

en P-nummer van de vervoerder en het volgnummer van de 

ondernemerskaart waarvoor de coördinaten zijn geregistreerd. 

[..] 

In het functionele berichtstructuur ten behoeven van het coördinaten 

exportbericht wordt de volgende cardinaliteit aangegeven voor AUTO 

(Kenteken) 1..2 (minimaal 1, maximaal 2). 

Bijlage 2 van de regeling heeft betrekking op de gegevenslevering door de BCT. De daarin 

opgenomen xsd’s gelden voor de gegevensexportbestanden, maar niet voor de manier 

waarop de gegevens op de BCT worden opgeslagen. 

Artikel 6, derde lid, geeft aan welke informatie onderdeel uitmaakt van de 

positiegegevens: 

3.De positiegegevens, bedoeld in het tweede lid, bevatten ten minste de volgende 

gegevens: 

a.de coördinaten; 

b.of er een positie bepaald is; 

c.het aantal satellieten op basis waarvan de positie van de auto bepaald is; 

d.de HDOP-waarde uitgedrukt in een getal tussen nul en vijftig; 

e.het tijdstip van de positiebepaling. 

Bij het opslaan van de positiegegevens wordt niet uitgegaan van de opslag van gegevens 

van het voertuig en de bedrijfsvergrendeling. Deze gegevens maken immers geen deel ui t 

van de gegevensverzameling die in art. 6, lid 3 wordt voorgeschreven. De reden hiervoor is 

onder andere om de omvang van de vastgelegde positiegegevens zoveel mogelijk te 

beperken, en geen extreme opslageisen aan de BCT op te leggen. 




Wat moet er gebeuren in de volgende scenario: 

1. BCT is niet geactiveerd, er worden coördinaten opgeslagen onder 

AUTO (kenteken) = 0. 

2. BCT is geactiveerd, er worden coördinaten opgeslagen onder AUTO 

(kenteken) = AA11BB. 

3. BCT wordt gedeactiveerd, alle gegevens worden geëxporteerd en 

daarna verwijderd met uitzondering van de SYSTEEMGEGEVENS en 

POSITIEGEGEVENS. 

4. BCT is niet geactiveerd, er worden coördinaten opgeslagen onder 

AUTO (kenteken) = 0. 

5. BCT is geactiveerd, er worden coördinaten opgeslagen onder AUTO 

(kenteken) = BB22AA. 

Wat moet er nu gebeuren met de coördinaten welke nog op de BCT 

opgeslagen zijn onder kenteken AA11BB en de betreffende 

bedrijfsvergrendeling We kunnen echter maximaal onder twee Auto’s 

coördinaten opslaan. 

Bij de export van de positiegegevens kan daardoor alleen een beroep gedaan worden op 

de voertuiggegevens uit de huidige activering. Alle positiegegevens die zijn vastgelegd 

voor het tijdstip van de huidige activering zijn niet (direct) te herleiden tot een voertuig, 

waardoor zij onder één nul-entiteit worde geexporteerd. De positiegegevens die zijn 

vastgelegd na de huidige activering worden gekoppeld aan het huidige voertuig. 

Onze aanname is dat de cardinaliteit niet 1..2 moet zijn, maar 1..n moet 

zijn. Minimaal 1 AUTO registratie en geen maximum aangeven. 

47 We hebben nog een extra vraag betreffende het volgende scenario: 

1. Chauffeur logt in met zijn/haar chauffeurskaart 

2. Chauffeur start een rit 

3. Chauffeur verwijderd zijn/haar chauffeurskaart uit de BCT 

(geblokkeerde sessie) 

4. Chauffeur voert zijn/haar chauffeurskaart na 10 minuten weer in de 

BCT 

5. Chauffeurs geeft aan dat hij/zij vanaf het moment dat de kaart uit 

de BCT verwijderd is geweest pauze heeft gehad 

Hoe moet we dit verwerken in combinatie met een rit welke gestart is 

(nog actief is in de geblokkeerde sessie), maar er tussentijds pauze is 

uitgevoerd 

Het geschetste scenario is niet mogelijk. 

Door de verwijdering van de chauffeurskaart is de kaartsessie geblokkeerd, maar duurt 

wel voort. Het weer inbrengen van de chauffeurskaart zal de kaartsessie deblokkeren, 

maar dit is geen begin van de sessie. Alleen aan het begin van een kaartsessie kan er 

aangegeven worden dat er andere werkzaamheden zijn verricht of pauze is genoten. 

Zie Artikel 9, lid 4: 

De bestuurder kan aan het begin van een kaartsessie handmatig aangeven dat hij nadat de 

voorgaande kaartsessie is afgesloten nog andere werkzaamheden dan rijden heeft 

uitgevoerd, of pauze heeft genoten. 

In het beschreven scenario is de laatste handmatig ingevoerde informatie de start van de 

rit. Dit is dan ook de enige informatie die volgens art. 15, lid 3 kan worden geannuleerd. 




Dit is een vreemd theoretisch scenario, maar we willen dit graag correct 

kunnen afhandelen en registreren. 

1. Is het toegestaan de rit te vervolgen Hierbij overlappen de rit 

starten eind datum/tijd met de handmatig toegevoegde pauze. 

2. Of, mogen we de rit als ‘gestopt’ beschouwen en hierbij dan ook 

geen eindgegevens voor vastleggen, maar wel ondertekenen met de 

systeemkaart 

3. Of, we gaan niet toestaan om activiteiten toe te voegen in het geval 

er nog een geblokkeerde sessie actief is, welke vervolgt kan worden, 

waarbij één of meerdere ritten actief zijn. 

Zie Artikel 15, lid 3: 

Uitsluitend de laatste handmatig ingevoerde en geaccepteerde informatie kan door de 

bestuurder worden geannuleerd. Deze handeling wordt door de boordcomputer 

geregistreerd. 

Onze voorkeur en aanname is dat de derde optie de meest passende en 

nette oplossing biedt. 



Kaartspecificaties 


1 Welke eisen worden er aan de cardreaders voor de BCT gesteld De regelgeving vereist dat de hardware van de cardreaders voldoen aan deel 1, 2 en 3 van 

ISO 7816. Hierbij wordt een reader voor de systeemkaart en een reader voor de 

boordcomputerkaarten onderscheiden. In de systeemkaartreader moet een ID-000 kaart 

(SIM-kaart formaat) kunnen worden verzegeld en de chip van deze kaart worden 

uitgelezen. De boordcomputerkaartreader moet de chip op een ID-1 kaart (bankkaart 

formaat) kunnen lezen die van buiten de boordcomputerbehuizing wordt ingebracht. De 

specificaties van de 'software' aansturing van de kaart worden nog uitgewerkt, maar 

vallen grotendeels binnen de overige delen van de ISO 7816-standaard. De regelgeving 

stelt verder geen eisen aan de readers, zoals bijvoorbeeld mechanische vergrendeling. 

2 Zijn de kaartstructuur documenten ook in het Engels beschikbaar Nee, de specificaties zijn alleen in het Nederlands beschikbaar 

3 In de kaartspecificatie op hardware nivo wordt onderscheid gemaakt 

tussen class A, class B en class C voor de 'operating conditions'. 

Dit bepaald de voedingsspanning waarop de kaarten werken. Waar 

wordt uitsluitsel gegeven over de 'class' waarin de 

boordcomputerkaarten vallen 

4 In appendix A van de “Technische specificaties gebruik BCT-kaarten” 

staan een aantal scenario's waarin aangegeven staat wat, op welke 

manier, naar de kaart geschreven moet worden. Op basis van deze 

opslag worden ook de 'annuleringen' vastgelegd. Voor de genoemde 

scenario's zijn die ook duidelijk. 

Echter, in het volgende scenario is het dan onduidelijk op welke manier 

de informatie op de kaart opgeslagen moet worden: 

1. invoer voorgaande werkzaamheden "Start werk" om 8:30 

2. Corrigeren, met invoer "start pauze" 8:00 

3. Login 9:00 

4. Start werk 9:00 

Gaat dit dan resulteren op de kaart in het volgende 

Start werk 8:30:00 '1' B 

Start Pauze 8:00:00 '1' B 

Login 9:00:00 '0' B 


De technische specificaties van de gebruikte chip zijn gepubliceerd via 

http://ivw.nl/onderwerpen/taxi/boordcomputer_taxi/fabrikanten/ 

specificaties/kaartspecificaties/ 

In de tekst behorende bij stap 5 van paragraaf 7.1 van de kaartspecificaties wordt het 

volgende gesteld: “Een start die eerder is dan het einde van de vorige “Start werk” of 

“Start pauze” activiteit, zal die eerdere activiteit geheel of gedeeltelijk veranderen. “ 

In het onderstaande voorbeeld loopt de Pauze van 8:00 – 9:00 uur, omdat Start Werk 

feitelijk door Pauze wordt overschreven. 

Als in onderstaand voorbeeld Start Werk van 8:30 naar 8:45 gecorrigeerd zou zijn levert 

dat het volgende op: 

1. Invoer voorgaande werkzaamheden "Start werk" om 8:30 

2. Corrigeren, met invoer "start pauze" 8:00 

2b. Invoer “Start werk” om 8:45 

3. Login 9:00 

4. Start werk 9:00 

Met het volgende resultaat op de kaart, waarbij de start pauze er voor zorgt dat de start 

werk om 8:30 wordt opgeheven en de start werk om 8:45 de pauze beëindigd. 




In dit geval is het dan niet duidelijk of je PAUZE van 8:00-8:30, WERK 

8:30-9:00 hebt ingevuld, of dat PAUZE van 8:00-9:00 loopt. 

5 Het plaatsen van een digitale handtekening met gebruik van het 

commando PSO HASH leidt tot een foutmelding 6A88. 

6 Om de kaartimplementaties te kunnen valideren zou een testplan met 

gedetailleerde testcases nuttig zijn. Is het beschikbaar stellen van het 

dergelijk testplan mogelijk 

7 Tijdens het testen met referentiekaarten ondervinden we een technisch 

probleem. We volgen de kaartspecificatie, maar het resultaat is niet wat 

we verwachten. Het is onduidelijk dit een kaart- of een BCT issue is. Kan 

je hiervoor support leveren 


Start Pauze 8:00:00 '1' B 


Login 9:00:00 '0' B 


Het commande PSO HASH maakt gebruik van een referentie naar het sleutelmateriaal in 

het Security Data Object (SDO) op de kaart. Omdat dit SDO een lokaal object is, moet de in 

de kaartstructuur documenten gespecificeerde keyReference niet letterlijk worden 

overgenomen, maar met bit8 hoog (dus ‘85’H in plaats van ‘05’H). In versie 1.5 van de 

“Technische specificaties gebruik BCT-kaarten” is dit verduidelijkt. 

De partijen die de kaartspecificaties hebben opgesteld zijn ons inziens ook de partijen die 

ondersteuning zouden kunnen geven op het gebied van de implementatie van de 

specificaties. IVW is niet voornemens een uitputtend testplan beschikbaar te stellen in 

aanvulling op de reeds gepubliceerde specificaties. 

Helaas is IVW niet in staat om support te geven op technische issues. Hiervoor ontbreekt 

het ons simpelweg aan de benodigde kennis, mensen en middelen. 

Wel kan ik je verwijzen naar de partijen die IVW hebben bijgestaan bij de verwezenlijking 

van de specificaties van de kaarten. Dit zijn: 

- Kaart gerelateerde onderwerpen: Collis 

- PKI gerelateerde onderwerpen: Ordina Security & Risk Management 

Wellicht zijn zij in staat om de door jullie gewenste support te geven. Wellicht ten 

overvloede: IVW heeft geen support overeenkomst met deze partijen, dus eventuele 

commerciële afspraken zullen direct met deze partijen moeten worden gemaakt. 

8 Tijdens ontwikkeling van de boordcomputertaxi vormt de default retry 

counter van één op de systeemreferentiekaart een probleem. 

Wat zijn de mogelijkheden om 'ontwikkelkaarten' te ontvangen welke 

niet/minder strict zijn geconfigureerd 

9 Kan een blokkade van de PIN opgeheven worden op 

systeemreferentiekaarten 

Uiteraard blijft IVW ondersteuning bieden op het gebied van onduidelijkheden in de weten 

regelgeving. 

Op de nieuwe generatie referentiekaarten zal de retry counter op de systeemkaart 

worden verhoogd naar 15. 

Nee. Voor dit soort zaken zullen de referentiekaarten gelijk zijn aan de productiekaarten. 




10 In de regeling en bijbehorende bijlagen worden een aantal performance 

eisen gesteld aan de gehele BCT gesteld. De snelheid van de BCT 

systeem- en boordcomputerkaarten heeft invloed op de BCT 

performance. Om de haalbaarheid hiervan tegen het ons 

architectuurdesign te toetsen zijn we op zoek naar performance eisen 

van de BCT kaarten. Bijvoorbeeld hoelang mag de systeemkaart doen 

over het zetten van een handtekening zoals gespecificeerd in paragraaf 

8.6 van de "Technische specificaties gebruik BCT-kaarten" 

Er zijn geen aparte snelheidseisen aan de BCT kaarten gesteld. De snelheid van de kaart is 

afhankelijk van de gebruikte chip. De specificaties van deze chip zijn te vinden via 

http://www.ivw.nl/onderwerpen/taxi/boordcomputer_taxi/fabrikanten/ 

specificaties/kaartspecificaties/ en daar de laatste link. 

Waar zijn de snelheidseisen die gesteld zijn aan de BCT kaarten te 

vinden 

11 De aanname die we hebben gedaan is dat de transportkey op de 

pinmailer van de systeemkaart gelijk is aan de transportkey1. Klopt deze 

aanname 

12 Hoe wordt vanuit de transportkey op de pinmailer van de systeemkaart 

op de KS.KENC en KS.KMAC gekomen 

13 Komt paragraaf 4.6 van de Technische specificaties gebruik BCT-kaarten 

overeen met Identification Authentication Signature For European 

Citizen Card hoofdstuk 5.2.2.2 

14 In een aantal eerdere projecten met smartcards hebben we geleerd dat 

sommige smartcards te weinig RAM geheugen hebben om de 

tussenresultaten van een RSA berekening op te slaan. Als gevolg van 

deze RAM beperkingen slaat de kaart deze tussenresultaten op in 

EEPROM geheugen. 

Een technische eigenschap van alle soorten EEPROM geheugen is dat 

het slijt bij elke schrijf en wis actie (program and erase cycle). Dit 

schijven (en dus ook weer wissen) van het EEPROM tijdens het 

uitvoeren van een RSA berekening veroorzaakt slijtage aan het 

EEPROM. Niet alle kaarten gebruiken "wearleveling" op dit punt om de 

slijtage aan het EEPROM te zo te verdelen dat er langere levensduur 

ontstaat. 

Dat hoort inderdaad het geval te zijn. 

KS.MAC = meest significante 16 bytes en KS.ENC = minst significante 16 bytes. 

Ja. 

De technische specificaties van de gebruikte chip zijn gepubliceerd op 

http://www.st.com/internet/mcu/product/216579.jsp 

De genoemde 2 Kbytes of NESCRYPT RAM zou voldoende moeten zijn om de resultaten 

van een RSA berekening op te slaan. 

Daarnaast worden 500,000 erase/write cycles van de User EEPROM ondersteund. 

Vraag 1: 

Gebruikt de BCT systeemkaart EEPROM geheugen tijdens het zetten van 




een digitale handtekening 

Mocht het antwoordt hierop Ja zijn dan hebben we ook nog de 

volgende vraag. 

Vraag 2: 

Hoeveel digitale handtekening kan de BCT kaart zetten voordat de het 

EEPROM de door de chipfabrikant gegarandeerde aantal "program and 

erase cycles" heeft bereikt 

15 Wij hebben een vraag over het opslaan van de rij en rusttijden op de 

Chauffeurskaart, Hoe de opslag gedaan moet worden is duidelijk 

uitgelegd, wij kunnen alleen nergens terug vinden wat er moet 

gebeuren als wij detecteren dat de opslag op de chauffeurskaart corrupt 

is. 

Er wordt wel gespecificeerd hoe een corrupte kaart te onderkennen is, 

en dat dit gelogd moet worden. Maar wat er daarna mee moet 

gebeuren kunnen we niet terugvinden. 

Er zijn ons inziens 2 mogelijkheden. 

1.) De kaart is vanaf dat moment onbruikbaar, en aangezien 

de chauffeur geen mogelijkheid heeft om de gegevens te 

repareren, zal deze een nieuwe kaart aan moeten vragen. 

2.) De Boordcomputer zal met behoud van zoveel mogelijk 

gegevens proberen de data te repareren. (d.m.v. 

verwijderen van dailyrecords die niet meer kloppen) 

16 Op pagina 14 van dit document TechSpecsGebruikBCTKaarten wordt 

stapsgewijs beschreven hoe een (vervangende) systeemkaart gekoppeld 

dient te worden aan de BCT. Daarnaast wordt op pagina 16 van dit 

document stapsgewijs beschreven hoe een huidige systeemkaart 

onklaar gemaakt dient te worden alvorens we een 

systeemkaartvervanging kunnen uitvoeren. 

Onze constatering is dat er geen rekening gehouden wordt met een 

scenario (waarschijnlijk de meest voorkomende waarbij een 

systeemkaartvervanging uitgevoerd moet worden) dat een 

systeemkaart defect is en een vervanging ervan nodig is. 

Er zijn twee scenario’s denkbaar bij corrupte gegevens op de chaufferskaart. 

1.) Vaste gegevens zijn corrupt 

De gegevens waarmee de chauffeurskaart is uitgeleverd, zoals het 

PKIoverheid certificaat, zijn corrupt geraakt. Hierdoor is de BCT niet langer in 

staat om het kaarttype en de kaarthouder te identificeren (art. 17, derde lid) 

en dient de kaart als ongeldig te worden aangemerkt. Hierdoor moet de 

kaart worden genegeerd (art. 17, tweede lid). 

2.) Rij- en rusttijden zijn corrupt 

De BCT stelt vast dat de laatste kaartsessie niet correct is afgesloten, de 

gegevens zijn immers corrupt. Hiervan wordt een logging gemaakt (art. 27, 

eerste lid onderdeel d). Hierop wordt verder geen actie ondernomen. De BCT 

voegt de nieuwe te registreren informatie toe aan een nieuwe kaartsessie 

met eigen dailyrecords. 

De systeemkaartvervanging is opgezet om bij het verlopen van een systeemkaart deze 

door een andere systeemkaart te vervangen zonder dat daarvoor kennis van sleutels 

nodig is bij degene die de vervanging uitvoert. 

In het geval van een defecte systeemkaart ligt het meer in de lijn der verwachting dat de 

systeemkaart wordt vervangen door een nieuwe systeemkaart, die is beschermd is met de 

oorspronkelijke fabrikantensleutel. 




Aangezien bij de eerste keer koppelen van een systeemkaart niet 

‘transportkey2’ wordt opgeslagen is deze niet bekend wanneer de 

systeemkaart vervangen moet worden door een vervangende 

systeemkaart. Dit komt voor in het geval dat de huidige systeemkaart 

defect is waardoor stap 4 niet uitgevoerd kan worden is aangezien 

‘transportkey2’ niet uitgelezen kan worden. 

Onze aanname is dat bij de eerste keer koppelen van een systeemkaart 

wel ‘transportkey2’ wordt opgeslagen zodat deze in alle gevallen 

bekend is bij het vervangen van een systeemkaart. 

17 Scenario 1: activiteiten toevoegen / aanpassen / verwijderen direct 

na/tijdens het inloggen middels een chauffeurskaart Tijdens dit scenario 

wordt de chauffeur gevraagd of er nog activiteiten toegevoegd moeten 

worden welke zijn uitgevoerd door de chauffeur. Indien de chauffeur dit 

met ja bevestigd is het mogelijk voor de chauffeur om activiteiten toe te 

voegen. 

Op de chauffeurskaart wordt rijtijd bijgehouden met een aparte teller 

per ‘start werk’ activiteit op de chauffeurskaart. Binnen dezelfde ‘start 

werk’ activteit is er ook een teller opgenomen welke bijhoudt wat de 

totale duur van de ‘start werk’ activiteit is. Het verschil tussen deze 

twee tellers duidt zich uit in aantal seconden ANDERE 

WERKZAAMHEDEN. 

Dit resulteert zich in de volgende ‘relatie’ tussen een chauffeurskaart en 

de BCT: 

Binnen het werkingsniveau Arbeidstijd worden drie typen activiteiten onderkend, te 

weten; RIJTIJD, ANDERE WERKZAAMHEDEN en PAUZE (art 9, eerste lid). Alles dat geen 

RIJDTIJD of PAUZE is wordt getypeerd als ANDERE WERKZAAMHEDEN. 

Gedurende de kaartsessie kan een chauffeur alleen PAUZE handmatig aangeven. RIJTIJD 

en ANDERE WERKZAAMHEDEN worden automatisch geregistereerd, en kunnen daarmee 

niet worden geannuleerd. Als een chauffeur PAUZE aangeeft, maar dit vervolgens 

annuleert dient het betreffende tijdsblok een andere typering te krijgen om gaten in de 

registratie te voorkomen. 

Geeft een chauffeur bij de aanvang van de kaartsessie aan dat hij sinds de afsluiting van de 

vorige kaartsessie nog ANDERE WERKZAAMHEDEN heeft uitgevoerd of PAUZE heeft 

genoten. Aangezien dit handmatige handelingen zijn is de chauffeur in staat om deze 

registratie te annuleren, bijvoorbeeld in het geval van een fout. 

[Tabel uit vraag verwijderd tbv leesbaarheid] 

In de tabel hierboven is duidelijk te zien dat er geen 1 op 1 relatie 

mogelijk is tussen ‘start werk’ op de chauffeurskaart en ANDERE 

WERKZAAMHEDEN en RIJTIJD op de BCT zoals dat wel mogelijk is voor 

‘start pauze’ op de chauffeurskaart en PAUZE op de BCT. Daarbij komt 

nog het feit dat alleen de laatst handmatige actie geannuleerd mag 

worden. 

Als we het document 




‘20120425TechSpecsGebruikBCTKaartenv1.7_tcm334-333038’ bekijken, 

waarin de technische beschrijving voor het gebruik van de BCT kaarten 

is beschreven, zijn er alleen voorbeeldscenarios beschreven (Bijlage A) 

waarbij een ‘start pauze’ activiteit op de chauffeurskaart gewijzigd / 

vervangen / geannuleerd kan worden, maar geen ‘start werk’ activiteit 

gewijzigd, vervangen of geannuleerd kan worden. 

Echter wordt wel beschreven in het document ‘Regeling specificaties en 

typegoedkeuring boordcomputer taxi’, Bijlage 2 artikel 4.1 Gegevens 

(betreffende arbeids-, rij- en rustijden), dat annuleren van PAUZE en 

ANDERE WERKZAAMHEDEN mogelijk moet zijn. 

Onze aanname is, omdat we geen 1 op 1 relatie hebben tussen ‘start 

werk’ en ANDERE WERKZAAMHEDEN, het niet mogelijk is om ANDERE 

WERKZAAMHEDEN te annuleren zoals dat op dezelfde manier wel 

mogelijk is voor PAUZE. 

Bovenstaande wordt bevestigd door het testhuis Collis, vanaf heden 

bekend onder de naam UL Transaction Security, kijkend naar hun 

reactie (citaat uit emailreactie) op onze vraag hoe zij dit kunnen 

faciliteren in hun testscenarios aangezien deze niet opgenomen zijn. 

[UL] Er is hier een discrepantie tussen de Regeling en de praktische 

uitvoering op de kaart (vanwege ruimtegebrek worden niet de tijden 

opgeslagen van rijden en andere werkzaamheden, maar de cumulatieve 

waarden gebruikt). Een mogelijke oplossing zou zijn dat, wanneer de 

chauffeurskaart in dezelfde boordcomputer gebruikt wordt, op de 

boordcomputer het laatste tijdstip opgezocht wordt van andere 

werkzaamheden en dit gebruikt wordt, tenzij het niet de laatste actie is. 

Overigens zal dit in het algemeen niet voldoen aan het feit dat het om 

een handmatige actie moet gaan. 

Klopt onze aanname betreffende scenario 1 

Scenario 2: vervangen van PAUZE tijdens gebruik van BCT (nadat inlog 

procedure is doorlopen) Tijdens het gebruik van de BCT is het mogelijk 

dat een chauffeur een pauze start. Onze aanname is dat een PAUZE 




alleen (en tijdens de hiervoor beschreven scenario 1) vervangen kan 

worden terwijl de chauffeur gebruikt maakt van de BCT en dat een 

PAUZE niet geannuleerd kan worden. 

• Een PAUZE kan alleen vervangen worden door ANDERE 

WERKZAAMHEDEN 

• Een PAUZE kan niet geannuleerd worden omdat er in dat geval 

een ‘gat’ in de registratie van de arbeidstijd ontstaat. 

Daarnaast is het volgens ons niet mogelijk om ANDERE 

WERKZAAMHEDEN te annuleren tijdens het gebruik van de BCT (nadat 

inlog procedure is doorlopen) om dezelfde reden dat een PAUZE niet 

geannuleerd kan worden vanwege het feit dat er dan ‘gaten’ in de 

registratie van de arbeidstijd ontstaan. 

Klopt onze aanname betreffende scenario 2 



Beveiliging 


1 Verzegeling systeemkaart 

De regeling (Artikel 2 Lid 1e) schrijft voor dat de systeemkaart verzegeld 

dient te worden in een ISO-7810 interface. Is het ook toegestaan om de 

systeemkaart inclusief interface onverzegeld in de BCT te plaatsen, maar 

de BCT als geheel te verzegelen 

Ja, mits de systeemkaart en interface dusdanig zijn aangebracht binnen de BCT dat de 

systeemkaart en interface geheel beschermd worden door de verzegeling van de BCT. 

2 Logische verzegeling systeemkaart 

De regeling (Artikel 2 Lid 1e) schrijft voor dat de systeemkaart verzegeld 

dient te worden in een ISO-7810 interface. Is het ook toegestaan om dit 

met een logische verzegeling te doen: de BCT herkent onmiddelijk als de 

systeemkaart is uitgenomen en weigert deze vervolgens als hij is 

teruggeplaatst 

3 USB-verlengsnoer 

Het is mogelijk om de BCT uit te voeren op zo'n manier dat hij geheel of 

gedeeltelijk is weggewerkt in de auto. Het is dan denkbaar dat de USBuitgang 

van de BCT ook is weggewerkt en dus niet direct benaderbaar is, 

maar wel (via een verlengsnoer o.i.d.) elders in de auto. Is dit 

toegestaan 

4 Meerdere schermen 

Is het toegestaan om de gegevens van de BCT op meerdere 

beeldschermen te tonen Zo ja, moeten dan alle beeldschermen 

voldoen aan alle eisen in het Protection Profile 

5 Ondernemerskaart op afstand 

Het Protection Profile schrijft voor (in bv P.UITVOEREN_GEGEVENS) dat 

de gegevens vastgelegd in de bedrijfsvergrendeling voor een 

ondernemer slechts mogen worden uitgevoerd als de 

Ondernemerskaart in de BCT wordt geplaatst. 

Voor een groot taxibedrijf is het erg bewerkelijk om deze gegevens 

regelmatig te verzamelen: daarvoor moet iemand met een 

Ondernemerskaart fysiek alle taxis langs. Kan dit ook anders 

6 Andere kaarten 

Is het gestelde in vraag #5 ook geldig voor andere kaarten, zoals de 

Nee. De verzegeling dient fysiek te zijn. Dit is om te voorkomen dat als verschillende 

merken BCTs verschillende vormen van verzegeling gebruiken het denkbaar is dat het toch 

mogelijk is dat een systeemkaart uit het ene merk BCT ongemerkt in een ander merk BCT 

kan worden teruggeplaatst. 

Ja. Hierbij dient wel (bijvoorbeeld via een inspecteurshandleiding) aan de inspecteur 

duidelijk te worden gemaakt dat dit zo is, en hoe hij daar bij de inspectie rekening mee 

moet houden, bijvoorbeeld door te controleren dat het kenteken van de taxi 

overeenstemt met de uitgelezen data. 

Ja, dat is toegestaan. Nee, er hoeft slechts 1 beeldscherm te voldoen aan alle eisen van 

het Protection Profile, mits in de handleiding van de BCT duidelijk is vastgelegd: 

- welk scherm dat is 

- dat de informatie op alle andere schermen slechts informatief van aard is en niet 

noodzakelijk correct of volledig hoeft te zijn 

Ja. Het is ook toegestaan om deze gegevens op afstand uit te lezen, mits daarbij wordt 

geborgd dat dit alleen maar kan worden gedaan via authenticatie via de 

Ondernemerskaart. 

Een oplossing waarbij iemand de Ondernemerskaart vanuit een PC voorzien van een 

kaartlezer gebruikt om bijvoorbeeld via GPRS op afstand in te loggen en zo de 

ondernemersgegevens uit te lezen is expliciet toegestaan. 

Op dit kanaal is artikel 13 van de "Regeling specificaties en typegoedkeuring 

boordcomputer taxi" van toepassing. Bij toepassing van dit kanaal kunnen de 

ondernemersgegevens alleen worden uitgevoerd over hetzelfde kanaal, en niet naar het 

leesvenster, de S.PRINTER of S.BEDRIJFSMIDDELEN. 

Nee. De ondernemerskaart is de enige voor wie dit is toegestaan. Alle andere kaarten 

dienen fysiek te worden ingebracht in de BCT. 




keuringskaart 

7 Vanuit de ondernemer is het wenselijk om bij het in gebruik nemen van 

een reeks van taxi's niet telkens de gegevens van de ondernemer (zoals 

telefoonnummer, landelijk klachtenmeldpunt) handmatig opnieuw op 

elke BCT moet invoeren, maar deze gegevens vanaf een extern 

opslagmedium (b.v. een USB memory stick) kan importeren in een BCT. 

Ja, de additionele gegevens van een taxionderneming die tijdens het instellen van de 

eerste bedrijfsvergrendeling voor die onderneming moeten worden ingevoerd mogen 

vanaf een extern opslagmedium ingeladen worden. 

De regeling BCT - Bijlage 1 - artikel 6.3 BCT-toegangsbeleid noemt in 

FDP_ITC.1 Import van gegevens zonder attributen: FDP_ITC.1.3 De TSF 

dwingt de volgende regels af wanneer gegevens worden ingelezen door 

de TSF: 

De TSF verwerkt gegevens alleen wanneer deze afkomstig zijn 

van: 

o de interne tijdklok van de TSF; 

o de interne verplaatsingsopnemer van de TSF; 

o contact signaal (ignition sense); 

o invoer door de gebruiker via het bedieningspaneel; 

o S.BEWEGINGSOPNEMER; 

o S.POSITIEBEPALINGSSENSOR; 

o S.BOORDCOMPUTERKAARTEN; 

o S.SYSTEEMKAART; 

o S.TAXAMETER. 

Dit lijkt het importeren van ondernemersgegevens vanaf een extern 

opslagmedium uit te sluiten. 

Mogen gegevens van een ondernemer bij het in gebruik nemen van 

taxi's vanaf een extern opslagmedium ingeladen worden 

8 In bijlage 1 staat bij FCS_COP.1.1: 

De TSF zal hash-operaties uitvoeren volgens zowel het SHA-1 en het 

SHA-256 cryptografische algoritme zoals gedefinieerd in de ISO/IEC 

10118-3, FIPS PUB 180-2 en ETSI TS 102 176-1 standaarden. 

Het gebruik van SHA256 of SHA1 is afhankelijk van de certificaten op de 

boordcomputerkaarten en systeemkaarten. 

In bijlage één bij de Regeling specificaties boordcomputer taxi wordt in FCS_COP.1.1 het 

volgende gesteld: “De TSF zal hash-operaties uitvoeren volgens zowel het SHA-1 en het 

SHA-256 cryptografische algoritme zoals gedefinieerd in de ISO/IEC 10118-3, FIPS PUB 

180-2 en ETSI TS 102 176-1 standaarden.”. 

In bijlage twee bij dezelfde regeling in artikel 2.8.1 aangegeven dat “de keuze van het 

algoritme voor de Digest en de Signature afhankelijk [is] van het certificaat op de kaart 




Wij hebben begrepen dat overheidsinstanties per 1 januari 2011 

verplicht zijn om certificaten uit te geven die SHA256 gebruiken i.p.v. 

SHA1. Het lijkt ons daarom niet zinvol om SHA1 te implementeren. 

waarmee de handtekening wordt gezet. Als dit certificaat met ‘RSA met SHA-256’ is 

ondertekend MOET SHA-256 worden gebruik. In de overige gevallen kan met SHA-1 

worden volstaan.” 

In de certificaatprofielen voor gebruik met de Boordcomputer Taxi is gespecificeerd dat 

deze certificaten worden ondertekend met ‘RSA met SHA-256’. SHA-1 wordt voor de 

ondertekening van certificaten niet meer gebruikt. Hieruit volgt dat ook voor de keuze van 

het algoritme voor de Digest en de Signature alleen SHA-256 overblijft. Vanuit dit 

perspectief is het niet nodig om SHA-1 ook te implementeren. 

9 Artikel 6.2 Identificatie en Authenticatie in Bijlage 1 stelt: 

FIA_UAU.1.1 De TSF staat het registreren van de [..] 

O.ARBEIDSTIJDGEGEVENS, O.RITGEGEVENS, [..] 

namens de gebruikersrol ONBEKEND toe, voordat een gebruiker is 

geauthentiseerd. 

Artikel 4, lid 4 definieert de rol onbekend en de bijbehorende 

werkingsmodus: 

De boordcomputer wisselt naar de volgende werkingsmodus afhankelijk 

van het type boordcomputerkaart dat in de kaartinterface is ingebracht 

en koppelt hier een gebruikersgroep aan overeenkomstig de volgende 

tabel: 

Type boordcomputerkaart: Geen 

Werkingsmodus: Operationele modus - Basis 

Gebruikersgroep: ONBEKEND 

Dit is onder andere tegenstrijdig voor O.ARBEIDSTIJDGEGEVENS in het 

volgende artikel: 

Artikel 9 

Lid 1. De boordcomputer registreert in de operationele modus, 

werkingsniveau arbeidstijd, de arbeids-, rij- en rusttijden, bedoeld in de 

artikelen 5:4, tweede en derde lid, 5:6, en 5:9, van de Arbeidstijdenwet 

en de artikelen 2.5:1, 2.5:2, 2.5:3, 2.5:4, 2.5:5, 2.5:6, eerste lid, en 2.5:7, 

In het certificaat is echter ook een zogenaamde subjectKeyIdentifier opgenomen. Dit veld 

wordt gevuld met de SHA-1 hash van de publieke sleutel van het certificaat. Mocht het 

voor de werking van de eigen boordcomputerfunctionaliteit nodig zijn om dit veld te 

gebruiken zal ook SHA-1 geïmplementeerd moeten worden. 

De redactie van FIA_UAU.1.1 is tot stand gekomen om het mogelijk te maken ritten te 

registreren terwijl er geen sprake is van het aanbieden van taxivervoer. Een voorbeeld 

hiervan is door de Belastingdienst aangedragen waarbij een taxibusje wordt verhuurd aan 

een sportvereniging om op zaterdag vervoer mee te plegen. Hoewel dit geen taxivervoer 

is dat onder de regelgeving valt is het vanuit fiscaal oogpunt belangrijk dat niet onmogelijk 

wordt gemaakt dit soort ritten te registreren ook als er geen gebruiker is ingelogd. 

FIA_FAU.1.1 maakt het mogelijk om na het inbrengen van een chauffeurskaart 

(identificatie) maar voor het invoeren van de bijbehorende PIN-code (authenticatie) alvast 

te beginnen met het registreren van gegevens waaronder O.ARBEIDSTIJDGEGEVENS. Voor 

een chauffeur die inlogt met zijn BSN valt het moment van identificatie en authenticatie 

feitelijk samen, waardoor FIA_UAU.1.1 niet van toepassing is. 

Echter, omdat FMT_SMR.2.3 stelt dat de rol BESTUURDER wordt aangenomen nadat de 

chauffeurskaart is ingebracht en geauthenticeerd, en er voor de rol ONBEKEND geen 

arbeidstijd wordt vastgelegd, zal het in de praktijk niet voorkomen dat er 

O.ARBEIDSTIJDGEGEVENS worden vastgelegd voordat authenticatie van de 

chauffeurskaart heeft plaatsgevonden. 




van het Arbeidstijdenbesluit vervoer van de bestuurder en maakt 

daarbij het volgende onderscheid: 

a. rijtijd; 

b. andere werkzaamheden dan rijden; 

c. pauze. 

Dit is onder andere tegenstrijdig voor O.RITGEGEVENS in het volgende 

artikel: 

Artikel 10 

Lid 1. De boordcomputer registreert in de operationele modus, 

werkingsniveau taxivervoer, per rit de 

ritadministratie en draagt zorg voor een aantoonbaar volledige 

registratie. 

Lid 7. In de boordcomputer kan in de operationele modus, 

werkingsniveau taxivervoer, handmatig de 

aanvang en het einde van de rit worden ingegeven en kan worden 

aangegeven of sprake is van 

een beladen of een onbeladen rit. 

Onze aanname is nu dat FIA_UAU.1.1 niet juist is en dat we voor de rol 

ONBEKEND geen O.ARBEIDSTIJDGEGEVENS en/of O.RITGEGEVENS gaan 

registreren. 

10 In bijlage 1 specificeert FAU_ARP1.1 dat de TSF een 

waarschuwingssignaal op het leesvenster geeft als een gebeurtenis 

wordt gedetecteerd. Een gebeurtenis kan ook een Mxxx code zijn (bv 

M003 het inbrengen van een BCT kaart). Het lijkt ons niet zinnig 

meldingen voor Mxxx codes te tonen aan de gebruiker. 

De inhoud van artikel 29.1 prevaleert boven FAU_ARP1.1. Alleen voor de Fxxx en Sxxx 

codes moet een melding getoond worden. Voor de overige gebeurtenissen (Mxxx) mag 

een melding aan de bestuurder gegeven worden. 

FAU_ARP1.1 is ook in tegenspraak met artikel 29.1 waar staat dat 

waarschuwingen getoond moeten worden voor fouten en storingen 

genoemd in artikel 26.2 en 26.4 (alle Sxxx en Fxxx). 

Wij gaan er vanuit dat artikel 26 prevaleert en dat alleen voor de Fxxx 

en Sxxx codes een melding getoond moet worden. 

11 FTA_SSL.2.1 in bijlage 2 stelt dat: 

De TSF zal S.BOORDCOMPUTERKAART toestaan een sessie te blokkeren 

Het blokkeren van een kaartsessie is mogelijk gemaakt om de chauffeur in staat te stellen 

tijdens de sessie zijn chauffeurskaart te gebruiken om zich aan een klant of andere 




door het uitnemen van S.BOORDCOMPUTERKAART zonder dat is 

aangegeven dat de sessie van de gebruiker is beëindigd en als de auto 

zich in de toestand stilstaan bevindt door middel van: 

het wissen van het scherm 

het blokkeren van alle invoerapparatuur behalve die benodigd 

is voor het opheffen van de blokkering 

Onze vraag is of ditzelfde geldt voor een auto die zich in rijdende 

toestand bevindt 

12 Er lijkt een inconsistentie te zitten in de verschillende artikelen rond het 

weergeven van gegevens door de bestuurder: 

persoon te identificeren. Hierbij is de veronderstelling gemaakt dat dit alleen plaatsvindt 

als het voertuig stilstaat. 

Indien de kaart wordt verwijderd als het voertuig rijdt is er geen bezwaar de sessie te 

blokkeren. Echter, vanuit het oogpunt van de verkeersveiligheid kan een sessie slechts 

worden gedeblokkeerd als het voertuig stilstaat. 

De BESTUURDER is op grond van P.UITVOEREN_GEGEVENS in staat om de eigen arbeids-, 

rij- en rusttijden naar het leesvenster uit te voeren. 

Volgens artikel FDP_ACF.1.2 uit bijlage 1 mag de BESTUURDER de eigen 

O.RITGEGEVENS en O.KAARTHOUDERGEGEVENS tonen op een 

leesvenster. 

In bijlage 1 stelt artikel 4.1 Beveiligingsbeleid – 

P.UITVOEREN_GEGEVENS dat een houder van een chauffeurskaart zijn 

eigen arbeids-, rij- en rusttijden naar een leesvenster kan uitvoeren. 

In Artikel 4, vierde lid van de Regeling specificaties en typegoedkeuring 

is beschreven dat type boordcomputerkaart, chauffeurskaart, 

gekoppeld is aan gebruikersgroep BESTUURDER. 

13 Wij hebben een tegenstelling in bijlage 1 gevonden t.o.v. artikel 21 en 

willen dit graag checken. 

FDP_ACT.1.2 kan dan ook gelezen worden als: 

- BESTUURDER mag: 

o de eigen O.RITGEGEVENS, O.ARBEIDSTIJDENGEGEVENS en O.KAARTHOUDERGEGEVENS 

tonen op een leesvenster; 

In aanvulling op hetgeen gesteld in FDP_ACF.1.2 dienen de gegevens die worden genoemd 

in artikel 22, tweede en vijfde lid op verzoek te worden getoond aan iedere gebruiker. 

Artikel 21.2 stelt "op verzoek van de gebruiker toont de boordcomputer 

de identificatie- en activateringsgegevens." 

Artikel 21.3 stelt "Op verzoek van de gebruiker toont de BCT, naast de 

gegevens bedoeld in het eerste en tweede lid, gegevens waarvoor de 

gebruiker geautoriseerd is." 

Wij concluderen hieruit dat de met de gebruiker in artikel 21.2 IEDERE 

gebruiker op de BCT wordt bedoeld (aangemeld of niet aangemeld). Dit 

lijkt ons voor service doeleinden ook wenselijk. 




Bijlage 1 specificeert op 2 plaatsen wie welke gegevens mag tonen: 

- artikel 4.1 P.UITVOEREN_GEGEVENS 

- artikel 6.3 BCT toegangsbeleid / FDP_ACF.1.2. 

In P.UITVOEREN_GEGEVENS wordt niets vermeld over deze gegevens. In 

FDP_ACF.1.2 wel. Hierin staat dat de systeemgegevens alleen door de 

toezichthouder, werkplaats of vervoerder op het leesvenster getoond 

mag worden. Dit is in tegenspraak met artikel 21.2/3. 

Wij gaan er vanuit dat artikel 21.2 hierin leidend is. 

14 In een eerder stadium hebben wij gevraagd wat de mogelijkheden 

waren om de data van de BCT export via een modemverbinding naar de 

server van een ondernemer te brengen. Hierbij is aangegeven dat het 

via een remote authenticatie door de ondernemerskaart het mogelijk is 

om deze gegevens (i.p.v via de USB) via een modemverbinding naar de 

walkant te sturen. Deze optie, gebaseerd op artikel 12 en 13 van de 

regeling) is door ons ook zo in de software geïmplementeerd. Dat wil 

zeggen dat: 

•Alleen via (een remote sessie met) de ondernemerskaart een data 

export van de eigen gegevens gestart kan worden. 

•De data die geëxporteerd wordt alleen de data is die t.b.v. die 

betreffende ondernemer geregistreerd is. 

•Het export bestand voorzien is van een elektronische handtekening. 

In het PP leest Bightsight echter dat alleen de vervoerder de aan hem 

beschikbare gegevens mag lezen en dat deze gegevens daarom via een 

verbinding met encryptie verzonden moeten worden, om te voorkomen 

dat een derde er kennis van neemt. 

Ons inziens wordt met bovenstaande implementatie voldaan aan de eis 

van [pp] FDP_ACF.1.2 omdat dit een eis is die betrekking heeft op de 

toegang tot deze gegevens en niet gaat over het transport van deze 

gegevens. 

De gegevens die door de BCT worden geregistreerd moeten door de vervoerder periodiek 

van de BCT naar de bedrijfsadministratie worden overgehaald. De vervoerder is 

verantwoordelijk voor de verwerking van deze gegevens en de daarbij behorende 

veiligheid ervan. Daarnaast moet regelgeving als de Wbp ook door de vervoerder in acht 

genomen worden. 

De vervoerder heeft twee mogelijkheden om de gegevens naar de bedrijfsadministratie 

over te halen. Hij kan kiezen voor een export middels een USB aansluiting. Deze interface 

is uitvoerig beschreven in de regelgeving. Daarnaast biedt de regelgeving de fabrikant van 

de BCT de mogelijkheid een additioneel kanaal te implementeren voor 

gegevensoverdracht. Hieraan zijn geen directe eisen gesteld, om de fabrikanten de 

mogelijkheid te laten hun eigen oplossing te gebruiken. 

Hoewel dit strikt genomen niet door de regelgeving wordt verplicht, adviseert ILT 

nadrukkelijk om het additionele kanaal te beveiligen, bijvoorbeeld door het te encrypten. 

Hierdoor wordt de vervoerder automatisch in staat gesteld aan zijn verplichtingen rond de 

bescherming van deze gegevens te voldoen. 

Mocht een fabrikant ervoor kiezen om geen beveiligd kanaal aan te bieden dient hij de 

vervoerder via de handleiding op de hoogte te brengen van het feit dat de gegevens 

tijdens de export door derden ingezien zouden kunnen worden. De vervoerder kan dan 

een afweging maken en er bijvoorbeeld voor kiezen om de export van gegevens in het 

voertuig te doen in plaats van op afstand. 




15 Is het toegestaan om de BCT op afstand uit te lezen zonder dat bij elke 

overdracht de ondernemerskaart moet worden gebruikt 

De specificaties van de BCT maken het mogelijk om via een andere verbinding dan de USB 

interface gegevens over te brengen. Op deze overbrenging zijn wel de 

gegevenstoegangsrechten van de bedrijfsmodus van toepassing. Uit vraag 5 van onderdeel 

beveiliging van de veelgestelde vragen volgt dat deze gegevenstoegangsrechten tot stand 

komen door de authenticatie van een ondernemerskaart aan het systeem. Door deze 

authenticatie wordt voldaan aan het uitgangspunt dat een ondernemer zelf de controle 

over de gegevensoverdracht moet hebben. Hij geeft er immers met de ondernemerskaart 

een opdracht toe. Hierdoor kan de boordcomputer vaststellen dat het inderdaad de 

desbetreffende ondernemer is. 

Een dergelijke opdracht kan ook gegeven worden buiten een fysieke verbinding tussen 

ondernemerskaart en boordcomputer, zolang de boordcomputer zelfstandig kan 

vaststellen dat de opdracht door een bepaalde ondernemerskaart is gegeven. Deze 

controle kan worden uitgevoerd als de opdracht door de ondernemerskaart wordt 

getekend. 

Om te voorkomen dat voor elke gegevensoverdracht opnieuw met de ondernemerskaart 

een opdracht moet worden getekend is het toegestaan om een dergelijke opdracht voor 

alle boordcomputers van de desbetreffende ondernemer te gebruiken. 

De getekende opdracht heeft een maximale geldigheidsduur van 5 weken. Hierdoor wordt 

afgedwongen dat een ondernemer periodiek de opdracht tot het overbrengen van de 

gegevens geeft, en daarmee de controle houdt over het proces. Voor de termijn is 

aangesloten bij de termijnen in artikel 19, tweede lid van de Regeling gebruik 

boordcomputer en boordcomputerkaarten. 



Gegevensoverdracht 


1 De XML schemas uit de regeling blijken niet als tekst maar als plaatjes 

zijn opgenomen in de regeling, ook op de website 

(http://wetten.overheid.nl/BWBR0027945/geldigheidsdatum_14-03- 

2011#Bijlage2) 

De XML schema’s zijn gepubliceerd via 

http://ivw.nl/onderwerpen/taxi/boordcomputer_taxi/ 

fabrikanten/specificaties/ 

regeling_specificaties_en_typegoedkeuring_boordcomputer_taxi/ 

Zijn de XML schema's ook beschikbaar in tekst formaat, zodat we ze niet 

over moeten tikken 

2 Bij het exporteren van de gebeurtenissen, artikel 6 uit bijlage 2 van de 

regeling, dienen de gebeurtenissen gegroepeerd te worden per 

vervoerder (op basis van de bedrijfsvergrendeling). De regeling 

vermeldt niet hoe gebeurtenissen die voor de eerste 

bedrijfsvergrendeling hebben plaatsgevonden geëxporteerd moeten 

worden. 

In de functionele berichtstructuur, artikel 6.2 uit bijlage 2 van de 

regeling, wordt het KvK-nummer, het P-nummer en het 

ondernemerskaartnummer vereist. In de opmerkingen wordt niet 

vermeldt dat deze velden, in dit geval, gevuld moet worden met nullen 

(zoals dat bij andere gevallen wel wordt vermeld). 

Klopt onze aanname dat we in dit geval het KvK-nummer, het P-nummer 

en het ondernemerskaartnummer moet vullen met nullen of moeten 

gebeurtenissen voor de eerste bedrijfsvergrendeling niet geëxporteerd 

worden 

3 In de regeling Artikel 23 wordt geëist dat bij het deactiveren alle 

gegevens overgebracht worden naar een externe gegevensdrager. Het 

derde lid van hetzelfde artikel specificeert dat indien op verzoek en de 

authenticatie op basis van een keuringskaart tevens een authenticatie 

op basis van een inspectiekaart heeft plaatsgevonden moeten ook alle 

positiegegevens 

overgebracht worden naar een externe gegevensdrager. 

Artikel 20 lid 3 eist dat er 2 jaar positiegegevens opgeslagen dienen te 

worden. 

Artikel 2.6.1 uit bijlage 2 stelt dat de gebruiker maximaal 1 jaar mag invoeren voor de 

periode waarover een gegevenslevering gaat. Dit zegt niets over de periode waarover de 

gegevens vastgehouden moeten worden. Hooguit betekent dit dat bij het uitvoeren van 

twee jaar aan data dat er ook twee gegevensleveringen moeten worden gemaakt. 

Gedurende de deactivering dienen inderdaad alle gegevens geëxporteerd te worden. Let 

overigens op dat voor de overdracht van de coördinaten buiten een authenticatie met de 

keuringskaart ook een authenticatie met de inspectiekaart nodig is. 

Bij het deactiveren dient de volledige informatie beschikbaar op de boordcomputer veilig 

gesteld te worden. Het is dan ook niet nodig de gebruiker de mogelijkheid te geven om 




Artikel 2.6.1 uit bijlage 2 van de regeling eist dat de maximale export een invoerperiode in te geven. Als de periode langer is dan voor één gegevenslevering is 

periode maximaal 1 jaar is. 

toegestaan dan dient de periode over meerdere leveringen verdeeld te worden. 

Artikel 23 uit de regeling, die eist dat alle gegevens overgebracht 

worden die zijn opgeslagen, lijkt in tegenspraak met wat in artikel 2.6.1 

uit bijlage 2 van de regeling wordt geëist. Deze beperkt de export tot 

maar 1 jaar wat minder is wat opgeslagen kan zijn. 

Klopt onze aanname dat indien, tijden de deactivatie, de 

positiegegevens overgebracht moeten worden naar een externe 

gegevensdrager, de maximale periode eis van 1 jaar niet van toepassing 

is 

Artikel 2.6 uit bijlage 2 stelt: 

"Om een gegevenslevering tot stand te laten komen, stelt de 

boordcomputer de houder van een boordcomputerkaart in staat om: 

a. zich met de boordcomputerkaart te authenticeren; 

b. de externe gegevensdrager met de overbrengingsinterface van de 

boordcomputer te verbinden; 

c. op de boordcomputer één of meerdere gegevensleveringen te 

selecteren. Standaard zijn alle gegevensleveringen waarvoor de 

gebruiker is geautoriseerd geselecteerd; 

d. op de boordcomputer een periode in te voeren waarover gegevens 

opgevraagd moeten worden voor de betreffende gegevenslevering(en). 

[...]" 

De opties die c en d bieden zijn in tegenspraak met het gestelde in 

artikel 23, die eist dat bij deactiveren altijd alle gegevens overgebracht 

moeten worden 

naar een externe gegevensdrager. 

Klopt daarnaast de aanname dat het gestelde in artikel 2.6 item c en d 

niet van toepassing zijn en altijd alle gegevens geëxporteerd moeten 

worden bij een deactivatie 




4 Bijlage 2 van de regeling specificeert dat bij de export van Chauffeurs 

data een begin en eind periode wordt meegenomen. Zowel in de 

geëxporteerde XML als in de naamgeving van het bestand. Het is 

onduidelijk welke waarden hiervoor gebruikt moeten worden aangezien 

er altijd maar een Chauffeur kaart data element uitgevoerd kan worden. 

Artikel 17, lid 15 van de regeling impliceert dat alleen de huidige 

gegevens van de chauffeurskaart geëxporteerd kunnen worden en niet 

de gegevens van een 'andere' periode. 

Welke periode moet er gehanteerd worden bij het exporteren van de 

chauffeurskaart data 

De methodiek rond het exporteren van de chauffeurskaartdata is gelijk aan bij de overige 

exports. Per gegevenslevering wordt aangegeven wat het begin en einde van de periode is 

waar de geëxporteerde data betrekking op heeft. 

De chauffeurskaartdata die moet worden geëxporteerd is de EF.Driver_Activity_Data (zie 

toelichting b van artikel 8.1 van bijlage 2 van de regeling specificaties). Deze data bevat 

datumtijd informatie over de records die erin zijn opgenomen. In het exportbericht zal 

moeten worden opgenomen de begin-datumtijd van het eerste record, en de einddatumtijd 

van het laatste record. Zie voor de opbouw van de EF.Driver_Activity_Data de 

“Technische specificaties gebruik boordcomputer- en systeemkaarten” op 

http://ivw.nl/Images/Technische%20specificaties%20gebruik%20BCT-kaarten_tcm247- 

277899.pdf 

5 In specificatie van alle export bestandsnamen in bijlage 2 van de 

regeling staat een spatie tussen de "DatumtijdBeginPeriode" en 

"_DatumtijdEindePeriode". 

Bijvoorbeeld: 

Chauffeurskaartdata_BSN_Chauffeurskaartvolgnummer- 

DatumtijdSamenstellenBericht_DatumtijdBeginPeriode 

_DatumtijdEindePeriode.xml. 

Is dit een typefout of is dit met opzet 

6 In Artikel 3.2 van bijlage 2 van de regeling specifieert de "Functionele 

berichtstructuur" van de ritadministratie. Hier staat ATA ipv (naar 

verwachting) DATA. Verder wordt nergens ATA gespecificeerd. Klopt dat 

hier DATA had moeten staan 

7 Fiscale Labels 

De brancheorganisatie Koninklijk Nederlands Vervoer Taxi, de 

Belastingdienst en een aantal fabrikanten van de boordcomputer taxi 

hebben in april van dit jaar een convenant ondertekend, met als doel 

uniforme en kwalitatieve wijze van vastlegging van gegevens in de 

boordcomputer taxi te garanderen, ten behoeve van fiscaal gebruik. 

Hiervoor is een aanvullende fiscale gegevens set gedefinieerd welke 

beschreven is in bijgevoegd document. 

De bestandsnamen dienen zonder spatie samengesteld te worden. De kennelijke spatie 

voor _DatumtijdEndePeriode moet dan ook worden genegeerd. 

Het klopt dat de D is weggevallen. Er hoort hier DATA te staan. 

De ILT heeft bij de verschillende fabrikanten van een BCT navraag gedaan naar de impact 

van het uitbreiden van de rittenadministratie.xsd. Hierbij bleek dat deze impact voor een 

aantal partijen te groot is om op dit moment een wijziging te kunnen rechtvaardigen. 

De Belastingdienst treedt naar aanleiding van het met KNV afgesloten convenant met de 

verschillende fabrikanten in overleg om de voor de fiscus relevante gegevens op een 

uniforme manier ter beschikking te kunnen stellen. 




Door dit label toe te voegen aan de Ritadministratie.xsd zullen de 

integriteit en authenticiteit van de gegevens gewaarborgd blijven, een 

van de eisen van het convenant. Zou het mogelijk zijn om in de 

Ritadministratie.xsd een extra element op te nemen om dit label te 

faciliteren 

8 Opmerking bij Rit 

Een veelgevraagde functie is het kunnen plaatsen van een opmerking bij 

het afsluiten van een rit door de chauffeur, op een manier zodat de 

opmerking onderdeel wordt van de Ritadministratie.xsd en de 

integriteit en authenticiteit van de opmerking gewaarborgd blijft. Zou 

het mogelijk zijn om in de Ritadministratie.xsd een extra element op te 

nemen 

Zie antwoord op vraag 7. 

Het heeft onze voorkeur dit binnen de ritadministratie.xsd te doen 

zodat ook de inspectiediensten deze informatie kan inzien. Bij de 

huidige handgeschreven rittenstaat is er ook ruimte voor de chauffeur 

om opmerkingen te plaatsen en die kunnen erg waardevol zijn voor 

chauffeur, ondernemer en inspectie. Bijv als er fouten zijn gemaakt met 

de bediening van de BCT kan de chauffeur dit ook precies melden op de 

rittenstaat. 

9 In bijlage 2 van "Regeling specificaties en typegoedkeuring 

boordcomputer taxi", Artikel 2.8.1 en 2.8.2 wordt de opbouw van een 

XML exportbericht respectievelijk een tekenbericht beschreven. Er is bij 

ons onduidelijkheid over de exacte interpretatie hiervan. 

Is het mogelijk, voor de éénduidigheid, om van beide berichttypen een 

consistent voorbeeld te geven, d.w.z. een XML bericht met geldige 

DigestValue, SignatureValue en X509Certificate elementen 

10 Is er verificatiesoftware beschikbaar om het xades export bestand te 

controleren 

11 Bijlage 2 Artikel 5.6 Integriteit gegevens stelt: 

“Het bericht ‘Coördinaten’ wordt ondertekend met een elektronische 

handtekening van de boordcomputer. De afzonderlijke coördinaten 

worden niet ondertekend.” 

ILT heeft ervoor gekozen om geen voorbeeld bestanden beschikbaar te stellen. Hiervoor is 

gekozen om te voorkomen dat de ontwikkeling van de exportberichten alleen plaatsvindt 

op basis van het (beperkte) voorbeeld en niet op de onderliggende standaarden. 

Om een zelf gegenereerd exportbericht te valideren kan gebruik gemaakt worden van de 

software als beschreven in antwoord 10. 

ILT stelt geen software beschikbaar om het xades bestand te controleren. Echter, omdat 

het bericht dient te voldoen aan de XadES standaard kan het worden gevalideerd met in 

de markt beschikbare tooling. Een voorbeeld van dergelijke tooling is de XML Security 

Library die via http://www.aleksey.com/xmlsec/ kan worden verkregen. 

Er is gekozen om ieder vastgelegd coördinaat in het bericht ‘Coördinaten’ (artikel 5 van 

bijlage 2) niet afzonderlijke te voorzien van een handtekening omdat dit een enorme extra 

hoeveelheid vast te leggen data teweeg zou brengen. De integriteit van de data wordt 

geborgd door een logische opeenvolging van vastgelegde coördinaten. 




De coordinaten.xsd heeft geen voorziening voor een handtekening 

geformuleerd in de functionele en technische berichtstructuur. Hoe 

moeten wij nu de integriteit gaan waarborgen 

Wij gaan er vanuit dat de handtekening en het boordcomputer 

certificaat toevoegt moeten worden aan coordinaten.xsd. Is dit juist en 

is dit vergeten 

Over welke inhoud moet de handtekening berekend worden, alleen 

over de data (inhoud van de xml elementen) of moet over het gehele 

xml bericht een handtekening gezet worden 

12 “Artikel 6 

Lid 3. De positiegegevens, bedoeld in het tweede lid, bevatten ten 

minste de volgende gegevens: 

a. de coördinaten; 

b. of er een positie bepaald is; 

c. het aantal satellieten op basis waarvan de positie van de auto bepaald 

is; 

d. de HDOP-waarde uitgedrukt in een getal tussen nul en vijftig; 

e. het tijdstip van de positiebepaling” 

Het bericht ‘Coördinaten’ wordt, net als de overige berichten, als onderdeel van een 

exportbericht uit de boordcomputer overgebracht. Dit exportgericht wordt wel 

ondertekend en is gespecificeerd in artikel 2.8 van bijlage 2. 

Artikel 6, derde lid, geeft de eisen aan waaraan de positiegegevens dienen te voldoen die 

door de positiebepalingsensor aan de boordcomputer worden geleverd. Onder andere op 

basis van de kwaliteitskenmerken van de positiegegevens in onderdeel b t/m d dient de 

boordcomputer in staat te zijn vast te stellen of er wordt voldaan aan het gestelde in 

artikel 6, vierde lid. 

Voor de gegevenslevering zijn deze kwaliteitskenmerken niet van belang. In het 

exportbericht dienen inderdaad alleen de gegevens uit artikel 6, derde lid, onderdeel a en 

e opgenomen te worden. 

Uw aanname is dan ook correct. 

Kijkend naar de coordinaten.xsd zijn alleen a en e opgenomen als 

attributen voor de GEGEVENSLEVERING. Onze aanname is dat de 

overige gegevens niet nodig zijn voor de GEGEVENSLEVERING en zullen 

dan ook niet geregistreerd worden. 

Is deze aanname correct 

13 Er is vastgelegd dat er bestanden met data van maximaal 1 jaar 

geëxporteerd kunnen worden. Voornamelijk de positiegegevens export 

kan een groot bestand opleveren (na de-activatie en 4 ogen principe). Is 

het toegestaan om bij de export van bijv een compleet jaar de XML 

bestanden te exporteren op weekbasis. Dus voor iedere week een apart 

bestand. Uiteraard binnen de gestelde snelheidseisen. Dan zal er dus op 

de USB stick een bestand per week worden gezet. 

Artikel 2.6.1 van bijlage 2 van de Regeling specificaties en 

Een gegevenslevering over een bepaalde periode bestaande uit meerdere delen moet 

echter wel aan dezelfde snelheidseis voldoen als een gegevenslevering over dezelfde 

periode bestaande uit één deel. 

Voorbeeld: stel dat een gegevenslevering over de periode van een jaar 52 Mbyte groot is, 

te weten 1 Mbyte per week. Indien de levering in een enkel bestand wordt gedaan mag 

daar maximaal 10+(49*3) = 157 seconden over gedaan worden. Het hanteren van de 

snelheidseis waarbij het overbrengen van 52 bestanden van 1 Mbyte 520 seconden in 




typegoedkeuring boordcomputer taxi geeft aan aan welke eisen de beslag neemt, is niet toegestaan. 

periode van gegevenslevering dient te voldoen. 

In dit artikel wordt gesteld dat de periode waarop een levering van 

toepassing is maximaal één jaar mag bedragen. Het opbreken van een 

dergelijke periode in meerdere bestanden is niet expliciet niet 

toegestaan. 

14 In de specificatie van de onderzoek xsd in bijlage 2 lezen wij dat NmFb NmFb moet inderdaad van het type String zijn in plaats van positiveInteger. 

een positiveInteger moet zijn. 

Dit lijkt ons niet correct. Wij nemen aan dat dit een string moet zijn. 

15 In bijlage 2, artikel 7.3 technische berichtenstructuur, zien wij dat het 

opmerkingen veld ontbreekt bij het periodiek onderzoek. In de xsd is 

het wel vermeld, dus gaan wij ervan uit dat dit veld aanwezig behoort te 

zijn. 

“Opm” is ten onrechte weggevallen als onderdeel van het periodieke onderzoek. Zowel 

“ActiveringsOnderzoek” als “PeriodiekOnderzoek” zijn van het type “Onderzoek”, waar 

“Opm” deel van uitmaakt. 

16 De beschrijving van het technische berichtstructuur te vinden in Artikel 

6.3 wijkt af van de elementen gebruikt in het XSD bestand: 

Gebeurtenis.xsd. Het gaat om het attribuut: 

Functionele berichtstructuur: Gebeurtenis volgnummer 

Technische berichtstructuur: GbVgNr 

Daarbij komt in de XSD beschrijving het element Gebeurtenis 

volgnummer niet voor. Deze lijkt weggevallen te zijn. 

In het XSD bestand Gebeurtenis.xsd dient inderdaad gebruik gemaakt te worden van het 

element GbVgNr in plaats van VgNr. 

Daarnaast komt in het XSD bestand het element GbVgNr zoals 

beschreven als technische berichtstructuur niet voor, maar wordt 

gebruik gemaakt van VgNr. Dit klopt niet en zou volgens ons GbVgNr 

moeten zijn. 

17 In bijlage 2, Artikel 3.7.1 Naamgeving is de bestandsnaam van de 

ritadministratie gespecificeerd. Deze bevat het onderdeel "Kenteken". 

Aangezien kenteken in de xsd als een string met lengte 6 is 

gespecificeerd nemen wij aan dat dit ook voor de bestandsnaam het 

geval is. 

18 Wij zien een conflict in de regeling m.b.t. de km stand. Artikel 7 

specificeert dat de km stand met een nauwkeurigheid van tenminste 

100 meter wordt bijgehouden. 

Deze aanname is juist. 

Uit de specificaties van het exportbericht blijkt dat de kilometerstand uit een heel getal 

bestaat. De kilometerstand van de BCT dient voor exportdoeleinden afgerond te worden 

op het dichtstbijzijnde hele getal. De nauwkeurigheid van de kilometerstand in de BCT 




blijft tenminste 100 meter. 

In bijlage 2 worden de KM standen gespecificeerd als non negative 

integers. Betekent dit dat in de export op hele kilometers afgerond 

dient te worden 

19 Uit onze testen komt een onduidelijkheid naar voren met de volgorde 

van D en M records in de ritadministratie. 

Situatie: 

1. start handmatig op de BCT 3x een contractrit (zitplaatsverhuur) 

2. Stop de rit die het eerst is gestart 

3. Annuleer het stoppen van de eerste rit 

Artikel 3.5 in bijlage 2 specificeert dat ritten in oplopende volgorde van 

volgnummer in de ritadministratie export file opgenomen moeten 

worden. Is dat ook vereist voor de D en M records of is het toegestaan 

deze in volgorde van optreden in te voegen 

20 In het xml schema van de ritadministratie is momenteel de coördinaat 

beginpunt rit een verplicht element (zie bijlage 2 artikel 3.2). 

Er zijn situaties te bedenken waarbij er geen coordinaat beginpunt 

bekend is. Bijvoorbeeld als een rit wordt gestart zonder GPS (in een 

garage), en die start rit weer wordt geannuleerd. Op dat moment 

komen er twee records in de gegevenslevering terecht en voor beiden is 

geen coordinaat beginpunt bekend. 

Wat dient er in dit geval voor het LocBeg element in de ritgegevens te 

worden ingevuld Of is het mogelijk dit element toch optioneel te 

maken in het xsd 

De regeling schrijft niet specifiek voor hoe om te gaan met de volgorde van de D en M 

records. Zowel het groeperen van de aanvullende D en M ritinformatie op basis van 

volgnummer als op basis van volgorde van optreden is toegestaan. 

Conform artikel 10, vierde lid van de Regeling specificaties en typegoedkeuring 

boordcomputer taxi dient een ontbrekend coördinaat te worden aangevuld zodra de 

positiegegevens beschikbaar komen. Er wordt niet voorgeschreven hoe deze 

functionaliteit in te vullen, zolang de coördinaten uiteindelijk op de voorgeschreven wijze 

in het exportbericht worden opgenomen. 

Zijn de coördinaten na vijf minuten nog steeds niet beschikbaar treedt daarmee een 

foutsituatie op. Wordt gedurende die foutsituatie een rittenstaat export gestart mag het 

LocBeg element met nullen worden uitgevuld. 

21 Bij de functionele certificering is er een inconsistentie gevonden tussen 

bijlage 2 en de xsd file voor coördinaten. 

Het exportbericht Coordinaten bevat alle coördinaten die door de boordcomputer zijn 

vastgelegd. Omdat een ingeschakelde boordcomputer minimaal eens per minuut een 

coördinaat vastlegt zal het exportbericht in praktische zin altijd coördinaten bevatten. De 




In bijlage2 artikel 5.2 staat voor het COORDINAAT element een 

cardinaliteit van 0..* (i.e. 0 of meer elementen). Functioneel element 

COORDINAAT mapt op technisch element COORD. 

opmerking over de inconsistentie tussen de beschrijving in bijlage 2 en de xsd file is 

terecht, maar zal in de praktijk niet tot problemen leiden. 

In het XSD voor coördinaten is het element COORD gedefinieerd als: 

 

Dit zegt dat er minimaal 1 en mogelijk meer elementen geregistreerd 

moeten worden. Dit is in tegenspraak met Bijlage 2 artikel 5.2. 

22 Op pagina 40 van het document “Regeling specificaties en 

typegoedkeuring boordcomputer taxi” staat onder andere het volgende 

beschreven (tabel): 

Deze aanname is correct. Alleen daar waar expliciet in de XSD opgenomen is het gebruik 

van Base64 encoding verplicht. 

“De volgende algoritmen worden voor het genereren van het 

exportbericht gebruikt: 

Encoding: Base64 

Op pagina 43 van het hierboven genoemde document staat een 

processchema beschreven dat het mogelijke proces weergeeft voor het 

tekenen van de gegevens en het exportbericht. Aangezien gesproken 

wordt over het mogelijke proces, is onze aanname dat deze manier van 

het tekenen van gegevens niet leidend is en hiervan afgeweken mag 

worden. We hebben er dan ook voor gekozen om niet alles met de 

codering Base64 op te slaan. 

De voornaamste reden om niet alles met Base64 encoding op te slaan is 

dat deze manier extra ruimte en processorkracht vereist van onze BCT. 

Aangezien wij op een zo efficiënt mogelijke manier gebruik willen 

maken van de hardware van onze BCT hebben wij gekozen om deze 

mogelijke implementatie niet op te nemen. 

We zullen wel Base64 encoding toepassen op de elementen van de XML 

gegevensleveringen welke gespecificeerd zijn in het XSD hiervan, maar 

niet over de gehele exportbericht (envelope). 




Graag vernemen we dat onze aanname correct is. 



Interface Taxameter 


1 Er wordt gesproken over taxameter-koppeling met een RS422-protocol. Dit 

kan ik niet meer terugvinden in de laatste versie Is RS422 vervallen 

In de discussies over de conceptregeling die IVW de afgelopen periode met de fabrikanten 

heeft gehad bleek een sterke voorkeur voor het RS232 protocol boven RS422. Hierop is de 

generieke taxameterkoppeling in de regeling aangepast, om tegemoet te komen aan de 

wensen van de fabrikanten. 

2 In bijlage 3 van de Regeling wordt een generieke taximeter-interface 

voorgeschreven. 

In EIS-AL-1 en EIS-FI-1 (artikel 2.2 en 2.3) staat dat het een RS-232- 

verbinding moet zijn, terwijl EIS-FI-8 t/m -10 (in art. 2.3) een differentiële 

RS-422 verbinding bepalen. 

Moet een RS-232 interface aanwezig zijn conform EIS-AL-1/EIS-FI-1 of een 

RS-422 interface conform EIS-FI-8 t/m -10 

3 Een BCT heeft een RS232 poort voor het aansluiten van een externe 

taximeter. Indien de BCT zelf voorzien is van een geactiveerde taximeter 

mag deze poort dan gebruikt worden voor andere doeleinden Deze poort 

kan in de software geconfigureerd worden dus als de klant later toch een 

externe taximeter wil gebruiken dan kan de configuratie worden 

aangepast dat deze poort weer een externe taximeter poort wordt. 

4 In het protocol voor de taximeter interface in bijlage 3 wordt gebruikt 

gemaakt van een CRC voor de foutcontrole voor de dataverzending. In EIS- 

LI-8 staat dat het gaat om een 16 bits CRC-CCITT met als polynoom x16 + 

x12 + x5 + 1. 

Binnen deze specificaties lijken nog verschillende varianten te zijn. 

Bijvoorbeeld of de initiële waarde 0x0 of 0xFFFF moet zijn. De waarde 

0xFFFF lijkt hier de de-facto standaard / meest gebruikte waarde te zijn. 

Kunnen jullie bevestigen dat dit de juiste keuze is 

5 Wij hebben een vraag over de specificatie van A_RITBEDRAG in artikel 

2.4.3.6 van bijlage 3. 

Dit bericht bevat het veld TARIEF_AANTAL. Onze veronderstelling is dat dit 

veld altijd een waarde > 0 moet hebben omdat een taximeter altijd een 

tarief moet aangeven in een ritbedrag. 

Er dient een RS-232 interface aanwezig te zijn. Zie hiervoor de vernieuwde bijlage 3 bij de 

regeling. Deze is als apart document op 

http://www.ivw.nl/onderwerpen/taxi/boordcomputer_taxi/fabrikanten/ 

specificaties/regeling_specificaties_en_typegoedkeuring_boordcomputer_taxi/ 

gepubliceerd. 

De regelgeving vereist dat de BCT een interface voor de taxameter als beschreven in 

bijlage 3 beschikbaar heeft. 

Dit impliceert dat op ieder moment een daartoe geschikte taxameter op deze interface 

moet kunnen worden aangesloten. Zolang dit gewaarborgd blijft kan de poort ook voor 

andere doeleinden worden gebruikt. 

De waarde 0xFFFF is inderdaad de te gebruiken waarde. De reden hiervoor is de volgende: 

“The CRC is preset to all 1's to detect errors involving a loss of leading zero's.” 

Het bericht A_RITBEDRAG is het antwoord op het bericht VR_RITBEDRAG, dat bedoeld is 

om het ritbedrag op te vragen. Het zou kunnen voorkomen dat de functiestand op het 

moment van opvragen ‘vrij’ is. In dat geval is er geen sprake van een ritbedrag, en ook niet 

van toegepaste tarieven in dat ritbedrag. 

Het kan dus voorkomen dat het veld TARIEF_AANTAL een waarde van 0 bevat. 

6 In artikel 2.4.3.6 van bijlage 3 komen de attributen RIT_VERTREKTIJD en Artikel 10, vijfde lid stelt het volgende ¨De boordcomputer neemt de prijs van het vervoer 




RIT_AANKOMSTTIJD voor. Zijn we ‘verplicht’ om de attributen 

RIT_VERTREKTIJD en RIT_AANKOMSTIJD te gebruiken voor de ritregistratie 

van BCT of mogen we de datum en tijd gebruiken van de BCT zelf 

per rit en eventuele toeslagen over uit de in de auto aanwezige taxameter.¨ De datum en 

tijd worden niet uit de taxameter overgenomen. Met de elementen RIT_VERTREKTIJD en 

RIT_AANKOMSTTIJD uit het bericht A_RITBEDRAG kan worden gecontroleerd of het 

betreffende ritbedrag hoort bij de rit in kwestie. 



Typegoedkeuring 


1 In het pakket van eisen van de BCT staat o.m. dat voor certificering de BCT 

moet voldoen aan de normen NEN-ISO-10605 (ESD test), NEN-IEC-IEC- 

60068-2-1 Cold, NEN-IEC-IEC-60068-2-2 Dry heat, NEN-IEC-IEC-60068-2-30 

Cyclic Damp Heat test. Daarbij wordt alleen de norm gesteld en geen 

specifieke criteria. De normen laten echter ruimte voor een specifieke 

invulling. 

De fabrikant heeft voor de ESD test de volgende criteria bepaald en vraagt 

of deze voor de RDW acceptabel zijn.: 

NEN-ISO-10605 (ESD test) 

Met: 

ESD contact ontladingen met 8kV 

ESD lucht ontladingen met 14kV 

Performance criteria C 

Test 1 

Standard 

High Temp 

Operational 

Duration 

Dry heat test 

IEC 60068-2-2 test Bd 15%RH 

+ 70 0C 

Yes, after climate stabilization 

16 hrs 

Welk niveau moet voor EDS testen worden gebruikt (Regeling artikel 30 lid 1) 

Minimum Severity level waarbij wordt getest en Functional Status level waaraan moet 

worden voldaan is: 

ESD test volgens 

NEN-ISO-10605 Vooralsnog Severity level III. Onderzocht wordt of moet worden 

bijgesteld naar level IV. 

Met: 

ESD contact ontladingen met 

ESD lucht ontladingen met 

Functional Status Classification 

7 kV 

14 kV 

A 

Aan welk test type en welke minimale tijdsduur moet worden voldaan bij de testen 

benoemd in artikel 30 lid 2 en 3 van de Regeling 

Voor de genoemde testen geldt de hieronder vermelde tijdsduur en test type : 

Cold test, Dry heat test en Damp heat, cyclic test 

IEC 60068-2-1 volgens testtype Ad 16 uur 

IEC 60068-2-2 volgens testtype Bd 16 uur 

IEC 60068-2-30 volgens testtype Db 24 uur 6cycli 

Test 2 

Standard 

Low Temp 

Operational 

Duration 

Cold test 

IEC 60068-2-1 test Ad 

-20 0C 

Yes, after climate stabilization 

16 hrs 

Test 3 

Cyclic Damp Heat test 

Standard IEC 60068-2-30 test Db 

Climate 12 hrs +25 °C/ 95%RH & 12 hrs +40 °C/ 95%RH 

Operational No 

Cycle Time 24 hrs 

Cycles 6 




2 Het beeldscherm van een boordcomputer raakt tijdens de instralingstest 

verstoord. De frequentiebereiken (in MHz) waarin dit plaatsvindt zijn 

grofweg als volgt, 24V/m, 1kHz AM modulatie: 

107-122 

192-258 

550-1259 

Zowel voor horizontale als voor verticale polarisatie van het veld. Sterkste 

effecten treden op bij verticale polarisatie. 

De metingen blijven correct, echter het display wordt onleesbaar. Is dit 

acceptabel 

De complete boordcomputer taxi moet worden typegoedgekeurd op basis van Richtlijn 

72/245/EG na verwerking van Richtlijn 2004/104/EG. Er is sprake van aantasting van de 

immuniteitsfuncties zoals gedefinieerd in 72/245/EG artikel 2.1.12 

c) ‘functies die bij storing verwarring teweegbrengen bij de bestuurder of andere 

weggebruikers’. 

e) ‘functies die bij storing een invloed hebben op de wettelijk verplichte gegevens van het 

voertuig, bv. die van de snelheidsmeter en de kilometerteller’. 

De BCT valt daarmee onder de immuniteitsfuncties. 

Dergelijke storingsgevoeligheid biedt de mogelijkheid tot moedwillige verstoring met als 

doel de gebruiker of de handhaver te misleiden. De BCT is bedoeld als handhavingsmiddel. 

Eén van de vormen van handhaving is de handhaving langs de weg, waar de handhaver 

gegevens van de BCT afleest t.b.v. handhaving. Als het op een eenvoudige manier mogelijk 

is om een dergelijk controle te storen voldoet de BCT niet langer aan de doelstellingen 

ervan. Daarnaast voldoet een BCT waarvan het scherm niet af te lezen is niet langer aan 

de eisen uit art. 21, eerste, tweede en derde lid van de Regeling specificaties en 

typegoedkeuring. 

3 Voor de typegoedkeuring verzoekt de fabrikant om de eisen uit artikel 30 

lid 4 en 5 te certificeren op basis van de reeds uitgevoerde ISO7637 testen 

als onderdeel van de R10/Rev4. 

De BCT moet in het licht van bovenstaande worden afgekeurd. 

Het voldoen aan de eisen in artikel 30 lid 4 en 5 kan worden aangetoond met genoemde 

testen en waar mogelijk ook op basis van design review. 

Artikel 30 

4. De boordcomputer is beveiligd tegen kortsluiting, overspanning 

en polariteitomkering. 

5. De boordcomputer is bestand tegen kortstondige onderbrekingen 

of voedingspanningvariaties die worden veroorzaakt door het starten van 

de auto. 

In verband met de aanvraag E-markering heeft de fabrikant in overleg met 

de technische dienst het goed functioneren in een "onvriendelijke 

voertuigomgeving” laten testen volgens ISO 7637-2004. Naar de mening 

van de fabrikant zijn de eisen uit de Regeling specificaties en 

typegoedkeuring boordcomputer taxi, artikel 30 lid 4 en 5 op de volgende 

wijze af te dekken: 




Lid 4 door de volgende ISO 7637 testen: 

- kortsluiting: puls 1, 2b 

- overspanning: puls 2a 

- polariteitomkering: puls 1 

Lid 5 

puls 4 test 

4 In Bijlage 3 van de Regeling technische eisen boordcomputer staan een 

aantal vraag- en antwoordberichten genoemd. Het blijkt nu dat bij 

fabrikanten niet alle vraagberichten uitgestuurd worden. De reden 

daarvoor is dat zij met het antwoord niets doen in de BCT. Het gaat hier 

voornamelijk om de VR_TOTALEN en de VR_TAXAMETER_INFO. 

Hoe dient daar bij de certificeringstesten mee omgegaan te worden 

Graag uitleg over achtergronden met betrekking tot voorgeschreven 

berichtgeving VR_TOTALEN, VR_TAXAMETER_INFO (Artikel 2.4.3. Eisen 

aan de berichtstructuur) en de ‘Prioriteit en afhankelijkheid van eisen’ 

(artikel 2.5) van bijlage 3 in de Regeling. 

5 Een BCT bestaat uit twee delen: een BU (basis unit) en GU (Gebruikers 

Unit). De GU is een “kleine” user interface. De BU bevat het overgrote deel 

van de functionaliteit. Beide zijn onderling verbonden met een kabel. 

Daarbij vormt de BU de interface tot de auto en randapparatuur (o.a. 

voeding, tacho-puls en printer). 

Zoals opgenomen in de toelichting bij de Regeling Specificaties en Typegoedkeuring: 

“Bijlage 3 beschrijft een uniforme, open uitgang, ten behoeve van de koppeling van de 

boordcomputer aan een willekeurige taxameter. Zo wordt mogelijk gemaakt dat 

taxameters op een vrij gemakkelijke en eenduidige manier aan de boordcomputer 

gekoppeld kunnen worden. Dit vraag overigens wel om een op deze ingang aangepaste 

taxameter. 

Indien deze ingang achterwege gelaten zou worden bestaat het risico dat er op de 

Nederlandse markt vanwege de inrichting van de boordcomputer uitsluiting plaatsvindt 

van bepaalde taxameters.” 

De verschillende vraag- en antwoordberichten zijn opgesteld om een uniforme koppeling 

met een daartoe geschikte taxameter mogelijk te maken. Artikel 2 schrijft onder eerste lid, 

onderdeel i voor dat een boordcomputer onder andere bestaat uit een interface voor de 

taxameter als beschreven in bijlage 3. Hieronder vallen ook de genoemde berichten, los 

van het feit of zij in deze specifieke implementatie gebruikt worden. Een boordcomputer 

die niet voldoet aan de eisen uit bijlage 3 kan niet als BCT aangemerkt worden, het 

apparaat voldoet immers niet aan alle eisen. 

Met de prioriteit van de eisen in artikel 2.5 is getracht aan te geven welke eisen leidend 

zijn. Er is goed voor te stellen dat de logische eisen prima invulbaar zijn zonder gebruik te 

maken van een RS-232 interface. Door de prioritering van eisen wordt discussie 

voorkomen. 

De EMC test kan niet worden uitgevoerd op uitsluitend het RS-232 interface gedeelte. De 

boordcomputer zal in zijn geheel in de test moeten worden betrokken. Wanneer de 

boordcomputer bestaat uit een basis unit en gebruiksunit die via een interface met elkaar 

zijn verbonden en het één kan niet zonder het ander functioneren, dan betreft het geheel 

de boordcomputer taxi en dient het geheel te worden typegoedgekeurd. 




De vraag betreft de e-markering: kan de GU worden beschouwd als niet 

direct verbonden met het voertuig In dat geval wordt volstaan met een e- 

markering voor de BU en een CE markering voor GU+BU. Dit is beschreven 

in automotive directive 2004/104/EC paragraaf 3.2.1: “connected via an 

interface type approved to this directive as amended”.

Veelgestelde vragen fabrikanten Boordcomputer Taxi - Inspectie ...

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?