Veelgestelde vragen fabrikanten Boordcomputer Taxi. Algemeen

Veelgestelde vragen fabrikanten Boordcomputer Taxi

Algemeen # 1

Vraag Waar worden de specificaties voor de Boordcomputer Taxi beschikbaar gesteld?

2

Worden de specificaties vertaald naar het Engels?

3

Wanneer verwacht de Inspectie VenW de boordcomputer kaarten voor de fabrikanten beschikbaar te hebben?

Antwoord 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 Nee, niet door de Inspectie Verkeer en Waterstaat. 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

Versie 1.9

De testreferentiekaarten zijn beschikbaar en kunnen worden besteld via: [email protected]. 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

pagina 1/48

Datum: 15-5-2013

Veelgestelde vragen fabrikanten Boordcomputer Taxi #

Vraag voertuig zit, maar een printer een overbodige investering lijkt:

Antwoord 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.

5

Is het mogelijk om het ritbewijs (de printer) achterwege te laten bij ritten zonder een directe financiele transactie? 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.

Versie 1.9

pagina 2/48

Datum: 15-5-2013

Veelgestelde vragen fabrikanten Boordcomputer Taxi Specificaties # 1 2

3 4

Vraag Mag de GPS sensor ook een externe module zijn van de Boordcomputer Taxi? Mag de additionele software gebruik maken van bijvoorbeeld voorgeschreven functionaliteiten zoals de GPS sensor?

Met welke frequentie vindt de periodieke opslag van GPS coördinaten door de Boordcomputer Taxi plaats? 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?

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

Versie 1.9

Antwoord Ja dat mag, mits er voldaan wordt aan de gestelde kwaliteitseisen voor de Boordcomputer Taxi. 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. Conform artikel 7 lid 6 van de regeling registreert de Boordcomputer de coördinaten met een interval van één maal per minuut. 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. 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

pagina 3/48

Datum: 15-5-2013


Vraag koppelen, tijdelijk uit de taxi te halen en vervolgens bij een volgend gebruik weer terug te plaatsen?

9

Moet het op de BCT, naast BSN, ook mogelijk zijn handmatig op basis van een NI nummer het werkingsniveau arbeidstijd in te schakelen? 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.

10

11

12

Wordt er voldaan aan de gestelde eisen als de BCT deze waarschuwing (met bevestiging) toont bij het opstarten nadat de spanningsonderbreking is hersteld? 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? 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.

13

Is het juist dat "alleen gegevens die zijn vastgelegd behorende bij de

Versie 1.9

Antwoord 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. Ja, het NI nummer moet kunnen worden gebruikt om het werkingsniveau arbeidstijd in te schakelen. Ja, de waarschuwing kan worden getoond nadat de spanningsonderbreking is hersteld.

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. Ja, alle gegevens die voor een ondernemer zijn vastgelegd, in één of meerdere

pagina 4/48

Datum: 15-5-2013


14

15

16

Vraag actieve bedrijfsvergrendeling" (artikel 12 lid 2) betekent "alleen gegevens die zijn vastgelegd op een moment dat de huidige bedrijfsvergrendeling, of een eerdere bedrijfsvergrendeling van dezelfde vervoerder, actief was"? 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? 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. Wat is de definitie van "de staat" in deze eis? Met "de staat" wordt bedoeld de toestand waarin de boordcomputer zich bevond op het moment dat de stroomonderbreking optrad.

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

Nee, de volledige inhoud van de chauffeurskaartdata dient aan de ondernemer van de actieve bedrijfsvergrendeling beschikbaar gemaakt te kunnen worden.

Met “de staat” wordt bedoeld de toestand waarin de boordcomputer zich bevond op het moment dat de stroomonderbreking optrad.

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.

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'?

17

18

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. 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? Art 17 lid 2: De boordcomputer negeert ingebrachte ongeldige boordcomputerkaarten.

Versie 1.9

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

pagina 5/48

Datum: 15-5-2013


Vraag 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; 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.

Antwoord begonnen of reeds is verstreken; 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.

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.

19

20

Zijn deze interpretaties / aannames correct? 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? 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

Versie 1.9

pagina 6/48

Datum: 15-5-2013


Vraag

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.

Antwoord kunnen corrigeren. 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.

22

23

24

Is het standaard plaatsen van "-" en "R" toegestaan, zodat alleen numerieke input ingevoerd hoeft te worden bij activatie? Hoeven zowel de ingevoerde bandenmaat als de effectieve omtrek alleen in de BCT worden opgeslagen en op verzoek te worden uitgevoerd?

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? 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

Versie 1.9

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.

pagina 7/48

Datum: 15-5-2013


Vraag 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.

Antwoord

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?

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/).

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.

26

27

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. Onze oplossing zal bestaan uit een gecertificeerde BCT die voldoet aan

Versie 1.9

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. 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. Volgens FDP_ITC.1.3 verwerkt de TFS alleen gegevens als deze afkomstig zijn van o.a.

pagina 8/48

Datum: 15-5-2013


Vraag 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.

Antwoord 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.

Daarom verzoeken wij toe te staan dat een BESTUURDER (indien

Versie 1.9

pagina 9/48

Datum: 15-5-2013


29

Vraag 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. 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.

30

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? Artikel 4 lid 8 stelt dat het mogelijk moet zijn voor een chauffeur om in te loggen met zijn/haar BSN nummer.

Antwoord

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.

Scenario 2. Het invoeren van een chauffeurskaart / werkplaatskaart / ondernemerskaart terwijl een BSN sessie actief is.

31

Volstaat het om de BSN sessie af te breken, een nieuwe sessie te starten voor de desbetreffende kaart? 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

Versie 1.9

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.

pagina 10/48

Datum: 15-5-2013


32

33

34

Vraag 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. 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? 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. In bijlage 1, artikel 6.3, FDP_ACF.1.2 staat dat de vervoerder basis-,

Versie 1.9

Antwoord

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.

De redactie van het artikel is wat ongelukkig met betrekking tot de systeemgegevens.

pagina 11/48

Datum: 15-5-2013


35

Vraag arbeidstijd-, rit-, bedrijfs-, kaarthouder-, gebeurtenis- en systeemgegevens mag tonen. Hierbij wordt de restrictie opgelegd dat deze gegevens gedurende de eigen bedrijfsvergrendeling geregistreerd moeten zijn. 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. 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 ?

Versie 1.9

Antwoord Deze gegevens worden in de BCT ingebracht voordat er sprake is van een bedrijfsvergrendeling en dienen beschikbaar te zijn binnen elke bedrijfsvergrendeling.

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.

pagina 12/48

Datum: 15-5-2013

Veelgestelde vragen fabrikanten Boordcomputer Taxi # 36

37

Vraag 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) 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)".

Antwoord 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.

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.

38

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. 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

Versie 1.9

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

pagina 13/48

Datum: 15-5-2013


39

Vraag 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. 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. 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. Wij verwachten dat dit nummer dezelfde eigenschappen heeft als het BSN nummer ( 8 of 9 cijfers, voldoet aan 11-proef).

Antwoord werkmappen bij te houden waar de verschillende vervoerders kopieen van ontvangen. 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. 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

Versie 1.9

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)

pagina 14/48

Datum: 15-5-2013


41

42

43

Vraag van de registratie van arbeids-, rij-, en rustijden. Indien onze aanname niet klopt dan horen we graag hoe dit wel gelezen moet worden. 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. 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. Wat wordt bedoelt met de werkelijke positie in artikel 6.4?

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

Versie 1.9

Antwoord

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.

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. 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

pagina 15/48

Datum: 15-5-2013


44

45

Vraag 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. 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? 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? 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.”

Antwoord onder a).

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:

Versie 1.9

pagina 16/48

Datum: 15-5-2013


46

Vraag 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. 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).

Versie 1.9

Antwoord

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.

pagina 17/48

Datum: 15-5-2013


Vraag 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.

Antwoord 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.

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.

47

Onze aanname is dat de cardinaliteit niet 1..2 moet zijn, maar 1..n moet zijn. Minimaal 1 AUTO registratie en geen maximum aangeven. 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?

Versie 1.9

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.

pagina 18/48

Datum: 15-5-2013


Vraag

Antwoord

Dit is een vreemd theoretisch scenario, maar we willen dit graag correct kunnen afhandelen en registreren.

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.

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. Onze voorkeur en aanname is dat de derde optie de meest passende en nette oplossing biedt.

Versie 1.9

pagina 19/48

Datum: 15-5-2013

Veelgestelde vragen fabrikanten Boordcomputer Taxi Kaartspecificaties # 1

Vraag Welke eisen worden er aan de cardreaders voor de BCT gesteld?

2 3

Zijn de kaartstructuur documenten ook in het Engels beschikbaar? In de kaartspecificatie op hardware nivo wordt onderscheid gemaakt tussen class A, class B en class C voor de 'operating conditions'.

4

Dit bepaald de voedingsspanning waarop de kaarten werken. Waar wordt uitsluitsel gegeven over de 'class' waarin de boordcomputerkaarten vallen? 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 Start werk 9:00:00 '0' B

Versie 1.9

Antwoord 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. Nee, de specificaties zijn alleen in het Nederlands beschikbaar 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. 2. 2b. 3. 4.

Invoer voorgaande werkzaamheden "Start werk" om 8:30 Corrigeren, met invoer "start pauze" 8:00 Invoer “Start werk” om 8:45 Login 9:00 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.

pagina 20/48

Datum: 15-5-2013


Vraag 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?

Antwoord Start werk 8:30:00 '1' B Start Pauze 8:00:00 '1' B Start werk 8:45:00 '1' B Login 9:00:00 '0' B Start werk 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

9

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? Kan een blokkade van de PIN opgeheven worden op systeemreferentiekaarten?

Versie 1.9

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.

pagina 21/48

Datum: 15-5-2013


11

12 13

14

Vraag 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"? Waar zijn de snelheidseisen die gesteld zijn aan de BCT kaarten te vinden? De aanname die we hebben gedaan is dat de transportkey op de pinmailer van de systeemkaart gelijk is aan de transportkey1. Klopt deze aanname? Hoe wordt vanuit de transportkey op de pinmailer van de systeemkaart op de KS.KENC en KS.KMAC gekomen? 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? 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.

Antwoord 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.

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

Versie 1.9

pagina 22/48

Datum: 15-5-2013


Vraag een digitale handtekening?

Antwoord

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

15

16

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? 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) 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.

Versie 1.9

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.

pagina 23/48

Datum: 15-5-2013


Vraag

Antwoord

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.

17

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. 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

Versie 1.9

pagina 24/48

Datum: 15-5-2013


Vraag ‘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.

Antwoord

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

Versie 1.9

pagina 25/48

Datum: 15-5-2013


Vraag 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.

Antwoord

• 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?

Versie 1.9

pagina 26/48

Datum: 15-5-2013

Veelgestelde vragen fabrikanten Boordcomputer Taxi Beveiliging # 1

2

3

4

Vraag 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? 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? 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? 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

Versie 1.9

Antwoord 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.

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.

pagina 27/48

Datum: 15-5-2013


Vraag keuringskaart? 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.

Antwoord 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.

8

Mogen gegevens van een ondernemer bij het in gebruik nemen van taxi's vanaf een extern opslagmedium ingeladen worden? 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.

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.”.

Het gebruik van SHA256 of SHA1 is afhankelijk van de certificaten op de boordcomputerkaarten en systeemkaarten.

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

Versie 1.9

pagina 28/48

Datum: 15-5-2013


Vraag 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.

Antwoord 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,

Versie 1.9

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.

pagina 29/48

Datum: 15-5-2013


10

Vraag 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. 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.

Antwoord

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).

11

Wij gaan er vanuit dat artikel 26 prevaleert en dat alleen voor de Fxxx en Sxxx codes een melding getoond moet worden. FTA_SSL.2.1 in bijlage 2 stelt dat: De TSF zal S.BOORDCOMPUTERKAART toestaan een sessie te blokkeren

Versie 1.9

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

pagina 30/48

Datum: 15-5-2013


12

Vraag 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? Er lijkt een inconsistentie te zitten in de verschillende artikelen rond het weergeven van gegevens door de bestuurder:

Antwoord persoon te identificeren. Hierbij is de veronderstelling gemaakt dat dit alleen plaatsvindt als het voertuig stilstaat.

Volgens artikel FDP_ACF.1.2 uit bijlage 1 mag de BESTUURDER de eigen O.RITGEGEVENS en O.KAARTHOUDERGEGEVENS tonen op een leesvenster.

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;

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.

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.

13

In Artikel 4, vierde lid van de Regeling specificaties en typegoedkeuring is beschreven dat type boordcomputerkaart, chauffeurskaart, gekoppeld is aan gebruikersgroep BESTUURDER. Wij hebben een tegenstelling in bijlage 1 gevonden t.o.v. artikel 21 en willen dit graag checken.

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.

Versie 1.9

pagina 31/48

Datum: 15-5-2013


Vraag

Antwoord

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.

14

Wij gaan er vanuit dat artikel 21.2 hierin leidend is. 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.

Versie 1.9

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.

pagina 32/48

Datum: 15-5-2013


Vraag Is het toegestaan om de BCT op afstand uit te lezen zonder dat bij elke overdracht de ondernemerskaart moet worden gebruikt?

Antwoord 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.

Versie 1.9

pagina 33/48

Datum: 15-5-2013

Veelgestelde vragen fabrikanten Boordcomputer Taxi Gegevensoverdracht # 1

2

Vraag 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-032011#Bijlage2) Zijn de XML schema's ook beschikbaar in tekst formaat, zodat we ze niet over moeten tikken ? 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.

Antwoord De XML schema’s zijn gepubliceerd via http://ivw.nl/onderwerpen/taxi/boordcomputer_taxi/ fabrikanten/specificaties/ regeling_specificaties_en_typegoedkeuring_boordcomputer_taxi/

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).

3

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? 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.

Versie 1.9

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

pagina 34/48

Datum: 15-5-2013


Vraag Artikel 2.6.1 uit bijlage 2 van de regeling eist dat de maximale export periode maximaal 1 jaar is.

Antwoord een invoerperiode in te geven. Als de periode langer is dan voor één gegevenslevering 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?

Versie 1.9

pagina 35/48

Datum: 15-5-2013


Vraag 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?

5

6

7

In specificatie van alle export bestandsnamen in bijlage 2 van de regeling staat een spatie tussen de "DatumtijdBeginPeriode" en "_DatumtijdEindePeriode". Bijvoorbeeld: Chauffeurskaartdata_BSN_ChauffeurskaartvolgnummerDatumtijdSamenstellenBericht_DatumtijdBeginPeriode _DatumtijdEindePeriode.xml. Is dit een typefout of is dit met opzet? 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? 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.

Versie 1.9

Antwoord 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_tcm247277899.pdf 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.

pagina 36/48

Datum: 15-5-2013


8

9

10

11

Vraag 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? 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? 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. 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? Is er verificatiesoftware beschikbaar om het xades export bestand te controleren?

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.”

Versie 1.9

Antwoord

Zie antwoord op vraag 7.

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.

pagina 37/48

Datum: 15-5-2013


12

Vraag

Antwoord

De coordinaten.xsd heeft geen voorziening voor een handtekening geformuleerd in de functionele en technische berichtstructuur. Hoe moeten wij nu de integriteit gaan waarborgen?

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.

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? “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”

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.

13

Is deze aanname correct? 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

Versie 1.9

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

pagina 38/48

Datum: 15-5-2013


14

15

16

Vraag typegoedkeuring boordcomputer taxi geeft aan aan welke eisen de 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. In de specificatie van de onderzoek xsd in bijlage 2 lezen wij dat NmFb een positiveInteger moet zijn. Dit lijkt ons niet correct. Wij nemen aan dat dit een string moet zijn. 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. 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

Antwoord beslag neemt, is niet toegestaan.

NmFb moet inderdaad van het type String zijn in plaats van positiveInteger.

“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. In het XSD bestand Gebeurtenis.xsd dient inderdaad gebruik gemaakt te worden van het element GbVgNr in plaats van VgNr.

Daarbij komt in de XSD beschrijving het element Gebeurtenis volgnummer niet voor. Deze lijkt weggevallen te zijn.

17

18

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. 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. 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.

Versie 1.9

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

pagina 39/48

Datum: 15-5-2013


Vraag

Antwoord 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.

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.

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

20

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 ? 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.

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.

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?

21

Bij de functionele certificering is er een inconsistentie gevonden tussen bijlage 2 en de xsd file voor coördinaten.

Versie 1.9

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

pagina 40/48

Datum: 15-5-2013


Vraag 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.

Antwoord 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: <xs:element name="COORD" maxOccurs="unbounded">

22

Dit zegt dat er minimaal 1 en mogelijk meer elementen geregistreerd moeten worden. Dit is in tegenspraak met Bijlage 2 artikel 5.2. 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).

Versie 1.9

pagina 41/48

Datum: 15-5-2013


Vraag Graag vernemen we dat onze aanname correct is.

Versie 1.9

Antwoord

pagina 42/48

Datum: 15-5-2013

Veelgestelde vragen fabrikanten Boordcomputer Taxi Interface Taxameter # 1

Vraag Er wordt gesproken over taxameter-koppeling met een RS422-protocol. Dit kan ik niet meer terugvinden in de laatste versie? Is RS422 vervallen?

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-232verbinding moet zijn, terwijl EIS-FI-8 t/m -10 (in art. 2.3) een differentiële RS-422 verbinding bepalen.

3

4

5

6

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? 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. In het protocol voor de taximeter interface in bijlage 3 wordt gebruikt gemaakt van een CRC voor de foutcontrole voor de dataverzending. In EISLI-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 ? 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. In artikel 2.4.3.6 van bijlage 3 komen de attributen RIT_VERTREKTIJD en

Versie 1.9

Antwoord 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. 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. Artikel 10, vijfde lid stelt het volgende ¨De boordcomputer neemt de prijs van het vervoer

pagina 43/48

Datum: 15-5-2013


Vraag 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?

Versie 1.9

Antwoord 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.

pagina 44/48

Datum: 15-5-2013

Veelgestelde vragen fabrikanten Boordcomputer Taxi Typegoedkeuring # 1

Vraag 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-IEC60068-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

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 Standard Climate Operational Cycle Time Cycles

Cyclic Damp Heat test IEC 60068-2-30 test Db 12 hrs +25 °C/ 95%RH & 12 hrs +40 °C/ 95%RH No 24 hrs 6

Versie 1.9

Antwoord 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 7 kV ESD lucht ontladingen met 14 kV Functional Status Classification 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

pagina 45/48

Datum: 15-5-2013


Vraag 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?

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.

Antwoord 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. 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:

Versie 1.9

pagina 46/48

Datum: 15-5-2013


Vraag

Antwoord

Lid 4 door de volgende ISO 7637 testen: - kortsluiting: puls 1, 2b - overspanning: puls 2a - polariteitomkering: puls 1

4

Lid 5 puls 4 test 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.

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.

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).

Versie 1.9

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.

pagina 47/48

Datum: 15-5-2013


Vraag

Antwoord

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 emarkering 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”.

Versie 1.9

pagina 48/48

Datum: 15-5-2013

Veelgestelde vragen fabrikanten Boordcomputer Taxi. Algemeen

Recommend Documents